我们即将解决客户对基于 Web 的应用程序的需求，该应用程序包含大量 产品及其数据 - 包括价格、重量、体积等。
除价格外的所有数据都是将存储一次的数据，之后可能不会更改。另一方面，价格将至少每天更新一次以适应不断变化的货币汇率。因此，我们考虑过使用 noSQL 数据库，但我还没有经验来决定它是一个好主意还是只是一个奇特的现代解决方案？
是吗？
非常感谢!
最佳答案
As Michael explained ，关系数据库就足够了，具体取决于您的具体要求。但是，NoSQL 数据库可能是更好的解决方案，具体取决于您的两个方面的要求:数据的数量和格式。
数据量
如果数据量可以很容易地由单个关系数据库服务器处理，那么一定要使用那个关系数据库。但是，如果您要处理单个服务器无法有效处理的大量数据，NoSQL 解决方案可能是更好的选择。 NoSQL 数据库更适合跨服务器分布，因为它们不必处理关系完整性和原子事务等问题。
数据模型
如果您的所有产品都大致包含相同的属性，并且所有这些属性都可以轻松地存储在一个表中，那么请使用关系数据库。但是，如果每个产品类型的数据模型可能存在很大差异和/或产品数据被规范化为多个表并且不容易被反规范化，那么无模式 NoSQL 解决方案(例如文档数据库)可能成为更好的选择。这样您就不必处理大量数据的连接操作。
简而言之，如果您要处理大量数据，或者处理(部分)无模式的数据，NoSQL 绝对是一个可行的解决方案。
优化关系数据库
请记住，关系数据库也可以通过 sharding 针对大量数据进行优化。 .例如，您可以根据 SKU 将产品拆分到单独的表中。那么数据库只需要处理小表，而不是单个大表。这些表可以存储在单独的服务器上以分散负载。
优化您的应用架构
另一种选择是使用 CQRS architecture在关系数据库之上。所有数据修改查询都发送到单个主数据库。然后将这些修改发布到只读数据库或缓存，其中包含数据的非规范化表示。数据检索查询在只读数据库上执行以获得更好的性能。尽管这在纸面上是一个不错的架构，但它确实对应用程序的整体架构产生了相当大的影响。所以我不会推荐 CQRS，除非你以前用过它。
您的问题没有简单的答案，因为这完全取决于具体要求。我的建议是在项目的设计阶段牢记关系和 NoSQL 解决方案。如果您随后意识到关系数据库就足够了，那么就使用它。如果您意识到使用 NoSQL 数据库同样容易，请尝试一下。
不是一个是/否的答案，但希望有一些食物:)
关于mysql - 用于存储产品信息的 noSQL？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3485226/