sql文本字段vs平面文件vs nosql文档存储

Question

我打算让一个SQL事实表涉及一个我不希望索引的文本字段（我只会读出数据并且很少更新它）。我认为这个表可能会变得非常大，主要是由于这个文本字段。我的数据库中的其余数据确实是有关系的，但我相信如果我存储指向平面文件的指针（其中每个指针指向存储在S3中的不同文本文件），我可以更容易和更便宜地扩展。而不是使用文本字段。

一种似乎越来越受欢迎的替代方案是完全基于NoSQL文档的解决方案（例如CouchDB，MongoDB等）。我想知道什么是权衡（可扩展性/可靠性/安全性/性能/易于实现/易于实现）简单地使用SQL文本字段，指向平面文件的指针，或者在NoSQL文档存储的上下文中完全重新思考整个系统之间的维护/成本？

Answer 1

最好的方法是使用关系数据库来处理普通（非文本）数据，并将大（文本）数据保存在“其他地方”，可以比关系数据库更好地处理大数据。

首先，让我们讨论为什么在关系数据库中保存大数据是错误的想法：'

• 行大小变得更长，因此读取带有目标行的磁盘页所需的I / O气球
• 备份大小，更重要的是，备份次扩大到可以削弱DBA任务甚至使系统脱机（然后关闭备份，然后磁盘发生故障，哎呀）
• 您通常不需要搜索文本，因此无需在数据库中使用
• 关系数据库和库/驱动程序通常不擅长处理异常大的数据，处理它的方式通常是特定于供应商的，使任何解决方案都不可移植

您选择的“其他地方”很广泛，但包括：

• 像Cassandra，MongoDB等大型数据存储软件
• 像Lucene这样的NoSQL数据库
• 文件系统

做最简单的工作 - 只要你按照以下方式进行需求计算，它们都是有效的：

• 峰值写入性能
• 峰值读取性能
• 长期存储量

另一个提示：不要在关系数据库中存储关于文本的任何。而是使用关系数据库行的id命名/索引文本。这样，如果您更改实施，则无需重新设置数据模型。