hi, Thu, Mar 30, 2017 at 12:48:52, basil wrote about "[uanog] riak":
riak кто-то использует? интересует какой-то отзыв, ибо инфы очень мало по нему, сейчас тестируем - пока нравится, но может есть какие-то подводные камни
Использовали, хоть и не в сверхбольших масштабах. Впечатления следующие: 1. Основная роль key-value без упорядочения ключей, разве что с разделением по корзинам - выполняется беспроблемно. Сюда - добавление/удаление и итерирование в его стиле. 2. Резервирование хранения - тоже неплохо сделано и регулируется на ходу почти как угодно. Что не рулилось - количество партиций, поэтому при создании всего кластера их надо делать с запасом, даже если на старте один сервер в кластере :) Дальше между серверами они перераспределят сами. 3. Бэкенды со странностями. Bitcask хранит ключи в RAM, это становится невозможно на огромных объёмах (знакомые закачивали в него сотни гигабайт), и имеет меньше возможностей. Eleveldb хорошо работает при операциях типа "вгрузили пару миллиардов ключей, погоняли, удалили", но вот шаблон, который его порвал - это постоянное обновление небольшого набора ключей - сжатие в eleveldb работало крайне медленно. Мы добивались раздутия крошечной базы до единиц гигабайт и самосдутия до нормального размера после снятия любой активности в течение двух недель. Что-то там в логике сжатия не так (другие реализации LSM не страдают таким). Это надо иметь в виду при тесте нагрузки. 4. При рассинхронизации данных на разных партициях он оставляет вопрос решить, где правильные данные, клиенту. Клиенты сразу надо писать с заточкой под это. В зависимости от значений параметров R, W и прочих в запросе, можно снизить вероятность нарваться на это, но она никогда не падает до 0. 5. Для диагностики надо уметь внедряться с контрольными вопросами в еноду. Это относительно лёгкое умение, но несколько дней таки потребует. В качестве альтернативы тому же подходу - смотреть на Cassandra и ScyllaDB, обе делают в принципе то же самое, но ещё есть вторичные ключи. (Есть Riak Time Series, но ещё сырой.) -netch-