Компания Google [[http://google-opensource.blogspot.com/2011/07/leveldb-fast-p... объявила о переводе LevelDB (http://code.google.com/p/leveldb/), высокопроизводительной системы для хранения данных в формате ключ/значение, в разряд открытых проектов. Хранилище LevelDB написано на языке С++ и подключается к приложениям в виде разделяемой библиотеки (как SQLite и BerkeleyDB), обеспечивая возможность организации упорядоченных наборов данных, в которых строковые ключи сопоставлены со строковыми значениями. Код LevelDB открыт (http://code.google.com/p/leveldb/source/browse/#svn%2Ft...) под лицензией BSD.
Отдельно подчеркивается поддержка эффективного упорядоченного хранения, т.е. связки ключ/значение хранятся в отсортированном виде. Среди примеров возможных применений LevelDB, упоминается использование библиотеки в web-браузере, для хранения кэша последних открытых страниц, или использование в пакетном менеджере для хранения списка установленных пакетов и с...URL: http://google-opensource.blogspot.com/2011/07/leveldb-fast-p...
Новость: http://www.opennet.me/opennews/art.shtml?num=31325
Похоже, в ChromeOS таки будет реестр.
> Похоже, в ChromeOS таки будет реестр.Ну в ff вообще sqlite встроен - и ничего и ничего и ничего (с)..
...ничего хорошего
> ...ничего хорошегоДа вообще-то лучше чем тот ужас который до него был. Никогда не видели RDF-портянку на МЕГ? А скорость ее парсинга себе представляете?! Файрфоксина с отросшей хистори доSQLITEовой эпохи являла собой довольно унылое зрелище. С sqlite то что касается истории стало в РАЗЫ быстрее. Наверное потому что теперь не надо на вообще каждую операцию парсить меговый XMLоподобный кусок текста.
Да и с sqlite при превышении 15к записей в истории firefox начинает тупить. Но может тут виной 1Гб+ кэш на диске.
SQLite нынче встроен уже дохрена куда, начиная от XnView и заканчивая Андроидом.
Ориентация Chrome на множество процессов как-то не стыкуется с:
>>LevelDB не поддерживается одновременный доступ к БД нескольких процессов - в заданный момент времени только один процесс может работать с файлом базы.
В чем проблема ?Выделенный процесс "chrome-leveldb",
> В чем проблема ?
> Выделенный процесс "chrome-leveldb",а все остальные с ним и разговаривают.
Не говоря уже о том, что в реестр гораздо реже пишут, чем читают. Во всяком случае, должны.
>> В чем проблема ?
>> Выделенный процесс "chrome-leveldb",
> а все остальные с ним и разговаривают.На своём уникальном языке, ибо SQL им 'не нужен'?
По-моему это огород в огороде.
К сожалению, W3C не приняли SQL-реализацию базы, а прията будет, судя по всему, IndexedDB - довольно примитивное NoSQL-хранилище. Под него LevelDB отлично подойдёт.
s/К сожалению/К счастью/obvious fix.
Разговаривают на своём API, а не языке. Для KV хранилищь большего не нужно
Что-то я не понял, а чем гугла не устроил Tokyo Cabinet? Not invented here?
> Что-то я не понял, а чем гугла не устроил Tokyo Cabinet? Not invented here?Если бы вы занимались профессиональными разработками, то знали бы, что свой код, сделаный под себя и свои задачи, всегда лучше, чем чужой. Даже если он менее производительный и фичастный.
Естественно, реальность такова, что весь код самому не перепишешь, даже будучи средней компанией. Поэтому приходится использовать чужой код.
Но крупные компании могу себе такое позволить. Поэтому они и достигли таких высот, что их основатели не пытались быть похожими на других, а шли своим путем.
Чем оно лучше Berkeley DB? Совместимо ли API с Berkeley DB (или существует ли адаптер)?Кто додумался сравнивать продукт типа Berkeley DB (ключ/значение) с SQLite?
Вообще, над bdb помнится сделали какой-то урезанный вариант sql. Может поэтому?
Хотите сказать, что тестировали работу LevelDB с SQL? ;)
> Хотите сказать, что тестировали работу LevelDB с SQL? ;)Нет, не хочу сказать. А он это умеет? К bdb вроде как урезанный вариант скуля прикрутили. Хотя объединили их тут по совсем иному признаку: это не сервера СУБД а движки бд, которые можно влинковать в свою программу. И никаких гребаных посторонних процессов и прочих демонов с конфигами. Можно конечно и как кдешники - вдуть под локальную базу с одним пользователем целого мускуля с какими-то дефолтовыми параметрами, повесить жирный демон в памяти от загрузки до шатдауна, независимо от его востребованности и выжрать 30 мегз рамы непонятно на что и зачем. Но так делают только настоящие п....сы. К счастью, не все программеры такие же как кдешники.
Значит они тестировали совсем не то, для чего эти БД предназначены. В забивании гвоздей микроскоп тоже покажет не лучшие результаты, но это не значит, что всем нужно срочно выбрасывать микроскопы и заменять нашими новомодными каменными топорами.А влинковать можно и libcddb, и libdbus, и libkdb (тоже имеют db в названии) — будем сравнивать с ними?
> Вообще, над bdb помнится сделали какой-то урезанный вариант sql.Отстали вы от жизни :) Оракл давно уже вовсю продвигает BerkeleyDB как сторадж с SQLite фрондэндом. Так что есть полноценный SQL, включая view, триггеры, виртуальные таблицы и другие плюшки. А от BerkeleyDB есть конкурентный доступ, репликация и проч.
Да, не хватает сравнения с постгресом и ораклом.
> Да, не хватает сравнения с постгресом и ораклом.А постгреса и оракла можно влинковать в программу как статическую либу-движок работающую с необслуживаемой/малообслуживаемой и не администряемой БД? Или предлагается сравнить СУБД и голый движок БД? Ну тогда надо посравнивать двигатели и автомобили в сборе для пущего кайфа.
А ничего что SQLite и InnoDB это реляционные движки? Которые медленние по определению.
> А ничего что SQLite и InnoDB это реляционные движки? Которые медленние по
> определению.ничего. сложилась практика применять SQLite там, где достаточно простых key-value (привет, тормозилла!). вот и сравнивают с практикой, а не со сферическими конями в вакууме. и это правильно.
>> А ничего что SQLite и InnoDB это реляционные движки? Которые медленние по
>> определению.
> ничего. сложилась практика применять SQLite там, где достаточно простых key-value (привет,
> тормозилла!). вот и сравнивают с практикой, а не со сферическими конями
> в вакууме. и это правильно.InnoDB тоже применяют? Там где достаточно key-value сложилась практика применять BDB. C ней они почему-то сравнивать не стали. Я считаю, что подборка для сравнения не корректна. В ней из трёх альтернатив только одна принадлежит к тому же классу, что и LevelBD. Они говорят, что их бд быстрее, а реально это говорит только о том, что сапожным молотком обувь тачать эффективнее, чем кувалдой для забивания свай. Кто бы сомневался.))))
на картинке вижу киото и скулит. возможно, стоило бы добавить bdb, но кому эта окаменелость нужна?
> на картинке вижу киото и скулит. возможно, стоило бы добавить bdb, но
> кому эта окаменелость нужна?Эта "окаменелость" вовсю используется в продакшене, в проектах которым не пару лет от рождения, и где структуры баз не реляционные в принципе.
С InnoDB сравнивали не гугловцы, но об этом упомянуто в новости (я про основную ссылку).
З.Ы. А вообще мы флудим. Хорошо, что проект был открыт. Если он нужен, значит он будет развиваться. Как говорится спрос покажет. Всё остальное не критично.
> в проектах которым не пару лет от рождениявот именно.
Даже до тебя дошло что bdb порвёт их как Тузег грелку? :)
И при этом не имеет ограничений на только один процесс и прочей мути ...
> Даже до тебя дошло что bdb порвёт их как Тузег грелку? :)
> И при этом не имеет ограничений на только один процесс и прочей
> мути …нет, даже до меня дошло, что legacy — это страшно.
Чего бы они были медленными п определению? Они вылизывались десятки лет, и как примитивные key-value хранилища показывают достаточно хорошие результаты. Смотрите в сторону HandlerSocket - там это наглядно продемонстрировано.
Мда, видимо придется в таких случаях тег "сарказм".
Сказано это было к тому, что изначально не с тем сравнивали.
Oracle же !
Oracle Berkeley DB?Да, это веская причина.
> Чем оно лучше Berkeley DB? Совместимо ли API с Berkeley DB (или
> существует ли адаптер)?
> Кто додумался сравнивать продукт типа Berkeley DB (ключ/значение) с SQLite?Ну видимо, не монструозно.
> Чем оно лучше Berkeley DB?Тем, что Berkley DB принадлежит Oracle'у, а LevelDB нет.
Никто не хочет ввязываться в патентные разборки с Oracle'ом.
Патентные разборки не связаны с происхождением кода. Придолбаться могут и к совершенно независимой разработке.
А если разработка не независима, то придолбаться значительно легче. (И для суда это понятнее.)
Говорили вот, что RedisDB какой-то нереально быстрый.Как я понял, такая производительность - обычное дело для key-value хранилищ "/
Редис быстрый так как вся база в оперативной памяти. При падении системы потеря всей информации, наработанной после последней синхронизации.
А вообще, да NoSQL быстрее. Например можно хранить все в бинарных деревьях, как в Couchdb. Да и атомарность у них обычно на уровне одной записи, то есть пол базы в залоченном состоянии не висит.
> Редис быстрый так как вся база в оперативной памяти. При падении системы
> потеря всей информации, наработанной после последней синхронизации.
> А вообще, да NoSQL быстрее. Например можно хранить все в бинарных деревьях,
> как в Couchdb. Да и атомарность у них обычно на уровне
> одной записи, то есть пол базы в залоченном состоянии не висит.Это у кого ж пол-базы в залоченном состоянии получается? Ну ладно SQLite лочит всю базу целиком. Но уже мускул с MyISAM лочит одну таблицу, а поставь нормальный бакэнд - будут локи на уровне строки. А спор "деревья против хэша" - он давний и однозначного решения не имеет - одно быстрее на чтение, другое на запись. В зависимости от паттерна использования надо выбирать разные реализации.
Что же касается редиса - за скорость там расплачиваемся ещё диким расходом памяти - если не ошибаюсь, её тратится раз в десять больше, чем объём хранимых данных. Что весьма неприятно иногда.
> Что же касается редиса - за скорость там расплачиваемся ещё диким расходом
> памяти - если не ошибаюсь, её тратится раз в десять больше,
> чем объём хранимых данных. Что весьма неприятно иногда.Ошибаетесь.
Я с ним в продакшне работаю, вообще-то. На 64-битной системе с разумными размерами ключей (в пределах пары десятков байт) значений (сотни байт) имено это и видим. Если к размерам ключей/значений будете придираться - это комментарии пользователей, вполне типичный размер.
> Я с ним в продакшне работаю, вообще-то. На 64-битной системе с разумными
> размерами ключей (в пределах пары десятков байт) значений (сотни байт) имено
> это и видим. Если к размерам ключей/значений будете придираться - это
> комментарии пользователей, вполне типичный размер.Извиняюсь, возможно вы и правы.
У Redis, как заявляют сами разработчики, проблемы с хранением мелких данных. Они с этим борются, но вроде безуспешно.
(ЗЫ А если не секрет, зачем вы в Redis комментарии храните ?)
> Редис быстрый так как вся база в оперативной памяти. При падении системы
> потеря всей информации, наработанной после последней синхронизации.
> А вообще, да NoSQL быстрее. Например можно хранить все в бинарных деревьях,
> как в Couchdb. Да и атомарность у них обычно на уровне
> одной записи, то есть пол базы в залоченном состоянии не висит.У Mongo атомарности нет вообще, у Couch ЕМНИП тоже.
> При падении системы потеря всей информации, наработанной после последней синхронизации.
Там есть Safe-mode. Правда в нем он всего в пару раз быстрее SQL.
Я к тому, что LevelDB по скорости как раз вполне сравним с RedisDB (судя по представленным данным). А с включенным fsync (упомянутый safe-mode) уделывает его во много раз.
>>у Couch ЕМНИП тоже.Изменяет. Атомарность там на уровне записи единичного документа.
http://guide.couchdb.org/editions/1/en/documents.html
Redis - он не совсем key-value, вообще-то. А так - ну, собственно, выборка по первичному ключу (ближайший аналог этой библиотеки) даже в мускуле весьма шустра, особенно если воспользоваться кодом японцев и избавиться от парсинга SQL. HandlerSocket выдавал у них в тестах около 750000 операций чтения в секунду - это на восьми ядрах, но зато по сети. В общем, цифры сравнимые.
> Redis - он не совсем key-value, вообще-то. А так - ну, собственно,
> выборка по первичному ключу (ближайший аналог этой библиотеки) даже в мускуле
> весьма шустра, особенно если воспользоваться кодом японцев и избавиться от парсинга
> SQL. HandlerSocket выдавал у них в тестах около 750000 операций чтения
> в секунду - это на восьми ядрах, но зато по сети.
> В общем, цифры сравнимые.Достали уже.
1) Redis key-value, просто со структурами данных.
2) Неправильно считают. Надо считать транзакции, а не операции. Тогда SQL вчистую сливает. Проверено.
> просто со структурамиСтруктуры данных индексировать гораздо сложнее, чем текстовые строки. Следовательно и сам движок существенно отличается от других key-value БД.
>> операций чтения
> Надо считать транзакции, а не операцииЧто за транзакции чтения такие?
А кстати, что насчет Exadata 2? Это если говорить о транзакциях? Кто там кому сливает?
>> просто со структурами
> Структуры данных индексировать гораздо сложнее, чем текстовые строки. Следовательно и
> сам движок существенно отличается от других key-value БД.
>_<Массивы и словари обычные. И о какой индексации, вообще идет речь ?
Redis - это очень круто, не спорю. Он поддерживает не только хранение всякого разного,
но и потоки сообщений, крайне (для key-value DB)>>> операций чтения
>> Надо считать транзакции, а не операции
> Что за транзакции чтения такие?Пруф теста, пожалуйста.
... крайне (для key-value DB) сложные операции над данными. И очень хорошая документация кстати.Но это не отменяет того, что она k-v База Данных. Продвинутая, но все-же.
Покажите мне в MyISAM транзакции. Что до редиса - штуковину, умеющую делать intersert для множеств, я в чистые key-value (рядом с TokyoCabinet и memcached) записывать не готов.
на random reads sosnooley. откуда вывод: подходит в качестве архива, не подходит в качестве базы, где данные постоянно нужны. не буду кабинет на неё менять.
#Случайное чтение в режиме холодного старта: 60 тыс операций в секунду;удивляют эти тесты,
просто весь 64 мб файл закеширован в памяти.давайте на базе 1000 терабайт потестим ? и общей памятью 100 гб
У тебя есть такая СХД и генераторные скрипты для правдоподобных данных? Давай.
сразу видна жесткая специализация под элементарные вещи. Такое ощущение, что разрабы таких вот noSQL только и занимаются, что тестируют быстродействие.
Попробовали бы на немного более серьёзных вещах, чем
for x in 0..1000:
db.put('key',i)Почему нельзя сделать группы (метки, теги - как угодно). Ведь если есть:
a1=>value1
a2=>value2часто необходимо выбрать/удалить/обновить ключи вида a* сразу. Не говоря уже об таких примитивах, как поиск. Это не noSQL, а какой-то usefulDB получается.
угу, мне тоже интересно, кто бы по префиксам мог выбирать эффективно. Реализаций же масса возможна, по идее.
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;
Именно
Смешные результаты.
Запись константной строки?
Очень реалистичная задача.Польза NoSql в технологии Map/Reduce и очень легкой скалируемости(просто добавь серверов).
А mySql не нужна.
> Чем оно лучше Berkeley DB?Если не ошибаюсь лицензией. У Berkeley DB не LGPL как того хотелось бы для библиотеки, а GPL только другими словами. В итоге если гугл захочет хоть что-то закрытое выпустить в свет использующее Berkeley DB, то будет платить ораклу. По моему достаточная причина для того чтобы гуглу не использовать эту библиотеку. Собственно и не гуглу перед использованием Berkeley DB сначала стоит поинтересоваться расценками, т.к. сегодня сделаешь свободный проект и все нормально, а завтра понадобится сделать что-то закрытое но привычную библиотеку не сможешь использовать из-за цены.
http://www.oracle.com/technetwork/database/berkeleydb/downlo...