Привет, меня зовут Костя Осипов, и я занимаюсь разработкой СУБД. На Хабре есть несколько моих статей про MySQL, Tarantool и про всякое-разное. Кроме того, я веду Telegram-канал, где делюсь инсайтами в области управления базами данных. Сегодня я выступаю в роли основателя компании Picodata, создающей одноимённую открытую СУБД, и управляющего директора ПАО Arenadata по исследованиям и разработке. Ниже — вольный пересказ моего недавнего доклада на HighLoad. Он про то, что нас ждёт в мире СУБД завтра, и, в частности, про место резидентных СУБД в архитектурах будущего.
Бэкграунд: эволюция аппаратного обеспечения и СУБД
Если вы, как и я, уже предсказывали тренды СУБД лет десять назад, вы любите посмеяться над собой. Среди различных нереализовавшихся прогнозов — и радикальное снижение стоимости оперативной памяти, и рост её доступных объёмов. Появление энергонезависимой оперативной памяти и исчезновение классических накопителей и SSD-дисков. Также активно прогнозировали переход на облачное, горизонтально масштабируемое аппаратное обеспечение и тотальную контейнеризацию. Не буду останавливаться сейчас на каждом тренде отдельно, подсвечу только главную фишку эпохи Webscale — горизонтальное масштабирование. Подход стал синонимом высоких нагрузок, и типичная СУБД будущего лет десять назад виделась именно как горизонтально масштабируемая, облачная, резидентная СУБД. Тема же сегодняшней статьи — совсем другое будущее, которое к тому же уже практически наступило.
Компания Pascari не так давно анонсировала свой очередной жёсткий диск на 122 TB. Похожие жёсткие диски планирует выпускать и Solidigm. Дело не только в большом объёме, но и в производительности ввода-вывода — один диск предоставляет 3 млн IOPS на чтение и 35 тыcяч IOPS на запись. В восьми таких дисках суммарно более петабайта данных, ну и дополнив конфигурацию современными процессорами на 96–128 ядер (взять хотя бы AMD EPYC 9xxxx), мы получаем мини-дата-центр в формфакторе двухъюнитового сервера. Соотношение размера диска к скорости записи такое, что для того, чтобы просто заполнить диск данными, нужно 12 и более часов.
Но если сверхбольшие накопители стали настолько доступны, нужно ли нам ещё горизонтальное масштабирование? Ведь многие современные СУБД, оптимизированные под многопоточность и большие объёмы памяти (например, тот же OrioleDB — форк PostgreSQL), показывают результаты, сопоставимые с кластерами на нескольких машинах.
Есть и горизонтально масштабируемые системы, которые извлекают из одного узла на порядок бо́льшую скорость, чем классические СУБД. На скриншоте — ScyllaDB: на трёх средних узлах (32 ядра, 3,5 Ghz, 256 GB RAM) с фактором репликации 3 производительность составляет 500 000 запросов в секунду.
Напрашивается вывод, что дело не столько в противопоставлении горизонтальной и вертикальной масштабируемости, сколько во внутреннем устройстве СУБД, которое должно быть адекватно современному оборудованию.
Тренды в мире СУБД
Взрывной рост размера SSD-дисков и количества ядер на одном кристалле действительно является ключевым изменением в оборудовании сегодня, но мир СУБД был бы слишком скучен, если бы дело ограничивалось чем-то одним. Скажу пару слов о тенденциях современного мира данных.
Разделение compute и storage. Сама идея разделения вычислений и хранения противоречит принципу локальности данных (помните девиз Tarantool — bring compute close to storage), но с ростом популярности облаков такой подход, хотя и менее эффективный, сделался экономически оправданным: масштабировать вычисления стало проще, а хранение как сервис значительно подешевело. По мере роста объёмов данных всё чаще приоритет отдаётся снижению стоимости хранения, даже в ущерб скорости и эффективности обработки. Ещё одна причина популярности этого подхода — отставание кластерных СУБД от современных реалий: расширение и сжатие (шринк) кластера, работа в Kubernetes до сих пор считаются «особенными» операциями. Среди лидеров этого тренда — Trino, DuckDB с её облачной MotherDuck, Neon; в то же время существует и контртренд, например Turso. Можно предположить, что в ближайшие 5–10 лет эволюция снова приведёт нас к конвергентным архитектурам: рынок аналитики требует минимальной задержки, и запрос на near-real-time-аналитику становится всё более очевидным.
Закрытие исходного кода и ставка на облака
Вендоры всё активнее переходят на проприетарные лицензии. Среди примеров — MongoDB, Elasticsearch, ScyllaDB, Greenplum, CockroachDB, Timescale. Кто-то стремится защитить свой продукт от облачных провайдеров, кто-то — выстраивает модель продаж «база как сервис» (DBaaS). Деглобализация также вбивает осиновый кол в экосистему открытого ПО; здесь примерами послужат гонения на разработчиков по их территориальной принадлежности, глубокие форки открытых проектов, сделанные в Китае, всё большая консервативность мейнтейнеров крупных проектов. Также мы замечаем:
Фрагментацию лицензий: AGPL, BSL, SSPL. Переиспользование кода между non-free-лицензиями невозможно, что приводит к фрагментации ресурсов сообщества.
Глубокую привязку к облакам: многие СУБД теперь поставляются как managed service и вне этого окружения теряют часть возможностей.
На фоне усиливающегося давления на open source: переходов к проприетарным лицензиям, ограничений на использование кода и растущей зависимости от облачных провайдеров — всё меньше проектов остаются по-настоящему открытыми. В такой ситуации можно предположить, что в долгосрочной перспективе действительно открытыми останутся только платформенные игроки: не те, кто делает одну конкретную СУБД, а те, кто предлагает целую экосистему решений для работы с данными и не зависит от монетизации одного продукта.
Специализация и структуризация продуктов
Тренд на polyglot persistence не новый: он зародился около 15 лет назад с появлением горизонтально масштабируемых key/value-СУБД, таких как Cassandra, а также с развитием шин данных, прежде всего Kafka. Однако куда более показательно то, что, вопреки ожиданиям, консолидации рынка так и не произошло. Напротив, появляются всё новые специализированные СУБД — для задач искусственного интеллекта, аналитики, встраиваемые решения и так далее. По-настоящему новым трендом стал рост модульности в мире баз данных. Ещё 10 лет назад проекты, предлагающие «строительные блоки» для создания СУБД, можно было пересчитать по пальцам одной руки: в первую очередь это RocksDB, SQLite и H2. Их главное преимущество — возможность не разрабатывать все компоненты СУБД с нуля. Например, RocksDB используется в MySQL, ArangoDB, TiDB, Yugabyte и других, а FoundationDB построен на базе SQLite. При этом такие ключевые части, как, например, оптимизатор запросов, долгое время оставались немодульными. Сегодня ситуация начала меняться, и можно предположить, что в будущем СУБД всё чаще будут собираться из готовых компонентов — по аналогии с тем, как современные приложения собираются из библиотек и фреймворков.
Apache DataFusion Kernel представляет собой аналитический оптимизатор запросов, который используется в разных продуктах.
etcd-raft используется как модуль репликации данных как в самом etcd, так и в CockroachDB.
cassandra-accord, реализация нового алгоритма управления транзакциями в Apache Cassandra изначально создана и развивается как отдельный проект.
DuckDB может быть использована далеко не только в контексте DuckDB Labs.
Turso переписал sqlite на Rust, сделав эту библиотеку доступной “нативно” для Rust экосистемы.
Dremio со своим проектом Apache Iceberg переопределяет ландшафт работы с холодными данными.
Всё это соответствует и изменениям в бизнес-ландшафте: CIO и CDO больше не принимают решения о покупке той или иной СУБД, а делают ставку на экосистему в целом (Amazon, Google или, например, в России — Sber Platform V, Yandex, Arenadata), а разработчику оставляют выбор конкретного инструмента в пределах экосистемы.
Место резидентных СУБД
Цель приведённого обзора — дать обоснование продуктовому видению Picodata, о котором я начну рассказывать далее. Так, например, появление больших и быстрых дисков означает, что скорость доступа к диску больше не может быть фактором выбора резидентной СУБД. Закрытие вендоров и переход в облака означают, что для того, чтобы сохраниться как продукт и сообщество, необходимо в первую очередь дать разработчикам удобный инструмент для решения типовых задач. Тренд на разделение compute и storage, эластичность означает, что добавление и удаление узлов в кластере и работа в Kubernetes должна стать рутиной и не влиять на производительность, пропускную способность и, главное, troubleshooting кластера. Разберёмся в этом более детально.
Резидентные СУБД достигают кратного прироста производительности не просто за счёт размещения данных в оперативной памяти. Действительно, тогда было бы достаточно дать PostgreSQL побольше памяти под кэш. Для кратного ускорения используются специализированные структуры данных, менеджеры транзакций, управление многозадачностью. Для горизонтального масштабирования применяется архитектурный подход shard-per-core: все данные сегрегируются по ядрам процессора, таким образом устраняются блокировки и конкуренция потоков за данные. Нужны ли все эти усилия, если скорости диска стало достаточно?
Чтобы ответ на этот вопрос стал очевидным, достаточно взглянуть на конкретные цифры. Время отклика современного SSD составляет 10–20 микросекунд, тогда как доступ к оперативной памяти (DIMM4) занимает всего 10–20 наносекунд. Несмотря на то что диски стали в 100 раз быстрее по сравнению с SAS HDD (средняя задержка — 1–2 миллисекунды), разница между SSD и памятью всё ещё составляет три порядка. Но что происходит, если между чтением и пользователем стоит операционная система и сеть? К задержке добавляются накладные расходы ОС — возьмём, например, 50 микросекунд, что соответствует размеру кванта планировщика в Linux по умолчанию. Плюс время передачи данных внутри дата-центра — около 200–300 микросекунд. В итоге общее время ответа складывается из всей этой цепочки, и легко увидеть, что сами операции чтения — будь то с диска или из памяти — становятся несущественными на фоне общей стоимости запроса в микросервисной архитектуре.
А что, если отказаться от идеи дезагрегации вычисления и хранения, и логику приложений, для которых скорость работы действительно критична, разместить внутри СУБД, в виде плагина или хранимой процедуры? И вот мы снова вернулись к ускорению на 3–5 порядков, которое даёт прямой доступ к данным.
Сценарии, когда подобного рода трансформация может быть оправдана:
интеграция данных из разных источников в виде высокодоступной, массовой витрины - например, личный кабинет клиента для любой компании федерального масштаба;
тарификация, высокочастотная торговля, real time bidding, рекламный таргетинг, скоринг в реальном времени;
компрессия и анализ IoT данных на лету, платформы данных в промышленности;
ускорение ERP, расчетные задачи (себестоимость, отчётность, заработная плата) для крупных вертикально интегрированных компаний.
Во всех этих случаях «чуть быстрее» может означать «существенно выигрываем в бизнесе».
Вот и выходит, что в то время, как вертикально масштабируемые СУБД снова набирают популярность благодаря быстрому росту мощности серверов, IMDG (in-memory data grid) подход не потерял свою релевантность.
Хранимые процедуры и подход микросервисов
Поговорим про ограничения данного подхода. Часть из них — в предубеждениях, но часть действительно существует, и хороший инструмент должен их учитывать.
В большинстве высоконагруженных проектов сегодня хранимые процедуры — это антипаттерн. Знаете ли вы, что ближайшим родственником SQL/PSM (это стандартный диалект PL/SQL) является ADA, созданный в 1980 году? Но дело даже не в архаичном синтаксисе.
Сложность управления процессом разработки
В мире микросервисов и DevOps мы привыкли хранить код в системе контроля версий, масштабировать вычисления stateless-контейнерами, накатывать обновления пакетами, тестировать всё в CI/CD, отлаживаться онлайн с помощью A/B-тестирования. Аналогов современным методам разработки в мире хранимых процедур просто нет. Ну или о них никто не говорит.Сложность отладки и тестирования
Как запустить интерактивный отладчик, изолировать исключение или предотвратить возникновение hot spots на продуктивных данных? Для действительно высоконагруженных приложений нужны не только функциональные тесты, но и тесты производительности. В то же время практики тщательного покрытия тестами миграций схемы данных либо логики СУБД не слишком распространены: проще воспользоваться schema-less-подходом и хранить всё в json (до свидания не только производительность, но и качество данных).Сложность обновлений: как консистентно обновить логику внутри распределённого кластера без простоя? Инструменты вроде Flyway или Liquibase помогают мигрировать схемы, но с логикой в базе (особенно распределённой) они не работают. Кроме того, теперь версии схемы и кода хранимых процедур должны совпадать. При этом, если во время обновления что-то пошло не так, откатиться может быть невозможно.
Picodata предлагает как инструменты, так и методы по работе с перечисленными ограничениями. Далее поговорим о них.
Домены отказа, тиры и версионируемые плагины на Rust
Задам контекст. Задача любой кластерной СУБД — разделение данных между узлами таким образом, чтобы для пользователя они представляли единое целое, при этом система могла использовать мощности всех узлов одновременно.
Для этого мы:
Разделяем все данные на фрагменты — шарды, при этом каждый шард обслуживает один процесс СУБД, выполняющийся на одном ядре процессора. Шард хранит данные всех имеющихся таблиц, а как именно данные таблицы разделяются между множеством шардов, определяется при создании таблицы.
При катастрофоустойчивой конфигурации шард обслуживается не одним процессом СУБД, а несколькими, каждый из которых хранит полную копию данных шарда и запущен в своём дата-центре. Чтобы устранить путаницу между шардами и процессами СУБД, мы процессы также называем инстансами или узлами, а набор инстансов, хранящий данные одного шарда, — репликасетом.
Для того чтобы легко можно было перебалансировать данные между шардами, есть вторичное разбиение данных внутри шарда — бакеты. Если размер одного шарда — десятки или сотни гигабайт, то размер бакета исчисляется в десятках мегабайт, что позволяет гибко балансировать нагрузку и при необходимости оперативно перемещать лишь часть данных шарда на другой узел.
Тут стоит отметить, что данный подход одинаково хорошо масштабируется как горизонтально, так и вертикально: если на одной машине множество ядер, мы запускаем равное числу ядер число процессов СУБД, таким образом максимально утилизируя мощность сервера.
Но вся эта когнитивная сложность, необходимая для эффективной утилизации ресурсов современного «железа», скрыта от пользователя, ведь всё управление кластеризацией и балансировкой данных происходит автоматически. Для того чтобы управлять большим кластером было удобно и просто, мы предприняли следующие шаги:
Реализовали внутренний state provider. Аналог etcd, который является частью каждого узла и хранит состояние в системных таблицах. Таким образом, все метаданные кластера консистентно реплицируются на все узлы (для репликации мы использовали популярную библиотеку в Rust-экосистеме raft-rs), что позволяет восстановить топологию и схему данных кластера практически при любой аварии. Встроенная репликация также работает значительно быстрее, чем внешний сервис, что позволяет быстро развёртывать большие кластеры и забыть об ошибках добавления или удаления узлов.
Предложили DBA ёмкий и лаконичный способ описания конфигурации, введя концепцию доменов отказа. Домен отказа — это пара ключ/значение, которая описывает расположение узла в кластере. Например, datacenter: msk. Всё, что администратор должен сделать при добавлении инстанса, — указать, где он находится. Остальное берёт на себя встроенный кластер менеджер: скопирует на инстанс начальное состояние, определит пару для репликации данных, перераспределит данные между существующими инстансами и новым и так далее.
Для управления кластером используются лишь две операции: добавить инстанс (add) или удалить инстанс (expel). Все процессы СУБД доступны для подключения и выполнения запросов, автоматически маршрутизируя вычисления к нужному инстансу с данными. Восстановление после аварии, перебалансировка данных выполняются также автоматически.
Замечу, что домен отказа не обязан описывать именно дата-центр. Он может задавать и конкретный сервер или стойку внутри дата-центра.
На иллюстрации два сервера в одном дата-центре, при этом данные 100% зарезервированы, т.е. каждый сервер содержит полную копию.
Picodata автоматически распределила реплики между доменами.
При падении одной машины или даже целого дата-центра система всё ещё остается работоспособной (при условии, что вы настроили нужное число реплик).
Тиры
Типовые кластера чаще всего состоят из одинаковых инстансов и выполняют одну задачу, но есть и более сложные сценарии, когда этого недостаточно.
часть ресурсов кластера нужно выделить для вычислений или балансировки нагрузки;
развёртывание 1+1 или 2+2: у вас два DC, и нужно, чтобы при падении одного данные оставались доступны на запись в другом (но не хочется городить целый третий DC);
разные данные необходимо хранить с разным уровнем надёжности;
размер данных превышает размер оперативной памяти, и для ряда таблиц необходимо использовать движок хранения vinyl.
Каждый инстанс, таким образом, принадлежит строго одному домену отказа и одному тиру. Вместе эти два параметра описывают множество возможных топологий развёртывания, как полностью симметричных, где каждый домен отказа содержит все существующие тиры, так и асимметричные, когда, например, арбитр находится в выделенном домене отказа (дата-центре), не хранит данные и предназначен для того, чтобы обеспечить 100% доступность кластера даже в случае выхода из строя основного дата-центра.
Управление кодом и миграциями: Blue-Green Deploy для плагинов
Подождите, всё красиво, наверное, но при чём здесь in-memory-вычисления? Управление кластером «из коробки» реализовано во многих кластерных СУБД: MongoDB, CockroachDB, Cassandra и так далее. Действительно, домены отказа и тиры никак не помогают версионировать и отлаживать хранимые процедуры. Они являются фундаментом отказоустойчивого кластера, но для действительно blue/green-развёртывания нам понадобится не один такой кластер, а два (blue и green), и они должны быть соединены репликационным каналом:
В микросервисном мире Blue-Green Deploy — это практика, позволяющая разворачивать новую версию приложения параллельно со старой, тестируя её «вживую», и при любом сбое откатываться без простоя. Мы же решили распространить этот принцип и на код, живущий внутри СУБД. Почему?
Кластерная среда усложняет обновления
В обычной СУБД вы обновляете код или схему «на одном сервере». Но если база распределена, всё должно обновляться согласованно и сразу на всех узлах кластера, чтобы избежать рассинхронизации (один узел с новой версией схемы, другой — со старой, один — с одной версией приложения, другой — со старой).Необходимость «аккуратной» миграции
Транзакционные данные могут быть «привязаны» к структурам, которые меняются с версией кода. Если в плагине добавились новые поля или изменились таблицы, то сперва нужно мигрировать схему и данные, затем включать новую логику.Безопасный откат
Любая новая версия может содержать ошибки или вести себя непредсказуемо под нагрузкой. Blue-Green Deploy даёт понятные шаги отката (Rollback), если что-то пошло не так.
Мы используем модель Blue-Green Deploy не только для плагинов, но и для любой пользовательской логики в классической микросервисной архитектуре. Процесс состоит из чётких шагов: сначала происходит миграция схемы (SQL-скрипт), затем конфигурация новой версии плагина, а только затем включение новой версии кода во всём кластере. Если на каком-то этапе возникает ошибка, вся операция откатывается.
Компоненты Blue-Green Deploy в Picodata
Версия плагина
У каждого плагина есть версия (например, 1.0, 1.1), и в кластере не может одновременно существовать более двух разных версий одного и того же плагина (Blue — старая, Green — новая).Манифест (manifest)
Это специальный файл с описанием, что за плагин мы устанавливаем, как он собирается, какой у него функционал. Он также указывает на SQL-скрипты миграции.
name: weather_cache
description: That one is created as an example of Picodata's plugin
version: 0.1.0
services:
- name: weather_service
default_configuration:
openweather_timeout: 5
migration: migrations/0001_weather.dbМиграции (up / down)
В манифесте прописаны SQL-файлы, где есть секции up и down.
-- pico.UP
CREATE TABLE "weather" (
id UUID NOT NULL,
latitude NUMBER NOT NULL,
longitude NUMBER NOT NULL,
temperature NUMBER NOT NULL,
PRIMARY KEY (id)
)
USING memtx
DISTRIBUTED BY (latitude, longitude);
-- pico.DOWN
DROP TABLE "weather";up запускается при установке или обновлении плагина (например, добавляются новые таблицы или поля).
down выполняется при откате (убираются изменения, если мы решили вернуться на предыдущую версию).
Конфигурация (configuration)
Когда плагин установлен, нужно задать ему параметры (вроде ключей доступа, настроек внешних соединений и так далее). Вся конфигурация хранится консистентно во всём кластере, а не только на одной ноде. Каждая установленная версия имеет свой набор конфигурационных параметров, то есть их можно менять независимо. При установке новой версии плагина начальные значения конфигурации берутся из старой версии и из манифеста.Enable / Disable
После миграции и настройки мы можем «включить» (enable) новую версию плагина или «выключить» (disable) старую. Это происходит синхронно и согласованно на всех нодах.
Как выглядит процесс обновления плагина
Ставим (или загружаем новую версию) плагина
Picodata получает манифест, собирает/распаковывает плагин, регистрирует его как «возможный для установки».Выполняем миграцию
Запускается up-скрипт, меняющий схему (если нужно). Все изменения происходят атомарно на всех узлах кластера. Если миграция прошла успешно, мы сохраняем состояние. Если нет — откат и лог ошибок.Настраиваем и «привязываем» к нужным тирам
При необходимости указываем, на каких тирах (и узлах) должен работать плагин, какие параметры ему передаются. Конфигурация реплицируется по всему кластеру.Enable новой версии
Как только всё готово, говорим системе «включить» новую версию. Она начинает обслуживать запросы, а старая продолжает существовать до тех пор, пока мы не убедимся, что всё работает.Disable/Remove старой версии
Если всё нормально, отключаем старую версию. Если что-то пошло не так — делаем откат (rollback), запустив down для миграции и вернувшись к прежнему коду.
Но и это ещё не всё. Для того чтобы новые версии можно было легко отлаживать без влияния на production-развёртывание, мы реализовали специальный плагин — ouroboros, — осуществляющий логическую асинхронную репликацию между кластерами Picodata. Ouroboros позволяет в любой момент создать копию оригинального кластера, а затем реплицировать либо все данные исходного кластера, либо выборочно, лишь некоторые таблицы. Например, для сложного приложения реплицироваться может лишь таблица, содержащая входящие запросы, что позволяет «выполнить» новую версию логики приложения на резервном кластере независимо от основного. После успешной отладки новой версии на резервном кластере у пользователя есть выбор: постепенно переключить весь трафик на резерв, поменяв таким образом blue- и green-кластеры местами, либо установить обновление на основной кластер.
Мы также основательно подошли к вопросу модуляризации кода и удобства его доставки. Picodata использует Rust как основной язык расширений и пользуется модульной архитектурой этого языка программирования. Внутри плагина код может быть разбит на сколь угодно большое количество модулей и зависимостей, но при создании установочного бандла мы всегда создаём один-единственный бинарный файл. Если кластер использует несколько плагинов, они взаимодействуют между собой через общие данные (таблицы), а не код. Это защищает production от карнавала зависимостей на несовместимые версии при установке нескольких плагинов. Если вы знакомы с экосистемой Go, то ближайшей аналогией будет именно go build. Ну и, наконец, мы создали утилиту pike, которая автоматизирует все шаги разработки и поставки плагина в кластер.
Все эти инструменты и методы в совокупности и делают подход с размещением логики рядом с данными управляемым.
SQL в Picodata
Плагины и расширения в Picodata имели бы крайне ограниченный функционал, если бы им не был доступен кластерный SQL. Работу SQL мы также постарались сделать максимально эффективной.
Так, основным протоколом взаимодействия с СУБД мы сделали сетевой протокол PostgreSQL. Это, в частности, означает, что работают многие инструменты PostgreSQL-экосистемы, например psql и DBeaver, а также работают многие драйверы.
В некоторых известных проектах (например, CockroachDB или TiDB) данные хранятся как бы в едином пространстве «ключ-значение» (RocksDB, TiKV и так далее) и логика SQL реализована поверх NoSQL-хранилища. Это удобно для автоматического шардирования, но может порождать ненужные перемещения данных между узлами кластера во время JOIN.
Picodata передаёт управление коллокацией связанных данных в руки разработчика.
Для сценариев работы с клиентом при создании схемы можно добиться того, чтобы все данные по одному клиенту находились на одном узле, а глобальные таблицы-справочники были идентичны на всех узлах. В результате:
большинство бизнес-сценариев не потребует перемещения данных между узлами кластера;
большинство транзакций будет выполняться локально на одном узле, т.е. конфликты транзакций и взаимные блокировки исчезнут;
нагрузку на кластер можно будет действительно распараллелить.
Коллокация по ключу
По умолчанию данные разбиваются между всеми узлами кластера по ключу распределения:
CREATE TABLE ITEM (
I_ID INTEGER NOT NULL,
I_IM_ID INTEGER,
I_NAME VARCHAR(24),
I_PRICE NUMBER,
I_DATA VARCHAR(50),
PRIMARY KEY (I_ID)
)
USING MEMTX DISTRIBUTED BY (I_ID);bash
pkill --full "i2"
pkill --full "i4"SELECT I_ID FROM ITEM WHERE I_ID=1;
-- результат:
+------+
| I_ID |
+======+
| 1 |
+------+
(1 rows)SELECT I_ID FROM ITEM WHERE I_ID=2;
-- результат:
error: requested bucket is unreachableДля управления колокацией данных при создании таблицы используется расширение SQL DISTRIBUTED BY. Похожий синтаксис реализован в Greenplum. Если мы говорим DISTRIBUTED BY (client_id) для таблиц orders, payments, sessions, то все записи определённого клиента попадут на один узел в кластере.
Глобальные таблицы
Для данных, необходимых на всех узлах, есть возможность задать глобальное (global) распределение.
CREATE TABLE WAREHOUSE (
W_ID INTEGER NOT NULL,
W_NAME VARCHAR(10) NOT NULL,
W_TAX DOUBLE,
W_YTD DOUBLE,
PRIMARY KEY (W_ID)
)
USING MEMTX DISTRIBUTED GLOBALLY;В аналитических сценариях глобальные таблицы используются для “small dimension table”: когда факт-таблицы распределены, а измерения глобальны.
Итоги
Можно сказать, что Picodata — это попытка переосмыслить in-memory-базы данных в эпоху, когда современное «железо» (миллионы IOPS, сотни терабайт на одном сервере) делает горизонтальное масштабирование далеко не всегда оправданным. Мы постарались сделать удобный инструмент для разработчиков, занимающихся действительно высоконагруженными проектами. В эпоху всеобщей смены лицензий и закрытия ключевых возможностей мы не только сохранили открытую лицензию BSD, но и продолжаем инвестиции в открытое ПО. Для наших корпоративных клиентов мы предлагаем версию продукта, имеющую сертификат ФСТЭК и целый ряд коммерческих расширений: по работе с промышленными данными, миграции с проприетарных СУБД, замене Redis или Cassandra.
Каждый день в продукте появляются новые возможности. Версия 25.1 реализует оконные функции. В среднесрочных планах такие возможности, как материализованные представления, стоимостный оптимизатор запросов, колоночное хранение. Если будущее сложится так, что in-memory-СУБД заместят классические системы, такие как PostgreSQL и Oracle, то в локомотиве этого движения точно будет Picodata.
