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

Question

我计划有一个涉及文本字段的 SQL 事实表，我不希望对其建立索引(我只会读出数据并且很少更新它)。我认为这个表可能会变得很大，主要是因为这个文本字段。我数据库中的其余数据确实是关系型的，但是我相信如果我改为存储指向平面文件的指针(其中每个指针指向存储在 S3 之类的文件中的不同文本文件)，我可以更轻松、更便宜地进行扩展而不是使用文本字段。

似乎越来越流行的替代方案是完全基于 NoSQL 文档的解决方案(例如 CouchDB、MongoDB 等)我想知道权衡是什么(可扩展性/可靠性/安全性/性能/易于实现/易于维护/成本)是简单地使用 SQL 文本字段、具有指向平面文件的指针，还是在 NoSQL 文档存储的上下文中完全重新考虑整个系统？

Answer 1

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

首先，让我们讨论一下为什么将大数据保存在关系数据库中是一个坏的想法:'

• 行大小变得更长，因此需要 I/O 读取带有目标行气球的磁盘页面
• 备份大小，更重要的是，备份时间扩大到可以削弱 DBA 任务甚至使系统脱机的程度(然后关闭备份，然后磁盘出现故障，哎呀)
• 您通常不需要搜索文本，因此没有必要将其存入数据库
• 关系数据库和库/驱动程序通常不擅长处理异常大的数据，而且处理数据的方式通常因供应商而异，这使得任何解决方案都不可移植

您对“其他地方”的选择范围很广，但包括:

• Cassandra、MongoDB等大型数据存储软件
• NoSQL 数据库，如 Lucene
• 文件系统

做最简单的工作 - 只要您为以下方面进行需求计算，它们都是有效的:

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

另一个提示:不要在关系数据库中存储有关文本的任何内容。相反，使用关系数据库行的 id 命名/索引文本。这样，如果您更改实现，则不必重新调整数据模型。