将 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 处理的所有事务请求都将包括业务逻辑中的最后一步，即通过列表 id 更新 MongoDB 中的相应文档；我们计划使用 MongoDB Java API 来促进更新文档的集成。
因此，本质上，由于该网站的阅读量最大，该架构允许我们水平扩展 MongoDB 以容纳更多用户。使用 MySQL 使我们能够利用关系数据库的 ACID 属性，同时通过 JBoss 中间件保持 MongoDB 存储的更新。
这个架构有什么问题吗？没有一个平台可以同时提供一致性、可用性和分区容错性——NoSQL 系统通常会放弃一致性——但至少通过这种混合方法，我们可以以增加系统复杂性为代价来实现这三者，并且我们对此我们很满意，因为我们的所有要求都得到了满足。
We are building a large scale e-comm web site to service over 100,000 users, but we expect the number of users to grow rapidly over the first year. In general, the site functions very much like ebay where users can create, update, and remove listings. User can also search listings and purchase an item of interest. Basically, the system has transactional and non-transactional requirements:
**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
We want to leverage the power of scalable, document-based NoSQL data stores such as Couch or MongoDB, but at the same time we need a relational store to support our ACID transactional requirements. So we have come up with a hybrid solution which uses both technologies.
Since the site is "read mostly", and, to meet the scalablity needs, we set up a MongoDB data store. For the transactional needs, we set up a MySQL Cluster. As the middleware component we use JBoss App server cluster.
When a "search" request comes in, JBoss directs the request to Mongo to handle the search which should produce very quick results while not burdening MySQL. When a listing is created, updated, removed, or purchased, JBoss services the transactions against MySQL. To keep MongoDB and MySQL synchronized, all transactional requests handled by JBoss against MySQL would include a final step in the business logic that updates the corresponding document in MongoDB via the listing id; we plan to use the MongoDB Java API to facilitate this integration of updating the document.
So, in essence, since the site is read mostly, the architecture allows us to scale out MongoDB horizontally to accommodate more users. Using MySQL allows us to leverage the ACID properties of relational databases while keeping our MongoDB store updated through the JBoss middleware.
Is there anything wrong with this architecture? No platform can offer consistency, availability, and partition-tolerance at the same time -- NoSQL systems usually give up consistency -- but at least with this hybrid approach we can realize all three at the cost of additional complexity in the system, and we are ok with that since all of our requirements are being met.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
这种做法并没有什么问题。
事实上，目前我也在开发利用 SQL 和 SQL 的应用程序（电子商务）。非SQL。我们的应用程序是一个 Rails 应用程序，90% 的数据存储在 mongo 中，并且仅是事务性的和数据性的。库存物品存储在mysql中。所有事务都在 Mysql 中处理，其他一切都由 mongo 处理。
There is nothing wrong with this approach.
Infact Currently am also working on the application (E-Commerce) which leverages both SQL & NonSQL. Ours is a rails application and 90% of the data is stored in mongo and only transactional & inventory items stored in mysql. All the transactions are handled in Mysql, and everything else goes to mongo.
如果您已经构建了它，那么除了有点过于进取之外，该架构并没有太大的问题。不过，在这样的系统上从头开始，我可能会忽略 SQL 和中间件。
NoSQL 数据存储中的一致性丧失并不像您所建议的那么彻底。除了其中许多确实支持事务并且可以设置为特定查询的立即一致性这一事实之外，我怀疑您的一些要求只是关系设计事物的产物。您关心的似乎是需要更新多条记录的操作 - 列表是否真的有多条记录，或者只是这样设置，因为 SQL 记录必须具有平面结构？
另外，如果搜索和视图是在 MySQL 之外处理的，那么无论如何您都已经有效地建立了最终一致性系统。
If you have already built it, there isn't too much wrong with the architecture aside from being a little too enterprisey. Starting from scratch on a system like this though, I'd probably leave out SQL and the middleware.
The loss of consistency in NoSQL data stores isn't as complete as you suggest. Aside from the fact that many of them do support transactions and can be set up for immediate consistency on particular queries, I suspect some of your requirements are simply an artefact of designing things relationally. Your concern seems to be around operations that require updates to multiple records - Is a listing really multiple records, or just set up that way because SQL records have to have a flat structure?
Also, if search and view are handled outside of MySQL, you have effectively set up an eventual consistency system anyway.