Объемы данных и требования к скорости их обработки за последние десятилетия многократно выросли. Системы управления базами данных (СУБД) пытаются соответствовать новым реалиям и претерпевают значительные эволюционные и революционные изменения. Одним из таких эволюционных факторов является движение в сторону т.н. вертикальных (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.

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

Ссылки по теме:

  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.

  • Sharing

    Facebooktwittergoogle_plusredditpinterestlinkedinmailby feather