Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 34
А как оно по сравнению с MongoDB, Redis и другими?
Мне кажется правильней её сравнивать с Memcached или Mambase — они также предназначены для хранения пар ключ-значение. MongoDB и Redis же предоставляют более богатый функционал.
Memcache же не обеспечивает хранения…
Вы видимо совсем о Рэдисе не слышали, раз так говорите. А Memcached не предназначена для хранения.
redis как раз и есть хранилище ключ-значение
>Мне кажется правильней её сравнивать с 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
нет, вот здесь ты ошибаешься: 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
>MongoDB и Redis же предоставляют более богатый функционал.
но меньшую производительность,
хотя на базе Lvdb можно самому построить удобный для тебя функционал, который не будет уступать тому же MongoDB или Redis,
ниже в комментариях, если интересно, я кинул ссылку на TreeDb — где я на базе Tokyo Cabinet сделал продукт (надо допилить кой-какие детали и выложить в общий доступ) с функциональностью первого редиса, но превосходящего его по производительности.
но меньшую производительность,
хотя на базе Lvdb можно самому построить удобный для тебя функционал, который не будет уступать тому же MongoDB или Redis,
ниже в комментариях, если интересно, я кинул ссылку на TreeDb — где я на базе Tokyo Cabinet сделал продукт (надо допилить кой-какие детали и выложить в общий доступ) с функциональностью первого редиса, но превосходящего его по производительности.
В полку NoSQL прибыло! Бенчмарки конечно красивые, особенно последовательные чтения/запись. Вот только жаль, что с другими NoSQL решениями они не сравнивали.
каждый сравнивает с выгодной для него позиции. Как показал опыт, надо сделать свои бенчмарки, потому что любое тестирование очень условно: железо, объем ОЗУ и выделенного кеша, использование конкретного АПИ, режима постоянного соединения и прочих тонкостей.
То что было на официальной презентации продукта не всегда совпадает с ожиданиями на твоем боевом сервере. Я уже съел собаку на всяких тестированиях.
Обязательно приму на вооружение с сделаю свои бенчмарки.
То что было на официальной презентации продукта не всегда совпадает с ожиданиями на твоем боевом сервере. Я уже съел собаку на всяких тестированиях.
Обязательно приму на вооружение с сделаю свои бенчмарки.
А какой смысл сравнивать производительность хранилища пар ключ-значение с SQLite? Честнее с Berkeley DB.
И да, почему размещено в блоге Data Mining?
про berkey db — в точку, есть еще поделка kdb (http://kx.com/)
Kyoto Cabinet это и есть современный аналог BerkleyDB
Причина простая: Если бы вместо 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.
Если все-таки совсем внимательно и попристальнее присмотреться к этим графикам, то сразу видно, что результаты теста «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.
А какой смысл сравнивать производительность хранилища пар ключ-значение с SQLite
Может быть потому, что свое решение гугл позиционирует как встраиваемое. В таком случае вполне логично сравнить его SQLite.
Еще с утра эту новость на лоре читал.
Жаль пока сравнений с другими БД маловато. Но по графиках с SQLite3 в самом низу.
Жаль пока сравнений с другими БД маловато. Но по графиках с SQLite3 в самом низу.
И все-таки сравните с redis пожалуйста :).
их изначально нельзя сравнивать так как Redis — это законченное решение
а LevelDb — это emmbed решение. Если взять и реализовать поверх этого API, например, редис протокол — тогда можно сравнить их по производительности. Однозначно скажу, что если к LevelDb присабачить сетевой интерфейс, то он будет однозначно быстрее редиса.
Что касается сравнения, то у редиса более расширенный функционал: списки, множества.
Редис на типах key/value не может делать операции итераций/обратных итераций. Для этого используются списки. Но списки — это последовательный доступ, а LvDb позволяет использовать прямой доступ.
а LevelDb — это emmbed решение. Если взять и реализовать поверх этого API, например, редис протокол — тогда можно сравнить их по производительности. Однозначно скажу, что если к LevelDb присабачить сетевой интерфейс, то он будет однозначно быстрее редиса.
Что касается сравнения, то у редиса более расширенный функционал: списки, множества.
Редис на типах key/value не может делать операции итераций/обратных итераций. Для этого используются списки. Но списки — это последовательный доступ, а LvDb позволяет использовать прямой доступ.
И с MemcacheDB.
спасибо за информацию
что касается бенчмарков, то я конечно понимаю тестировщиков,
которые представляют тесты с выгодных для них позиций.
сравнение с Kyoto TreeDB — это не совсем правильно (я уже не говорю про SQLite)
так как LiveDb — это HashTable, ну сравнивали бы тогда уж с типом Kyoto HashDB — который на порядок быстрее,
так как внутренняя организация Kyoto TreeDB более сложная и представляет собой внутренее Hash хранилище с Tree индексом. И еще есть режим сжатия, отключив который можно добиться более высокой производительности.
еще раз спасибо за информацию, обязательно попробую использовать для какого нибудь из своих проектов.
что касается бенчмарков, то я конечно понимаю тестировщиков,
которые представляют тесты с выгодных для них позиций.
сравнение с Kyoto TreeDB — это не совсем правильно (я уже не говорю про SQLite)
так как LiveDb — это HashTable, ну сравнивали бы тогда уж с типом Kyoto HashDB — который на порядок быстрее,
так как внутренняя организация Kyoto TreeDB более сложная и представляет собой внутренее Hash хранилище с Tree индексом. И еще есть режим сжатия, отключив который можно добиться более высокой производительности.
еще раз спасибо за информацию, обязательно попробую использовать для какого нибудь из своих проектов.
Скорее всего, SQLite в качестве оппонента был выбран как одно из популярных встраиваемых решений.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Google открывает LevelDB: ещё одна внутренняя разработка