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