?

Log in

No account? Create an account

Entries by category: дизайн

http://www.google.com/search?q=Column-Stores+vs.+Row-Stores%3A+How+Different+Are+They+Really%3F

Column-Stores vs. Row-Stores: How Different Are They Really?


Daniel J. Abadi, Samuel R. Madden, Nabil Hachem, 2008



«Row store» и «column store» — два разных способа организации хранения данных. Распространённые SQL системы — MySQL, MS SQL, PostgreSQL — используют row stores: записи в таблицах хранятся в виде последовательности структур, каждая из которых содержит значения для соответствующих колонок. Альтернативным способом хранения является column store (MonetDB, Vertica (C-Store)): в отдельных структурах данных (упрощённо — файлах) последовательно хранятся содержимое ячеек для одной колонки, затем — для другой, и далее для всех колонок.

Column store дизайн представляет возможность использовать следующие оптимизации:
  • Колонки, имеющие низкую вариативность содержимого, могут хорошо сжиматься. В row stores рядом с полем с низкой вариативностью (пол) будет соседствовать поле B с высокой вариантивностью (номер телефона), усложняя или делая невозможным компрессию. Отсутствие подобных «лишних» данных в файле колонки позволяет с успехом использовать простые схемы компрессии, типа RLE.
  • При необходимости делать запросы, которые возвращают только небольшое подмножество колонок из таблицы, системы column store читают только содержимое тех колонок, которые участвуют в запросе. При большом количестве данных это пропорционально снижает количество данных, которые нужно прочитать с диска.
  • Поздняя материализация: данные из нескольких колонок собираются в кортежи на как можно более поздних этапах выполнения запросов.
  • Блочная итерация: значения передаются внутри итераторов обработчика запроса как блоки, а не как серии кортежей.

Бытует мнение, что некоторые из преимуществ, предоставляемых column stores, можно имитировать с использованием чуть более усложнённой схемы данных в row stores. Например, для таблицы, в которой N колонок, но выборка чаще всего производится по определённым M из них (M < N), имеет смысл создать отдельную табличку, включающую только те поля, которые используются в запросах. Также можно поиграться материализованными представлениями, либо делать index-only планы с комбинированными ключами.

Данная статья рассматривает тест TPC-H (несколько таблиц в «звёздной» схеме) на нескольких миллионах записей, и пытается применить все оптимизации row stores, которые призваны имитировать часть функциональности column stores. С противоположной стороны, берётся column store, и из неё последовательно выбрасываются все оптимизации, специфичные для column stores (например, отключается компрессия колонок).

Вывод статьи следующий:


Среднее время выполнения тестов TPC-H было в районе 4 секунды для column store, и 80..220 секунд для row store. Даже при использовании наилучшего сценария для row stores — использования материализованных представлений, которые были специально сделаны под запросы, которые были заранее известны — column stores выиграла: 4 с. vs. 10.2 с.

Никакие из попыток имитировать column stores не были особенно успешными. Вертикальное партиционирование неплохо работает в случае M < ¼N, но при ином отношении избыточное количество служебной информации (заголовки кортежей, избыточные копии идентификаторов записей) начинает доминировать в структуре I/O, и преимущество вертикального разбиения теряется. Index-only планы вынуждают объединять колонки используя дорогие hash джойны на TPC-H схеме, что существенно замедляет запросы. Материализованные представления дают наилучший результат в каких-то случаях, но в некоторых случаях bitmap-объединения могут быть медленнее, чем чисто последовательные сканы.

Что касается тех вещей, которые наиболее сильно влияют на преимущество column stores, то было показано, что компрессия и поздняя материализация дают наибольший вклад (10x и 3x, соответственно).

Отдельным вкладом статьи является то, что авторы предложили ещё одну оптимизацию column stores, а именно «invisible join», которая позволяет иногда ускорить column stores ещё процентов на 50—75.

Tags:

Profile

lionet
Lev Walkin
Website

Latest Month

December 2016
S M T W T F S
    123
45678910
11121314151617
18192021222324
25262728293031

Syndicate

RSS Atom
Powered by LiveJournal.com
Designed by yoksel