Использование NoSQL и реляционных хранилищ данных для большого сайта

Question

Мы создаем крупномасштабный веб-сайт электронной связи для обслуживания более 100 000 пользователей, но мы ожидаем, что число пользователей будет быстро расти в течение первого года.В целом, сайт очень похож на ebay, где пользователи могут создавать, обновлять и удалять списки.Пользователь также может искать списки и покупать интересующий объект.По сути, система предъявляет транзакционные и нетранзакционные требования:

**Transactional**
Create a listing (multi-record update)
Remove a listing
Update a listing
Purchase a listing (multi-record update)

**Non-Transactional**
Search listings
View a listing

Мы хотим использовать возможности масштабируемых хранилищ данных NoSQL на основе документов, таких как Couch или MongoDB, но в то же время нам нуженреляционное хранилище для поддержки наших требований к транзакциям ACID.Таким образом, мы придумали гибридное решение, в котором используются обе технологии.

Поскольку сайт «в основном читается», и для удовлетворения потребностей в масштабируемости мы создали хранилище данных MongoDB.Для транзакционных нужд мы настроили MySQL Cluster.В качестве компонента промежуточного программного обеспечения мы используем кластер серверов приложений JBoss.

Когда приходит запрос «поиск», JBoss направляет запрос в Mongo для обработки поиска, который должен давать очень быстрые результаты, не обременяя MySQL.Когда список создается, обновляется, удаляется или приобретается, JBoss обслуживает транзакции с MySQL.Чтобы синхронизировать MongoDB и MySQL, все транзакционные запросы, обрабатываемые JBoss к MySQL, должны включать последний шаг в бизнес-логике, который обновляет соответствующий документ в MongoDB через идентификатор листинга;мы планируем использовать Java API MongoDB для облегчения этой интеграции обновления документа.

Итак, по сути, поскольку сайт в основном читается, архитектура позволяет нам масштабировать MongoDB по горизонтали, чтобы вместить больше пользователей.Использование MySQL позволяет нам использовать свойства ACID реляционных баз данных, поддерживая обновление нашего хранилища MongoDB через промежуточное ПО JBoss.

Что-то не так с этой архитектурой?Ни одна платформа не может обеспечить согласованность, доступность и устойчивость к разделам одновременно - системы NoSQL обычно отказываются от согласованности - но, по крайней мере, с помощью этого гибридного подхода мы можем реализовать все три за счет дополнительной сложности в системе, и мывсе в порядке, так как все наши требования выполняются.

Answer 1

В этом подходе нет ничего плохого.

Infact В настоящее время я также работаю над приложением (E-Commerce), которое использует как SQL, так и NonSQL.Наше приложение является рельсовым, и 90% данных хранятся в монго, а в MySQL хранятся только элементы транзакций и инвентаря.Все транзакции обрабатываются в Mysql, а все остальное идет в Монго.

Answer 2

Если вы уже создали его, в архитектуре не так уж и много проблем, кроме того, что вы слишком корпоративны. Начиная с нуля в такой системе, я бы, вероятно, не учел SQL и промежуточное ПО.

Потеря согласованности в хранилищах данных NoSQL не так полна, как вы предполагаете. Помимо того факта, что многие из них поддерживают транзакции и могут быть настроены для немедленной согласованности по конкретным запросам, я подозреваю, что некоторые из ваших требований являются просто артефактом проектирования отношений. Похоже, ваша проблема связана с операциями, требующими обновления нескольких записей. Является ли список действительно несколькими записями или просто настроен так, потому что записи SQL должны иметь плоскую структуру?

Кроме того, если поиск и просмотр обрабатываются вне MySQL, вы все равно эффективно настроили систему согласованности.