Про использование Riak в боевых условиях

Оригинал тут: http://lionet.livejournal.com/98362.html

Тут всплыло: http://juick.com/zamotivator/1652611

Давайте поясню мою позицию.

У нас действительно, как сказал Макс, довольно большая и нагруженная инсталляция риака. У нас 50 машин с десятком гигабайт памяти на каждой. Используется InnoDB сторадж. Каждая машина почти упирается в диск на запись. Всего полгода назад эта инсталляция входила в топ 3, наверное, продакшн 24/7 инсталляций Риака в мире (сейчас в top 50). Поэтому когда я что-то говорю про риак, троллям нужно помолчать и послушать.

У нас этот кластер обслуживает несколько сотен гигабайт данных (сотни миллионов ключей), в него происходит запись и чтение от нескольких сот до нескольких тысяч раз в секунду.

Кроме этого кластера у нас десятки PostgreSQL-инсталляций, так что мы не NoSQL-фанбои. Впрочем, есть у нас ещё и MySQL, и Membase.
С каждым продуктом у нас своя войнушка в масштабирование (наиболее нестабильным, но и наиболее шустрым решением в продакшне является membase).

В течение месяца одна или две риаковских ноды обязательно выйдут из строя из-за флуктуаций континуума на Amazon'е. Мы этих вылетов не замечаем, продакшн продолжает работать. Так что операционно риак — это достаточно удобная сущность. Ночью никого не будит, если хардвер слёг.

Проблемы же с риаком такие:

1. Довольно медленный map/reduce; почти не юзабельный на практике на больших данных. Кому нужен MR — используйте хадуп что-ли.
2. Links и link-walking — это шутка такая. Использовать её нельзя, если _максимальное_ количество линков больше чем примерно десяток. Графовую базу из риака не построишь.
3. Расширять кластер удобно от трёх до четырёх нод. Добавил ноду и всё. От десяти до пятидесяти нод расширять — это большой геморрой, ибо ребалансировка происходит долго (добавь ноду — балансируй, добавь другую — балансируй: это может длится неделями). В итоге нам пришлось заказывать платную помощь, которая нам расширила кластер, по сути, руками (полуавтоматически).

Проблема с нашим шаблоном использования риака такие: ключи не имеют выраженного хот-сета, размер значения — примерно 4k. Отсюда достаточно большая нагрузка на диск, когда каждое добавление нового ключа может приводить к сплитам букетов.

Что бы я изменил:

1. Не использовал бы Amazon, а использовал бы хостинг с SSD-дисками. Например, Take2. Это мгновенно окупается.
2. Попробовал бы Bitcask-backend или LevelDB. Потому что всё равно весь датасет должен быть в памяти (у вас датасет на диске и всё ок? Так вам риак не особо нужен).

Что бы я рекомендовал:

• Если вы не знаете, чем именно (алгоритмически, операционно) вам поможет Riak, начните с mysql/postgresql в K/V режиме, дальше разберётесь.
• Если вы думаете, что нужен задел на будущее, но о том, каким именно будет это будущее, не знаете, начните с mysql/postgresql, дальше разберётесь.
• Если вы хотите использовать MR в качестве рабочего инструмента (а не редчайших прогонов) — не используйте riak.
• Если вы точно поняли, что вам нужен Риак, но рассчитали, что вам должно хватить всего пять-десять машин — то это сигнал к тому, что вы не получите достаточных преимуществ от Риака перед тремя-четырьмя нодами с MySQL.
• Есди ваш продакшн не настолько критичен и может денёк полежать, либо если данных немного, и какая-нибудь master/slave конфигурация SQL-решения выдержит нагрузку, либо у вас собственный хардверный кластер и вы не используете внешние виртуализованные сущности, то использование Риака даёт мало преимуществ перед тем же MySQL в K/V режиме.

Чем нам нравится Риак? Не нужно просыпаться, если бокс упал. Однажды мы даже решили подождать, пока у человека не закончится отпуск, прежде чем возвращать в строй упавшую ноду. Риак позволил нам не упереться в вертикальные ограничения боксов на амазоне: мастер/слейв ящик с полутерабайтом памяти и с 5kIOPS на амазоне не соберёшь.

Обычно же при выборе Riak исходят из каких-то астрономических построений: не имея опыта сопровождения больших баз данных, не имея представления о том, сколько данных будет в проекте, не имея представления о том, что можно и нельзя использовать в Riak на больших данных, не имея представления о том, чем InnoDB-бэкенд риака отличается от MySQL. Всем таким астроархитекторам надо советовать не морочить себе голову и начинать с наиболее традиционных решений. Потом жизнь и опыт покажут, где есть узкие места, и дадут возможность рассуждать о том, как эти узкие места убрать. И вообще, является ли Riak решением для этих узких мест.