Два размера подходят большинству: PostgreSQL и Clickhouse

С момента появления System R в 1974 году реляционные базы данных в целом, и SQL-базы в частности, стали доминирующим подходом для хранения данных, и до сих пор сохранили это положение, несмотря на появление многочисленных серьезных конкурентов. Слухи о кончине и упадке традиционных реляционных баз данных появляются постоянно, но PostgreSQL уверенно держит позиции и опережает  как своих предшественников, так и предполагаемых преемников.

Фактически, база данных MySQL была настолько распространена, что стала частью одноименного стека LAMP (Linux, Apache, MySQL, Perl), преобладающего в ранних веб-разработках.

Единственным большим исключением из этой тенденции является OLAP, со специализированными методами, позволяющими резко повысить производительность определенных рабочих нагрузок. А новые соперники, такие как ClickHouse, качественно изменили подходы к аналитике.

Один размер не подходит для всех

Часто бывает, что доминирующая технология применяется бездумно, даже если это нецелесообразно. По этой причине часто встречаются решения, когда любые виды данных помещаются в реляционные базы данных общего назначения. Можно найти такие экстремальные примеры, как базы данных Oracle для датасетов с  пятью небольшими элементами (не столбцами, а именно единицами данных) или использование компанией Apple базы данных SQLite для логов (они позже исправили эту ошибку).

Разработка DNS-сервера Bind10 началась с целью решить проблемы масштабирования Bind9, используя SQLite в качестве бэкенда. Но разработка была прекращена ISC в 2014 году, а OSS-проект Bundy в настоящее время не активен. С другой стороны, PowerDNS изначально фокусировался на масштабировании производительности с помощью MySQL/PostgreSQL.

В 2005 году Майкл Стоунбрейкер (Michael Stonebraker), ученый в области баз данных (Ingres и позже PostgreSQL), вместе с Угур Кетинтемел (Uğur Çetintemel) написали статью «One Size Fits All»: An Idea Whose Time Has Come and Gone» (перевод на русский — «Один размер пригоден для всех: идея, время которой пришло и ушло«), утверждая, что все это слишком затянулось, подкрепив этот аргумент бенчмарками.

Вкратце, есть множество рабочих нагрузок помимо основной — Online Transaction Processing (OLTP), с которыми базы данных с привычной архитектурой не справлялись и их применение не имело смысла.

Следует отметить, что Стоунбрейкер  и Кетинтемел выступали не против реляционных баз данных или SQL, а против конкретной архитектуры, происходящей от оригинальных систем System R и Ingres, которые были и продолжают использоваться в большинстве систем баз данных общего назначения.

Эта архитектура имеет следующие особенности:

• Дисковые хранилища, ориентированные на строки, и индексные структуры

• Многопоточность для уменьшения задержек

• Управление параллелизмом через блокировки

• Восстановление на основе журналов транзакций

Помимо задач обработки текста, с которой традиционная архитектура справляется плохо, также есть хранилища данных, где  столбцовые хранилища оказались в 10-100 раз эффективнее традиционных хранилищ, ориентированных на строки.

Clickhouse

Прогноз об отделении OLAP-движков от обычных баз данных в значительной степени сбылся, и теперь OLAP сами по себе являются важной категорией, а Vertica, коммерческое ответвление оригинального cstore, о котором идет речь в статье, является одним из основных игроков.

Практические преимущества этих баз данных для аналитической обработки данных, как и предполагалось, достаточно существенны, поэтому наличие отдельного движка для них вполне оправдано.

Или даже необходимо, как это произошло в случае с OLAP-базой данных Yandex ClickHouse, которая недавно была выделена в стартап, получивший финансирование в рамках серии В на сумму 250 млн долларов США. Разработчики ClickHouse хотели анализировать данные в реальном времени, но не с помощью специализированных структур данных, как это обычно бывает в данной области, а с помощью стандартного языка SQL. Конечно, для использования специализированных структур были причины: использование стандартных инструментов считалось невозможным, отчасти из-за архитектуры. Но как это часто бывает, невозможное оказалось «просто» большим объемом работы и блестящими инженерными решениями. Через несколько лет разработчики получили то, к чему стремились: специализированный движок для OLAP, но с возможностью SQL-запросов и аналитики в реальном времени.

Впечатляют как инженерные решения, так и результаты бенчмарков, включая наши собственные тесты (видео).

ClickHouseзначительно быстрее расширений PostgreSQL, таких как CitusDB или Timescale DB, и, по некоторым данным, быстрее, чем Vertica.

Конец эпохи?

В статье 2005 года OLTP оставалась единственной областью, где традиционная архитектура (дисковая, ориентированная на строки, многопоточная) оставалась жизнеспособной. Два года спустя Стоунбрейкерс соавторами опубликовали статью «The end of an Architectural Era (It’s Time for a Complete Rewrite)»  (перевод на русский — «Конец архитектурной эпохи, или Наступило время полностью переписывать системы управления данными«), где утверждалось, что даже для OLTP существующие движки могут быть превзойдены в десятки раз.

Ключевым моментом стало то, что давно принятые предположения об относительной производительности различных компонентов больше не являются точными, и выяснилось, что, около 90% бюджета производительности движка базы данных используется не для фактической обработки данных, а для накладных расходов, таких как управление буферами и блокировками. Таким образом, если бы мы могли устранить эти накладные расходы, то сделали бы механизм базы данных, который в десятки раз быстрее существующих. Для достижения таких результатов потребуется создать однопоточный движок базы данных, работающий в оперативной памяти, что является радикальным отходом от существующей архитектуры.

Но это не выглядит таким уж беспрецедентным. С момента создания первых баз данных емкость оперативной памяти увеличилась более чем в миллион раз, поэтому многие рабочие нагрузки, которые раньше требовали постоянного хранения из-за своего размера, теперь можно обрабатывать в памяти.

Например, еще в начале 2000-х годов Yahoo придерживалась политики, согласно которой любой датасет размером менее 2 ГБ должен храниться в оперативной памяти, а не на диске. Чуть позже архитектуры EventPoster, In-Process REST и LMAX с шаблоном Disruptor показали, что переход от сложных многопоточных систем на базе дисков к однопоточным архитектурам на базе оперативной памяти может дать огромные преимущества в плане простоты, надежности и производительности.

И это при 32-битных вычислениях. Сегодня мы можем получить отдельные серверы с десятками терабайт памяти, сконфигурированные для нас одним щелчком мыши (с последующим выставлением счета…), поэтому рабочие нагрузки, которые мы можем хранить в оперативной памяти, весьма значительны.

Stonebraker и его команда создали H-Store, академический прототип, и voltdb, коммерческий продукт с соответствующим стартапом.

Это не вызвало бурного распространения в мире баз данных

Удивительно, но это не потому, что не работает так, как задумано. Из всех отчетов следует, что все действительно работает так, как заявлено, и выполняет свои обещания.

Однако эти обещания сопровождаются компромиссами, и похоже, что они не подходят для большинства доменов. Во-первых, хотя хранение всей базы данных в оперативной памяти в наше время вполне осуществимо, но это, вероятно, часто не лучшее решение с точки зрения цены и производительности,  когда большинство данных являются холодными. Во-вторых, хотя пиковая производительность может быть намного выше, машины сейчас настолько быстры, что максимальная пиковая производительность необходима только для очень специфических случаев.

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

PostgreSQL

Итак, похоже, что эра баз данных OLTP с традиционной архитектурой на самом деле не закончилась. Но это не должно сильно беспокоить профессора Stonebraker, поскольку претендент на победу по-прежнему является его детищем, просто более ранним. Нет, не Ingres — ранний публичный аналог System R от IBM, а его преемник: PostgreSQL.

PostgreSQL становится, или уже стал, лидером среди баз данных с традиционной архитектурой, в соответствии с настроениями в отрасли и различными рейтингами. Конечно, среди баз данных, не связанных тем или иным образом с крупными вендорами баз данных. 

В GitLab мы тоже используем PostgreSQL с репликацией, отказавшись от MySQL в 2019 году, отчасти потому, что PostgreSQL действительно обладает важными для нас функциями, а также по причине того, что большинство наших клиентов и так его использовали.

А что насчет NoSQL?

Ну, и что насчет этого? Хотя движение NoSQL в начале 2000-х годов говорило о некоторых недостатках популярных баз данных, технологические ограничения действительно имели значение только в очень редких случаях. NoSQL — это не совсем категория СУБД, а скорее особенность таких движков баз данных, как PostgreSQL.

С увеличением вычислительной мощности и быстродействия хранилищ большие объемы и скорость транзакций могут обрабатываться традиционными движками баз данных, а нетрадиционные могут обслуживать реляционные модели, используя SQL в качестве интерфейса, например, VoltDB и Spanner от Google, построенный на основе BigTable. Бывают ситуации, когда реляционная база данных не нужна, а достаточно хранилищ ключ-значение или документов JSON, но, например, PostgreSQL прекрасно справляется с JSON в большинстве таких случаев. В современных реляционных базах данных также есть поддержка и специализированных возможностей, таких, как полнотекстовый поиск или GIS.

Через пару дней в OTUS пройдет открытый урок «Особенности мажорного обновления PostgreSQL с расширениями на примере расширения PostGIS». На этом занятии рассмотрим:
— Какие виды обновления PostgreSQL бывают.
— Какие методы используются при обновлении системы.
— Как обновить кластер БД, в котором уже установлены расширения.
— Особенности методов обновления.
Регистрация на занятие для всех желающих — по ссылке.