Объедините MySQL, Sphinx и MongDB. Хорошая идея?

Question

Для нового проекта я собираюсь объединить MySQL, Sphinx и MongoDB. MySQL для реляционных данных и поиск по числовым значениям, Sphinx для свободного текстового поиска и MongoDB для геоданных. Поскольку мои (быстрые) тесты показывают, что MongoDB является самым быстрым для гео-запросов, sphinx для свободного текстового поиска и MySQL для поиска реляционных данных. Поэтому, чтобы получить лучшую производительность, мне, возможно, придется объединить их в моем проекте.

Есть, однако, три недостатка.

1. Три точки отказа, т.е. Sphinx, MySQL и MongoDB может привести к сбою , который остановит мой сайт
2. мне нужны данные в трех базах данных и должны держать их в курсе (все данные только изменения из них в день, так что это не худшая проблема).
3. Требования к оборудованию и главным образом ОЗУ проходят через крышу , поскольку все базы данных хотят, чтобы большая часть ОЗУ была способна выполнять.

Итак, вопросы состоят в том, чтобы объединить три, оставить один (возможно, MongoDB и использовать Sphinx для геоданных), или даже пойти только с одним (MongoDB или MySQL)?

Чтобы дать представление о данных, реляционные данные приблизительны к 6 ГБ, геоданные около 4 ГБ и данные freetext около 16 ГБ.

Answer 1

Не совсем поняли, имеют ли записи/коллекции/документы, содержащиеся в 3 dbs, ссылки на меж-db. EG, если имена пользователей, задания, номера телефонов указаны в Mysql, а адреса пользователей - в Mongo. Я буду считать, что ответ «Да».

имхо, имеющий 3 различных решений для хранения данных не рекомендуется, потому что:

1) (самое главное) Вы не можете совокупные данные из 2-х блоков данных (в масштабируемым способом).

Пример: Предположим, что вы сохраняете пользовательские данные (имена пользователей) в Mysql и географические координаты пользователя в Mongo. Вы не можете запрашивать фильтры/сортировки в полях, расположенных на обоих dbs. Например, вы не можете:

SELECT all users 
WHERE name starts with 'A' 
SORT BY distance_from_center 

То же самое касается Sphinx.

Решение: вы либо ограничиваете доступ к данным, доступным в одной БД, либо дублируете/зеркалируете данные с одного разряда на другой.

2) Расходы на техническое обслуживание: 3 сервера для обслуживания, различные стратегии резервного копирования/резервирования, различные стратегии масштабирования; Расходы на разработку: разработчик должен использовать 3 библиотеки запросов, 3 разных способа запроса и т. Д.

3) Проблемы несоответствия/синхронизации, с которыми необходимо вручную обращаться (EG вы хотите вставлять данные как в монго, так и в mysql; предположим, что mongo написал данные, но mysql поднял исключение ссылочной целостности, так что теперь у вас есть несогласованность между dbs).

4) О стоимости HW, единственный RAM-eater - MongoDB (рекомендуется, чтобы он имеют все индексы в ram). Для серверов MySQL и Solr вы можете контролировать потребление памяти.

Что бы я сделал:

• Если я не нужны все функции SQL (например, транзакции, ссылочную целостность, соединения, и т.д.) Я бы с Монго

• Если мне нужно эти функции, и я могу жить с более низкой производительностью в геооперациях, я бы пошел с MySQL

• Теперь, если мне нужен (я имею в виду, мне действительно нужен) полнотекстовый поиск и возможности Mongo/Mysql FTS недостаточно, я бы добавил также службу FTS er, как Sphinx, Solr, Elasticsearch и т. д.