Comments 10
Спасибо. Полезно.
По поводу звука — не актуально, сам дурак.
По поводу звука — не актуально, сам дурак.
Круто! Спасибо! А доклад от Мамбы точь в точь, как на highload++ 2012
Честно говоря послушав, у меня сложилось такое же мнение как и у тех кто там был. Сделали велосипед не попробовав даже nosql базы. Основная отговорка — избыточный функционал. Функционала много не бывает, главное чтобы он не мешал производительности.
посмотрел доклад баду, все почти в точности как и у нас…
да, мы тоже пошли по пути баду и сделали свой велосипед свое nosql решение, потому-что существующие не справлялись, с тем исключением, что взяли за основу TokyoCabinet.
В отличие от архитектуры решения баду — у нас есть минишардинг, т.е. мы шардим наши хештаблицы, т.е. не используем одну большую, а используем несколько средних в пределах одного демона.
Ну и у нас объемы в 10 раз меньше, чем в баду.
В хранилище держим счетчики симпатий (типа лайки), геоданные и еще какую-то муть… Производительность в продакшене 4.5К транзакций в сек. Реально — может выдержать больше процентов на 30.
подробнее
да, мы тоже пошли по пути баду и сделали свой велосипед свое nosql решение, потому-что существующие не справлялись, с тем исключением, что взяли за основу TokyoCabinet.
В отличие от архитектуры решения баду — у нас есть минишардинг, т.е. мы шардим наши хештаблицы, т.е. не используем одну большую, а используем несколько средних в пределах одного демона.
Ну и у нас объемы в 10 раз меньше, чем в баду.
В хранилище держим счетчики симпатий (типа лайки), геоданные и еще какую-то муть… Производительность в продакшене 4.5К транзакций в сек. Реально — может выдержать больше процентов на 30.
подробнее
Sign up to leave a comment.
Записи докладов с конференций по высоким нагрузкам HPC