小编Lor*_*ato的帖子

在我自己的服务器和AWS服务器上进行了多天的研究和多次负载测试后,我决定向社区提问.

我正在开发一个图像跟踪平台.在此平台上,用户可以关注图像和其他图像,这些图像是作为对后续图像的回复而发送的.

基本方案

"跟踪"表可在未来12个月内达到1,000,000,000条记录.我们担心,每个用户访问我们的家必须咨询所有照片,并通过他们加入照片来显示.在跟踪表中,不进行DELETE和UPDATE,仅进行INSERTS.

我已经使用Spawner数据生成器执行测试生成虚拟数据,在"跟踪"表中放置了1亿条记录.在完成三个必需的JOIN时,我得到了一个非常好的respio时间(或者我认为)~35ms,但是当我执行100个或更多并发查询时,系统运行速度非常慢,甚至需要25秒才能回答.

我开始认为MongoDB至少可以帮助每个用户(文档)有一系列照片跟随(子文档),但其中一个问题是16mb的限制,另一个是带来每个"回复" "(带有字段photo_id的文件).我还试图做一个除了跟踪之外的集合(带有user_id和photo_id的文档)以避免16mb的问题,但仍然存在带来"回复"的问题(我不认为这是一个最佳解决方案,除了我理解对于Relational数据,不使用NoSQL.您必须使用适当的工具)

问题:

1 - SQL是设计用于进行此类查询还是我对技术的使用不当？

2 - 在这种情况下不应使用MongoDB,因为它依赖于关系数据.我对吗？

3 - 你有什么建议吗？

老实说,我非常关心性能,特别是公寓达到了一排排

为什么你不应该使用MongoDB - Sarah Mei:感兴趣的文章引起了标题的巨大轰动.我已经阅读了有关该文章的几个意见,我变得更加困惑

用于测试的服务器:

第一:

与MariaDB的-AWS免费套餐.

第二:

-CPU:Celeron J1900

-RAM:4GB 1666mhz

-SSD:32 GB

-OS:Ubuntu服务器16.04

- 软件:MariaDB

第三:

-CPU:i7 7700

-RAM:16GB 2133mhz

-SSD:512

-OS:Windows 10

- 软件:MariaDB