noSQL 用于存储产品信息？
我们即将解决客户对基于 Web 的应用程序的需求，该应用程序包含大量产品及其数据 - 包括价格、重量、物理体积等。
除了价格之外的所有数据都是数据，这些数据将被存储一次，然后可能不会改变。另一方面，价格每天至少更新一次，以适应不断变化的货币汇率。因此，我们考虑过使用 noSQL 数据库，但我还没有经验来决定它是一个好主意还是只是解决我们问题的一个奇特而现代的解决方案？
是吗？
多谢！
We are about to solve a customer's need of a web based application that holds a big amount of products and their data - including prices, weights, physical volyme, and much more.
Everything but the prices are data that is data that will be stored once, and then probably not changed. The prices on the other hand will be updated at least once per day to suit the changing currency exchange rates. Therefore we have thought a bit about going for a noSQL-database, but I have yet not the experience to decide whether it is a good idea or just a fancy and modern solution to our problem?
Is it?
Thanks a lot!
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
正如 Michael 所解释的，关系数据库就足够了，具体取决于您的确切的要求。但是，NoSQL 数据库可能是更好的解决方案，具体取决于您的需求的两个方面：数据的数量和格式。
数据量
如果单个关系数据库服务器可以轻松处理数据量，那么请务必使用该关系数据库。但如果您正在处理单个服务器无法有效处理的大量数据，NoSQL 解决方案可能是更好的选择。 NoSQL 数据库更适合跨服务器分布，因为它们不必处理关系完整性和原子事务等事务。
数据模型
如果您的所有产品大致包含相同的属性，并且所有这些属性都可以轻松存储在单个表中，那么请使用关系数据库。但是，如果每个产品类型的数据模型可能存在很大差异，并且/或者产品数据被规范化为多个表并且不能轻易去规范化，那么无模式 NoSQL 解决方案（例如文档数据库）可能会是一个更好的选择。那么您就不必处理大量数据的连接操作。
简而言之，如果您正在处理大量数据，或者处理（部分）无模式的数据，NoSQL 绝对是一个可行的解决方案。
优化关系数据库
请记住，关系数据库还可以通过 分片。例如，您可以根据 SKU 将产品拆分为单独的表。那么数据库只需要处理小表，而不是单个大表。这些表可以存储在单独的服务器上以分散负载。
优化您的应用程序架构
另一种选择是在关系数据库之上。所有数据修改查询都发送到单个主数据库。然后，这些修改会发布到只读数据库或缓存，其中包含数据的非规范化表示。在只读数据库上执行数据检索查询以获得更好的性能。尽管从纸面上看这是一个不错的架构，但它确实对应用程序的整体架构产生了相当大的影响。所以我不会推荐 CQRS，除非你以前使用过它。
您的问题没有简单的答案，因为这完全取决于具体的要求。我的建议是在项目的设计阶段同时考虑关系和 NoSQL 解决方案。如果您随后意识到关系数据库就足够了，那么就使用它。如果您意识到使用 NoSQL 数据库同样容易，请尝试一下。
不是一个是/否的答案，但希望有一些食物:)
As Michael explained, a relational database can be sufficient, depending on your exact requirements. However, a NoSQL database may be a better solution, depending on two aspects of your requirements: the amount and format of the data.
The amount of data
If the amount of data can easily be handled by a single relational database server, then use that relational database by all means. But if you're dealing with amounts of data that cannot be handled by a single server efficiently, a NoSQL solution may be a better choice. NoSQL databases are better for distribution across servers, because they don't have to deal with things like relational integrity and atomic transactions.
Data model
If all of your products roughly contain the same properties and all of these properties can easily be stored in a single table, then use a relational database. But if the data model can strongly differ per product type and/or the product data is normalized to multiple tables and cannot easily be denormalized, then a schema-less NoSQL solution, such as a document database, may be a better choice. Then you won't have to deal with join operations on huge amounts of data.
In short, if you're dealing with large amounts of data, or with data that is (partially) schema-less, a NoSQL is definitely a viable solution.
Optimize the relational database
Keep in mind that a relational database can also be optimized for large amounts of data by sharding. For example, you can split the products into separate tables based on the SKU. Then the database only has to deal with small tables, instead of a single large table. These tables could be stored on separate servers to spread the load.
Optimize your application architecture
Another option is to use a CQRS architecture on top of relational databases. All data modification queries are sent to a single master database. These modifications are then published to read-only databases or caches, which contain a denormalized representation of the data. Data retrieval queries are performed on the read-only databases for better performance. Although this is a nice architecture on paper, it does have quite an impact on the overall architecture of your application. So I wouldn't recommend CQRS unless you have used it before.
There's no easy answer to your question as it all depends on the exact requirements. My suggestion is to keep both relational and NoSQL solutions in mind during the design phase of the project. If you then realize that a relational database is sufficient, then use that. If you realize that it's just as easy to use a NoSQL database, try that.
Not a yes/no answer, but hopefully some food for though :)
虽然 noSQL 数据库可以解决您的问题，但在我看来，它也很适合标准关系模型。您可能希望将价格作为一个单独的表，与主产品表进行 1-1 连接，以便经常更新的表更小（并且您或数据库可以使用不同的策略来处理这两个表）。
While a noSQL database could solve your problem, it seems to me that it would also fit well in a standard relational model. You might want to make the prices a separate table with a 1-1 join to the main products table so that the oft-updated table is smaller (and you or the database can use different strategies for dealing with the two tables).