Кто-нибудь знает что-нибудь о внутренних компонентах OLAP?

Question

Я немного разбираюсь во внутренних элементах базы данных.На самом деле я уже реализовывал небольшой, простой движок реляционной базы данных раньше, используя структуры ISAM на диске и индексы BTree и все такое прочее.Это было весело и очень познавательно.Я знаю, что теперь, когда я немного больше знаю о том, как работают СУБД под капотом, я гораздо лучше разбираюсь в тщательном проектировании схем баз данных и написании запросов.

Но я ничего не знаю о многомерных моделях данных OLAP, и мне было трудно найти какую-либо полезную информацию в Интернете.

Как информация хранится на диске?Какие структуры данных составляют куб?Если модель MOLAP не использует таблицы со столбцами и записями, то...что?Какие типы структур данных, особенно в многомерных данных, делают модель MOLAP настолько эффективной?Используют ли реализации MOLAP что-то аналогичное индексам RDBMS?

Почему OLAP-серверы намного лучше обрабатывают специальные запросы?Те же виды агрегаций , которые могли бы занять часы работы для обработки в обычной реляционной базе данных может быть обработан за миллисекунды в OLTP-кубе.Какова лежащая в основе модели механика, которая делает это возможным?

Answer 1

Я внедрил пару систем, которые имитировали работу OLAP-кубов, и вот пара вещей, которые мы сделали, чтобы заставить их работать.

1) Основные данные хранились в n-мерном массиве, все в памяти, и все ключи были реализованы через иерархии указателей на базовый массив.Таким образом, у нас могло бы быть несколько разных наборов ключей для одних и тех же данных.Данные в массиве были эквивалентом таблицы фактов, часто в ней было всего несколько фрагментов данных, в одном случае это были цена и количество проданных.

2) Базовый массив часто был разреженным, поэтому после его создания мы удаляли все пустые ячейки, чтобы сэкономить память - много сложной арифметики указателей, но это работало.

3) Поскольку у нас была иерархия ключей, мы могли довольно легко писать процедуры для легкой детализации иерархии.Например, мы могли бы получить доступ к данным за год, пройдя по ключам месяцев, которые, в свою очередь, сопоставлены дням и / или неделям.На каждом уровне мы бы агрегировали данные как часть построения куба - вычисления выполнялись бы намного быстрее.

4) Мы не реализовывали какой-либо язык запросов, но мы поддерживали детализацию по всем осям (до 7 в наших самых больших кубах), и это было напрямую привязано к пользовательскому интерфейсу, который понравился пользователям.

5) Мы внедрили основные компоненты на C ++, но в наши дни я считаю, что C # мог бы быть достаточно быстрым, но я бы беспокоился о том, как реализовать разреженные массивы.

Надеюсь, это поможет, звучит интересно.

Answer 2

Книга Запущены службы анализа Microsoft SQL Server 2008 в нем достаточно подробно излагаются некоторые особенности SSAS 2008.Это не совсем "вот как именно SSAS работает под капотом", но это довольно наводит на размышления, особенно со стороны структуры данных.(Здесь не так подробно / конкретизированы точные алгоритмы.) Несколько вещей, которые я, как любитель в этой области, почерпнул из этой книги.Это все о SSAS MOLAP:

• Несмотря на все разговоры о многомерных кубах, данные таблицы фактов (она же группа измерений) по-прежнему, в первом приближении, в конечном счете хранятся в основном в 2D-таблицах, по одной строке на факт.Ряд операций OLAP, по-видимому, в конечном счете состоят из перебора строк в 2D-таблицах.
• Однако внутри MOLAP данных потенциально намного меньше, чем внутри соответствующей таблицы SQL.Один из трюков заключается в том, что каждая уникальная строка сохраняется только один раз, в "хранилище строк".Затем структуры данных могут ссылаться на строки в более компактной форме (в основном по идентификатору строки).SSAS также сжимает строки в хранилище MOLAP в той или иной форме.Я полагаю, что такое сокращение позволяет большему количеству данных одновременно оставаться в оперативной памяти, и это хорошо.
• Аналогично, SSAS часто могут выполнять итерацию по подмножеству данных, а не по полному набору данных.Задействовано несколько механизмов:
  • По умолчанию SSAS создает хэш-индекс для каждого значения измерения / атрибута;таким образом, он "сразу" знает, какие страницы на диске содержат соответствующие данные, скажем, за год = 1997.
  • Существует архитектура кэширования, в которой соответствующие подмножества данных хранятся в оперативной памяти отдельно от всего набора данных.Например, вы могли кэшировать вложенный куб, содержащий всего несколько ваших полей и относящийся только к данным за 1997 год.Если запрос запрашивает только о 1997 году, то он будет повторяться только по этому вложенному кубу, тем самым ускоряя процесс.(Но обратите внимание, что "вложенный куб" - это, в первом приближении, просто 2D-таблица.)
  • Если вы используете предопределенные агрегаты, то эти меньшие подмножества также могут быть предварительно вычислены во время обработки куба, а не просто вычислены / кэшированы по требованию.
• Строки таблицы фактов SSAS имеют фиксированный размер, что предположительно помогает в какой-то форме.(В SQL, в constrast, у вас могут быть строковые столбцы переменной ширины.)
• Архитектура кэширования также означает, что после вычисления агрегации ее не нужно повторно извлекать с диска и пересчитывать снова и снова.

В любом случае, это некоторые из факторов, влияющих на SSAS.Я не могу утверждать, что нет и других жизненно важных вещей.