【发布时间】：2012-01-12 23:49:39
【问题描述】：
我计划创建一个 SQL 事实表，其中包含一个我不希望对其进行索引的文本字段（我只会读出数据并且很少更新它）。我认为这个表可能会变得很大，主要是由于这个文本字段。我的数据库中的其余数据确实有意义，但我相信如果我存储指向平面文件的指针（其中每个指针指向存储在 S3 之类的不同文本文件中的不同文本文件），我可以更轻松、更便宜地进行扩展而不是使用文本字段。
似乎越来越受欢迎的替代方案是完全基于 NoSQL 文档的解决方案（例如 CouchDB、MongoDB 等）。维护/成本）在简单地使用 SQL 文本字段、使用指向平面文件的指针还是在 NoSQL 文档存储的上下文中完全重新考虑整个系统之间？
【问题讨论】：
-
这是一个非常复杂的问题。 “相当大” 的概念非常模糊。您是在谈论 TB 级数据还是 PB 级数据？增长率是多少？什么查询需要快速，什么可以接受的慢？
-
此特定文本数据预计约为 50 TB。预计在峰值负载期间将增长约 500 kb/秒。理想情况下，所有 select 语句都很快（它们将被预定义，因为只有 Web 服务才能访问数据库），而插入和更新可能会很慢。
-
如果要在32位系统上使用MongoDB，首先要考虑的是只能存储2GB的数据。 MongoDB 生产商表示，由于大多数 PC 将是 64 位，因此问题将很快得到解决，因此他们不想更改程序以允许 32 位 PC 使用超过 2GB 的内存。至少我是这么读的。所以这是第一个问题，但我认为 CouchDB 没有这个问题。
-
MongoDB 32 位系统支持仅适用于开发人员。生产系统总是在 64 位系统上运行，这已经是很长时间的标准了。要求背后的原因是因为 MongoDB 被设计为利用内存映射文件。
标签： sql mongodb text flat-file nosql