几GB并不是很“大”。它更像是企业数据库的正常大小。只要您在加入表格时经过 PK，它应该工作得非常好，即使在未来（只要您没有每天获得 TB 的数据）。

大多数在大数据环境中工作的专业人士认为> ~5TB是大数据一词的开头。但即便如此，安装下一个最好的 nosql 数据库并不总是最好的方法。您应该始终考虑要使用数据归档的任务（聚合、读取、搜索、挖掘、..），以找到解决您问题的最佳工具。

即，如果您在数据库中进行大量搜索，最好运行一个 solr 实例/集群并不时对来自 Postgres 或您的 SQL Server 等 DBMS 的数据进行非规范化并将其放入 solr 而不是仅仅移动数据在持久性和性能方面从 sql 到 nosql。

要回答这个问题，您必须回答您可以承受的妥协。RDBMs 实现ACID。这在资源方面是昂贵的。没有酸性的 NoSQL 解决方案。请参阅CAP 定理以深入了解这些想法。

因此，您必须了解每种解决方案给出的每种折衷方案，并选择最适合您的问题的方案。

大数据实际上与“它有多大”无关。

首先，几千兆字节根本不算大，几乎什么都不是。所以不要打扰自己，我认为您的系统将继续有效工作一段时间。

然后你必须考虑如何使用你的数据。

• SQL 方法：每一个数据都是珍贵的，经过精心收集和选择，重点放在存储高价值和结构良好的数据上。这可能代价高昂，一切都是相互链接的，并且有利于结构良好的系统和功能数据。
• 大数据方法：在大数据中，您基本上存储几乎所有内容，无论其价值如何，然后进行主动分析过程。事物没有联系，它们是复制的。例如，假设我有一个博客条目。在大数据中，不会有指向其作者的链接，但作者将嵌入到博客条目中。方式更具可扩展性，但需要不同且更复杂的方法。

如果您的应用程序使用存储“功能”数据，我建议您继续使用 SQL。如果您存储数据是为了以后搜索或报告，并且如果这个数据量可能会迅速增加，我会建议使用大数据。在我看来，当您处理必须不断收集和分析的真实数据时，大数据很有用。

我在 stackoverflow 上发布了一个非常详细的答案，关于何时适合使用关系数据库与文档（或 NoSQL）数据库，在这里：

使用关系数据库/ORM 或文档数据库/ODM 的动机

概括：

• 对于小东西，使用您熟悉的任何工具

• 几千兆字节绝对是小东西：它不会变大，直到它太大而无法放入具有合理数量节点（16-32）的单个MySQL 集群中，这意味着可能有 8-16TB 数据和几百万个事务每秒（或更传统的基于硬盘驱动器的数据库，每秒多达 100 TB 数据和几千个事务）。

• 如果你被另一个数据库（不是 MySQL 集群）卡住了，那么通过加入 FusionIO 硬件来获得更多的收益。

• 一旦您拥有超过几 TB 的数据并且速度超过每秒数千个事务，现在是考虑先在应用程序代码中进行逻辑分片，然后再转向 NoSQL 的好时机。

• 卡桑德拉:)