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

Мы создаем крупномасштабный веб-сайт электронной связи для обслуживания более 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 обычно отказываются от согласованности — но, по крайней мере, с помощью этого гибридного подхода мы можем реализовать все три за счет дополнительной сложности системы, и мы с этим все в порядке, так как все наши требования выполняются.


person user646584    schedule 23.06.2011    source источник


Ответы (2)


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

Infact В настоящее время я также работаю над приложением (электронная коммерция), которое использует как SQL, так и NonSQL. У нас приложение для рельсов, и 90% данных хранятся в монго, а только транзакционные и инвентарные элементы хранятся в mysql. Все транзакции обрабатываются в Mysql, а все остальное — в монго.

person RameshVel    schedule 23.06.2011
comment
Милая, приятно получить подтверждение нашего приближения. Вы используете Rails для обработки бизнес-логики? - person user646584; 23.06.2011

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

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

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

person Tom Clarkson    schedule 23.06.2011
comment
Мы согласны с тем, что Mongo обрабатывает поиск и просмотр, поскольку синхронизация между MySQL и Mongo должна быть почти мгновенной; ничего страшного, если в результатах поиска не будет нескольких списков, пользователь не заметит разницы. - person user646584; 23.06.2011
comment
Что ничем не отличается от синхронизации между двумя узлами mongo или двумя узлами SQL. Какие данные вы ожидаете потерять, если не поместите их в SQL? окончательная согласованность намного быстрее, чем вы думаете, особенно если вы можете указать важные операции чтения на главном узле. - person Tom Clarkson; 23.06.2011