Где и как хранить данные рекомендательного сервиса?

Question

[Valeriy Solovyov]

Всем доброго времени суток
Делаю рекомендательный сервер: оценка, отзывы, рекомендации.
(Объектов рекомендаций тысячи + отзывы) * (разные языки). Операции чтения сильно преобладают над записью (>>5x).
Вопрос: как построить отказоустойчивый сервис.
Офтоп:

Для некоторых сайтов (php+mysql) не было нормального хостинга. То тех.работы, то сервер завис. В итоге сделал Master->multi Master mysql replication + динамический dns(возвращается ип на "живые" сервера). 3 VPS позволили без большого даунтайма работать + когда "сгорел" сервер на хостинге, ничего не пострадало.
Вот только МММ репликация работала с проблемами из-за удаленности серверов по датацентрам. Пришлось скрипты-костили писать =(

Возвращаюсь:
Сначала хотел сделать все на SQL базе с помощью Master->Salve репликаций:

• отдельно демон добавления комментариев/описаний, который всё складывает в очередь, которая обрабатывается на мастере.
• Сам сайт будет читать данные со слейвов

Минусы для меня:

1. SQL-архитектура
2. настройка Master->Salve репликации
3. Если упадёт мастер, то нужно хранить очередь = как обеспечить сохранность очереди
4. Если мастера долго нет?

Потом я подумал что можно реализовать на MongoDB:

• Есть репликация
• Не нужен DBA =)
• Скорость по выше
• Не нужно вначале реализовывать работу с очередью, можно оставить на потом

Из непонятного мне в таком случае:

• Если VPS в разных датацентрах, то какие последствия?
• Если ноды будут отваливаться, будет ли деградация производительности?

Answer 1

[Александр Никитин]

Зачем Вам для такой задачи SQL бд? Посмотрите в сторону NoSQL или движков типа Elasticsearch...

Answer 2

[lega]

Если VPS в разных датацентрах, то какие последствия?

Должно работать нормально, я в одном проекте сделал ноду на домашнем компе с динамическим ип (через OpenVPN) для бекапов, работало стабильно.

Answer 3

[Влад Животнев]

Mysql Percona Galera ответ вам. Только бэкапить не забывайте и пишите _всегда_ только в одну ноду (какую - пофиг, просто на синхронных записях в разные хосты галера ощутимо тупит).

3 ДЦ - хорошо подойдут digitalocean@london, digitalocean@ams1, digitalocean@ams2

Answer 4

[Gleb Palienko]

Вообще, mongo неплохо вписывается под ваш кейс.

Но в пункте "не нужен DBA" могу с вами поспорить - с монгой вы иногда будете попадать в ситуации "запрос торомозит но я не понимаю почему, а вылечилось все перезагрузкой демона". И гугл, в силу молодости монги не всегда сможет помочь.

А теперь по вашим вопросам:
1. Проблем быть не должно. Только учтите, что при падении мастера один из слейвов берет на себя роль мастера, и нагрузка на него изменится, что нужно учесть в планировании архитектуры серверов.
2. Ну, при падении слейва у вас упадет производительность чтения соответственно ). А при падении мастера где-то за 1-4 минуты (зависит от конфигурации) выбирается новый мастер. Тут производительность может немного просесть в момент, когда старый мастер включится и начнется синхронизация, но опять же - зависит от конфигурации и объемов данных.

Если необходимо, могу более подробно проконсультировать в скайпе )