在我自己的服务器和 AWS 服务器上进行了多天的研究和多次负载测试后，我决定询问社区。
我正在开发一个图像跟踪平台。在此平台上，用户可以关注图片以及作为对关注图片的回复而发送的其他图片。
基本方案
“跟踪”表在接下来的 12 个月内可以达到 1,000,000,000 条记录。我们担心每个访问我们家的用户都必须查阅所有照片，然后通过 JOIN 收集照片以显示。 在跟踪表中，不进行DELETE和UPDATE，只进行INSERTS。
我已经使用 Spawner Data Generator 执行了生成虚拟数据的测试将 1 亿条记录放入“跟踪”表中。在执行三个必需的 JOIN 时，我得到了很好的响应时间(我认为是这样)，约为 35 毫秒，但是当我执行 100 个或更多并发查询时，系统运行非常慢，甚至需要 25 秒才能回答。
我开始认为 MongoDB 至少可以在每个用户(文档)后面有一组照片 ID(子文档)的部分提供帮助，但其中一个问题是 16mb 的限制，另一个是带来每个“回复”(带有字段 photo_id 的文档)。我也尝试过做一个除了跟踪之外的收集(带有 user_id 和 photo_id 的文档)来避免 16mb 的问题但是仍然存在带来“回复”的问题(我不认为这是一个最佳解决方案，除了我理解关系数据不要使用 NoSQL。您必须使用适当的工具)
问题:
1 - SQL 是专为进行此类查询而设计的，还是我对技术的使用不当？
2 - 在这种情况下不应使用 MongoDB，因为它非常依赖关系数据。我说得对吗？
3 - 你有什么建议吗？
老实说我很在意性能，尤其是公寓达到十亿行
Why You Should Never Use MongoDB - Sarah Mei : 感兴趣的文章，引起了标题的极大轰动。我已经阅读了关于那篇文章的几种观点，但我越来越困惑了
用于测试的服务器:
首先:
-带有 MariaDB 的 AWS 免费套餐。
第二个:
-CPU:赛扬J1900
-内存:4GB 1666mhz
-固态硬盘:32GB
-操作系统:Ubuntu服务器16.04
-软件:MariaDB
第三:
-CPU:i7 7700
-内存:16GB 2133mhz
-固态硬盘:512
-操作系统:Windows 10
-软件:MariaDB
最佳答案
Is SQL designed to make such queries...?
查询像什么？您还没有显示任何查询。
当您需要针对数百万行优化查询时，您必须非常具体地说明您正在优化哪些查询。您可以使用索引、分区或其他技术，但每种优化都是针对特定查询进行优化，以其他查询为代价。
MongoDB should not be used in this case because it relies a lot on relational data. Am I right?
MongoDB 3.2 支持 $lookup，这有点像外连接。但它不太可能像 SQL 中的索引连接那样高效。
MongoDB 的另一个策略是存储更复杂的文档，所有相关数据都在嵌套结构中。这样您就不必进行联接，但它会针对某种数据检索进行优化。
Do you have any recommendations?
我建议根据您将要处理的数据量适当调整服务器的大小。
为它们提供足够的 RAM，以便您可以将数据集保存在 InnoDB 缓冲池中。确保调整您的 MySQL/MariaDB 选项以利用系统 RAM。
为他们提供更强大的 CPU，可以执行更多并发线程(在您的情况下，顶级 CPU 仍然是单个 4 核 CPU，HT 仅用于 8 个线程)。 100 个并发线程让您的普通 CPU 不堪重负也就不足为奇了。
还打算多用缓存。对大型数据集的查询将非常昂贵。最快的查询可能是您根本不必执行的查询，因为结果已经在缓存中。您需要在应用程序级别进行架构以减少 SQL 查询负载。
关于mysql - 大量数据的 SQL 与 NoSQL 性能，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/46008710/