Компания 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.me/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.me/opennews/art.shtml?num=38499
> рассчитанная на использование на Flash-накопителях.У файловой системы спросить не забыли?
> Если один SSD-накопитель демонстрирует производительность до 100 тысяч случайных операций
> записи и чтения в секунду, распределив хранилище на десять таких накопителей,
> производительность может быть увеличена до миллиона операций в секунду.Это только в теории, в реальности включится Закон Амдала и его друзей.
Тут закон Амдала особо мешать не будет, ибо узким местом для распаралелливания скорее всего будут процессор, память и шина, а они пока быстрее чем SSD.
хранилища всегда масштабируются линейно, если, конечно, не нужна транзакционность - единственное ограничение масштабируемости в данном случае. Закон Амдала вообще не из этой оперы.
> хранилища всегда масштабируются линейно, если, конечно, не нужна транзакционность - единственное
> ограничение масштабируемости в данном случае. Закон Амдала вообще не
> из этой оперы.Ну я и не сомневался, что дальше чтения википедии мало кто способен пойти. :)
а зачем файловая система на raw device ? :)
В твоём ПТУ этого не объяснили? Печалька
А что не так? Базы сплошь и рядом на raw device работают. Тем более на энтерпрайзных SSD, где контроллер нормальный, в FS особого смысла нет.
сплошь и рядом не работают. Этим путём шли некоторые СУБД в 9х, но многие вернулись назад.
> А что не так? Базы сплошь и рядом на raw device работают.
> Тем более на энтерпрайзных SSD, где контроллер нормальный, в FS особого смысла нет.А бэкап и рестор на RAW-девайсах ты будешь писать и поддерживать?
коли субд взялась работать с raw девайсом, то тулзы для саппорта тоже даёт. Но это чаще геморее чем работать с традиционной фс.
это они петабайт на SSD хранят? оО А как же голодающие дети в Африке?
> это они петабайт на SSD хранят? оО А как же голодающие дети
> в Африке?SSD диски всё равно не сытные - можно и под данные использовать.
Месяц баз данных от facebook.
Это уже вторая база открытая ими: http://www.opennet.me/opennews/art.shtml?num=38368
"Log-Structured-Merge-Database"
Хмммм... как бы это перевести? БД со слиянием, структурированным по журналу?
так она не sql что ли? :(
вообще не понимаю, зачем ноускьюэль нужны базы?
для хранения картинок
Где сравнение производительности с mysql/postgresql/oracle?
И чисто ради лулзов - c MSSQL ))) Сколько запросов она успеет обработать в секунду? 50-100, может 1000 даже, ггг.
>Где сравнение производительности с mysql/postgresql/oracle?Сравнивать NoSQL с SQL?