MySQL还是NoSQL？推荐的处理大量数据的方法

Question

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

所以看起来很像这样：

Userid将是唯一的，并且stringid对每个用户都是唯一的。

该应用程序就像一个简单的待办事项列表应用程序，因此每个用户平均有50个待办事项。 我正在使用stringid，以便用户可以在任何给定时间删除特定任务。

我认为这个todo应用程序可能在3年内完成700万个任务，这让我害怕使用MySQL。

所以我的问题是，如果这是处理大量数据的实际推荐方法使用长字符串（每个新任务获得一个新行）？而是MySQL是选择此类项目的正确数据库解决方案吗？

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

Answer 1

这不是“大量”数据的问题（mysql处理大量数据就好了，2毫安行在任何情况下都不是“大量”）。

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

如果你有无模式数据，速度比一致性更重要，你应该/应该使用一些NoSql数据库。我个人不知道todo列表是如何从NoSql中获利的（在这种情况下并不重要，但我想现在大多数programmig框架对关系数据库的支持比对Nosql更好）。

Answer 2

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

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

原因在于你只想通过stringid查询（即删除或更新），你不必总是在两个字段之间进行查询以利用你的索引（或者添加必须添加单个索引）在stringid和userid上启用每个字段的查询，这意味着我的内存空间和磁盘占用了索引）。

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

Answer 3

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

MySQL可以处理数百万条记录，SQLite不能（至少没有那么有效）。 Mongo（NoSQL）试图在内存（以及文件系统）中保存它的集合，所以我看到它在内存有限的服务器上记录的记录少于100万，但它提供了分片，可以帮助它更有效地扩展。 / p>

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

Answer 4

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

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