The OpenNET Project / Index page

[ новости/++ | форум | wiki | теги | ]

28.07.2011 10:33  Компания Google открыла исходные тексты БД LevelDB

Компания Google объявила о переводе LevelDB, высокопроизводительной системы для хранения данных в формате ключ/значение, в разряд открытых проектов. Хранилище LevelDB написано на языке С++ и подключается к приложениям в виде разделяемой библиотеки (как SQLite и BerkeleyDB), обеспечивая возможность хранения упорядоченных наборов данных, в которых строковые ключи сопоставлены со строковыми значениями. Код LevelDB открыт под лицензией BSD.

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

Положительной чертой LevelDB является минимальное число зависимостей, что позволяет легко портировать библиотеку для разнообразных систем. В настоящий момент LevelDB уже работает в Unix-подобных ОС, Mac OS X, Windows и Android. Отдельно отмечается, что LevelDB является достаточно специализированным решением, например, LevelDB не поддерживает выполнение SQL-запросов и подключение индексов; не поддерживается одновременный доступ к БД нескольких процессов - в заданный момент времени только один процесс может работать с файлом базы (возможна работа в многопоточных программах); отсутствует встроенное решение для организации клиент-серверного доступа, работа сервера может быть организована в виде приложения-надстройки.

Основные возможности LevelDB:

  • В качестве ключей и привязанных к ним значений может использоваться произвольный байтовый массив;
  • Данные хранятся отсортированными по связанному с ними ключу;
  • Пользователь может переопределить метод сортировки, указав собственную функцию сравнения;
  • Управление данными производится через базовые операторы Put(key,value), Get(key) и Delete(key);
  • В рамках одной атомарной операции в базу может быть внесено сразу несколько изменений;
  • Поддерживается создание снапшотов, представляющих собой неизменный срез состояния БД на текущий момент времени. Со снапшотом можно работать в штатном режиме, но в нём не будут отражаться изменения базы, производимые после его создания;
  • Над данными можно использовать прямые и обратные итерации (переходить к следующему или предыдущему элементу отсортированного списка);
  • Данные хранятся в сжатом виде, для сжатия используется библиотека Snappy;
  • Все внешние операции на уровне операционной системы, такие как работа с файлами, производится через виртуальный программный интерфейс, который позволяет пользователю изменить поведение библиотеки при взаимодействии с операционной системой.

Библиотека достаточно хорошо оптимизирована и демонстрирует высокую производительность при различных видах использования. Разработчики Google провели сравнение производительности LevelDB c такими системами, как SQLite, Kyoto Cabinet и InnoDB. В результате тестирования было выявлено, что существенное преимущество LevelDB наблюдается при пакетном обновлении данных (изменение сразу порции записей), затрагивающем большое число ключей, распределенных по всему хранилищу.

Результаты тестирования производительности базы LevelDB (ключ - 16 байт, значение - 100 байт, изначальное число записей - 1 миллион, итоговый размер базы с учетом сжатия - 62 Мб):

  • Последовательная запись: 1.765 micros/op; 62.7 MB/s;
  • Запись со сбросом изменений на диск (выполнение вызова fsync) после каждой операции: 268.409 micros/op; 0.4 MB/s (10000 операций в секунду);
  • Записи в случайном порядке: 2.460 micros/op; 45.0 MB/s;
  • Перезапись существующих ключей: 2.380 micros/op; 46.5 MB/s;
  • Случайное чтение в режиме холодного старта: 60 тыс операций в секунду;
  • Последовательное чтение в режиме холодного старта: 232.3 MB/s;
  • Последовательное чтение в обратном порядке в режиме холодного старта: 152.9 MB/s;
  • Случайное чтение после проведения большого числа случайных записей: 85 тыс операций в секунду;
  • Случайное повторяющиеся чтение: 100 тыс операций в секунду;
  • Случайное повторяющиеся чтение с кэшем в который вмещаются все распакованные данные: 190 тыс операций в секунду.


  1. Главная ссылка к новости (http://google-opensource.blogs...)
  2. OpenNews: Компания Google открыла код Snappy, библиотеки для сжатия данных
Лицензия: CC-BY
Тип: Программы
Ключевые слова: LevelDB, database, nosql
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение Ajax/Линейный | Раскрыть все сообщения | RSS
 
  • 1.1, тоже Аноним (ok), 11:38, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]
  • +11 +/
    Похоже, в ChromeOS таки будет реестр.
     
     
  • 2.3, klalafuda (?), 11:49, 28/07/2011 [^] [ответить]    [к модератору]
  • +2 +/
    > Похоже, в ChromeOS таки будет реестр.

    Ну в ff вообще sqlite встроен - и ничего и ничего и ничего (с)..

     
     
  • 3.4, anon8 (ok), 11:55, 28/07/2011 [^] [ответить]    [к модератору]
  • +5 +/
    ...ничего хорошего
     
     
  • 4.14, Аноним (-), 13:10, 28/07/2011 [^] [ответить]     [к модератору]
  • +/
    Да вообще-то лучше чем тот ужас который до него был Никогда не видели RDF-портя... весь текст скрыт [показать]
     
     
  • 5.46, Аноним (-), 19:30, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Да и с sqlite при превышении 15к записей в истории firefox начинает тупить. Но может тут виной 1Гб+ кэш на диске.
     
  • 3.11, Аноним (-), 13:00, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    SQLite нынче встроен уже дохрена куда, начиная от XnView и заканчивая Андроидом.
     
  • 2.9, gkv311 (ok), 12:42, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Ориентация Chrome на множество процессов как-то не стыкуется с ... весь текст скрыт [показать]
     
     
  • 3.15, uhbif19 (?), 13:12, 28/07/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    В чем проблема ?

    Выделенный процесс "chrome-leveldb",

     
     
  • 4.16, uhbif19 (?), 13:13, 28/07/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    > В чем проблема ?
    > Выделенный процесс "chrome-leveldb",

    а все остальные с ним и разговаривают.

     
     
  • 5.21, тоже Аноним (ok), 13:35, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Не говоря уже о том, что в реестр гораздо реже пишут, чем читают. Во всяком случае, должны.
     
  • 5.24, gkv311 (ok), 13:38, 28/07/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    >> В чем проблема ?
    >> Выделенный процесс "chrome-leveldb",
    > а все остальные с ним и разговаривают.

    На своём уникальном языке, ибо SQL им 'не нужен'?
    По-моему это огород в огороде.

     
     
  • 6.51, Аноном (?), 22:08, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    К сожалению, W3C не приняли SQL-реализацию базы, а прията будет, судя по всему, IndexedDB - довольно примитивное NoSQL-хранилище. Под него LevelDB отлично подойдёт.
     
     
  • 7.55, anonymous (??), 22:18, 28/07/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    s/К сожалению/К счастью/

    obvious fix.

     
  • 6.59, all_glory_to_the_hypnotoad (ok), 22:41, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Разговаривают на своём API, а не языке. Для KV хранилищь большего не нужно
     
  • 1.2, Аноним (-), 11:40, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +4 +/
    Что-то я не понял, а чем гугла не устроил Tokyo Cabinet? Not invented here?
     
     
  • 2.43, a (??), 17:23, 28/07/2011 [^] [ответить]     [к модератору]  
  • +2 +/
    Если бы вы занимались профессиональными разработками, то знали бы, что свой код,... весь текст скрыт [показать]
     
  • 1.5, gegMOPO4 (ok), 11:56, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +3 +/
    Чем оно лучше Berkeley DB? Совместимо ли API с Berkeley DB (или существует ли адаптер)?

    Кто додумался сравнивать продукт типа Berkeley DB (ключ/значение) с SQLite?

     
     
  • 2.6, Аноним (-), 12:02, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Вообще, над bdb помнится сделали какой-то урезанный вариант sql. Может поэтому?
     
     
  • 3.7, gegMOPO4 (ok), 12:23, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Хотите сказать, что тестировали работу LevelDB с SQL? ;)
     
     
  • 4.13, Аноним (-), 13:07, 28/07/2011 [^] [ответить]     [к модератору]  
  • +2 +/
    Нет, не хочу сказать А он это умеет К bdb вроде как урезанный вариант скуля пр... весь текст скрыт [показать]
     
     
  • 5.26, gegMOPO4 (ok), 13:45, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Значит они тестировали совсем не то, для чего эти БД предназначены В забивании ... весь текст скрыт [показать]
     
  • 3.38, Veter (??), 16:21, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Отстали вы от жизни Оракл давно уже вовсю продвигает BerkeleyDB как сторадж с... весь текст скрыт [показать]
     
  • 2.10, anon8 (ok), 12:47, 28/07/2011 [^] [ответить]    [к модератору]  
  • +2 +/
    Да, не хватает сравнения с постгресом и ораклом.
     
     
  • 3.17, Аноним (-), 13:14, 28/07/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    А постгреса и оракла можно влинковать в программу как статическую либу-движок ра... весь текст скрыт [показать]
     
     
  • 4.25, sanDro (ok), 13:39, 28/07/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    А ничего что SQLite и InnoDB это реляционные движки? Которые медленние по определению.
     
     
  • 5.36, anonymous (??), 15:36, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    ничего сложилась практика применять SQLite там, где достаточно простых key-valu... весь текст скрыт [показать]
     
     
  • 6.37, sanDro (ok), 15:46, 28/07/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    InnoDB тоже применяют Там где достаточно key-value сложилась практика применять... весь текст скрыт [показать]
     
     
  • 7.39, anonymous (??), 16:29, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    на картинке вижу киото и скулит. возможно, стоило бы добавить bdb, но кому эта окаменелость нужна?
     
     
  • 8.40, sanDro (ok), 16:41, 28/07/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    Эта окаменелость вовсю используется в продакшене, в проектах которым не пару л... весь текст скрыт [показать]
     
     
  • 9.42, anonymous (??), 17:20, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    > в проектах которым не пару лет от рождения

    вот именно.

     
     
  • 10.61, Аноним (-), 03:47, 29/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Даже до тебя дошло что bdb порвёт их как Тузег грелку? :)
    И при этом не имеет ограничений на только один процесс и прочей мути ...
     
     
  • 11.62, anonymous (??), 04:21, 29/07/2011 [^] [ответить]     [к модератору]  
  • +/
    нет, даже до меня дошло, что legacy 8212 это страшно ... весь текст скрыт [показать]
     
  • 5.52, Аноном (?), 22:11, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Чего бы они были медленными п определению Они вылизывались десятки лет, и как п... весь текст скрыт [показать]
     
  • 4.47, anon8 (ok), 19:41, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Мда, видимо придется в таких случаях тег "сарказм".
    Сказано это было к тому, что изначально не с тем сравнивали.
     
  • 2.12, 1 (??), 13:02, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Oracle же !
     
     
  • 3.22, gegMOPO4 (ok), 13:35, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Oracle Berkeley DB?

    Да, это веская причина.

     
  • 2.18, uhbif19 (?), 13:14, 28/07/2011 [^] [ответить]     [к модератору]  
  • +1 +/
    Ну видимо, не монструозно ... весь текст скрыт [показать]
     
  • 2.23, Аноним (-), 13:38, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    > Чем оно лучше Berkeley DB?

    Тем, что Berkley DB принадлежит Oracle'у, а LevelDB нет.
    Никто не хочет ввязываться в патентные разборки с Oracle'ом.

     
     
  • 3.27, gegMOPO4 (ok), 13:49, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Патентные разборки не связаны с происхождением кода. Придолбаться могут и к совершенно независимой разработке.
     
     
  • 4.33, Аноним (-), 14:51, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    А если разработка не независима, то придолбаться значительно легче. (И для суда это понятнее.)
     
  • 1.19, uhbif19 (?), 13:17, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    Говорили вот, что RedisDB какой-то нереально быстрый.

    Как я понял, такая производительность - обычное дело для key-value хранилищ "/

     
     
  • 2.20, Аноним (-), 13:33, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Редис быстрый так как вся база в оперативной памяти При падении системы потеря ... весь текст скрыт [показать]
     
     
  • 3.29, Crazy Alex (ok), 13:58, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Это у кого ж пол-базы в залоченном состоянии получается Ну ладно SQLite лочит в... весь текст скрыт [показать]
     
     
  • 4.31, uhbif19 (?), 14:17, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Ошибаетесь ... весь текст скрыт [показать]
     
     
  • 5.56, Аноном (?), 22:20, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Я с ним в продакшне работаю, вообще-то На 64-битной системе с разумными размера... весь текст скрыт [показать]
     
     
  • 6.66, uhbif19 (?), 23:39, 31/07/2011 [^] [ответить]    [к модератору]  
  • +/
    > Я с ним в продакшне работаю, вообще-то. На 64-битной системе с разумными
    > размерами ключей (в пределах пары десятков байт) значений (сотни байт) имено
    > это и видим. Если к размерам ключей/значений будете придираться - это
    > комментарии пользователей, вполне типичный размер.

    Извиняюсь, возможно вы и правы.

    У Redis, как заявляют сами разработчики, проблемы с хранением мелких данных. Они с этим борются, но вроде безуспешно.

    (ЗЫ А если не секрет, зачем вы в Redis комментарии храните ?)

     
  • 3.32, uhbif19 (?), 14:20, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    > Редис быстрый так как вся база в оперативной памяти. При падении системы
    > потеря всей информации, наработанной после последней синхронизации.
    > А вообще, да NoSQL быстрее. Например можно хранить все в бинарных деревьях,
    > как в Couchdb. Да и атомарность у них обычно на уровне
    > одной записи, то есть пол базы в залоченном состоянии не висит.

    У Mongo атомарности нет вообще, у Couch ЕМНИП тоже.

    >  При падении системы потеря всей информации, наработанной после последней синхронизации.

    Там есть Safe-mode. Правда в нем он всего в пару раз быстрее SQL.

    Я к тому, что LevelDB по скорости как раз вполне сравним с RedisDB (судя по представленным данным). А с включенным fsync (упомянутый safe-mode) уделывает его во много раз.


     
     
  • 4.34, Аноним (-), 15:00, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    >>у Couch ЕМНИП тоже.

    Изменяет. Атомарность там на уровне записи единичного документа.
    http://guide.couchdb.org/editions/1/en/documents.html


     
  • 2.28, Crazy Alex (ok), 13:53, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Redis - он не совсем key-value, вообще-то. А так - ну, собственно, выборка по первичному ключу (ближайший аналог этой библиотеки) даже в мускуле весьма шустра, особенно если воспользоваться кодом японцев и избавиться от парсинга SQL. HandlerSocket выдавал у них в тестах около 750000 операций чтения в секунду - это на восьми ядрах, но зато по сети. В общем, цифры сравнимые.
     
     
  • 3.30, uhbif19 (?), 14:16, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    > Redis - он не совсем key-value, вообще-то. А так - ну, собственно,
    > выборка по первичному ключу (ближайший аналог этой библиотеки) даже в мускуле
    > весьма шустра, особенно если воспользоваться кодом японцев и избавиться от парсинга
    > SQL. HandlerSocket выдавал у них в тестах около 750000 операций чтения
    > в секунду - это на восьми ядрах, но зато по сети.
    > В общем, цифры сравнимые.

    Достали уже.

    1) Redis key-value, просто со структурами данных.
    2) Неправильно считают. Надо считать транзакции, а не операции. Тогда SQL вчистую сливает. Проверено.

     
     
  • 4.41, Аноним (-), 16:53, 28/07/2011 [^] [ответить]     [к модератору]  
  • +/
    Структуры данных индексировать гораздо сложнее, чем текстовые строки Следовател... весь текст скрыт [показать]
     
     
  • 5.45, Аноним (-), 19:04, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    А кстати, что насчет Exadata 2? Это если говорить о транзакциях? Кто там кому сливает?
     
  • 5.64, uhbif19 (?), 23:25, 31/07/2011 [^] [ответить]    [к модератору]  
  • +/
    >> просто со структурами
    > Структуры данных индексировать гораздо сложнее, чем текстовые строки. Следовательно и
    > сам движок существенно отличается от других key-value БД.
    >_<

    Массивы и словари обычные. И о какой индексации, вообще идет речь ?

    Redis - это очень круто, не спорю. Он поддерживает не только хранение всякого разного,
    но и потоки сообщений, крайне (для key-value DB)

    >>> операций чтения
    >> Надо считать транзакции, а не операции
    > Что за транзакции чтения такие?

    Пруф теста, пожалуйста.


     
     
  • 6.65, uhbif19 (?), 23:28, 31/07/2011 [^] [ответить]    [к модератору]  
  • +/
    ... крайне (для key-value DB) сложные операции над данными. И очень хорошая документация кстати.

    Но это не отменяет того, что она k-v База Данных. Продвинутая, но все-же.


     
  • 4.54, Аноном (?), 22:15, 28/07/2011 [^] [ответить]    [к модератору]  
  • +1 +/
    Покажите мне в MyISAM транзакции. Что до редиса - штуковину, умеющую делать intersert для множеств, я в чистые key-value (рядом с TokyoCabinet и memcached) записывать не готов.
     
  • 1.35, anonymous (??), 15:34, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    на random reads sosnooley. откуда вывод: подходит в качестве архива, не подходит в качестве базы, где данные постоянно нужны. не буду кабинет на неё менять.
     
  • 1.44, evgeny_t (ok), 18:59, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    #Случайное чтение в режиме холодного старта: 60 тыс операций в секунду;

    удивляют эти тесты,
    просто весь 64 мб файл закеширован в памяти.

    давайте на базе 1000 терабайт потестим ? и общей памятью 100 гб

     
     
  • 2.50, Аноним (-), 21:56, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    У тебя есть такая СХД и генераторные скрипты для правдоподобных данных? Давай.
     
  • 1.48, pro100master (ok), 21:19, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    сразу видна жесткая специализация под элементарные вещи. Такое ощущение, что разрабы таких вот noSQL только и занимаются, что тестируют быстродействие.
    Попробовали бы на немного более серьёзных вещах, чем
    for x in 0..1000:
    db.put('key',i)

    Почему нельзя сделать группы (метки, теги - как угодно). Ведь если есть:
    a1=>value1
    a2=>value2

    часто необходимо выбрать/удалить/обновить ключи вида a* сразу. Не говоря уже об таких примитивах, как поиск. Это не noSQL, а какой-то usefulDB получается.

     
     
  • 2.57, Аноном (?), 22:21, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    угу, мне тоже интересно, кто бы по префиксам мог выбирать эффективно. Реализаций же масса возможна, по идее.
     
  • 1.49, szh (ok), 21:44, 28/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    http://maxpert.tumblr.com/post/3329352663/the-nosql-dogma


        100,000 writes took 29.6542 seconds ( ~ 3372 writes / second )
        100,000 reads in order took 18.4197 seconds ( ~ 5429 reads / second )
        100,000 reads in random order 17.0343 seconds ( ~ 5870 reads / second ) (Socking!)

    CREATE TABLE 'foo'.'kv' (
        'key' CHAR(255) NOT NULL,
        'val' TEXT NOT NULL,
        PRIMARY KEY ('key')
    ) ENGINE = MyISAM;

     
     
  • 2.58, Аноном (?), 22:27, 28/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Именно
     
  • 2.63, Аноним (-), 10:09, 31/07/2011 [^] [ответить]    [к модератору]  
  • +/
    Смешные результаты.
    Запись константной строки?
    Очень реалистичная задача.

    Польза NoSql в технологии Map/Reduce и очень легкой скалируемости(просто добавь серверов).
    А mySql не нужна.

     
  • 1.60, Телегин Дмитрий (?), 01:44, 29/07/2011 [ответить] [показать ветку] [···]    [к модератору]  
  • +/
    > Чем оно лучше Berkeley DB?

    Если не ошибаюсь лицензией. У Berkeley DB не LGPL как того хотелось бы для библиотеки, а GPL только другими словами. В итоге если гугл захочет хоть что-то закрытое выпустить в свет использующее Berkeley DB, то будет платить ораклу. По моему достаточная причина для того чтобы гуглу не использовать эту библиотеку. Собственно и не гуглу перед использованием Berkeley DB сначала стоит поинтересоваться расценками, т.к. сегодня сделаешь свободный проект и все нормально, а завтра понадобится сделать что-то закрытое но привычную библиотеку не сможешь использовать из-за цены.
    http://www.oracle.com/technetwork/database/berkeleydb/downloads/licensing-098

     

     Добавить комментарий
    Имя:
    E-Mail:
    Заголовок:
    Текст:


      Закладки на сайте
      Проследить за страницей
    Created 1996-2018 by Maxim Chirkov  
    ДобавитьПоддержатьВебмастеруГИД  
    Hosting by Ihor