Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 39
хранение данных на flesh дискахОго! Это какая-то новая технология? Диски из плоти :)
Прошу прощения за оффтоп
Было бы интересно посмотреть на сравнения между leveldb и rocksdb.
Сам я такие бенчмарки не проводил. Но думаю нет оснований не верить Фэйсбуку: github.com/facebook/rocksdb/wiki/Performance-Benchmarks
Только стоит обратить внимание на конфигурацию стенда, на таком стенде действительно есть профит в силу правок в архитектуру LevelDB.
На счет стенда согласен. У Фэйсбука действительно уникальные условия использования.
Тут важно два момента: LevelDB изначально не проектировалась для больших объемов данных, RocksDB наоборот; LevelDB не проектировалась для работы на SSD накопителях. Как следствие LevelDB на SSD потенциально может обернуться проблемами преждевременного износа SSD диска.
Тут важно два момента: LevelDB изначально не проектировалась для больших объемов данных, RocksDB наоборот; LevelDB не проектировалась для работы на SSD накопителях. Как следствие LevelDB на SSD потенциально может обернуться проблемами преждевременного износа SSD диска.
Полностью согласен, у LevelDB действительно выше нагрузка при записи. Вы замеряли производительность RocksDB или RocksServer на своем железе? Можете привести конфиг и rps на random write/read (желательно с key 8b, value 250b, но если есть другие бенчи — норм)? Кстати, какое отношение объема базы / RAM у вас в проекте?
У них разные задачи и подразумевается разная инфраструктура под ними. KVS нужно подбирать не по бенчмаркам на чужом железе и чужих средах, а исключительно под свою задачу и окружение. И да, если ваша инфраструктура windows-based можно забыть про rocksdb, слишком велика завязка на *nix особенностях. Если LevelDB можно адаптировать (и это успешно сделано ребятами из Bitcoin'а), то тут грусть печаль.
Если есть желание, можете рассказать про условия своей задачи и как вы используете LevelDB, дам совет здесь же. Перебрал множество современных key value storages, есть опыт, с удовольствием поделюсь. Статья не потяну сейчас, но обсудить и обменяться опытом — было бы круто.
Если есть желание, можете рассказать про условия своей задачи и как вы используете LevelDB, дам совет здесь же. Перебрал множество современных key value storages, есть опыт, с удовольствием поделюсь. Статья не потяну сейчас, но обсудить и обменяться опытом — было бы круто.
Хотелось бы сравнения с другими популярными NoSQL хранилищами. То, что это написано в Facebook — безусловно круто. Хорошо бы знать на сколько круто.
У RocksDB специфичная область применения. Поэтому сравнивать его нужно с хранилищами одного класса. Разумеется Redis'у она проиграет (по крайней мере при старте точно должна). Логичным было бы сравнивать, я думаю, с RethinkDB т.к. это тоже зрелое решение пригодное для установки на SDD носитель. Но я таких тестов не видел, а у самого пока руки не дошли их написать.
Как можно сравнивать RocksDB и Redis? Тогда уже RocksServer / Redis и то сравнение будет не совсем корректным.
Я как раз и имел в виду, что некорректно сравнивать разные по своей природе NoSQL хранилища. Если говорить конкретно о RocksServer, то его основную область применения я вижу в достижении высокой производительности за счет переноса данных с HDD на более быстрый носитель и экономия на инфраструктуре за счет использования SDD вместо памяти. Тут не так уж и много вариантов для сравнения.
есть еще такой вариант — github.com/ideawu/ssdb-rocks от автора ssdb (LevelDB + net interface, очень клевая штука, имеет аналогичный с редисом интерфейс, все планирую написать статью о ней, использую в продакшине уже больше года)
Да я ее видел. Я тоже изначально хотел ее использовать. Честно, сейчас уже не вспомню что мне не понравилось, но отказался я от нее поковыряв исходники. Сейчас еще раз посмотрю попробую ответить подробнее.
Посмотрел еще раз. К сожалению, наскоком так не смог найти почему я от нее отказался. На первый взгляд, с того момента когда я последний раз ее смотрел, код очень сильно поменялся.
Каково ваше впечатление от использования? Какие-нибудь глюки ловили? В последнее время я часто вижу ее в топе Гитхаба в разделе C++. Может быть ее уже допилили и там действительно все хорошо.
Каково ваше впечатление от использования? Какие-нибудь глюки ловили? В последнее время я часто вижу ее в топе Гитхаба в разделе C++. Может быть ее уже допилили и там действительно все хорошо.
Мы кстати сравнивали RocksDB и в итоге остановились именно на SSDB. Уже не вспомню почему. Но SSDB работает вполне стабильно у нас на продакшене, крутит порядка 300ГБ данных в общей сложности. Полет нормальный.
make install
ну сколько же раз писали про это и пакетные дистрибутивы… checkinstall же!
Я у себя так и собираю.
src/description-pak у меня как раз для checkinstall и лежит. Просто по идее сборка может проходить на любом Линукс дистрибутиве. Поэтому я не стал про это здесь писать. Тем более на Хабре уже много раз про checkinstall писали, поэтому мне показалось что не обязательно еще раз напоминать. Кстати для удаления я не забыл добавит команду make uninstall. Так что в данном конкретном случае make install вполне безопасен.
> Для реализации http слоя был использован Libevent.
Весьма похвально. Libevent используется в memcached.
Весьма похвально. Libevent используется в memcached.
Отличное решение! Вам стоит расширить набор бэкэндов для своего RocksServer'а, в силу практически идентичного API можно добавить LevelDB и HyperLevelDB. Это сделает проект еще интереснее, да и для своего проекта сможете выбрать тот бэкэнд, который действительно даст максимальный профит.
Спасибо за отзыв.
Никогда не сталкивался с HyperLevelDB. Если честно, я досконально не разбирался с API LevelDB. И сейчас мне трудно сказать в какой части они перестают быть совместимыми. Знаю точно, что то что я сейчас использую от RocksDB есть и в LevelDB. С другой стороны различные итераторы появившиеся в поздних версях RocksDB или семейства столбцов, скорее всего, в LevelDB отсутствую.
Вообще планы развивать RocksServer и добавлять бэкенды есть. Но сначала я хотел перейти к его практическому использованию. В текущем виде он решает те задачи которые есть у меня в настоящий момент и сама архитектура предполагает не сложное его расширение.
Никогда не сталкивался с HyperLevelDB. Если честно, я досконально не разбирался с API LevelDB. И сейчас мне трудно сказать в какой части они перестают быть совместимыми. Знаю точно, что то что я сейчас использую от RocksDB есть и в LevelDB. С другой стороны различные итераторы появившиеся в поздних версях RocksDB или семейства столбцов, скорее всего, в LevelDB отсутствую.
Вообще планы развивать RocksServer и добавлять бэкенды есть. Но сначала я хотел перейти к его практическому использованию. В текущем виде он решает те задачи которые есть у меня в настоящий момент и сама архитектура предполагает не сложное его расширение.
Как раз не смотрел итераторы в RocksDB и доп. фишки, но базовые вещи 1-в-1. HyperLevelDB полностью совместим с LevelDB в плане API. А можете рассказать больше про текущие задачи, действительно интересно (можно без функционала, если нельзя раскрывать, просто конфиг / требования / объемы / среда и т.д.).
Не уверен что верно понял ваш вопрос, но попробую ответить как понял.
Году где-то в 2012 я переписывал один довольно посещаемый проект (в то время посещаемость была ~50 000 хостов/сутки ). Сервер справлялся с нагрузкой но время отклика оставляло желать лучшего. Оптимизация MySQL кардинально ситуацию не улучшила. В итоге было решено добавить кэширующий слой. В качестве бекенда для кэширующий библиотеки были поставлены Redis и Memcached. В итоге время отклика стало экстремально низким: 2-6 мс, но поддержка проекта стала вызывать боль. Появилась сильная связанность. Вот собственно тогда размышляя над тем как такое получилось пришло понимание, что кэширования должно быть ровно столько, что бы оно не увеличивало связанность компонентов внутри проекта.
Теперь что меня привело к написанию RocksServer'a. Сейчас у меня наконец то представилась возможность поучаствовать в написании большого интересного проекта. Я не знаю заранее какой будет посещаемость но изначально время отклика должно быть экстремально низким. Собственно, обоснование того, почему какой бы эффективный алгоритм не использовало хранилище данных, все упирается в носитель (HDD) я описал в статье. Поэтому изначально рассматривал хранилища оптимизированные под SSD.
Инфраструктура. Планируется использовать Debian сервер (может быть будет Ubuntu). Структуру каталогов я планирую хранить в Resdis. Под него будет отведено 2-3 Гб. Все остальные данные пойдут в RocksServer. Под данные ожидается выделить 100-300 Гб. Мне уже писали в личку, что такой объем данных вполне можно засунуть в ОЗУ, но это существенно увеличит стоимость архитектуры. Поэтому из практических соображений SSD является для меня оптимальным компромиссом.
Что касается тонкой настройки самого RocksDB, то, как я уже говорил, в боевых условиях я его еще не испытывал, поэтому ничего полезного по этому поводу пока сказать не могу.
Году где-то в 2012 я переписывал один довольно посещаемый проект (в то время посещаемость была ~50 000 хостов/сутки ). Сервер справлялся с нагрузкой но время отклика оставляло желать лучшего. Оптимизация MySQL кардинально ситуацию не улучшила. В итоге было решено добавить кэширующий слой. В качестве бекенда для кэширующий библиотеки были поставлены Redis и Memcached. В итоге время отклика стало экстремально низким: 2-6 мс, но поддержка проекта стала вызывать боль. Появилась сильная связанность. Вот собственно тогда размышляя над тем как такое получилось пришло понимание, что кэширования должно быть ровно столько, что бы оно не увеличивало связанность компонентов внутри проекта.
Теперь что меня привело к написанию RocksServer'a. Сейчас у меня наконец то представилась возможность поучаствовать в написании большого интересного проекта. Я не знаю заранее какой будет посещаемость но изначально время отклика должно быть экстремально низким. Собственно, обоснование того, почему какой бы эффективный алгоритм не использовало хранилище данных, все упирается в носитель (HDD) я описал в статье. Поэтому изначально рассматривал хранилища оптимизированные под SSD.
Инфраструктура. Планируется использовать Debian сервер (может быть будет Ubuntu). Структуру каталогов я планирую хранить в Resdis. Под него будет отведено 2-3 Гб. Все остальные данные пойдут в RocksServer. Под данные ожидается выделить 100-300 Гб. Мне уже писали в личку, что такой объем данных вполне можно засунуть в ОЗУ, но это существенно увеличит стоимость архитектуры. Поэтому из практических соображений SSD является для меня оптимальным компромиссом.
Что касается тонкой настройки самого RocksDB, то, как я уже говорил, в боевых условиях я его еще не испытывал, поэтому ничего полезного по этому поводу пока сказать не могу.
Если я верно вас понял, то вы имеете опыт работы с такими системами. Было бы очень интересно услышать с какими нюансами вы сталкивались.
Просто прошел тернистый путь подбора KVS под свои задачи. LevelDB, HyperLevelDB, Sophia, тайгер, решение от Symas'а и куча наркомании уровня BangDB. Причем как *nix, так и Windows среды (это было страшно). Какие нюансы вас интересуют?
Пожалуй, самый забавный проект, начиная от оффсайта, заканчивая производительностью и API. Его, как и всех остальных, нужно уметь готовить. Играться компараторами, к примеру (настроек у него минимум). Его однозначный плюс — это автор, в отличии от того же Говарда Чу из OpenLDAP'а, к примеру, Дмитрий из mail.ru готов выслушать, помочь (в рамках проекта) и пообщаться за жизнь.
Гонялся под виндой и линухом. Кстати, виндовый порт (написал биндинги под C#) не смотря на disclaimer создателя относительно содержимого — оказался вполне стабильный на небольшой нагрузке, LevelDB он обошел на поставленных задачах. Но в продакшен так и не ушел пока что. Для меня он в TOP-3 по совокупности и на втором месте по скорости в рамках поставленных задач.
Гонялся под виндой и линухом. Кстати, виндовый порт (написал биндинги под C#) не смотря на disclaimer создателя относительно содержимого — оказался вполне стабильный на небольшой нагрузке, LevelDB он обошел на поставленных задачах. Но в продакшен так и не ушел пока что. Для меня он в TOP-3 по совокупности и на втором месте по скорости в рамках поставленных задач.
Добро пожаловать в мир Key/Value ;),
На мой взгляд, было бы очень логично использовать мемкешовый протокол. Есть куча готовых клиентов.
Хотя в проектах можно использовать и курл…
спаисбо за разработку…
На мой взгляд, было бы очень логично использовать мемкешовый протокол. Есть куча готовых клиентов.
Хотя в проектах можно использовать и курл…
спаисбо за разработку…
Да вы правы. В текущем виде Memcache протокол смотрелся бы там очень логично. Я даже подумаю над тем, что бы добавить еще один уровень абстракции и сделать протокол заменяемым.
Поясню, почему я изначально не остановился на Memcache протоколе. RocksDB предоставляет бо`льшие возможности нежели Memcached и в дальнейшем я планирую расширять функциональные возможности. соответственно на каком то этапе Memcache протокол будет исчерпан.
Но, безусловно, никто не обязан использовать все возможности сервера. И вполне можно обойтись только базовыми. Так что ваше замечание очень полезно. Спасибо.
Поясню, почему я изначально не остановился на Memcache протоколе. RocksDB предоставляет бо`льшие возможности нежели Memcached и в дальнейшем я планирую расширять функциональные возможности. соответственно на каком то этапе Memcache протокол будет исчерпан.
Но, безусловно, никто не обязан использовать все возможности сервера. И вполне можно обойтись только базовыми. Так что ваше замечание очень полезно. Спасибо.
Просто по опыту скажу, что мемкешед более подходящее решение, так как сам написал пару оберток к существующим key/value (Sophia & Tokyo). Скажу больше, у нас в компании большинство демонов общаются с фронтэндом используя мемкешовый протокол. А недостаточную функциональность просто расширяем, добавляя префикс к ключам, или иным способом.
Например мультидел для ключей 123,456 и 789 можно реализовать так:
в клиент передаем строку «123,456,789» которая не противоречит концепции ключа.
Принципиально, можно поддерживать два и более протоколов, как реализовано, например, в TokyoTyrant или тот же мемкеш поддерживает текстовый и бинарный протокол.
Например мультидел для ключей 123,456 и 789 можно реализовать так:
delete 123,456,789в клиент передаем строку «123,456,789» которая не противоречит концепции ключа.
Принципиально, можно поддерживать два и более протоколов, как реализовано, например, в TokyoTyrant или тот же мемкеш поддерживает текстовый и бинарный протокол.
Насколько оно быстрее TokuDB?
Мне кажется некорректно сравнивать движок для MySQL со специфичным key/value хранилищем.
TokuDB — такое же специфичное хранилище для SSD.
Его достоинство в том, что оно умеет эффективно сжимать данные (в разы меньше места занимают, чем на mysql), получается экономия на дисковом пространстве — актуально для SSD.
Плюс быстрая запись, оптимизированная под SSD.
Так что вполне уместно было бы сравнить эти движки по параметрам: скорость записи, скорость чтения, сколько данные места на диске занимают.
Его достоинство в том, что оно умеет эффективно сжимать данные (в разы меньше места занимают, чем на mysql), получается экономия на дисковом пространстве — актуально для SSD.
Плюс быстрая запись, оптимизированная под SSD.
Так что вполне уместно было бы сравнить эти движки по параметрам: скорость записи, скорость чтения, сколько данные места на диске занимают.
Судя по результатам теста, память неиспользуеться?
А почему такой маленький объем данных?
Сколько времени длился тест?
Какой размер на диске занимала база?
Какова была конфигурация тестового стенда?
Сколько клиентов запрашивало данные?
Клиент запускался на той же машине?
Возможно имело смысл использовать датасет с размером заведомо большим чем объем оперативной памяти.
Например 20М записей размером по 150 байт или 150% от объема оперативной памяти.
А почему такой маленький объем данных?
Сколько времени длился тест?
Какой размер на диске занимала база?
Какова была конфигурация тестового стенда?
Сколько клиентов запрашивало данные?
Клиент запускался на той же машине?
Возможно имело смысл использовать датасет с размером заведомо большим чем объем оперативной памяти.
Например 20М записей размером по 150 байт или 150% от объема оперативной памяти.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
RocksDB сервер – быстрое key-value хранилище для SSD накопителей