MySQL 还是 NoSQL？处理大量数据的推荐方式答案

【问题标题】：MySQL or NoSQL? Recommended way of dealing with large amount of dataMySQL 还是 NoSQL？处理大量数据的推荐方式
【发布时间】：2013-03-10 03:43:27
【问题描述】：

我有一个数据库，大量用户将使用该数据库来存储随机长字符串（最多 100 个字符）。表格列将是：userid、stringid 和实际的长字符串。

所以它看起来很像这样：

Userid 是唯一的，stringid 对于每个用户来说都是唯一的。

该应用就像一个简单的待办事项列表应用，因此每个用户平均有 50 个待办事项。我使用 stringid 是为了让用户能够在任何给定时间删除特定任务。

我假设这个待办事项应用程序可能会在 3 年内完成 700 万个任务，这让我害怕使用 MySQL。

所以我的问题是，如果这是处理具有长字符串的大量数据的实际推荐方法（每个新任务都有一个新行）？ MySQL 是适合此类项目的数据库解决方案吗？

我还没有经历过大量数据，我正在努力为遥远的未来拯救自己。

【问题讨论】：

【解决方案1】：

这不是“大量”数据的问题（mysql 可以很好地处理大量数据，2 mio 行无论如何都不是“大量”）。

MySql 是一个关系型数据库。因此，如果您有可以标准化的数据，这些数据分布在许多表中，以确保每个数据点只保存一次，那么您应该使用 MySql（或 Maria，或任何其他关系数据库）。

如果您有无模式数据并且速度比一致性更重要，那么您可以/应该使用一些 NoSql 数据库。就我个人而言，我不知道待办事项列表如何从 NoSql 中受益（在这种情况下并不重要，但我想到目前为止，大多数 programmig 框架对关系数据库的支持比对 Nosql 的支持更好）。

【讨论】：

【解决方案2】：

这是一个非常简单的关系用例。我认为这里不需要 NoSQL。

您提供的表格应该可以正常工作，但是，我个人会质疑复合主键的必要性，因为您将展示这个。我可能会在 stringid 上有一个主键，只是为了强制所有记录的唯一性。而不是跨用户 ID 和字符串 ID 的复合主键。然后我会在用户 ID 上放置一个常规索引。

这样做的原因是，如果您只想通过 stringid 查询（即删除或更新），您不必总是必须跨两个字段查询以利用您的索引（或添加必须添加单独的索引在 stringid 和 userid 上启用每个字段的查询，这意味着我在内存和磁盘中的空间被索引占用）。

至于 MySQL 是否是正确的解决方案，这真的由您来确定。我会说 MySQL 在处理两个整数 id 字段上有 200 万行和 2 个索引的表时应该没有问题。这是假设您已分配足够的内存来将这些索引保存在内存中。当然有大量关于使用 MySQL 的信息，所以如果你只是想学习，它可能是一个不错的选择。

【讨论】：

如果应用程序“繁荣”并达到 100 万用户会怎样。如果 100 万用户完成 50 个任务，那就是 5000 万行不同的行。 MySQL每次登录时搜索特定用户ID的所有任务是否存在性能问题？
如果你有适当的索引（索引？）就不行，而且你为什么认为 nosql 会更快？
@ClydeM 这就是索引的用途。使用 NoSQL 解决方案不会阻止您需要查询用户的记录，这些文档存储也使用索引。
@ClydeM 我有数亿行的 MySQL 表。你的底线是，这对你来说是一个很好的问题，并且可能需要你从根本上改变你的数据库架构（即添加服务器复制、升级硬件等）。当您开始时，我不一定会担心考虑“假设”场景的方式。或许在接下来一年左右的时间里，围绕您可以合理预期的流量来设置您的服务。

【解决方案3】：

无论您认为什么是“大量数据”，现代数据库引擎都旨在处理大量数据。 “关系还是 NoSQL？”的问题不是关于哪个选项可以支持更多数据。不同的关系和 NoSQL 解决方案将以不同的方式处理大量数据，其中一些解决方案比其他解决方案更好。

MySQL 可以处理数百万条记录，而 SQLite 不能（至少效率不高）。 Mongo（NoSQL）试图将它的集合保存在内存（以及文件系统）中，所以我看到它在内存有限的服务器上的记录不到 100 万条时失败了，尽管它提供了分片，可以帮助它更有效地扩展。

底线是：您存储的记录数量不应影响 SQL 与 NoSQL 决策，该决定应留给您将如何保存和检索数据。听起来您的数据已经标准化（例如 UserID），如果您在删除用户时也希望保持一致性（TODO 项目也被删除），那么我建议您使用 SQL 解决方案。

【讨论】：

【解决方案4】：

我假设所有查询都将引用特定的用户 ID。我还假设 stringid 是内部使用的虚拟值，而不是实际的任务文本（您的随机字符串）。

在 {userid, stringid} 上使用带有复合主键的 InnoDB 表，由于聚集索引的工作方式，您将获得所需的所有性能。

【讨论】：