В 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 должно быть разумным.
у.... кофе мало выпил, ерунду написал. Глобал, таблица, здесь же они близнецы братья.

Sergei ObrastsovГлавное здесь - уход от "длинной структуры" вида ^Data(i1,i2,i3...i10)ок, попробуем.

Большая просьба от владельца триальной версии (у нее размер кэша 2М если я не ошибаюсь)

Попробуйте пожалуйста запустить на комерческой версии вложенный тест и отпостите (или на stpl@mail.ru) пожалуйста строку со временем выполения и желательно с некоторыми параметрами железа, по крайней мере память,процессор.

Спасибо! а результаты любопытные. Я думал на коммерческой версии будет быстрее за счет большего кэша (а так результаты эквивалентные видимо за счет более быстрого процессора) и странно что чтение получилось дольше записи. (У меня на триале существенно быстрее записи)

я думал что обращение к "соседним" элементам массива будет покрываться кэшем и поэтому расчитывал на более быстрое чтение из массива.

ОК, спасибо

Всем спасибо!

увы, пока отказался от Caché. Возможно я чтото не понимаю в этой жизни, но ч.б. сделать нужную мне "модель" мне придется заниматься обычным программированием на каше. Мне кажется для этого есть более подходящие языки программирования.
А использовать Caché только для хранения многомерных данных довольно накладно.
В общем на мой взгляд Caché и COS в частности это средство не программирования а работы с данными (пусть даже это объекты), и для моих данных я не нашел в каше готовой поддержки, а программировать ее на COS рука не поднимается.

Sergei Obrastsov Stplувы, пока отказался от Caché. Возможно я чтото не понимаю в этой жизни, но ч.б. сделать нужную мне "модель" мне придется заниматься обычным программированием на каше. Мне кажется для этого есть более подходящие языки программирования.
Более подходящие для чего? Для работы с данными? Очень сомневаюсь в этом. :)
скорее для вычислений. Например нужен алгоритм для какогото расчета по имеющимся в базе данным. Извелечь данные Caché может лучше всех. А дальше мне надо написать код вычислений. Так вот этот код как раз писать на COS мне и не хочется (а вынести это в другой слой приложения тоже не получится т.к. он д.б. в непосредственной близости к данным изза постоянной работы с ними)

Sergei Obrastsov Stpl
В общем на мой взгляд Caché и COS в частности это средство не программирования а работы с данными (пусть даже это объекты), и для моих данных я не нашел в каше готовой поддержки, а программировать ее на COS рука не поднимается.
Ну, что тут скажешь? Каждый привык к чему-то своему. Кому-то готовые решения подавай, а кто-то и сам их создает.
вот мне и придется самому их создавать. И если это задача для программирования, то и язык имхо должен быть языком программирования а не скриптом.
Впрочем уверен что тот кто много лет работает с Caché скажет что там можно сделать все.
Может он даже будет прав. Но тогда мне в команду нужен такой человек.
хм... поспрашивать чтоли...

LittleCatНа COS действительно можно реализовать любой алгоритм обработки этих данных, и единственное, что может помешать этому - быстродействие полученной программы (подобные системы изначально не предназначались, например, для сложных математических вычислений). Но это преодолимо, есть прекрасный механизм - CallIn, программа обработки может быть написана например на С, и Cache в этом варианте занимается единственным делом, хранит и предоставляет данные.
ну вот еще один из пробелов ознакомления, я на это не обратил внимания. Посмотрю.

Stpl
Хотелось бы понять, чем скрипт отличается от языка программирования, чтобы сделать вывод, что такое COS :-)
имхо скрипт это то что не компилируется в выполнимый код. Одна из побочных проблем скриптов и COS в частности это невозможность полного синтаксического контроля при компиляции. Думаю список может быть длинным, а я про наболевшее :)

в целом у меня серьезных вычислений нет. Взамен стоит задача расчета/аггрегации данных многомерном массиве. Это можно описать примерно так:
многомерная матрица с деревьями на гранях/размерностях и работа с ней (хранение и быстрый многопотоковый доступ).
Быстрое выявление зависимых и зависящих ячеек. При этом зависимости
строятся комбинацией деревьев размерностей + дополнительными связями отдельно
накладываемыми на матрицу.
Стоит еще учитывать такое свойство дерева как наличие или отсутствие данных в узлах.
Из всего пространства этой матрицы и зависимостей вычисляется непустое
(оптимизированное) на данный момент множество с которым будет вестись основная
работа.
При изменении непустых ячеек "меняются" непустые зависимые.
При добавлении/удалении данных меняется оптимизированное пространство.
Дальше уровень агрегирования данных позволяющий вычислять данные для узлов
на основании дерева зависимостей и свойств узлов/листьев (например унарные операторы) а также заданной степени агрегации (для исключения взрывного роста объемов)

Т.е. арифметика то простая, а все остальное обычное программирование.

Hampster-MumpsterСтанислав, предложение посетить "подвальчик на В.О." остается в силе :) Возможно, Вы найдете здесь недостающую вам готовую поддержку.как насчет завтра? сейчас отпишусь Алексею мылом.

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