>>966114 (OP)
Что за ёба-распределённая система? Что хранится в Riak?

>>966128
Спасибо за внимание к посту. В риак хранятся отсканированные документы т.е. картинки. В редис хранятся счетчики - статистика за текущий день. Основной вопрос можно ли на одном серваке несколько баз данных держать разных в т.ч. на одном дисковом массиве. Есть ли смысл ssd под файлы баз данных использовать? Система гетерогенная, обмен между частями с помощью ampq rabbit.

>>966173
> Основной вопрос можно ли на одном серваке несколько баз данных держать разных в т.ч. на одном дисковом массиве

Да как бы нездоровье, если пропускной способности массива хватает.
Если важна безопасность, то каждую БД в джейл помещай или в свою виртуалку.

>>966173
Прямо бинари храните в Риаке?
Вообще очень похоже на то, чем мы занимаемся на работе: тоже сканированные документы, только каждый раз рендерятся, тоже статистика считается.
Тоже библиотека какая-то?

>>966114 (OP)
>Думаю их на 1 сервер поставить
Какой смысл? Вся суть Riak в p2p, что если падает где-то сервак, на работу системы это вообще не влияет, мастера тонет. Но если у тебя всё на 1 серваке, то когда какой толк?

Не используй риак кроме как для key/value.
Из-за отсутствия транзакций с ним реальная боль.
Конфликты нормально не порешать.
Пагинация очень ограниченная.
С поиском хз, ноя думаю что там так же все через жопу.

После долго использования риака мы так и не поняли в чем его фишка кроме тупого хранения значений по ключам.

>>966314
сканированные анкеты, бро

>>966114 (OP)
Что это за хипстер?
>А риак у меня - 3 ноды. Думаю их на 1 сервер поставить
Как можно догадаться поставить распределенную систему на 1 сервер?
>Сколько минимально серверов мне понадобится
Как можно ответить на этот вопрос не зная ни нагрузки, ни параметров этих самых серверов. Плюс эти все системы можно 100 лет тюнить что бы добиться оптимальной приемлимой производительности.
Мой совет вам - бросайте страдать хуйнёй, берите постгрес, складывайте файлики на диск и не выёбывайтесь. Очевидно же что вы не знаете с чем связываетесь.
Ах да, эластик можно оставить если он используется для логов (как часть ELK например).
>>966445
>После долго использования риака мы так и не поняли в чем его фишка кроме тупого хранения значений по ключам
С Riak не работал, но что тебе еще нужно от тупого key-value store?

>>967054
Спасибо

Помню как-то любопытствовал что за риак, начал читать официальную доку, там так было написано: если у вас меньше 5 или 7 нод, забудьте про риак, это не для вас.

>>967054
Дык у него вроде как много фич есть. Но они как-то не то чтобы ахуенно работают.
Да и разрешение конфликтов часто не очень тривиальная задача.

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

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

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

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



Dec. 2nd, 2011 at 3:42 PM


Тут всплыло: 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 решением для этих узких мест.

Риаку 5+ машин надо