На сайте проекта VMware Labs появилось обновление базы данных SplinterDB версии 0.2.9. Напомним, что это высокопроизводительная нереляционная база данных типа key-value. Изначально Open source решение SplinterDB разработано VMware Research Group в плотном сотрудничестве с группой разработки решений линейки vSAN. Ключевой особенностью этой базы данных является возможность быстро работать как с запросами на вставку/обновление данных, так и с запросами на чтение пар ключ-значение из хранилища. В ноябре мы писали о том, что вышел прототип реализации сервера этой СУБД - SplinterDB Server 0.1 (в отличие от исходного проекта это не open source).

По итогам тестов VMware эта БД работает в 7 раз быстрее на запись и в 1.5 раза на чтение по сравнению с ближайшим аналогом - RocksDB:

Давайте посмотрим, что нового появилось в SplinterDB 0.2.9 и предыдущем небольшом обновлении:

• В документации есть строчка о простом старте сервера одной командой
• Улучшенные руководства по использованию примеров на языке Go
• Добавлены фоновые сообщения в логе
• Улучшена эффективность работы с дисковым пространством для маленьких ключей
• Ключи ограничены длиной 102 байта
• Исправления ошибок в библиотеке SplinterDB library

Развернуть образ SplinterDB Server можно следующей командой:

docker pull projects.registry.vmware.com/splinterdb_server/grpc-server:0.1.20

Запускается он так:

docker run --rm -it --init projects.registry.vmware.com/splinterdb_server/grpc-server:0.2.9 --help

Скачать SplinterDB Server 0.2.9 можно по этой ссылке. Помните, что это экспериментальный код, его нельзя использовать в производственной среде!

Некоторое время назад мы писали о 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 можно следующей командой:

docker pull projects.registry.vmware.com/splinterdb_server/grpc-server:0.1.20

Запускается он так:

docker run --rm -it --init projects.registry.vmware.com/splinterdb_server/grpc-server:0.1.20 --help

Скачать SplinterDB Server 0.1 можно по этой ссылке. Помните, что это экспериментальный код, его нельзя использовать в производственной среде!

В середине июня компания VMware представила сообществу Open Source свою новую разработку - нереляционную базу данных типа key-value SplinterDB. Базы данных с механиками "ключ-значение" работают очень быстро и в данный момент применяются для решения широкого круга задач. VMware сделала тут вот какую вещь - эта СУБД работает еще быстрее остальных (иногда в разы), поэтому она позиционируется как "ultra fast"-решение для высокопроизводительных нагрузок.

Платформа SplinterDB была разработана VMware Research Group в плотном сотрудничестве с группой разработки решений линейки vSAN. Ключевой особенностью этой базы данных является возможность быстро работать как с запросами на вставку/обновление данных, так и с запросами на чтение пар ключ-значение из хранилища. Вот так это выглядит в сравнении с СУБД RocksDB (она была разработана в Facebook), которая работает в той же нише, что и SplinterDB, на примере бенчмарка Yahoo Cloud Services Benchmark (YCSB):

SplinterDB максимально использует возможности ядер процессоров, легко масштабируется и использует все преимущества технологии организации хранилищ NVMe. Поэтому SplinterDB можно использовать поверх существующих key-value хранилищ, а также традиционных реляционных баз данных, NoSQL-СУБД, микросервисов, обработчиков потоков, архитектуры edge/IoT, хранилищ метаданных и графовых баз данных.

SplinterDB - это внедренное key-value хранилище во внешней памяти, что означает, что приложения используют SplinterDB путем линковки библиотеки SplinterDB в свой исполняемый файл. SplinterDB хранит данные на высокопроизводительных дисках SSD NVMe и может масштабироваться до огромных датасетов, которые значительно превышают объемы доступной памяти RAM.

На картинке выше показан пример, где SplinterDB и RocksDB хранили датасет 80 GiB в системе, имеющей 4 GiB RAM. Так как лишь малая часть базы данных помещалась в кэш оперативной памяти, то эффективность работы подсистемы ввода-вывода была ключевым фактором оценки производительности. Для теста использовались диски Intel Optane SSD, которые поддерживают 2 GiB/sec на чтение и запись. При этом RocksDB использовала только 30% доступного канала обмена с хранилищем (для операций записи), а SplinterDB использовала до 90% канала. При чтении SplinterDB также показала себя в полтора раза лучше, чем RocksDB, за счет более эффективного использования CPU и техник кэширования.

В чем же секрет такого высокого уровня производительности? Дело в том, что современные key-value хранилища (включая SplinterDB, RocksDB, LevelDB, Apache Cassandra и другие) хранят данные в больших сортируемых таблицах. Запросы ищут значения в каждой таблице, спускаясь от новых данных к старым. Таким образом, запросы замедляют систему, накапливая все больше и больше таблиц с данными. Чтобы избежать замедления работы, эти системы время от времени объединяют несколько отсортированных таблиц в одну (это называется compaction). Это и создает дисбаланс между скоростью на чтение и скоростью на запись. За счет этого запросы исполняются быстро, но вот вставка данных замедляется. Если compaction делать реже, то вставка будет работать быстрее, но и чтение замедлится.

SplinterDB делает compaction более чем в 8 раз реже, чем RocksDB, поэтому вставка данных и работает в первой примерно в 7 раз быстрее, чем во второй. Но что со скоростью на чтение? Чтобы поддерживать высокую скорость чтения, SplinterDB работает иначе, чем современные хранилища. Большинство из них используют фильтры Bloom (или их еще называют cuckoo), чтобы ускорять запросы.

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

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

SplinterDB использует новый вид фильтра, называемый routing filter. Один такой фильтр может заменить несколько фильтров типа Bloom, cuckoo или ribbon и может покрыть сразу несколько таблиц. Обычные фильтры могут сказать только, есть ли соответствующий ключ в доступности в данный момент или нет, а вот routing filter может не только сказать, что ключ есть, но и указать на то, какая конкретно из отсортированных таблиц его содержит. Поэтому запросам нужно делать гораздо меньше работы по поиску в фильтрах, а значит снижается нагрузка на CPU.

Кроме того, поиск в одном фильтре может сильно сэкономить на запросах ко многим таблицам, даже если этот фильтр занимает много места в RAM. Этот механизм работы с данными и был придуман в VMware. Все это позволяет существенно экономить на вычислительных мощностях для очень тяжелых и интенсивных нагрузок.

Более подробно о данной технологии можно почитать на официальном сайте SplinterDB, репозиторий продукта на GitHub доступен тут.