mysql - 为类似 Tinder 的应用程序设计高效的 MySQL 数据库

Question

我正在创建一个像 Tinder 这样的应用程序。用户可以向右滑动或喜欢，向左滑动或不喜欢其他用户。问题是关于存储用户的操作。如下用户操作需要一个表

Person 1.   |   Person 2.    |     op
__________________________________
000001.          000007.          Dislike
000001.          000011.          Like
000001.          000053.          Dislike
000001.          000173.          Dislike

它存储操作，也用于不向用户显示更多次。到目前为止一切正常。

但问题是，如果只有 1000 个用户刷另外 1000 个用户，那么该表将有 100 万行。如果有 100,000 个用户这样做......它会达到 100M 行!这是非常巨大的。

你们有什么想法可以设计一个不会长得这么大的结构吗？

谢谢。

Answer 1

有几件事需要考虑。

首先，除非您知道需要运行的查询类型，否则表的大小并不是很有趣。正如其他人所说，拥有数亿行的表没什么可怕的，如果您在可索引字段上查询，您可能可以扩展到 十亿 行，而无需采用奇异的解决方案通过购买更大更好的硬件。因此，90% 的查询都是

选择 * 来自用户 其中 user_id 不在 (选择 interacted_user_id 来自互动 其中 interacting_user_id = $current_user) 限制 10

我的猜测是，这将在您的笔记本电脑上扩展到数亿行，在一台像样的服务器上扩展到数十亿行。我的强烈建议是使用没有分区的简单关系解决方案或其他奇特的解决方案，直到您扩展到不再有效的程度，并且您已尽可能调整查询并升级硬件。这比任何其他解决方案都便宜/容易。

更大的挑战将是地理空间方面 - 据推测，您希望根据与当前用户的距离对结果进行排序。

您可以对数据进行分区的一种方法是按区域收集“交互”。这需要一些思考——您可能不想要“硬”边界，而是想要重叠的地理区域。 map 上的每个点都可能有几个重叠的“区域”，每个区域都有自己的表格。您在一个地区拥有的用户越多，重叠的圆圈就越小——曼哈顿可能有 3 个地区，格陵兰可能只有 1 个。然后您的查询会查看每个重叠地区的表，并合并以前没有的用户与当前用户交互。