The OpenNET Project / Index page

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

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

28.07.2011 10:33

Компания 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
Тип: Программы
Короткая ссылка: https://opennet.ru/31325-LevelDB
Ключевые слова: LevelDB, database, nosql
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (64) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | 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-портянку на МЕГ? А скорость ее парсинга себе представляете?! Файрфоксина с отросшей хистори до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 не поддерживается одновременный доступ к БД нескольких процессов - в заданный момент времени только один процесс может работать с файлом базы.
     
     
  • 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 +/
    > Что-то я не понял, а чем гугла не устроил 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. Может поэтому?
     
     
  • 3.7, gegMOPO4 (ok), 12:23, 28/07/2011 [^] [^^] [^^^] [ответить]  
  • +/
    Хотите сказать, что тестировали работу LevelDB с 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 есть конкурентный доступ, репликация и проч.

     
  • 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 и 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 +/
    Эта окаменелость вовсю используется в продакшене, в проектах которым не пару л... текст свёрнут, показать
     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    Чего бы они были медленными п определению? Они вылизывались десятки лет, и как примитивные key-value хранилища показывают достаточно хорошие результаты. Смотрите в сторону HandlerSocket - там это наглядно продемонстрировано.
     
  • 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 +/
    > Чем оно лучше 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) уделывает его во много раз.


     
     
  • 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 [^] [^^] [^^^] [ответить]  
  • +/
    > просто со структурами

    Структуры данных индексировать гораздо сложнее, чем текстовые строки. Следовательно и сам движок существенно отличается от других 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.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:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

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