Comments 12
Хотелось бы немного подробностей.
Почему именно кассандра? От неё отказались в фейсбуке и, на сколько я знаю, отказываются (или уже отказались) в твиттере.
Какой replication factor? Пишете/читаете с кворумом?
Сталкивались с проблемой потери данных в случае hinted handoff и потери ещё одной машины?
Ну и вообще, сколько у вас примерно данных в целом, сколько дисков в штуках, сколько памяти, и сколько запросов в секунду, это самые интересные цифирки.
Почему именно кассандра? От неё отказались в фейсбуке и, на сколько я знаю, отказываются (или уже отказались) в твиттере.
Какой replication factor? Пишете/читаете с кворумом?
Сталкивались с проблемой потери данных в случае hinted handoff и потери ещё одной машины?
Ну и вообще, сколько у вас примерно данных в целом, сколько дисков в штуках, сколько памяти, и сколько запросов в секунду, это самые интересные цифирки.
Почему именно кассандра? Если подходить исторически, то потому что с ней уже некоторое время игрались и были знакомы. С технической точки зрения важнейшими были: простота расширения и отсутствие каких-либо выделенных узлов или процессов: очень не хотелось вносить в систему SPOF или добавлять без нужды сложную архитектуру ка примеру HBase. По функциональности и производительности она очевидно удовлетворяла нашим требованиям.
Фактор репликации у нас равен единице на каждый датацентр, то есть фактически в каждом датацентре находится одна полная копия данных, а в сумме получается шесть копий — благодаря этому все чтения и записи происходят локально в пределах датацентра.
Пишем и читаем с consistency level ONE. Мы не пробовали работать на уровне QUORUM или LOCAL_QUORUM, в основном потому что для нас важнее времена ответа. Та consistency которая обеспечивается на уровне ONE для нас достаточна.
Нет, с потерей данных мы не сталкивались.
Дисков у нас по одному 300-гигабайтнику на сервер, из этих 300Г в худшие времена бывало занято до 150-200G — это было тогда, когда процедура repair выполнялась не так как должна, без предварительной чистки tombstones. В результате все эти tombstones копировались между серверами и занимали кучу места. Сейчас на каждом диске хранится обычно 40-60 гиг, то есть получается на датацентр 120 гиг. Про память писал — 8 гиг на каждом сервере, под кучу для явы отдаём вот так:
MAX_HEAP_SIZE=«3584M»
HEAP_NEWSIZE=«600M»
С запросами ситуация разная в разных датацентрах и в разное время суток. Максимум что приходилось видеть на один сервер — на уровне 200 чтений/100 записей в секунду. В целом на кластер приходится на уровне до 1000 в секунду.
Фактор репликации у нас равен единице на каждый датацентр, то есть фактически в каждом датацентре находится одна полная копия данных, а в сумме получается шесть копий — благодаря этому все чтения и записи происходят локально в пределах датацентра.
Пишем и читаем с consistency level ONE. Мы не пробовали работать на уровне QUORUM или LOCAL_QUORUM, в основном потому что для нас важнее времена ответа. Та consistency которая обеспечивается на уровне ONE для нас достаточна.
Нет, с потерей данных мы не сталкивались.
Дисков у нас по одному 300-гигабайтнику на сервер, из этих 300Г в худшие времена бывало занято до 150-200G — это было тогда, когда процедура repair выполнялась не так как должна, без предварительной чистки tombstones. В результате все эти tombstones копировались между серверами и занимали кучу места. Сейчас на каждом диске хранится обычно 40-60 гиг, то есть получается на датацентр 120 гиг. Про память писал — 8 гиг на каждом сервере, под кучу для явы отдаём вот так:
MAX_HEAP_SIZE=«3584M»
HEAP_NEWSIZE=«600M»
С запросами ситуация разная в разных датацентрах и в разное время суток. Максимум что приходилось видеть на один сервер — на уровне 200 чтений/100 записей в секунду. В целом на кластер приходится на уровне до 1000 в секунду.
забыл сказать что в проекте кторый работает со счетчиками в кассандре мы в тестах н апроизводительность получаем до 10-20К запросов в секунду. Причём добавление каждого следующего сервера линейно добавляет ёмкости по запросам
Я правильно понимаю, что вы не используете встроенный в кассандру механизм репликации и сами руками пишете 6 копий?
Нет, конечно — она сама всё делает. У кассандры есть хорошо оптимизированный механизм репликации между ДЦ — если запис данных произошла в датацентре A и нужно поместить две копии записанных данных в датацентр B, то кассандра посылает только одно сообщение в сторону B, в том датацентре узлы уже сами скоординируются. Так что мы её используем для репликации очень даже хорошо.
О, забыл добавить про хадуп: он в мульти-ДЦ конфигурации не живёт вообще практически никак. В том же ФБ есть хитрожопая система горячего свапа неймноды, но это вариант для 2 ДЦ максимум, и ещё качественный канал между ними нужен.
у кассандры есть шикарная фишка — можно сделать кластер с «виртуальными датацентрами». Например у вас есть кластер, который в реалтайме пишет/читает какие-то данные. Периодически эти данные требуют тяжелой обработки через MR к примеру. В кассандре можно построить два «виртуальных» датацентра, настроить репликацию из «реалтаймового» датацентра в аналитический и пусякать тяжелые задачи в нём, не нагружая реалтайм сервера никакой тяжелой обработкой.
спасибо за статью! Очень полезна для тех, кто только начинает использовать касандру и еще не набил себе шишек
Собственно, я почему так расспрашивал: один разраб из фейсбука на прошлогоднем YaC пол дня с нами тусил. Он рассказал нам страшную историю о том, почему они перестали использовать кассандру :)
Правда, у них по сравнению с автором поста несколько нечестные условия: всего 2 ДЦ, и оба в штатах.
Правда, у них по сравнению с автором поста несколько нечестные условия: всего 2 ДЦ, и оба в штатах.
А какой у вас характер нагрузки по чтению? Сколько данных в среднем возвращает один запрос на чтение? И сколько их вообще в секунду?
Sign up to leave a comment.
Cassandra глазами Operations