从SQL迁移到NoSQL会以什么大小的数据受益？

作为关系数据库程序员（大部分时间），我阅读了有关关系数据库如何不扩展以及MongoDB等NoSQL解决方案如何扩展的文章。由于到目前为止我开发的大多数数据库都是中小型的，所以我从来没有遇到过一些索引，查询优化或模式重新设计尚未解决的问题。

我希望看到MySQL会遇到什么样的大小。多少行？

（我知道这将取决于应用程序和存储的数据类型。让我知道的一个东西基本上是遗传学数据库，因此将有一个主表，带有3或4个查找表。主表将在其中包含其他内容，例如染色体参考和位置坐标。很可能会查询到染色体上两个药水之间的许多条目，以查看其中存储了什么。

有多少数据？

有两个重要的阈值：

1. 整个数据都适合RAM
2. 整个索引数据都适合RAM

有了快速的固态硬盘，除非您的流量过大，否则第一个门槛将不再是一个问题。

酸度

扩展RDBMSes的问题之一是，按设计，它们是ACID，这意味着事务和行级锁（甚至在某些较旧/较简单的RDBMSes中为表级）。如果您有很多查询同时修改了许多数据，那么这可能是一个限制因素。NoSQL解决方案通常采用最终的一致性模型。

RDBMS如何缩放数据大小？

RDBMS无法在数据大小上扩展并不是完全正确的，有两种选择：垂直分区和水平分区（也称为分片）。

垂直分区基本上是将不相关的表保留在单独的数据库服务器上，从而使每个表的大小保持在上述阈值以下。这使得使用普通SQL联接这些表变得不那么直接且效率更低。

分片是指根据特定的密钥在多个服务器之间的一个表中分配数据。这意味着对于查找，您知道要根据该键查询哪个服务器。但是，这会使不在分片键上查找的查询复杂化。

在两种分区的情况下，如果走极端，基本上就会遇到与NoSQL数据库相同的情况。

我认为数据的大小不是唯一的因素。“数据模型”也是非常重要的部分。

电子商务目录页面（Solr，ElasticSearch），Web分析数据（Riak，Cassandra），股价（Redis），社交网络中的关系连接（Neo4J，FleetDB）仅是NoSQL解决方案真正兴起的一些示例。

恕我直言，在考虑NoSQL解决方案或RDBMS时，数据模型比数据的大小更重要。

如果关系数据库无法扩展，则无济于事。不必担心扩展问题。

SQL在进行某种分析时会遇到问题，但是触发该问题并不需要太多数据。例如，考虑一个表，该表的列基于唯一键引用其他行。通常，这可用于创建树结构。您可以编写引用相关行的快速SQL语句。或相关行的相关行。实际上，您可以进行任何特定数量的跳转。但是，如果您想为每一行选择符合条件的链中第一相关行中的一个字段，那么它将变得很复杂。

考虑一张在国家，省/州，县，镇和村庄级别的办公室位置表，每个办公室都参考其上报的办公室。有没有保证每个办公室的报告办公室仅上涨了一个级别。对于选定的一组办公室（不是全部在一个级别上），您要列出每个人的相关国家办公室。这需要循环执行SQL语句，即使今天也要花费很长时间。（我过去在选择30个办公室时花了30秒，但这是很久以前的事，而切换到存储过程会有所帮助。）

因此，另一种选择是将整个结构放入一个大数据块中，对其进行标记并存储。当您要分析数据时，一次性将所有数据读取到内存中，设置指针以跟踪结构，您可以在眨眼间处理数百万个办公室。

这与数据量没有多大关系。关键是数据组织的性质。如果关系布局有帮助，那么您想要的是RDBMS。如果没有的话，某种大容量存储的速度将快一点到四千万倍。

请注意，如果这些数据集之一变得太大而无法容纳到内存中，则您的非SQL数据库将无法正常工作。另一个问题是您一次需要多个块中的数据。你可以做到这一点，如果和仅如果所有块装入内存一次。用户在加载它们时必须等待。

如果您的关系数据库将导致您的问题，它会在您向其中放入大量数据之前这样做。唯一的扩展问题可能是程序，当您为nosql DB组装的数据块（如果必须使用一个）变得太大时，就变成了程序。（请仔细阅读内存不足错误。较新的语言有时会对内存产生奇怪的影响。）

我认为采用NoSQL或分布式解决方案的第一个原因不是所有数据的大小，而是表的大小。分布式解决方案最有效的方法是将表拆分到不同的节点，然后当您需要查询表时，每个节点将处理其表的一部分。

RDBMS可以做到这一点，但是已经建立了新的NoSQL数据库浪潮来做到这一点。Oracle，MSSQL和MySQL采用了集中式模型，并对其进行了调整，以使其可在分布式环境中工作。但是，它们仍然遵守严格的ACID规则，而某些新数据库不遵守严格的规则，例如使用最终一致性。

没有固定的数据量，您应该选择一个。需要考虑的是数据库的需求及其接收的使用量。NoSQL数据库可以更快地处理较大的数据集，而关系数据库使您确信您的数据符合ACID原则是正确的。

值得一提的是，您的数据模型对事物的影响很大。如果您发现自己需要创建某种形式的树结构（即，在包含复合主键中包含所述外键的表上具有自引用外键），则可能应该考虑使用某种形式的数据库来处理这些结构数据类型确实很好（例如mongodb或benchdb）。

就像其他人所说的那样，您还应该考虑应用程序中正在发生的事情。如果您确实需要跨多个表的ACID，那么您确实需要坚持使用RDBMS，但是如果您拥有可以在其中包含一些陈旧数据的东西，并且需要NoSQL模式的灵活性（如果愿意，可以将其称为无模式）仍然具有某种形式的隐式架构），那么您可以考虑抢购NoSQL存储（http://www.10gen.com/customers/craigslist，此处是craigslist切换的一个示例...但是请记住，他们正在归档〜10TB的数据，我知道这些数据根本不适合您的中小型数据库大小，但是用例可能会有所帮助）。

请记住，NoSQL系统不一定可以代替RDMS，但在许多情况下，您可以通过Polyglot Persistence的想法来补充RDBMS，并且可以将大多数数据存储在RDBMS中，但是在特定的细分市场中，您可以卸载某些数据库数据到某种形式的NoSQL存储。

Mongo可以安装在许多计算机/节点上。PostgreSQL没有提供用于分片的内置工具，但是citus出现了。

MongoDB支持的数据库最大为64 TB，文档大小为16兆字节。

MySQL的数据库限制为256 TB，表的最大大小为64 TB，记录限制为4 GB

PostgreSQL对数据库没有限制（用于测试的某处确实存在4 TB），并且表中任何一个字段的大小限制为1 GB，表的最大大小限制为64 TB。