SQL文本字段 vs 平面文件 vs NoSQL文档存储

Question

SQL文本字段 vs 平面文件 vs NoSQL文档存储

4

我计划创建一个SQL事实表，其中包含一个不希望进行索引的文本字段（我只会读取数据并且很少更新它）。我认为由于这个文本字段，这个表可能会变得非常大。我的数据库中的其他数据确实有关联，但是我相信如果我使用指向存储在类似于S3的平面文件中的不同文本文件的指针（每个指针都指向不同的文本文件）而不是使用文本字段，则可以更轻松且更便宜地扩展。

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

- user1080972

2

这是一个非常复杂的问题，很难回答。*"相当大"*的概念非常模糊。你是在谈论千兆字节的数据还是拍字节的数据？增长率是多少？哪些查询需要快速响应，哪些可以接受较慢的速度？ - Gates VP

这个特定的文本数据预计将达到50TB的数量级。在高峰期负载期间，它预计每秒增长约500kb。理想情况下，所有的选择语句都应该很快（它们将被预定义为只有Web服务才能访问数据库），而插入和更新可能会比较慢但仍然可以接受。 - user1080972

如果您想在32位系统上使用MongoDB，首先要考虑的是它只能存储2GB的数据。MongoDB的生产商表示，随着大多数PC都将会是64位，这个问题将会很快得到解决，所以他们不想改变程序来允许32位PC处理超过2GB的数据。至少这是我所读到的。因此，这是一个第一个问题，但我认为CouchDB没有这个问题。 - aufziehvogel

MongoDB 32位系统仅支持开发环境使用，生产系统始终运行在64位系统上，这已经成为长期标准。该要求背后的原因是MongoDB被设计用于利用内存映射文件。 - Dylan Tong

1个回答

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Bohemian · Accepted Answer

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

首先，让我们讨论一下为什么将大量数据存储在关系型数据库中是一个“坏主意”：

- 行大小变得更长，因此读取目标行的磁盘页面所需的I/O也会急剧增加。 - 备份大小以及更重要的备份时间也会增加到足以瘫痪DBA任务甚至使系统离线的程度（然后备份被关闭，然后磁盘失败，哎呀）。 - 您通常不需要搜索文本，因此不必将其保存在数据库中。 - 关系型数据库和库/驱动程序通常不能很好地处理异常大的数据，并且处理方式通常是特定于供应商的，从而使任何解决方案都无法移植。

"其他地方" 的选择很广泛，包括：

- Cassandra、MongoDB等大容量数据存储软件 - Lucene 等 NoSQL 数据库 - 文件系统

做最容易实现的事情——只要您对以下需求进行了计算，它们都是有效的：

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

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