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

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

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

最好的方法是对正常(非文本)数据使用关系数据库,并将"(其他地方)的大(文本)数据"保存为可以比关系数据库更好地处理大数据.

首先,让我们讨论为什么在关系数据库中保存大数据是个坏主意:'

行大小变得更长,因此在具有目标行的磁盘页中读取所需的I/O气球

备份大小,更重要的是,备份时间扩大到可以削弱DBA任务,甚至使系统脱机(然后关闭备份,然后磁盘发生故障,哎呀)

您通常不需要搜索文本,因此不需要在数据库中使用它

关系数据库和库/驱动程序通常不擅长处理异常大的数据,处理它的方式通常是特定于供应商的,使任何解决方案都不可移植

您选择的"其他地方"很广泛,但包括:

大型数据存储软件,如Cassandra,MongoDB等

像Lucene这样的NoSQL数据库

文件系统

做最简单的工作 - 只要你做了以下的需求计算,它们都是有效的:

峰值写入性能

峰值读取性能

长期存储量

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