Google открывает LevelDB: ещё одна внутренняя разработка

    Компания Google открыла исходные коды LevelDB — это созданный в Google быстрый движок (библиотека) для работы с хранилищем пар ключ-значение.

    Библиотеку LevelDB на C++ можно использовать для разных целей. Например, веб-браузер может обрабатывать с помощью LevelDB кэш недавно посещённых страниц. Операционная система — список установленных пакетов и зависимостей между ними, а любое приложение может использовать LevelDB для хранения пользовательских настроек.

    Библиотека LevelDB сделана таким образом, чтобы её было удобно использовать как строительный блок при создании хранилищ более высокого уровня. Будущие версии браузера Chrome содержат реализацию программных интерфейсов IndexedDB HTML5 API, которые построены поверх LevelDB. Даже высокопроизводительная база данных Google Bigtable управляет миллионами сегментов таблиц (tablets), в которых содержание конкретного сегмента представлено аналогом LevelDB. Недавно для распределённой базы данных Riak также была добавлена поддержка LevelDB.

    В самой библиотеке LevelDB оставили минимум зависимостей, так что её легко портировать на любые системы. Она уже портирована на различные Unix-системы, OS X, Windows и Android.

    Что касается производительности, то Google предлагает посмотреть на эти бенчмарки, которые сравнивают производительность LevelDB с SQLite и Kyoto Cabinet. В некоторых тестах LevelDB имеет очень значительное преимущество.

    Кроме того, разработчики Riak проводили сравнение с InnoDB. В этих тестах главным преимуществом LevelDB перед другими системами вроде SQLite и Kyoto Cabinet является то, что LevelDB оптимизирована для массовых апдейтов, в которых изменяются многие ключи в большом адресном пространстве. Это важное условие для эффективного обновления инвертированного индекса, который не помещается в оперативной памяти.

    Библиотека распространяется под свободной лицензией BSD-типа.

    via Open Source at Google

    Средняя зарплата в IT

    113 000 ₽/мес.
    Средняя зарплата по всем IT-специализациям на основании 10 037 анкет, за 2-ое пол. 2020 года Узнать свою зарплату
    Реклама
    AdBlock похитил этот баннер, но баннеры не зубы — отрастут

    Подробнее

    Комментарии 34

      0
      А как оно по сравнению с MongoDB, Redis и другими?
        +6
        Мне кажется правильней её сравнивать с Memcached или Mambase — они также предназначены для хранения пар ключ-значение. MongoDB и Redis же предоставляют более богатый функционал.
          +1
          Memcache же не обеспечивает хранения…
            0
            Вероятно имелась в виду Memcachedb
              0
              ну так а это просто bdb.
            +2
            Вы видимо совсем о Рэдисе не слышали, раз так говорите. А Memcached не предназначена для хранения.
              0
              redis как раз и есть хранилище ключ-значение
                0
                Позвольте не согласиться. Если с ключами в редисе всё просто и понятно, то значениями могут быть довольно высокоуровневые типы: hash, set, ordered set
                  +2
                  Ну да, вы правы, но все равно логичнее сравнивать с ним, а не с SQLite :)
                0
                >Мне кажется правильней её сравнивать с Memcached или Mambase
                нет, вот здесь ты ошибаешься: Memcached или Mambase — это БД, а Kyoto Tb есть API для хранилища данных.
                Можно сравнивать с BerkeleyDb, хотя Kyoto Tb наиболее производительное из хранилищ типа key/value fallabs.com/kyotocabinet/kyotoproducts.pdf

                мои бенчмарки показали, что мое АПИ для Kyoto Tb более производительнее чем тот же memcache, хотя я еще успеваю в фоне скидывать на диск все апдейты. www.slideshare.net/akalend/treedb-keyvalue-nosql-database

                  0
                  >MongoDB и Redis же предоставляют более богатый функционал.
                  но меньшую производительность,
                  хотя на базе Lvdb можно самому построить удобный для тебя функционал, который не будет уступать тому же MongoDB или Redis,

                  ниже в комментариях, если интересно, я кинул ссылку на TreeDb — где я на базе Tokyo Cabinet сделал продукт (надо допилить кой-какие детали и выложить в общий доступ) с функциональностью первого редиса, но превосходящего его по производительности.
                +3
                В полку NoSQL прибыло! Бенчмарки конечно красивые, особенно последовательные чтения/запись. Вот только жаль, что с другими NoSQL решениями они не сравнивали.
                  +2
                  каждый сравнивает с выгодной для него позиции. Как показал опыт, надо сделать свои бенчмарки, потому что любое тестирование очень условно: железо, объем ОЗУ и выделенного кеша, использование конкретного АПИ, режима постоянного соединения и прочих тонкостей.

                  То что было на официальной презентации продукта не всегда совпадает с ожиданиями на твоем боевом сервере. Я уже съел собаку на всяких тестированиях.

                  Обязательно приму на вооружение с сделаю свои бенчмарки.
                  +10
                  А какой смысл сравнивать производительность хранилища пар ключ-значение с SQLite? Честнее с Berkeley DB.
                    +2
                    И да, почему размещено в блоге Data Mining?
                      +2
                      про berkey db — в точку, есть еще поделка kdb (http://kx.com/)
                        0
                        Kyoto Cabinet это и есть современный аналог BerkleyDB
                          +6
                          Причина простая: Если бы вместо SQLite в этом тестировании «случайно бы» поучаствовал BerkeleyDB, такой бы «красоты» в бенчмарк-графиках наверное бы не получились. А зачем портить такой красивый график (тем более график вовсе не красивый и красота далеко не убедительно)?

                          Если все-таки совсем внимательно и попристальнее присмотреться к этим графикам, то сразу видно, что результаты теста «Random Reads» почему-то по-отношению к LevelDB вовсе не вызывают реакцию какого-то бурного восхищения.

                          А когда смотришь на эти графики дальше, у меня почему-то и вообще в голову начали закрадываться всяческие нехорошие мысли и мутные подозрения.

                          Вот например, скорость таких вещей как «Sequential Reads» и «Sequential Writes», превосходство LevelDB в которых вроде так убедительно? Я вообще-то очень сильно напрягал мозг, вспоминая, насколько часто в реальных ситуациях в отличии от «синтетических тестов» всяческие «Sequential» могли бы стать узким местом в производительности (потому что мы «вовремя вспоминаем», что мы все это сравниваем применительно к таким вещам как Key/Value-storage).

                          А когда смотришь на графики дальше, общее состояние огорчения возрастает, и приходит полная уверенность, что SQLite в данном тесте поучавствовал действительно только «ради красоты».

                          Потому, что в таких тестах как «Batch Writes», Kyoto почему-то «случайно забыли», и оставив LevelDB одиноко состязаться на пару с SQLite.

                          Видимо, бенчмарк-казуса c «Random Reads» в измененной кофигурации (там, ниже, где увеличили «memory usage to 128 MB») и где LevelDB умудрился не только уступить Kyoto почти в 2.5 раза, но и даже чуть-чуть пропустить вперед SQLite, было достаточно.

                          Так что, не знаю как у Вас, у меня например, совсем не возникло «жгучего желания» по отношению к LevelDB, только из-за «волшебной силы бренда Google». Скорее наоборот, это как раз и портит всю картину (наверное я наивно ожидал большего от технологии, которая «made by google»).

                          А результаты «Random Reads» (так основная ниша, где уютненько обосновались всяческие nosql key-value storage продукты, завоевав ее своим высоким перфомансом и низким оверхедом) говорят совсем не в пользу LevelDB.
                            +1
                            согл, бенчмарки не показательны.
                            0
                            А какой смысл сравнивать производительность хранилища пар ключ-значение с SQLite

                            Может быть потому, что свое решение гугл позиционирует как встраиваемое. В таком случае вполне логично сравнить его SQLite.
                            0
                            а на каких языках для нее драйверы есть?
                              +3
                              Оно ж сишное, биндинги рисуются за полчаса максимум.
                                0
                                ну полчаса — ты загнул, но за дня два-три можно написать полноценный биндинг например для РНР или питона (я для тарантула бинд писал неделю по вечерам 2-3 часа)
                                  0
                                  Гм. Возможно. Для дотнета рисуются именно что за полчаса, местный P/Invoke — волшебная штука.
                              +1
                              Еще с утра эту новость на лоре читал.
                              Жаль пока сравнений с другими БД маловато. Но по графиках с SQLite3 в самом низу.
                                +1
                                И все-таки сравните с redis пожалуйста :).
                                  0
                                  их изначально нельзя сравнивать так как Redis — это законченное решение
                                  а LevelDb — это emmbed решение. Если взять и реализовать поверх этого API, например, редис протокол — тогда можно сравнить их по производительности. Однозначно скажу, что если к LevelDb присабачить сетевой интерфейс, то он будет однозначно быстрее редиса.

                                  Что касается сравнения, то у редиса более расширенный функционал: списки, множества.
                                  Редис на типах key/value не может делать операции итераций/обратных итераций. Для этого используются списки. Но списки — это последовательный доступ, а LvDb позволяет использовать прямой доступ.
                                  0
                                  И с MemcacheDB.
                                    0
                                    см мои коментари… уже надоело повторяться. Что касается MemcacheDB, то это memcached настройка над BerkeleyDb, которая сегодня уже не является самой быстрой из key/value embedded решений.
                                    Правильнее сравнивать с BerkeleyDb, qdbm или Tokyo/Kyoto Cb так как это все embedded решения
                                  • НЛО прилетело и опубликовало эту надпись здесь
                                    • НЛО прилетело и опубликовало эту надпись здесь
                                      +2
                                      спасибо за информацию

                                      что касается бенчмарков, то я конечно понимаю тестировщиков,
                                      которые представляют тесты с выгодных для них позиций.

                                      сравнение с Kyoto TreeDB — это не совсем правильно (я уже не говорю про SQLite)
                                      так как LiveDb — это HashTable, ну сравнивали бы тогда уж с типом Kyoto HashDB — который на порядок быстрее,
                                      так как внутренняя организация Kyoto TreeDB более сложная и представляет собой внутренее Hash хранилище с Tree индексом. И еще есть режим сжатия, отключив который можно добиться более высокой производительности.

                                      еще раз спасибо за информацию, обязательно попробую использовать для какого нибудь из своих проектов.
                                        0
                                        Скорее всего, SQLite в качестве оппонента был выбран как одно из популярных встраиваемых решений.
                                          0
                                          вполне возможно

                                        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                        Самое читаемое