У меня есть база данных, определенная поставщиком (всего около 140 ГБ) на Caché 2007. Она использует старую среду программирования MUMPS и обращается к глобальным элементам напрямую в иерархическом стиле. Существует один глобальный, на который приходится около 75% общего объема базы данных. Первый индекс в этой таблице представляет собой номер набора искусственных целых чисел. Следующие 2-3 подстроки являются постоянными идентификаторами подзадачи, которые разбивают блоки полей и обозначают повторяющиеся типы подзаголовков.Глобальное сопоставление одного индекса в другой базе данных
Один из этих повторяющихся субрекордов (тип записи 30) предназначен для заметок в учетной записи. Из-за способа использования системы этот размер учитывает очень большую часть общего пространства глобальной сети; Я бы оценил это как минимум на 50%. Из-за того, как Caché физически хранит данные в базе данных, сканирование этого глобального заканчивает загрузку всех или большинства этих заметок в качестве побочного эффекта, даже если они не имеют отношения к большинству операций. Это приводит к значительному увеличению стоимости операций ввода-вывода в глобальном масштабе, особенно когда вам требуется только одна крошечная деталь из множества учетных записей.
Пример: подстрочные ссылки на этом глобальный:
^ACCT(3461,10,1)="SOME^DATA"
^ACCT(3461,10,2)="MORE^DATA"
...
^ACCT(3461,30,1)="NOTE1 blah blah"
^ACCT(3461,30,2)="NOTE2 blah blah"
...
^ACCT(3461,30,100)="NOTE100 blah blah"
Я не могу изменить дизайн базы данных. Он контролируется внешним поставщиком, и в базе данных имеется большое количество жестко заданных ссылок MUMPS. Я думаю, что большая причина того, что пакетные операции настолько медленны в системе, объясняется высокой стоимостью этих в основном нерелевантных заметок, идущих вперед для поездки IO, когда доступны данные учетной записи. Сканирование всего этого глобального (т. Е. Когда нет полезного индекса поддерживаемого приложения) занимает не менее 8 часов.
Мысль о переносе данных примечаний из соседних других деталей в глобальном формате в отдельный файл базы данных с использованием средства глобального сопоставления, описанного в Guide to Using Caché Globals и Guide to System Administration. Если бы я мог сопоставить все индексы 30s с отдельным файлом базы данных в одной и той же базе данных Caché, большинство операций с данными (те, которые даже не заботятся о заметках) не приведут их в память вместе с деталями, которые они действительно заботятся около.
В руководстве по глобальной структуре (1-я ссылка) это выглядит правдоподобным, так как они показывают конкретное отображение второго индекса отдельно, чем 1-й подстрочный индекс. То, что они не показывают ни в одном из примеров, является синтаксисом, чтобы это произошло. На экране «Добавить новое глобальное картирование» в портале управления Caché, я должен быть в состоянии сделать что-то вроде
Global name: ACCT
Subscripts to be mapped: (BEGIN:END)(30)
Но то, что вариации я стараюсь в синтаксисе, я всегда получаю ERROR #657: Invalid subscript in reference 1 subscript #1.
StackExchange сведению : Этот вопрос, возможно, лучше подходит для dba.stackexchange.com, но там, по-видимому, есть нулевые вопросы Intersystems, и я не думаю, что это привлечет внимание.
Когда вы говорите «из-за того, как Caché хранит данные в базе данных» - знаете ли вы ссылку на это? Я могу задать вопрос, если хотите. – psr
Если вы перейдете к одной из разделов в разделе «Руководство по использованию Caché Globals» в разделе «Как хранятся глобальные блоки». В целом данные хранятся в дереве B +, упорядоченном по глубине индекса. –