Comments 14
UFO just landed and posted this here
Тоже как-то использовал LevelDB в своём небольшом NPAPI-плагине для хрома.
Но Google закрутили гайки и сейчас идёт переход всех NPAPI-плагинов на другие механизмы, в частности на NaCl / PNaCl.
Я наивно полагал что раз автор у LevelDB и браузера один и тот же, то у них есть совместимость. Тем более LevelDB есть в nacl-ports. Однако, увы и ах, после реализации своего Env в рамках File API NaCl база постоянно молча падала. К сожалению, мне было влом отлаживать байт-код, прошедший через несколько этапов трансляции и я нашёл альтернативное решение: unqlite. Абстрацкионный слой вышел даже тоньше ~250 строк против ~550 для leveldb.
Но Google закрутили гайки и сейчас идёт переход всех NPAPI-плагинов на другие механизмы, в частности на NaCl / PNaCl.
Я наивно полагал что раз автор у LevelDB и браузера один и тот же, то у них есть совместимость. Тем более LevelDB есть в nacl-ports. Однако, увы и ах, после реализации своего Env в рамках File API NaCl база постоянно молча падала. К сожалению, мне было влом отлаживать байт-код, прошедший через несколько этапов трансляции и я нашёл альтернативное решение: unqlite. Абстрацкионный слой вышел даже тоньше ~250 строк против ~550 для leveldb.
Отлична file based databased. Вопрос к автору статьи, не сталкивались ли вы с проседание производительности при очень большом количестве данных. Второй вопрос как решали проблемы атомарности чтения записи. Третий вопрос как решали проблему группировки данных, добавляли к ключу дополнительный префиксы и как при это работали с компараторами? Ну и последний вопрос, про forestdb не слышали? Не пробовали сравнивать?
Не автор статьи, но тоже активно использую levelDB и на клиенте и на сервере — пока доволен. чуток быстрее sqlite
на клиенте иногда приходят ошибки о разрушении базы данных.
но этим и sqlite страдает вероятно пользователи вырубают компы по питанию.
А «очень большом объеме» это сколько в цифрах?
у меня сейчас серверная база 3.6 гига и 1848 файлов по 2 м.
кто-то знает почему размер файла *.ldb выбрали таким мелким — ведь большое кол-во файлов в каталоге это вредно для файловой системы?
на сервере я отказался от sqlite в пользу levelDB из-за сжатия прозрачного — на VPS SSD диск дорогой
немного экономится денег.
на клиенте иногда приходят ошибки о разрушении базы данных.
но этим и sqlite страдает вероятно пользователи вырубают компы по питанию.
А «очень большом объеме» это сколько в цифрах?
у меня сейчас серверная база 3.6 гига и 1848 файлов по 2 м.
кто-то знает почему размер файла *.ldb выбрали таким мелким — ведь большое кол-во файлов в каталоге это вредно для файловой системы?
на сервере я отказался от sqlite в пользу levelDB из-за сжатия прозрачного — на VPS SSD диск дорогой
немного экономится денег.
У меня руки не дошли до тестирования производительности. Пока ждали новый сервер научились готовить PostgreSQL.
По поводу производительности. Особенность LevelDB это использование LSM-дерева. Ссылки в конце статьи ведут на видео 2013 где рассказываются про LSM. По производительность LevelDB есть такое видео Практика NOSQL в высоконагруженном проекте, Дмитрий Ананьев (Мамба) 2012 года, и немного Константин Осипов показывает неприятный бенчмарк. Как упоминал Осипов, Facebook развлекался с LevelDB, как результат имеем RocksDB. Вот бенчмарк RocksDB и LevelDB
На остальные вопросы ответить не могу, т.к. с ними не сталкивался.
По поводу производительности. Особенность LevelDB это использование LSM-дерева. Ссылки в конце статьи ведут на видео 2013 где рассказываются про LSM. По производительность LevelDB есть такое видео Практика NOSQL в высоконагруженном проекте, Дмитрий Ананьев (Мамба) 2012 года, и немного Константин Осипов показывает неприятный бенчмарк. Как упоминал Осипов, Facebook развлекался с LevelDB, как результат имеем RocksDB. Вот бенчмарк RocksDB и LevelDB
На остальные вопросы ответить не могу, т.к. с ними не сталкивался.
RPG18 а хотя бы автоинкремент делали?
Нет. Я его использовал для онлайновой агрегации и консолидацией KPI, для дальнейшего расчета показателей качества(KQI).
Я работал на больших объемах (наверное) — была специализированная задача работы с очень большими таблицами типа md5-хеш — некоторый ид, и это на размерах базы порядка 35+ Гб. Работало очень и очень быстро, практически не зависело от размера базы (у нас туда шла постоянная запись c пиками до пары тысяч в секунду записей). использовал интересный сервер поверх Leveldb — ssdb
Интересно, почему lmdb совсем не популярна. Потому, что не от гугла или потому, что api намного сложнее?
Sign up to leave a comment.
Использование LevelDB