假设我有一个电子商务网站，有数百万种产品，每天有数百万的页面浏览量，主要是产品详细信息页面。
比方说，我目前将所有数据都放在关系数据库中，这是以前的好方法。
将数据保存在关系数据库中以进行查询、聚合和过滤产品等操作的利弊是什么。。。但是使用平面json文件获取产品详细信息？
因此，每个产品有一个文件，所有细节都序列化为json。这些文件将被放置在一个高性能的cdn下，地理分布等等。当用户转到时
www.mysite.com/prods/00123
服务器（甚至客户端）会为布局加载一个模板文件，然后用它从cdn.mysite.com/prods/00123.json 之类的东西读取的数据填充它
因此，在这种情况下，我基本上不需要进行查询-我直接跳到以产品id命名的文件。我想它应该很快，但我会将可扩展性/缓存/地理分布委托给外部强大的合作伙伴（cdn，如akamai、亚马逊等），而不是构建我自己的（昂贵且难以维护）分布式数据库服务器？
我期待你的建议/反馈。。。尤其是当涉及到现实世界的体验时：）
谢谢！
根据您的要求，
最好将产品描述存储在像MongoDB这样的无模式数据库中，因为您的产品可能有非常不同的字段，属性（和相应的字段）的数量变化很大。此外，此类信息的书写频率远低于阅读频率。MongoDB具有集合级别的写锁，如果您喜欢进行一致的写操作，它可以阻止写大量的应用程序。然而，MongoDB中的读取速度非常快，因为您不必进行联接或从EAV模式表中获取字段值。不用说，基于您的数据卷的分片和复制需要在生产环境中完成。
它比存储在平面文件中要好，因为MongoDB的读取性能非常好，因为它有内存映射文件，而且还可以进行复制/分片。
然而，如果文件系统（或文件系统网络）提供了数据库提供的安全性、速度和可访问性，那么将数据存储在文件系统中并不是一个坏主意。如果平面文件被配置为以高效的方式提供服务，那么传统的dbvs平面文件参数就不成立。
然而，你不应该在MongoDB中存储购物车、结账交易等信息，因为你没有ACID交易，频繁的"一致性"写入和更新不是MongoDB的专长。