Главная
страница 1 ... страница 2страница 3страница 4страница 5страница 6

16.2.3 Преимущества модели данных на основе SAP HANA


В данной работе мы уже упоминали о том, что в настоящее время преодолевать ограничения классических реляционных баз данных, используя более низкоуровневые абстракции. Провозглашение того, что исключительно в рамках модели мы можем получить оптимальную производительность системы, сейчас не совсем оправданно. Именно на стыке технологий, относящихся к оптимизации «железа», и специального программного обеспечения, модели данных, учитывающей эту специфику, мы можем получить оптимальный результат. В этой главе мы хотели бы показать преимущества, которые дает нам именно наша модель данных, построенная на основе базы данных SAP HANA.



Механизмы сжатия и «словарь значений»

Таблица фактов, используемая в нашей модели, содержит естественные значения ключей, а также прочих необходимых для аналитики атрибутов, т.к. для повышения производительности мы исключили из модели таблицы измерений. Однако тогда большая часть полей является текстовыми и это также может повлиять на скорость работы, но в противоположную сторону. Здесь нам на помощь приходят внутренние механизмы компрессии данных, используемые в SAP HANA [15].

Внутренний механизм компрессии SAP HANA изображен на рисунке (Рис.5):

Рис.5 Алгоритм компрессии данных

В левой части изображен несжатый столбец значений фамилий сотрудников. В правой части показано, как устроена компрессия и физическое хранение таких данных. Сначала уникальные значения столбца сортируются по возрастанию, и затем каждому из них присваивается порядковый номер. Это хранится в оперативной памяти системы и называется «словарь значений». Сам столбец содержит ссылки на порядковые номера из словаря значений. Это позволяет использовать быстрый бинарный поиск при обработке запросов, применяя бинарное кодирование с помощью log2(NDICT) бит.
Поиск осуществляется следующим образом: мы находим значение в словаре, затем просматриваем значения столбца, используя индекс. Индекс представлен в виде массива значений строк для каждого значения из словаря.
Кроме того, мы получаем уменьшение размеров таблицы и базы данных соответственно за счет сжатия с использованием одного из следующих методов кодирования (префиксное кодирование, кодирование длин серий, кластерное кодирование, косвенное кодирование).

Таким образом, благодаря методам хранения данных, используемым в SAP HANA, для нас не имеет значения, какой тип имеет столбец, т.к. наличие порядковых номеров из словаря значений дает нам возможность осуществлять быстрый поиск по данным числового типа.



Секционирование таблиц и параллельная агрегация

Здесь мы объясним, для чего мы разделили транзакционные таблицы в первой модели на три – Manual_input, Depreciation, Driver_costs и почему установили связь между ними и таблицей Association_Dimension как 1:1. Дело в том, что измерения ССП и вид расходов содержат наибольшее количество значений членов измерений (организационная структура и детализированный управленческий план счетов). Однако в таблице Association_Dimension содержатся лишь внесенные комбинации, но лишь по одному разу. Это происходит потому, что пересечение комбинаций невозможно – для каждого ССП и вида расходов предопределен метод планирования (ручной, капитальные затраты или по нормам). Это позволяет максимально уменьшить количество записей, храня каждую комбинацию лишь по одному разу. Таким образом, мы можем разбить таблицу Association_Dimension на секции по двум измерениям: ССП и вид расходов, которые позволяют нам обрабатывать данные из различных частей с помощью различных ядер процессора и даже различных серверов. Устройство данного механизма в SAP HANA изображено на рисунке (Рис.6) (разбиение на секции возможно как по строкам, так и по столбцам):



Рис.6 Технология параллельной обработки секций

В SAP HANA предусмотрены следующие алгоритмы секционирования: циклическое, хэш-секционирование и секционирование по диапазонам. Так как значения измерений ССП и вид расходов нам заранее известны и будут встречаться равновероятно, для них следует применить секционирование по диапазонам. Также важный для секционирования атрибут – Время (Time), для него целесообразнее применить хэш-секционирование (нет информации о вероятности появления значений) [15].

Таким образом, за счет данных возможностей SAP HANA мы сможем достичь наибольшего параллелизма на аппаратном уровне. Это относится ко всем операциям – чтения, изменения. В данном случае мы получаем практически горизонтальное масштабирование производительности системы.

Секционирование также может помочь нам в модели таблицы фактов. Таблица фактов является многомерной и будет содержать большое количество столбцов. Кроме того, так как мы храним в ней все исторические данные по изменениям данных, таблица будет также большой горизонтально (обладать высокой кардинальностью). Для ускорения выполнения аналитических запросов мы можем использовать аналогичное секционирование по атрибутам ССП, вид расхода, статья (диапазонное) и время (хэш), т.к. эти атрибуты содержат наибольшее количество значений. Также необходимо настроить диапазонное секционирование по атрибуту версия, т.к. в аналитических отчетах нам будут нужны только актуальные данные, которые составляют лишь часть всей таблицы фактов. Следовательно, мы сможем добиться большего параллелизма. Но, кроме этого, разбиение на секции поможет нам применить механизм параллельной агрегации данных, реализованный в SAP HANA. Быстрая агрегация чрезвычайно эффективна для аналитических запросов по срезам данных.
Механизм параллельной агрегации схематично изображен на рисунке (Рис.7):


Рис.7 Технология параллельной агрегации

Параллельная агрегация работает следующим образом [15]:



  1. Выбираются секции входящего набора записей

  2. Секции помещаются в хэш-таблицы для обеспечения О(1) поиска

  3. Выполняется агрегация данных для данных секций в параллельных потоках и с использованием различных ядер процессора

  4. Затем агрегированные данные собираются в параллельных потоках, используя алгоритмы параллельного соединения (hash, range join, radix join, map-reduce, mergesort)

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

Обработка OLTP информации таблицами с поколоночным хранением

Таблицы с поколоночным хранением, используемые нами для моделирования таблицы фактов, используются и в других базах данных. В первую очередь они помогают оптимизировать операции чтения, когда нет необходимости читать для каждой записи значения всех столбцов, а можно прочитать из памяти лишь значения тех столбцов, которые участвуют в запросе. Однако SAP HANA также поддерживает эффективное выполнение операций добавления для поколоночных таблиц, или обработку OLTP-транзакций [14]. Это важно для нас, так как в любом случае мы создаем такую нагрузку на таблицу фактов, используя репликацию данных на триггерах. Кроме того, данные, поступающие для добавления, должны быть добавлены в «словарь значений», т.е. быть сжаты. Для этого в SAP HANA разработана концепция промежуточного хранения данных при вставке в таблицы с поколоночным хранением. Эта концепция состоит из трех стадий обработки записи. Данный жизненный цикл записи при добавлении изображен на рисунке (Рис.8):



Рис.8 Алгоритм обработки запросов к таблицам



  1. L1-delta: принимает на вход все запросы к таблице, сохраняя их в строчно-ориентированном формате, что более оптимально для ввода, удаления и изменения. Также здесь данные не сжимаются, оптимальный размер для запросов – 10,000-100,000 строк.

  2. L2-delta: во второй фазе записи уже хранятся в поколоночном формате, а также кодируются с использованием словаря значения. Но он остается не отсортированным, чтобы не снижать производительность OLTP-запросов по вторичным индексам, например, при проверке уникальности определенного значения. Оптимальный размер запросов – до 10 млн строк.

  3. Main store: здесь данные уже сжаты используя возможные техники кодирования и битовых векторов, а также отсортированы, т.е. хранятся в обычном, доступном для быстрого чтения формате.

Для нас здесь важно то, что первая и вторая фаза оптимизированы для операций добавления, изменения и удаления, как единичного, так и пакетного. Оптимизация алгоритмов соединения данных, хранящихся в каждой из трех фаз, более подробно описана в [15]. Главное, что поколоночная таблица будет легко справляться с операциями ввода, изменения и удаления, а при временном снижении нагрузки на систему будет добавлять данные из первых двух фаз в основной индекс. Таким образом, нам не следует опасаться падения производительности в результате наличия операций вставки в таблицы такого типа, хранящие сжатые данные.

<< предыдущая страница   следующая страница >>
Смотрите также:
«Методы моделирования данных в аналитических информационных системах»
411.45kb.
6 стр.
Методика определения актуальных угроз безопасности персональных данных при их обработке в информационных системах персональных данных
150.02kb.
1 стр.
Специализированные методы визуализации 2d и 3d изображениq в бортовых картографических системах
88.09kb.
1 стр.
Учебная программа Дисциплины р1 «Моделирование информационных процессов»
125.21kb.
1 стр.
Программа по дисциплине администрирование в информационных системах растягаев Д. В
128.76kb.
1 стр.
Политика безопасности персональных данных, обрабатываемых в информационных системах персональных данных в
227.68kb.
1 стр.
Методы анализа данных Кредиты: 3 Аннотация дисциплины
17.78kb.
1 стр.
Инструкция операторам по обработке персональных данных на пэвм
211.62kb.
1 стр.
1. Термины и определения (документы фстэк россии) Безопасность персональных данных
153.09kb.
1 стр.
Лабораторные работы по дисциплине "Теория экономических информационных систем"
95.98kb.
1 стр.
30. Методы моделирования сложных систем
85.7kb.
1 стр.
Базовая модель угроз безопасности персональных данных при их обработке в информационных системах персональных данных
1254.82kb.
8 стр.