Некоторое время назад мы писали о VMware SplinterDB - высокопроизводительной нереляционной базе данных типа key-value. Это open source решение, которое разработано VMware Research Group в плотном сотрудничестве с группой разработки решений линейки vSAN. Ключевой особенностью этой базы данных является возможность быстро работать как с запросами на вставку/обновление данных, так и с запросами на чтение пар ключ-значение из хранилища. На днях на сайте проекта VMware Labs вышел прототип реализации сервера этой СУБД - SplinterDB Server 0.1 (в отличие от исходного проекта это не open source).
SplinterDB максимально использует возможности ядер процессоров, легко масштабируется и использует все преимущества технологии организации хранилищ NVMe. Поэтому SplinterDB можно использовать поверх существующих key-value хранилищ, а также традиционных реляционных баз данных, NoSQL-СУБД, микросервисов, обработчиков потоков, архитектуры edge/IoT, хранилищ метаданных и графовых баз данных.
SplinterDB Server - это прототип хранилища ключ-значение, который распространяется как образ контейнера (для запуска потребуется Docker, Podman или любой другой аналогичный инструмент), который исполняется на сервере gRPC. Спецификация протокола gRPC также включена в релиз, есть также примеры клиентских приложений, написанных на языках Java и Go.
Напомним, что чтобы избежать замедления работы, SplinterDB и его аналоги время от времени объединяют несколько отсортированных таблиц в одну (это называется compaction). Это создает дисбаланс между скоростью на чтение и скоростью на запись. За счет этого запросы исполняются быстро, но вот вставка данных замедляется. Если compaction делать реже, то вставка будет работать быстрее, но и чтение замедлится. SplinterDB делает compaction более чем в 8 раз реже, чем ее аналог RocksDB, поэтому вставка данных и работает в первой БД примерно в 7 раз быстрее, чем во второй.
Но что со скоростью на чтение? SplinterDB использует новый вид фильтра, называемый routing filter. Один такой фильтр может заменить несколько фильтров типа Bloom, cuckoo или ribbon и может покрыть сразу несколько таблиц. Обычные фильтры могут сказать только, есть ли соответствующий ключ в доступности в данный момент или нет, а вот routing filter может не только сказать, что ключ есть, но и указать на то, какая конкретно из отсортированных таблиц его содержит. Поэтому запросам нужно делать гораздо меньше работы по поиску в фильтрах, а значит снижается нагрузка на CPU.
В итоге и вставка работает в 7 раз быстрее, и запросы на чтение в 1.5 раза производительнее:
На данный момент в работе СУБД есть такие ограничения: длина ключа 104 байта, значения - 1 КБ. Имейте в виду, что лучшие результаты SplinterDB показывает именно на NVMe-хранилищах из-за особенностей реализации алгоритмов работы с фильтрами.
Развернуть образ SplinterDB Server можно следующей командой:
RSS
