关系DBMS中的数据越来越大，是时候迁移到NoSQL了吗？

我们创建了一个用于电子学习的社交网络应用程序。这是我们正在实验室中研究的实验项目。在某些案例研究中已经使用了一段时间，并且关系DBMS（SQL Server 2008）中的数据越来越大。现在只有几千兆字节，并且表之间相互连接紧密。性能仍然不错，但是什么时候应该考虑其他选择呢？是性能问题吗？

几千兆字节不是很大。它更像是企业数据库的正常大小。只要您在连接表时检查PK，即使在将来（只要您一天不会获得TB的数据），它也应该能很好地工作。

在大数据环境中工作的大多数专业人员都将大于5TB作为大数据一词的开头。但是即使那样，也不总是安装次佳的nosql数据库的最佳方法。您应该始终考虑要与数据一起归档的任务（汇总，读取，搜索，挖掘，..），以找到解决问题的最佳工具。

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

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

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

大数据实际上并不是关于“大数据量”。

首先，几GB根本就不大，几乎没有。因此，请勿打扰您，我认为您的系统将继续有效运行一段时间。

然后，您必须考虑如何使用数据。

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

如果您的应用程序使用存储的“功能性”数据，我建议您继续使用SQL。如果您存储数据是为了以后进行搜索或进行报告，并且此数据量可能会快速增加，那么我建议您使用大数据。我认为，当您处理必须连续收集和分析的真实数据时，大数据很有用。

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

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

摘要：

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

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

• 如果您使用的是另一个数据库（不是MySQL Cluster），则可以通过添加FusionIO硬件来获得更多收益。

• 一旦您拥有的数据大于几TB，并且每秒的事务处理速度超过数千，那么现在正是时候开始着手研究应用程序代码中的逻辑分片，然后再转向NoSQL。

• 卡桑德拉 :)

迁移到NoSQL的时间取决于两件事：

1. 数据的性质/结构
2. 您目前的表现

当数据结构良好时（例如，可以将其建模为表，Excel电子表格或具有固定列数的一组行时），SQL数据库就很出色。当您需要执行很多表联接时（听起来也很像），这也很好。

当数据是非键值对以外的非结构化数据时，NoSQL数据库就很出色。

在性能方面，您必须问自己一个问题：您当前的SQL解决方案是否运行缓慢？

如果不是，请遵循“ IIABDFI ”原则。