СУБД с хранением данных по столбцами и по строкам

Анализ преимуществ колоночных хранилищ


Как говорилось в разд. 5, все три оптимизации, ориентированные на системы с хранением данных по столбцам, существенно повышают производительность соответствующих систем баз данных. Это сжатие, отложенная материализация и итерация по блокам. Кроме того, авторы расширили возможности C-Store методом скрытых соединений, который, как они ожидали, также будет способствовать повышению производительности. По-видимому, именно эти оптимизации являются причиной показанного на рис. 5 различия в производительности между колоночным хранилищем и вариантом строчного хранилища с материализованными представлениями, для которого имелся такой же объем ввода-вывода, что и для колоночного хранилища. Чтобы проверить это предположение, авторы последовательно удаляли оптимизации из базового варианта C-Store и после каждого шага измеряли производительность.

Удалить сжатие из C-Store было просто, поскольку в C-Store имеется специальный флаг, управляющий включением и отключением этого режима. Удалить метод скрытого соединения было тоже просто, потому что это новая операция, включенная в систему самими авторами. Для удаления отложенной материализации авторам пришлось вручную кодировать планы запросов, чтобы кортежи конструировались в начале выполнения плана. Удалить итерацию по блокам оказалось несколько труднее, чем перечисленные три оптимизации. В C-Store доступ к данным возможен через два интерфейса: «getNext» и «asArray». При применении первого метода требуется вызов функции для каждого очередного значения, в то время как во втором случае возвращается указатель на массив, который можно итерировать напрямую. Для операций, используемых в планах запросов SSBM и производящих доступ к блокам через интерфейс «asArray», авторы написали их альтернативные версии с использованием «getNext». Это привело только к существенному замедлению выполнения операций ограничения.

На рис. 7(a) показаны детальные (для каждого запроса) результаты последовательного удаления этих оптимизаций из C-Store; на рис. 7(b) эти результаты усреднены по всем запросам SSBM.
Следовательно, оптимизацию «перепись в предикат between» можно было использовать не менее одного раза для каждого запроса.

Понятно, что наиболее существенными оптимизациями являются сжатие и отложенная материализация. Сжатие повышает производительность в среднем в два раза. Однако, как отмечалось в разд. 5, авторы не поддерживают избыточного хранения таблицы фактов с несколькими порядками сортировки для получения полного преимущества от сжатия (отсортирован только один столбец – orderdate, и два столбца – quantity и discount – вторично отсортированы). Столбцы таблицы фактов, используемые в запросах SSBM, не очень хорошо сжимаются, если они не упорядочены, поскольку они являются либо ключами (и их множество обладает большой мощностью), либо случайными значениями. Первое звено запросов, в котором имеется доступ ко всем трем упорядоченным столбцам, демонстрирует преимущество по производительности, получаемое при использовании в запросах сильно сжатых столбцов. В этом случае сжатие приводит к повышению производительности на порядок. Так происходит из-за того, что последовательности значений в этих упорядоченных столбцах могут быть продольно закодированы (run length encoded, RLE). Продольное кодирование не только обеспечивает хороший коэффициент сжатия и, тем самым, сокращает накладные расходы ввода-вывода, но также и позволяет очень просто выполнять операции над сжатыми данными (например, предикат или агрегатную функцию можно применить сразу ко всей последовательности). Первично отсортированный столбец orderdate содержит всего 2405 уникальных значений, и поэтому средняя длина последовательности для этого столбца составляет 25000. Для его хранения требуется менее 64 килобайт дискового пространства.

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


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

Заметим, что после удаления всех оптимизаций колоночное хранилище ведет себя подобно строчному хранилищу. Столбцы немедленно «сшиваются» и обрабатываются после этого так же, как в строчном хранилище. Поэтому можно было бы ожидать, что колоночное хранилище будет выполнять запросы подобно строчному хранилищу с материализованными представлениями, поскольку требования к вводу-выводу и обработка запросов у них аналогичны – единственным различием является необходимость конструирования кортежей в начале выполнения плана запроса в колоночном хранилище. В подразделе 6.1 авторы предостерегали против прямых сравнений с System X, но при сравнении этих показателей со случаем CS Row-MV с рис. 5 можно видеть, насколько дорогостоящим может быть конструирование кортежей. Это согласуется с предыдущими результатами авторов.


Содержание раздела