我们即将解决客户对基于Web的应用程序的需求,该应用程序包含大量产品及其数据 – 包括价格,重量,物理价值等等.

除了价格之外的所有东西都是数据,这些数据将被存储一次,然后可能不会改变.另一方面,价格将至少每天更新一次,以适应不断变化的货币汇率.因此,我们已经考虑了一些关于使用noSQL数据库的问题,但是我还没有经验来决定它是一个好主意还是只是一个奇特而现代的解决方案来解决我们的问题？

是吗？

非常感谢！

解决方法:

As Michael explained,关系数据库就足够了,具体取决于您的具体要求.但是,NoSQL数据库可能是更好的解决方案,具体取决于您的要求的两个方面：数据的数量和格式.

数据量

如果单个关系数据库服务器可以轻松处理数据量,那么一定要使用该关系数据库.但是,如果您处理的是无法有效处理单个服务器的大量数据,NoSQL解决方案可能是更好的选择. NoSQL数据库更适合跨服务器分发,因为它们不必处理关系完整性和原子事务等事务.

数据模型

如果所有产品大致包含相同的属性,并且所有这些属性都可以轻松存储在单个表中,则使用关系数据库.但是,如果数据模型在每个产品类型上存在很大差异和/或产品数据被标准化为多个表并且不能轻易地进行非规范化,那么无模式NoSQL解决方案(例如文档数据库)可能是更好的选择.然后,您将不必处理大量数据的连接操作.

简而言之,如果您处理的是大量数据,或者处理(部分)无模式的数据,NoSQL绝对是一个可行的解决方案.

优化关系数据库

请记住,到sharding,关系数据库也可以针对大量数据进行优化.例如,您可以根据SKU将产品拆分为单独的表.然后数据库只需要处理小表,而不是单个大表.这些表可以存储在不同的服务器上以分散负载.

优化您的应用程序架构

另一种选择是在关系数据库之上使用CQRS architecture.所有数据修改查询都将发送到单个主数据库.然后将这些修改发布到只读数据库或高速缓存,其中包含数据的非规范化表示.在只读数据库上执行数据检索查询以获得更好的性能.虽然这是一个很好的纸质架构,但它确实会对应用程序的整体架构产生相当大的影响.因此,除非您以前使用过,否则我不会推荐CQRS.

你的问题没有简单的答案,因为这完全取决于具体的要求.我的建议是在项目的设计阶段牢记关系和NoSQL解决方案.如果您意识到关系数据库已足够,那么使用它.如果您意识到使用NoSQL数据库同样容易,那就试试吧.

不是是/否答案,但希望有些食物虽然:)