Как данные хранятся на диске при разной ориентации хранилища в СУБД: чем отличаются колоночные базы от строковых с точки зрения практического использования в дата-инженерии. Сравнительная таблица с примерами и выводами.
Как данные хранятся на диске и при чем здесь ориентация СУБД
Способы хранения данных в СУБД можно разделить на 2 категории: ориентация на строки и ориентация на столбцы. Изменяя способ хранения данных на жестком диске компьютера, можно повлиять на производительность базы данных и ее оптимизацию для транзакционных или аналитических рабочих нагрузок.
Чтобы лучше понять эту разницу, вспомним, как данные хранятся на жестком диске и как они считываются. На жестком диске данные организованы в блоки на самом низком уровне, который представляет собой наименьшую единицу, которую компьютер считывает с диска за раз. Базы данных будут загружать всю информацию из блоков, содержащих искомые данные. Если целевые данные хранятся в меньшем количестве блоков, база данных будет работать намного быстрее. Для логической группировки данных с целью повышения эффективности поиска существует множество походов, таких как разделение и кластеризация.
В базах данных, ориентированных на строки, данные хранятся на диске по одной строке за раз. Каждый фрагмент данных в блоке представляет собой одну строку из таблицы. Такой дизайн отлично подходит для транзакционных рабочих нагрузок, т.е. OLTP-приложений (Online Transaction Processing), в которых выполняются транзакции. Транзакция представляет собой набор операций, которые либо выполняются все вместе, либо не выполняются вообще, если откажет хотя бы одна из них. Например, получение каждого атрибута объекта, добавление объектов в таблицу или удаление объектов из нее. PostgreSQL и MySQL являются популярными примерами баз данных, ориентированных на строки. В них запись новых строк очень проста, поскольку идет добавление всей строки к существующим или новым блокам.
Ориентированное на строки хранилище очень удобно, когда необходимо получить доступ к большинству столбцов одновременно. Поэтому в них не рекомендуется иметь очень широкие таблицы, т.к. маловероятно, что к ним нужен постоянный доступ. Если одновременно требуется всего несколько столбцов, то ориентированное на строки хранение не самый подходящий выбор из-за считывания избыточной информации.
В СУБД, ориентированных на столбцы, данные хранятся на диске по одному столбцу за раз. Каждый фрагмент данных представляет собой целый столбец. Это означает, что все значения одно атрибута сущности будут сгруппированы вместе. Такой принцип хранения данных отлично подходит для аналитических рабочих нагрузок в OLAP-приложениях (Online Analytical Processing), где соединяются данные по очень большому количеству записей. Большинство запросов интересует только подмножество столбцов, доступных только для чтения. Например, расчет среднего возраста клиентов. Примерами колоночных баз данных можно назвать ClickHouse от Яндекса, Cassandra, Snowflake, Amazon Redshift и BigQuery. Также сюда относится Apache HBase, которая работает поверх распределенной файловой системы HDFS, обеспечивая возможности Google BigTable для Hadoop.
Степень сжатия данных в колоночном хранилище очень высока, поскольку каждый столбец имеет один и тот же тип данных. Это особенно важно для проектов Big Data с огромными объемами хранимых и обрабатываемых данных. Также значима возможность добавить в существующую таблицу новый столбец, не перемешивая все данные.
Многие колоночные базы данных используют денормализованную структуру, чтобы выполнять меньше соединений в SQL-запросах. В строковых базах данные обычно хранятся в нормализованных таблицах, чтобы их запись была более эффективной за счет обращения к отдельным таблицам.
Многие современные СУБД поддерживают оба типа хранения. Например, Greenplum и основанная на ней Arenadata DB позволяют для каждой таблицы настроить ориентацию на строки или на столбцы, о чем мы писали здесь и здесь. Это позволяет обрабатывать OLTP и OLAP-нагрузки в одной базе данных. Аналогичный гибридный подход поддерживается и в Teradata. Выбор ориентации хранения для сущности обычно определяется вариантами использования ее атрибутов. Если необходимо обращение ко всем атрибутам сущности, подойдет ориентация на строки. Когда спросом пользуются отдельные атрибуты, имеет смысл их хранить в таблицах, ориентированной на столбцы. А вот в ClickHouse используется только колоночный способ хранения данных, о чем мы подробно рассказываем здесь.
В заключение отметим, что из-за привязки к жесткому диску разделение на колоночную или строковую ориентацию не характерно для резидентных баз данных, т.е. тех, которые размещаются в оперативной памяти (Redis, Tarantool, Apache Ignite, InfinityDB, Memcached, SQLite и Mnesia, используемая в брокере сообщений RabbitMQ). В случае же записи данных на жесткий диск, любую СУБД, как реляционную, так и NoSQL, можно рассматривать в качестве колоночно- или строчно-ориентированного хранилища. Впрочем, как уже было отмечено выше, некоторые системы поддерживают обе модели хранения данных.
Узнайте больше подробностей по проектированию и поддержке современных дата-архитектур в проектах аналитики больших данных на специализированных курсах в нашем лицензированном учебном центре обучения и повышения квалификации для разработчиков, менеджеров, архитекторов, инженеров, администраторов, Data Scientist’ов и аналитиков Big Data в Москве:
Источники
