Стас,

А OLTP система на чем сделана?

Что касается реализации хранилищ данных и OLAP-систем, то на Cache' такие системы есть.
Посмотрите презентацию BitMap-индексы (С появлением BitMap-индексов можно более эффективно разрабатывать аналитические приложения на Caché. На занятии вы получите теоретические знания и получите практический опыт использования BitMap-индексов и приложения HyperIndex).

Очень стоит посмотреть на систему HyperIndex. Это свободно распространяемая система для создания витрин данных.
В архиве есть подробная документация.
Она позволяет добавить BI-функциональность к OLTP приложению на Cache'.

Есть коммерческие OLAP-системы на базе Cache' (Speedminer,...).
С данными в Cache' можно работать из OLAP-систем 3-х фирм (Cognos, BO, ...).

Перед тем как начинать что-то разрабатывать, советую прочитать пару статей про Cache', посмотреть как устроен объектный и прямой доступ.
Лучше всего дополнительно сходить на семинар Cache' Entree и пообщаться с консультантами InterSystems.

Данных, чтобы точно сказать, стоит делать Вашу систему на Cache' или нет пока недостаточно.


Успехов, Вадим

dials VadimFСтас,

А OLTP система на чем сделана?

Что касается реализации хранилищ данных и OLAP-систем, то на Cache' такие системы есть.
Посмотрите презентацию BitMap-индексы (С появлением BitMap-индексов можно более эффективно разрабатывать аналитические приложения на Caché. На занятии вы получите теоретические знания и получите практический опыт использования BitMap-индексов и приложения HyperIndex).



Не совсем тольок понятно из презентации, насколько большое падение производительности будет на операциях insert/update при использовании BitMap - индексов.
А вообще, достаточно интересные возможности появляются у каши.

BitMap-индексы появились несколько лет назад в версии Cache' 5.0. С тех пор в Cache' появилось много новых возможностей.

Любой индекс замедляет операции insert/update просто наш BitMap-индекс замедляет не так сильно, как у конкурентов.
Сравнимо с обычным индексом.
Это расширяет область применения BitMap-индексов. Их стоит активно применять и в OLTP-приложениях.

Вадим

Sergei Obrastsov dials Sergei Obrastsov dialsВ таком случае, если у BitMap - индексов нет такого минуса, как падение производительности, это полноценная замена обыкновенным индексам, только с большим количеством "+"?;-)
BitMap - специфические индексы и обеспечить ими полноценную замену обыкновенным, сиречь
сильно дифференцированным, индексам нельзя. Получится непомерное разрастание объема
и потеря в производительности, конечно. Это я просто не понял с ходу вопроса, прошу прощения.

Вообще, имеет ли смысл обыкновенные индексы заменять BitMap - индексами в таблицах, с объёмами данных более миллиона записей?
Или необходимо обыкновенные индексы дополнять BitMap?
Опять же все зависит от от дифференциации значений индекса. Если в индексе не более 100 значений и нужен офигенно быстрый поиск, то я бы рискнул перейти на BitMap, даже на данных более миллиона, а то и 10-ти. :)

Чем меньше уникальных записей в проиндексированном столбце, тем лучше для BitMap-индекса.
Граница, при которой стоит использовать BitMap-индексы, не 100 уникальных значений, а 1000-2000.
Понятно, что чем меньше, тем лучше.

Важный момент. BitMap-индексы используют $Bit-функции.
За счет этого, например, обеспечивается сжатие данных индекса, с помощью $Bit-функций можно осуществлять операции над сжатыми битовыми строками, реализована оптимизация журналирования и т.д.

В реальном приложении стоит поэкспериментировать с обычными и BitMap-индексами.

Вадим

Sergei Obrastsov VadimFЛюбой индекс замедляет операции insert/update просто наш BitMap-индекс замедляет не так сильно, как у конкурентов.

Вадим, Вы серьезно это говорите или реклама обязывает? Наш BitMap помедленней чем у конкурентов будет.


На чем основывается Ваше утверждение. Помедленней на каких операциях?

Когда запускалась Cache' 5.0. делались соответствующие тесты.
Сравнивалась производительность с РСУБД, где есть подобные индексы.
Скорость при изменении данных, проиндексированных с помощью BitMap-индексов, гораздо выше, чем у конкурентов.
У них BitMap-индексы стоит использовать только в Data Warehouse, у нас в OLTP.

Sergei Obrastsov
VadimF
Сравнимо с обычным индексом.

Вы шутите?!

Нет. Опять таки проводили тестирование.

Советую посмотреть материалы старых школ и симпозиумов на эту тему.


Вадим

Sergei Obrastsov VadimF Sergei Obrastsov VadimFЛюбой индекс замедляет операции insert/update просто наш BitMap-индекс замедляет не так сильно, как у конкурентов.

Вадим, Вы серьезно это говорите или реклама обязывает? Наш BitMap помедленней чем у конкурентов будет.


На чем основывается Ваше утверждение. Помедленней на каких операциях?

На обычной логике. У нас все-таки п-код, а не ассемблер. Более того, у нас интерпретатор вдвойне, поскольку BitMap реализован через классы. Или я чего-то не знаю?


BitMap-индексы используют $bit-функции, которые реализованы на уровне ядра.
Я об этом писал в этой ветке.
Можно найти об этом информацию в материалах, которые я советовал посмотреть и в документации.
Такой подход и позволил очень сильно увеличить производительность.

Sergei Obrastsov
VadimF
Когда запускалась Cache' 5.0. делались соответствующие тесты.
Сравнивалась производительность с РСУБД, где есть подобные индексы.
Скорость при изменении данных, проиндексированных с помощью BitMap-индексов, гораздо выше, чем у конкурентов.
У них BitMap-индексы стоит использовать только в Data Warehouse, у нас в OLTP.

Может все-таки завеса тайны когда-нибудь приподнимется и мы узнаем с чем производилось сравнение? Потому как более всего меня беспокоит ограничение строки данных размером в 32k.
Насколько я помню, в документации по BitMap указан верхний предел для строки даже не в 260 тысяч позиций, а всего в 64. Ну а если БД выходит за этот "небольшой" размер, начинается подгонка и вычисление строк?


Ограничение 32k снято на уровне ядра в Cache' 2007.1. В следующих версиях будет снято на уровне объектов и SQL.

На работу BitMap-индексов это сильно не влияет.
В документации описывается как храниться BitMap-индекс.
Caché Development Guides -> Using Caché Multi-Dimensional Storage -> SQL and Object Use of Multidimensional Storage -> Bitmap Indices

Вот отрывок:
The third subscript contains a chunk number; for efficiency, bitmap indices are divided into a series of bit strings each containing information for about 64000 rows from the table. Each of these bit strings are referred to as a chunk.

Размер каждого "кусочка" 8k, что соответствует размеру блока.


Sergei Obrastsov


VadimF
Сравнимо с обычным индексом.
Sergei Obrastsov
Вы шутите?!
Нет. Опять таки проводили тестирование.
Советую посмотреть материалы старых школ и симпозиумов на эту тему.

Ну что ж не буду пока спорить, отвечу после проверки.

Успехов. Будет время посмотрите и Hyperindex.
Там реализован bit-slicing. Скоро BitSlicing появится и в Cache'.
Но с Hyperindex Вы можете применять эту технологию уже в Cache' 5.0.x.

Вадим

Sergei Obrastsov Sergei Obrastsov
3. BitMap строка не помещается в блок, разве что в BigString, а там уже пофигу какой у Вас размер строки.
Брякнул, а не подумал, прошу прощения. Там ведь 8192, на фиксированных ссылках влезет.

Битовая строка храниться в сжатом виде!
Там 64000 элемента, но так как используется сжатие, это меньше 8k.

Вадим