Ни о чём →
СУБД — поворот на 90 градусов
Объемы данных и требования к скорости их обработки за последние десятилетия многократно выросли. Системы управления базами данных (СУБД) пытаются соответствовать новым реалиям и претерпевают значительные эволюционные и революционные изменения. Одним из таких эволюционных факторов является движение в сторону т.н. вертикальных (column-based) систем хранения.
Посмотрим в качестве примера на классическую таблицу EMPLOYEE:
Таблица Сотрудники/EMPLOYEE
В традиционных (row-based) СУБД эти данные будут размещаться построчно:
При этом чтобы выбрать, к примеру, имена всех сотрудников, придется сначала прочесть все строки, затем выбросить из них ненужное.
В вертикальных (column-based) СУБД те же самые данные будут представлены несколькими блоками:
(представлено в сильно упрощенном виде)
Фактически это новое представление данных развернуто на 90 градусов относительно традиционного. Это дает ряд преимуществ:
В 2009 году Майкл Стоунбрейкер (которого без преувеличения можно назвать Эйнштейном реляционных СУБД) предсказал скорый закат эры классических СУБД; чтобы не быть голословным, он заявил о разработке новой «вертикальной» СУБД Vertica.
Вендоры «традиционных» СУБД (такие Oracle и IBM), разумеется, не считают, что их эра закончилась. Поэтому в качестве современной парадигмы они предлагают «гибридные» системы хранения; фактически это надстройка над традионной системой хранения, где данные хранятся не целыми строками и не столбцами, а группами-блоками по несколько столбцов. Гибридная модель не так эффективна в сжатии данных, как «вертикальное» хранилище, однако является хорошим компромиссом.
Гибридные СУБД не всегда официально описываются как гибридные. Например, Oracle называет свою технологию Advanced Compression (11g), а «гибридные» блоки он называет compression unit. В нереляционной СУБД Cassandra, которую для своих нужд разработал Facebook, такие блоки называются column family.
Как и в случае объектных баз данных, вендоры явно действуют по проверенному принципу «мода скоро пройдет — а реляционные базы останутся навечно».
Небольшой FAQ. Зачем нужны вертикальные СУБД, если почти все современные СУБД поддерживают:
Давайте разберемся. Теоретически в обычной «горизонтальной» СУБД из индексов и materialized views мы можем смастерить хранилище, весьма эффективное по чтению (read-oriented). Допустим даже, что наша СУБД эффективно сжимает данные и даже индексы. В итоге мы сможем на выходе получить нечто вроде самодельного вертикального хранилища. Конечно, оно будет избыточным (а значит, запись данных усложняется...) и хранение данных не всегда будет оптимальным — но по сути будет соответствовать «вертикальному» или гибридному представлению.
Практически же вертикальная СУБД будет реализовывать все это более оптимально уже на уровне хранения данных. Ничего нового в используемых технологиях нет, как и пишет Стоунбрейкер про свой новый движок C-Store:
Ссылки по теме:
PS. На всякий случай уточним, что разделение между «вертикальными» и «горизонтальными» СУБД не имеет никакого отношения к популярной сейчас дихотомии SQL/NoSQL.
Посмотрим в качестве примера на классическую таблицу EMPLOYEE:
Таблица Сотрудники/EMPLOYEE
| ID | NAME | JOB_TITLE |
|---|---|---|
| 1 | Вася | Грузчик |
| 2 | Ирина | Секретарша |
| 3 | Петя | Кассир |
| 4 | Антон | Менеджер |
| 1 | Вася | Грузчик |
| 2 | Ирина | Секретарша |
| 3 | Петя | Кассир |
| 4 | Антон | Менеджер |
В вертикальных (column-based) СУБД те же самые данные будут представлены несколькими блоками:
| Блок ID | 1 | 2 | 3 | 4 |
|---|---|---|---|---|
| Блок NAME | Вася | Ирина | Петя | Антон |
| Блок JOB_TITLE | Грузчик | Секретарша | Кассир | Менеджер |
(представлено в сильно упрощенном виде)
Фактически это новое представление данных развернуто на 90 градусов относительно традиционного. Это дает ряд преимуществ:
- «Столбцовые» блоки данных меньше размером, а чем меньше размер данных, тем легче ими управлять.
- Блоки можно разносить на разные диски и даже сервера (вертикальное секционирование).
- Вертикальные («столбцовые») данные гораздо проще сжимать, что экономит место в памяти и разгружает дисковую систему.
В 2009 году Майкл Стоунбрейкер (которого без преувеличения можно назвать Эйнштейном реляционных СУБД) предсказал скорый закат эры классических СУБД; чтобы не быть голословным, он заявил о разработке новой «вертикальной» СУБД Vertica.
Вендоры «традиционных» СУБД (такие Oracle и IBM), разумеется, не считают, что их эра закончилась. Поэтому в качестве современной парадигмы они предлагают «гибридные» системы хранения; фактически это надстройка над традионной системой хранения, где данные хранятся не целыми строками и не столбцами, а группами-блоками по несколько столбцов. Гибридная модель не так эффективна в сжатии данных, как «вертикальное» хранилище, однако является хорошим компромиссом.
Гибридные СУБД не всегда официально описываются как гибридные. Например, Oracle называет свою технологию Advanced Compression (11g), а «гибридные» блоки он называет compression unit. В нереляционной СУБД Cassandra, которую для своих нужд разработал Facebook, такие блоки называются column family.
Как и в случае объектных баз данных, вендоры явно действуют по проверенному принципу «мода скоро пройдет — а реляционные базы останутся навечно».
UPDATE
Небольшой FAQ. Зачем нужны вертикальные СУБД, если почти все современные СУБД поддерживают:
- Компрессию данных
- Кластерные индексы, 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.
Ссылки по теме:
- http://cacm.acm.org/blogs/blog-cacm/32212-the-end-of-a-dbms-era-might-be-upon-us/fulltext
- http://www.daniel-lemire.com/blog/archives/2009/09/16/relational-databases-are-they-obselete/
- http://www.dbms2.com/2009/09/03/oracle-11g-exadata-hybrid-columnar-compression/
- http://www.daniel-lemire.com/blog/archives/2009/09/04/changing-your-perspective-horizontal-vertical-and-hybrid-data-models/
- http://storagemojo.com/2009/09/14/rdbms-going-like-mainframes/
- http://wiki.apache.org/cassandra/DataModel
PS. На всякий случай уточним, что разделение между «вертикальными» и «горизонтальными» СУБД не имеет никакого отношения к популярной сейчас дихотомии SQL/NoSQL.
14.12.2009 16:37+0300