Как стать автором
Обновить

СУБД — поворот на 90 градусов

Время на прочтение 3 мин
Количество просмотров 5.8K
Объемы данных и требования к скорости их обработки за последние десятилетия многократно выросли. Системы управления базами данных (СУБД) пытаются соответствовать новым реалиям и претерпевают значительные эволюционные и революционные изменения. Одним из таких эволюционных факторов является движение в сторону т.н. вертикальных (column-based) систем хранения.

Посмотрим в качестве примера на классическую таблицу EMPLOYEE:

Таблица Сотрудники/EMPLOYEE
ID NAME JOB_TITLE
1 Вася Грузчик
2 Ирина Секретарша
3 Петя Кассир
4 Антон Менеджер
В традиционных (row-based) СУБД эти данные будут размещаться построчно:
1 Вася Грузчик
2 Ирина Секретарша
3 Петя Кассир
4 Антон Менеджер
При этом чтобы выбрать, к примеру, имена всех сотрудников, придется сначала прочесть все строки, затем выбросить из них ненужное.

В вертикальных (column-based) СУБД те же самые данные будут представлены несколькими блоками:
Блок ID 1 2 3 4
Блок NAME Вася Ирина Петя Антон
Блок JOB_TITLE Грузчик Секретарша Кассир Менеджер

(представлено в сильно упрощенном виде)

Фактически это новое представление данных развернуто на 90 градусов относительно традиционного. Это дает ряд преимуществ:
  1. «Столбцовые» блоки данных меньше размером, а чем меньше размер данных, тем легче ими управлять.
  2. Блоки можно разносить на разные диски и даже сервера (вертикальное секционирование).
  3. Вертикальные («столбцовые») данные гораздо проще сжимать, что экономит место в памяти и разгружает дисковую систему.
В то же время можно заметить, что создание новой строки в БД повлечет за собой запись в три (!) физически разнесенных блока данных вместо одной записи в классическом «построчном» варианте. С точки зрения дисковой системы это не очень здорово. Поэтому «колоночное» хранилище считается более ориентированным на чтение и аналитические выборки (OLAP).

В 2009 году Майкл Стоунбрейкер (которого без преувеличения можно назвать Эйнштейном реляционных СУБД) предсказал скорый закат эры классических СУБД; чтобы не быть голословным, он заявил о разработке новой «вертикальной» СУБД Vertica.

Вендоры «традиционных» СУБД (такие Oracle и IBM), разумеется, не считают, что их эра закончилась. Поэтому в качестве современной парадигмы они предлагают «гибридные» системы хранения; фактически это надстройка над традионной системой хранения, где данные хранятся не целыми строками и не столбцами, а группами-блоками по несколько столбцов. Гибридная модель не так эффективна в сжатии данных, как «вертикальное» хранилище, однако является хорошим компромиссом.

Гибридные СУБД не всегда официально описываются как гибридные. Например, Oracle называет свою технологию Advanced Compression (11g), а «гибридные» блоки он называет compression unit. В нереляционной СУБД Cassandra, которую для своих нужд разработал Facebook, такие блоки называются column family.

Как и в случае объектных баз данных, вендоры явно действуют по проверенному принципу «мода скоро пройдет — а реляционные базы останутся навечно».

UPDATE


Небольшой FAQ. Зачем нужны вертикальные СУБД, если почти все современные СУБД поддерживают:
  1. Компрессию данных
  2. Кластерные индексы, materialized views, etc.
?

Давайте разберемся. Теоретически в обычной «горизонтальной» СУБД из индексов и materialized views мы можем смастерить хранилище, весьма эффективное по чтению (read-oriented). Допустим даже, что наша СУБД эффективно сжимает данные и даже индексы. В итоге мы сможем на выходе получить нечто вроде самодельного вертикального хранилища. Конечно, оно будет избыточным (а значит, запись данных усложняется...) и хранение данных не всегда будет оптимальным — но по сути будет соответствовать «вертикальному» или гибридному представлению.

Практически же вертикальная СУБД будет реализовывать все это более оптимально уже на уровне хранения данных. Ничего нового в используемых технологиях нет, как и пишет Стоунбрейкер про свой новый движок C-Store:
Lastly, materialized views, snapshot isolation,
transaction management, and high availability have also
been extensively studied. The contribution of C-Store is
an innovative combination of these techniques that
simultaneously provides improved performance, K-safety,
efficient retrieval, and high performance transactions.


Ссылки по теме:
  1. http://cacm.acm.org/blogs/blog-cacm/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext
  2. http://www.daniel-lemire.com/blog/archives/2009/09/16/relational-databases-are-they-obselete/
  3. http://www.dbms2.com/2009/09/03/oracle-11g-exadata-hybrid-columnar-compression/
  4. http://www.daniel-lemire.com/blog/archives/2009/09/04/changing-your-perspective-horizontal-vertical-and-hybrid-data-models/
  5. http://storagemojo.com/2009/09/14/rdbms-going-like-mainframes/
  6. http://wiki.apache.org/cassandra/DataModel

PS. На всякий случай уточним, что разделение между «вертикальными» и «горизонтальными» СУБД не имеет никакого отношения к популярной сейчас дихотомии SQL/NoSQL.
Теги:
Хабы:
+12
Комментарии 32
Комментарии Комментарии 32

Публикации

Истории

Ближайшие события

Московский туристический хакатон
Дата 23 марта – 7 апреля
Место
Москва Онлайн