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

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

    Похожие публикации

    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее
    Реклама

    Комментарии 32

      0
      Всего один минус и целых три плюсов, по-моему топик субъективен.
      Скажем не будет ли медленнее осуществляться горизонтальная выборка? (SELECT * FROM Table WHERE IdType = @Value)
      Что будет пониматься под индексацией?

      Топик создал больше вопросов чем прояснил ситуацию, срочно расширяйте материал.
        0
        Индексы в таких базах устроены сложнее. Приходится хранить указатель на каждый колоночный блок строки. В классическом индексе это просто указатель на строку.

        Что касается Cassandra, то там, я думаю, такой запрос сделать просто невозможно, если все колонки не лежат в одной column family (тут могу соврать).

        В любом случае, индексы не являются «заменой» вертикального хранилища. Это ортогональные понятия. Индексы не позволяют сжимать и секционировать данные.
          0
          «Индексы не позволяют сжимать и секционировать данные. „
          Секционировать — позволяют. А для сжатия и другие технологии есть, если что (у того же MS SQL, кстати, стратегии сжатия страницы данных вертикаль тоже учитвают).
            0
            Сжатие, безусловно, есть. И даже в DB2 пятилетней давности оно было. Но максимально эффективно сжать можно только разделив данные на колонки. Грубо говоря, чем больше разнородных данных мы пытаемся сжать, тем хуже они будут сжиматься.

            А как индексы позволяют секционировать ДАННЫЕ?
              0
              «Но максимально эффективно сжать можно только разделив данные на колонки.»
              Или объединив колонки… никогда не видели таблицу, где значения в колонках скореллированы?

              Ну и да, компрессия по колонкам в MS SQL тоже есть. Хотя он горизонтально ориентирован.

              «А как индексы позволяют секционировать ДАННЫЕ?»
              Во-первых, как я уже писал, с помощью индекса можно вынести часто необходимые данные отдельно от таблицы. Во-вторых, когда нам нужно секционирование по строкам, индексы тоже играют роль.
                0
                Компрессия в MS SQL и вообще компрессия в традиционных СУБД вряд ли делает погоду. Другое дело — если используется гибридное хранение данных, т.е. «объединив колонки» на физическом уровне. Делает ли это MS SQL — не знаю.

                >можно вынести часто необходимые данные отдельно от таблицы
                Это уже будет дублирование данных. По поводу секционирования по строкам — думаю, большинство вертикальных движков это решают даже лучше путем сортировки данных в колонках.
                  0
                  «Компрессия в MS SQL и вообще компрессия в традиционных СУБД вряд ли делает погоду»
                  Блажен, кто верует.

                  sqlblog.com/blogs/linchi_shea/archive/2008/05/11/sql-server-2008-page-compression-compression-ratios-from-real-world-databases.aspx

                  14 произвольно выбранных реальных БД — компрессия от 1.7 до 5.6 раз.

                  «вряд ли делает погоду», да.
                    0
                    Я не работал много с SQL Server, но судя по описанию его Page Level Compression работает только в пределах страницы и ухудшается при добавлении колонок в таблицу (т.к. при этом все меньше кортежей будет попадать в страницу).

                    Поэтому с большой вероятностью (тут, конечно, нужны тесты) описанный набор данных при колоночном хранении будет сжиматься гораздо лучше. Кроме того, интересно будет узнать, как это повлияло на пропускную способность SQL Server. В случае DB2 row compression, например, результат не так впечатляет:
                    When running our DSS workload (consisting of complex queries) a 6% throughput
                    improvement was observed in the single stream case when using row compression.
                      0
                      «Кроме того, интересно будет узнать, как это повлияло на пропускную способность SQL Server.»
                      Сжатие данных как бы не ради пропускной способности делается.
                        0
                        Сжатие данных как бы не ради пропускной способности делается.


                        О как. Ну, возможно в SQL Server это делается ради экономии места на диске стоимостью $500, однако в таких базах как KDB или Vertica компрессия данных является ключевым функционалом, влияющим на пропускную способность СУБД (в том числе за счет более «плотного» заполнения кэша, а также возможности фильтрации сжатых данных). :)
                          0
                          Ну так тогда может быть надо говорить о системах, которые умеют правильно пользоваться компрессией, а не просто о вертикалях или горизонталях?
                            0
                            Нет, не надо :)

                            Простая комбинаторика говорит о том, что данные, разрезанные по столбцам, сжимаются всегда лучше тех же данных, упакованных в одну строку :) или будет формально правильнее сказать «не хуже»
                              0
                              Вопрос в том, где и как применяется компрессия, вот в чем дело. Сам тот факт, что данные сжимаются «лучше», еще не значит, что от этой компрессии будет выигрыш в пропускной способности.

                              Про что и речь — если мы хотим получить выигрыш пропускной способности за счет компрессии данных, нам не обязательно нужна база с вертикальным хранением, нам нужна база, которая умеет применять компрессию для решения поставленной задачи.
        +2
        А смысл?

        Проблемы класса «При этом чтобы выбрать, к примеру, имена всех сотрудников, придется сначала прочесть все строки, затем выбросить из них ненужное» решаются правильно построенным индексом, а проблемы класса «чтобы прочитать строчку целиком надо полезть в много разных мест» не решаются никак.
          0
          Не совсем понял, причем тут индексы. Вы собираетесь в индекс запихнуть все данные? Индекс обычно содержит указатели на физические страницы данных и позволяет данные фильтровать, однако ну НИКАК не позволит прочесть эти данные с диска быстрее. Даже если пытаться сжимать индексы (что некоторым образом реализовано в BITMAP-индексах Oracle), это не даст никакого эффекта, т.к. сами данные не сжаты.

          >проблемы класса «чтобы прочитать строчку целиком надо полезть в много разных мест» не решаются никак

          Не всегда и не везде физическое разделение данных плохо. Иногда данные специально размещают в разных местах для лучшей масштабируемости. Запись однозначно дороже, но чтение может обойтись дешевле.
            0
            «Вы собираетесь в индекс запихнуть все данные?»
            Не все, а те, по которым часто идет выборка.

            «Индекс обычно содержит указатели на физические страницы данных и позволяет данные фильтровать, однако ну НИКАК не позволит прочесть эти данные с диска быстрее.»
            Если мы выбираем только данные, входящие в индекс, то читать физическую страницу данных просто не надо. Классическая стратегия оптимизации. Более того, то же относится к данным кластерного индекса (потому что они и является указателем). И так далее.
              0
              Если запихивать все нужные данные в индекс, то фактически это денормализация, то есть классическая схема-звездочка OLAP.

              Тут есть два момента.

              1. Запись становится дороже, а если индексов много — ох как дороже!
              2. Нет компрессии. Вместо уменьшения объема данных мы получили серьезный прирост (ибо данные теперь многократно дублируются). Думаю, не надо объяснять, чем это плохо.


              Это уже не говоря о том, что индексы (а именно B-деревья и хэш-таблицы) заточены на поиск и фильтрацию данных, а не на эффективное их хранение.
                +1
                Любое решение — компромис.

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

                Когда вы говорите про «запись индексов дороже», подумайте, сколько будет стоить запись нескольких колонок в вертикально-ориентированной СУБД, при условии, что по ним тоже нужны индексы (поиск-то никто не отменял).
                  0
                  так никто и не спорит.
                  Если бы вертикальные СУБД были лучше для всех, то все базы давно бы переделали в вертикальные.

                  >поиск-то никто не отменял
                  Поиск никто не отменял, только поиск этот немного другой. В вертикальном хранилище гораздо эффективнее можно делать сканирование таблицы по одной колонке и не в пример проще работать с секционированными (partitioned) данными. Поэтому сказать однозначно, что обязательно нужно столько же индексов, сколько в горизонтальной СУБД — нельзя.
                    0
                    Понимаете ли, скан таблицы по колонке — это все равно скан. И на больших объемах все равно будет медленно.
                      0
                      Медленно или медленнее? Скан по сжатым данным и по одной колонке всегда быстрее, чем по всем колонкам.

                      Касаемо индексов, если интересно, можно почитать, как они устроены в C-Store: C-Store: A Column-oriented DBMS. Там есть понятие Projection, которое приблизительно эквивалентно Materialized View с кластерным индексом. (Projection может быть отсортирован)
                        0
                        «Скан по сжатым данным и по одной колонке всегда быстрее, чем по всем колонкам.»
                        Это от организации данных зависит, очевидно.
                          0
                          я так не думаю, это тупо зависит от объема данных, который надо прочесть и от их фрагментации
                            0
                            Собственно и объем данных, которые надо прочитать для того, чтобы добраться до нужных, и их фрагментация — зависят от организации этих самых данных.
                              0
                              Если под организацией данных понимается способ их хранения, то да.
          +1
          >предсказал скорый закат эры классических СУБД;

          — быть может он также имел ввиду скорый закат SQL — как сердца классических СУБД (я не имею ввиду полную смерть SQL)? Ведь повернуть прямоугольник на 90 градусов с тем что бы его удобнее было помещать в шкаф или с тем что бы из него удобнее было доставать ложкой содержимое — это ещё не революция… Я сейчас даже не буду предполагать какие СУБД взойдут на горизонт после заката классических: деревянные, кубические… я не знаю. Но мне кажется это будет что-то большее чем поворот на 90 градусов… И быть может стандартный и любимый обеденный прибор (ложки вилки SQL) — будет уже не так удобен…
            0
            вертикальные бд нужны для быстрого доступа к таблицам, в которых мало INSERT и много SELECT. я прав? к примеру для хранения названия города и его координаты, оч удобно наверное. Но как же быть с остальными? тем более для быстрой выборки на сколько я знаю при сложных запросах можно использовать к примеру OLAP, пространственную бд. О каком закате эры реляциооных бд может быть после 2D транспанирования? согласен с multic
              0
              Мне кажется, гибридное решение Oracle более-менее все эти нужды покрывает. Можно создавать compression unit, можно классические таблицы, можно materialized view. Думаю, в будущем все вендоры внедрят вертикальную схему (как опцию), хотя на это уйдет лет 5, наверное.
                0
                На низком уровне данные хранятся в Б-деревьях — уже давно во многих крупных СУБД (тот же оракл). SQL — используется как внешний интерфейс для программистов БД. А таблицы — как относительно-унифицированная структура представлений данных между различными источниками.

                Для дерева и куба операция поворота тривиальна — модно укладывать одни данные в столбик, а другие в строку (если мы продолжаем оперировать табличной парадигмой) — как потребуется программисту.

                Другое дело, что деревья и кубы предоставляют принципиально новые возможности в работе с данными (а может и со знаниями) но до того как эти возможности и подходы будут повсеместно внедрены, как SQL, пройдёт не один десяток лет — потому что очень многое надо сначала понять — а потом — это понятое зерно посадить в головах… Это не быстрый процесс.

                Но какими бы ни были СУБД будущего, мне кажется с профессионального программиста БД не будут сняты такие задачи как проектирование и построение хранилищ данных, OLAP(оперативного анализа), Data Mining(интелектуального анализа), классификации, поиска ассоциативных правил, кластеров и прочего…
                  0
                  > На низком уровне данные хранятся в Б-деревьях — уже давно во многих крупных СУБД (тот же оракл).

                  Ого. Прямо-таки все данные и прямо в Б-деревьях? Б-дерево не самый удачный формат при большом объеме данных.

                  > Для дерева и куба операция поворота тривиальна — модно укладывать одни данные в столбик, а другие в строку

                  Операция, наверное, тривиальна, только с компрессией данных, боюсь, будут проблемы )))
            +1
            SQL не супер-удачный язык, но вряд ли он умрет в ближайшем будущем — альтернативы ему нет. Стоунбрейкер это прекрасно понимает и свой движок C-Store он делает как SQL-базу.

            Что касается революции, то я думаю, что ее не будет. Реляционные СУБД живут уже не один десяток лет и проживут еще долго. А вот сколько видов СУБД уже накрылось — не счесть. Навигационные (типа ISAM), сетевые, объектные…
              0
              Смотря что понимать под ближайшим будущим, если 10-15 лет — то точно будет жить, а если 30 — 50 — то далеко не факт.

            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

            Самое читаемое