В Cache' есть прекрасная вещь – многомерные массивы.
Они мне прекасно подходят для хранения кэшированных расчетных данных в таком варианте:
^Data(dim1,dim2,dim3,….dim10)
Массив разряженный, кол-во возможных елементов по "первым" трем-четырем размерностям около 1000, еще нескольким размерностям - несколько сотен, оставшиеся - несколько десятков.
В массиве предполагается хранить double+int+int

Чего можно ожидать от доступа к такому массиву? Приличной производительности или полных тормозов?
Может быть есть рекомендации для таких случаев? Например не более X размерностей если кол-во елементов >Y или чтото еще?
Спасибо,Стас

или это случай когда надо брать обычный Persistent класс и строить bitmap индексы?
Если да какой порядок разницы в производительности ожидать по сравнению с массивом?

Sergei ObrastsovСомнительно, что необходима такая глубина. Обычно 4-5 - уже предел, глубже лезть нет смысла.
Не забывай, что добираться до нижних уровней придется через верхние, а это ненавидимые всеми
р-субдшниками (sic!) вложенные циклы, не очень удобно. :)

имхо у меня не совсем так: логика построения значений индекса для доступа к массиву всеравно отдельная. Т.е. вызывать ^Data(1000,500,1) или ^Data(33,800,999) определяется отдельной "бизнес:)логикой" и какими средствами она расчитывает индексы сейчас не так важно.
меня больше интересует эффективность доступа к тому что я записал в массив т.е.
set ^Data(1000,500,1)=DataItem
...
$Data(^Data(1000,500,1),DataItem)

Или такой подход совсем неверный?

Sergei ObrastsovНеплохо было бы посмотреть что за данные, может подсказал бы другой вариант.

не хочется загружать конкретными проблемами, это скорее задача для пилота от Intersystems :)
с OLAP вы знакомы на уровне общих представлений? Если да то могу попробовать описать в их "терминах", это наверное немного удобнее.

Sergei Obrastsov
Что то double, int и прочего, нет в M типизации,
и в объектах она ложная, можно конечно паковать через $zl, $zw, но ведь и распаковывать
придется. :)
сорри: %Double, %Integer
я планировал писать в массив объекты простого класса например:


Доступа к ^Data "извне" не будет. бизнес-слой будет спрашивать значение у другого класса, который:
- определяет индексы для запрошенных данных
- провереяет наличие их в ^Data
- если их еще нет, или они помечены как устаревшие то считывает их "перебирая" ^Data() для зависимых данных и записывает результат тудаже в ^Data.

При изменении исходных данных (в другом классе) срабатывает или триггер или например %OnAfterSave которые для всех данных зависящих от измененных и существующих в ^Data выставляют флажок Dirty (моя пропертя) и записывает изменный DataItem в ^Data

Это совсем криво или не очень?

Sergei Obrastsov автор
Они мне прекасно подходят для хранения кэшированных расчетных данных в таком варианте:
^Data(dim1,dim2,dim3,….dim10)

Это кто писал? :) В данном варианте получается 10 уровней, что несколько пугает.

я писал:)
Да, в этом примере 10 уровней для организации глобала ^Data.

Sergei ObrastsovЯ же говорю, это "ложная" типизация. На самом деле все пишется символьной строкой.
а, ну да... не привык еще.

Sergei Obrastsov
Все-таки интересно было бы посмотреть на предполагаемые структуры.

CASE средствами увы не пользуюсь, а ч.б. выслать как-есть... пока еще нечего...
полные классы пока еще не рисовал т.к. борюсь с азами и синтаксисом.
Если вкратце "на словах". Объекты справочники - они же размерности в терминах olap:
OrgTree, AcountsTee,ProductsTree,BusinessTree,UserTree,... - это деревья по структуре: классы вероятно с parent-child Relationship "на себя" (обычное SQL решение, похоже в каше готовой поддержки нету. Наверное сделаю для них базовый классик с поддержкой нужных функций дерева)
Currencies,DataLevels,AccountingPeriods,...- классы для "обычных плоских" таблицы со своими пропертями
Основная таблица данных или фактов: класс с пропертями ID для каждой размерности (например OrgID, AccountID, Date, ….) и данными Value,Currency,…
ну и вспомогательные таблички типа ExchangeRates.
Если бы это было на олап моторчике то былабы еще размерность времени с несколькими иерархиями: Year-HalfYear-…. Year-Week-…. И т.п. Здесь встрою ее как есть внутрь расчетной части

^Data я предполагал как массив с доступом по полной комбинации всех ключевых размерностей, например ^Data(OrgID,AccountID,Date,….).

Это конечно не ответ на заданный вопрос но словесное описание нижнего слоя, надеюсь это обясняет почему в ^Data хочется много уровней. Дальше я еще не готов.... освоение целины продолжается

MX -- ALEX Stpl
Это совсем криво или не очень?

совет кашиста - рецидивиста

быстро сделайте основу программы без деталей и бантиков как угодно
но на рабочих реальных данных и запустите

затем вносите поправки уточнения по скорости
в узких местах

часто тормоз не там где думали
пытаюсь.... медленно получается ;) в смысле не пишется очень медленно :)

Sergei ObrastsovЭто конечно всего лишь вариант "развешивания по веткам", но принцип надеюсь понятен.

конечно понятен но не подходит. Данные в ^Data мне нужны на пересечении всех размерностей. Т.е. данные за AccountID=1 сами по себе не имеют смысла, они появляются только когда определены все остальные размерности Date,OrgID и т.д.
А этот вариант подошелбы например для реализации олаповских запросов по неполным размерностям, там действительно можно спросить данные например только по одной размерности, при этом для всех остальных будет принято некоторое дефолтное значение. Но мне это сейчас не нужно, я подбираю хранение результата на пересечении всех размерностей/индексов.

Например HyperIndex из этой области, но я думал попытаться обойтись глобалом т.к. данных не так уж и много. и я полагал что простой глобал быстрее таблицы пусть даже с bitmap индексами

Sergei ObrastsovПлохой совет. :(
Обычно это приводит к неуклюжей программе/комплексу, который больше половины своего
времени тратит на создание промежуточных массивов, только из-за того, что структуры
не были продуманы изначально. Не надо давать такие советы новичкам, плохих программ
и без этого полным-полно.
Я в защиту MX -- ALEX! Я сейчас "плохо видеть и говорить на M, COS и т.п." и одним теоретическим проектированием тут мне не обойтись, нужны эксперименты, и как раз именно сейчас. потом будет поздно потому что их небыло вначале :)

Sergei ObrastsovЭксперименты конечно нужны, но нельзя подходить к программе таким способом, дескать главное начать, а потом поправим. К сожалению, на практике оказывается, что поправлять бывает поздно и приходится уже идти начатым путем. Сколько раз на вопрос "А почему через ж...?" приходилось слышать грустный ответ "Ну вот, так получилось, возвращаться уже поздно было". Посему совет: лучше просидеть на старте больше положенного, зато получить удобные структуры.
абсолютно согласен. только я как раз на старте и сижу. причем похоже еще гдето в раздевалке :| но это мои проблемы...

Sergei Obrastsov
Получить данные по Date (я правильно полагаю что это дата?) можно только уже имея OrgID и
AccoutID. Ну а если необходима разбивка по датам? А если нужен конкретный диапазон дат?

тогда мы работаем с датами спустившись к ним по Org и Account.
А ^Data("d",Date) вроде мне ничего не даст т.к. мне туда и записать то ничего.
Можно конечно пойти по пути ^Data("OrgID,AccountID",Date) но это тогда скорее обычная таблица с составным ключем.
Sergei Obrastsov
Stpl
Например HyperIndex из этой области, но я думал попытаться обойтись глобалом т.к. данных не так уж и много. и я полагал что простой глобал быстрее таблицы пусть даже с bitmap индексами
HyperIndex - вещь конечно хорошая, но не стоит забывать об объемах. Особенно на больших массивах данных и уж тем более
при bit-slicing. Ну вот такой пример: при 200,000,000 записей в БД получаем 3125 chunks
по 64,000 бит на одно значение. Я не уверен, что это разумный подход.
наверное, но для таких количеств говорить о глобалах наверное тоже неразумно?

Sergei Obrastsov Stplтогда мы работаем с датами спустившись к ним по Org и Account.

А потом группируем по датам в другом массиве? :)
Stpl
А ^Data("d",Date) вроде мне ничего не даст т.к. мне туда и записать то ничего.

Да ну? А ^Data("d",Date,Org,Account) не получится? :)

а в чем тогда выигрыш по адресации к отдельным элементам?
если я правильно понял это нам дает возможность легко пройти по всем Date+Org или по Date независимо то Org и Account. Т.е. первыми вершинами дерева взять даты и использовать это при нарезке по датам. но дальше мне ведь надо искать нужные Org и Account.
Т.е. как я понимаю ^Data("d", ^Data("o"... могут понадобится как дополнительные глобалы а не как замена ^Data(Org,Account,Date)
Или я никак не пойму чтото главное?

Sergei ObrastsovСерьезно?! Это еще почему?! Прекрасно все работает и для больших количеств :)
Просто использование bitmap должно быть разумным.
у.... кофе мало выпил, ерунду написал. Глобал, таблица, здесь же они близнецы братья.