Используя комбинацию MySQL и MongoDB

Question

Имеет ли смысл использовать комбинацию MySQL и MongoDB. То, что я пытаюсь сделать, это использовать MySQl как «резервную копию необработанных данных», где все данные хранятся там, но не читаются оттуда.

Данные также хранятся одновременно в MongoDB, и чтение происходит только из mongoDB, потому что мне не нужно делать соединения и прочее.

Например, предположим, при сборке NetFlix

в MySQL у меня есть таблица для комментариев и фильмов. Затем, когда комментируется в MySQL, я просто добавляю его в таблицу, а в MongoDB обновляю документальный фильм, чтобы сохранить этот новый комментарий.

А потом, когда я хочу получить фильмы и комментарии, я просто беру документ с mongoDb.

Моя основная проблема связана с тем, как «новый» mongodb сравнивается с MySQL. В случае, когда в Mongo происходит что-то неожиданное, у нас есть резервная копия MySQL, где мы можем быстро получить откат приложения к mysql и memcached.

Answer 1

На бумаге это может звучать как хорошая идея, но есть много вещей, которые вы должны будете принять во внимание. Это сделает ваше приложение более сложным, чем вы думаете. Я приведу несколько примеров.

Две разные системы

Вы будете иметь дело с двумя разными системами, каждая со своим поведением . Это различное поведение затруднит синхронизацию всего.

• Что произойдет, если запись в MongoDB завершится неудачно, но в MySQL будет успешной?
• Или наоборот, когда ограничение столбца в MySQL нарушается, например?
• Что если в MySQL возникнет тупик?
• Что если ваша схема изменится? Одна миграция болезненна, но вам придется сделать две миграции.

Вам придется иметь дело с некоторыми из этих сценариев в коде приложения. Что подводит меня к следующему пункту.

Два слоя доступа к данным

Ваше приложение должно взаимодействовать с двумя внешними системами, поэтому вам нужно написать два слоя доступа к данным.

• Оба слоя должны быть проверены.
• Оба должны быть сохранены.
• Остальная часть вашего приложения должна взаимодействовать с обоими уровнями.
• Абстрагирование обоих слоев приведет к появлению еще одного слоя, что еще больше увеличит сложность.

вероятность каскадного сбоя

В случае сбоя MongoDB приложение вернется к MySQL и запишет в memcached. Но в этот момент memcached будет пустым . Таким образом, каждый запрос сразу после сбоя MongoDB попадет в базу данных. Если у вас есть сайт с большим трафиком, это также может легко отключить MySQL.

Слово совета

Укажите все возможные способы, с помощью которых вы думаете, что «нечто неожиданное» может произойти с MongoDB. Тогда используйте самое простое решение для каждого отдельного случая . Например, если вас беспокоит потеря данных, используйте replication . Если это повреждение данных, используйте отложенная репликация .