Компания Facebook объявила (https://www.facebook.com/notes/facebook-engineering/under-th...) об открытии исходных текстов проекта RocksDB (http://rocksdb.org/), в рамках которого развивается система для хранения данных в формате ключ/значение, рассчитанная на использование на Flash-накопителях. Код RocksDB написан на языке С++ и распространяется (https://github.com/facebook/rocksdb) под лицензией BSD. В качестве основы для RocksDB использованы прошлогодний выпуск проекта LevelDB 1.5 (http://code.google.com/p/leveldb/), развиваемого компанией Google.
Так же как LevelDB, SQLite и BerkeleyDB, проект RocksDB оформлен в виде разделяемой библиотеки, подключаемой к приложениям в процессе компиляции (для работы с базой из командной строки поставляется утилита ldb). Библиотека может быть использована в качестве низкоуровневого звена для создания более сложных серверов хранения. Ключевым отличием от LevelDB является переработанная структура хранилища, оптимизированная для Flash-накопителях. Хранение в базе организовано в форме лога (Log-Structured-Merge-Database), при этом разработчики Facebook попытались найти оптимальный компромисс между сценариями использования (интенсивное добавление/чтение/удаление, большой размер базы).
В качестве ключей и привязанных к ним значений могут выступать произвольные байтовые массивы данных. Связки ключ/значение хранятся в отсортированном по ключу упорядоченном виде, метод сортировки задаётся через задаваемую пользователем функцию сравнения (comparator). Управление данными производится (http://rocksdb.org/overview.html) через базовые операторы Put, Write (запись в пакетном режиме) , Get, MultiGet, Delete и Scan, RangeScan (переход на удовлетворяющие определённым критериям соседние элементы отсортированного списка).
В рамках одной атомарной операции в базу может быть внесено сразу несколько изменений. Поддерживается создание снапшотов со срезом состояния БД в текущий момент времени. Для контроля за возможным повреждением данных для каждого блока сохраняется контрольная сумма. Возможно открытие базы в режиме только для чтения. Данные могут автоматически сжиматься перед сохранением с использованием библиотек snappy (http://www.opennet.dev/opennews/art.shtml?num=30003), zlib и bzip2. Для отладочных целей предусмотрена возможность ведения детализированного отладочного лога. Доступны инструменты для полного и инкрементального хранения данных, а также механизм для реплицирования лога изменений на другую систему (например, для создания горячего бэкапа на удалённой системе).
В библиотеке реализован встроенный многопоточный упаковщик, занимающийся чисткой устаревших записей (блоки данных в RocksDB не изменяются, а только добавляются новые с последующим освобождением устаревших) и пригодный для использования в ситуациях размещения в одном хранилище терабайтов данных. Система уже достаточно хорошо отлажена и используется в Facebook для хранения почти петабайта данных. C позиции производительности RocksDB позволяет выжать максимум из возможностей кластеров Flash-накопителей. Если один SSD-накопитель демонстрирует производительность до 100 тысяч случайных операций записи и чтения в секунду, распределив хранилище на десять таких накопителей, производительность может быть увеличена до миллиона операций в секунду.
Тестирование показало, что RocksDB в 10 раз быстрее обрабатывает запросы на запись и в 30 раз быстрее операции случайного чтения по сравнению с использованием LevelDB на том же накопителе, дополнительно предоставляя гибкие возможности по масштабированию хранилища на несколько накопителей. При этом RocksDB потребляет заметно больше оперативной памяти, так как операции записи вначале сохраняются (https://github.com/facebook/rocksdb/wiki/Rocksdb-Architectur...) в размещённой в памяти структуре memtable, после чего сбрасываются в последовательно заполняемый лог, а после заполнения пула данные из лога сохраняются в основное упорядоченное SST-хранилище (https://github.com/facebook/rocksdb/wiki/Rocksdb-table-format).
URL: https://www.facebook.com/notes/facebook-engineering/under-th...
Новость: http://www.opennet.dev/opennews/art.shtml?num=38499