|
2.3, klalafuda (?), 11:49, 28/07/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Похоже, в ChromeOS таки будет реестр.
Ну в ff вообще sqlite встроен - и ничего и ничего и ничего (с)..
| |
|
|
4.14, Аноним (-), 13:10, 28/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
> ...ничего хорошего
Да вообще-то лучше чем тот ужас который до него был. Никогда не видели RDF-портянку на МЕГ? А скорость ее парсинга себе представляете?! Файрфоксина с отросшей хистори доSQLITEовой эпохи являла собой довольно унылое зрелище. С sqlite то что касается истории стало в РАЗЫ быстрее. Наверное потому что теперь не надо на вообще каждую операцию парсить меговый XMLоподобный кусок текста.
| |
|
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 на множество процессов как-то не стыкуется с:
>>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 отлично подойдёт.
| |
|
|
|
|
|
1.2, Аноним (-), 11:40, 28/07/2011 [ответить] [﹢﹢﹢] [ · · · ]
| +4 +/– |
Что-то я не понял, а чем гугла не устроил Tokyo Cabinet? Not invented here?
| |
|
2.43, a (??), 17:23, 28/07/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Что-то я не понял, а чем гугла не устроил Tokyo Cabinet? Not invented here?
Если бы вы занимались профессиональными разработками, то знали бы, что свой код, сделаный под себя и свои задачи, всегда лучше, чем чужой. Даже если он менее производительный и фичастный.
Естественно, реальность такова, что весь код самому не перепишешь, даже будучи средней компанией. Поэтому приходится использовать чужой код.
Но крупные компании могу себе такое позволить. Поэтому они и достигли таких высот, что их основатели не пытались быть похожими на других, а шли своим путем.
| |
|
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. Может поэтому?
| |
|
|
4.13, Аноним (-), 13:07, 28/07/2011 [^] [^^] [^^^] [ответить]
| +2 +/– |
> Хотите сказать, что тестировали работу LevelDB с SQL? ;)
Нет, не хочу сказать. А он это умеет? К bdb вроде как урезанный вариант скуля прикрутили. Хотя объединили их тут по совсем иному признаку: это не сервера СУБД а движки бд, которые можно влинковать в свою программу. И никаких гребаных посторонних процессов и прочих демонов с конфигами. Можно конечно и как кдешники - вдуть под локальную базу с одним пользователем целого мускуля с какими-то дефолтовыми параметрами, повесить жирный демон в памяти от загрузки до шатдауна, независимо от его востребованности и выжрать 30 мегз рамы непонятно на что и зачем. Но так делают только настоящие п....сы. К счастью, не все программеры такие же как кдешники.
| |
|
5.26, gegMOPO4 (ok), 13:45, 28/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Значит они тестировали совсем не то, для чего эти БД предназначены. В забивании гвоздей микроскоп тоже покажет не лучшие результаты, но это не значит, что всем нужно срочно выбрасывать микроскопы и заменять нашими новомодными каменными топорами.
А влинковать можно и libcddb, и libdbus, и libkdb (тоже имеют db в названии) — будем сравнивать с ними?
| |
|
|
3.38, Veter (??), 16:21, 28/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Вообще, над bdb помнится сделали какой-то урезанный вариант sql.
Отстали вы от жизни :) Оракл давно уже вовсю продвигает BerkeleyDB как сторадж с SQLite фрондэндом. Так что есть полноценный SQL, включая view, триггеры, виртуальные таблицы и другие плюшки. А от BerkeleyDB есть конкурентный доступ, репликация и проч.
| |
|
|
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 и InnoDB это реляционные движки? Которые медленние по
> определению.
ничего. сложилась практика применять SQLite там, где достаточно простых key-value (привет, тормозилла!). вот и сравнивают с практикой, а не со сферическими конями в вакууме. и это правильно.
| |
|
6.37, sanDro (ok), 15:46, 28/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
>> А ничего что SQLite и InnoDB это реляционные движки? Которые медленние по
>> определению.
> ничего. сложилась практика применять SQLite там, где достаточно простых key-value (привет,
> тормозилла!). вот и сравнивают с практикой, а не со сферическими конями
> в вакууме. и это правильно.
InnoDB тоже применяют? Там где достаточно key-value сложилась практика применять BDB. C ней они почему-то сравнивать не стали. Я считаю, что подборка для сравнения не корректна. В ней из трёх альтернатив только одна принадлежит к тому же классу, что и LevelBD. Они говорят, что их бд быстрее, а реально это говорит только о том, что сапожным молотком обувь тачать эффективнее, чем кувалдой для забивания свай. Кто бы сомневался.))))
| |
|
7.39, anonymous (??), 16:29, 28/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
на картинке вижу киото и скулит. возможно, стоило бы добавить bdb, но кому эта окаменелость нужна?
| |
|
8.40, sanDro (ok), 16:41, 28/07/2011 [^] [^^] [^^^] [ответить] | +1 +/– | Эта окаменелость вовсю используется в продакшене, в проектах которым не пару л... текст свёрнут, показать | |
|
|
|
5.52, Аноном (?), 22:11, 28/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Чего бы они были медленными п определению? Они вылизывались десятки лет, и как примитивные key-value хранилища показывают достаточно хорошие результаты. Смотрите в сторону HandlerSocket - там это наглядно продемонстрировано.
| |
|
4.47, anon8 (ok), 19:41, 28/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
Мда, видимо придется в таких случаях тег "сарказм".
Сказано это было к тому, что изначально не с тем сравнивали.
| |
|
|
2.18, uhbif19 (?), 13:14, 28/07/2011 [^] [^^] [^^^] [ответить]
| +1 +/– |
> Чем оно лучше Berkeley DB? Совместимо ли API с Berkeley DB (или
> существует ли адаптер)?
> Кто додумался сравнивать продукт типа Berkeley DB (ключ/значение) с SQLite?
Ну видимо, не монструозно.
| |
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 [^] [^^] [^^^] [ответить]
| +/– |
Редис быстрый так как вся база в оперативной памяти. При падении системы потеря всей информации, наработанной после последней синхронизации.
А вообще, да NoSQL быстрее. Например можно хранить все в бинарных деревьях, как в Couchdb. Да и атомарность у них обычно на уровне одной записи, то есть пол базы в залоченном состоянии не висит.
| |
|
3.29, Crazy Alex (ok), 13:58, 28/07/2011 [^] [^^] [^^^] [ответить]
| +/– |
> Редис быстрый так как вся база в оперативной памяти. При падении системы
> потеря всей информации, наработанной после последней синхронизации.
> А вообще, да NoSQL быстрее. Например можно хранить все в бинарных деревьях,
> как в Couchdb. Да и атомарность у них обычно на уровне
> одной записи, то есть пол базы в залоченном состоянии не висит.
Это у кого ж пол-базы в залоченном состоянии получается? Ну ладно SQLite лочит всю базу целиком. Но уже мускул с MyISAM лочит одну таблицу, а поставь нормальный бакэнд - будут локи на уровне строки. А спор "деревья против хэша" - он давний и однозначного решения не имеет - одно быстрее на чтение, другое на запись. В зависимости от паттерна использования надо выбирать разные реализации.
Что же касается редиса - за скорость там расплачиваемся ещё диким расходом памяти - если не ошибаюсь, её тратится раз в десять больше, чем объём хранимых данных. Что весьма неприятно иногда.
| |
|
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) уделывает его во много раз.
| |
|
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 [^] [^^] [^^^] [ответить]
| +/– |
> просто со структурами
Структуры данных индексировать гораздо сложнее, чем текстовые строки. Следовательно и сам движок существенно отличается от других key-value БД.
>> операций чтения
> Надо считать транзакции, а не операции
Что за транзакции чтения такие?
| |
|
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.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
| |
|