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

Question

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

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

它存储操作，也用于不再显示用户。到现在都没问题。

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

你们有没有想法设计一个不会变得这么大的结构？

谢谢你。

Answer 1

有几件事需要考虑。

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

select * from users where user_id not in (select interacted_user_id from interactions where interacting_user_id = $current_user) limit 10

我的猜测是这将扩展到您的笔记本电脑上的数亿行，以及一个体面的服务器上的数十亿行。我强烈建议您使用简单的关系解决方案，不要使用分区或其他奇异的解决方案，直到您扩展到不再适用的程度，并且您已经尽可能调整了查询​​并升级了硬件。这比任何其他解决方案都便宜/容易得多。

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

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

Answer 2

你永远不会有 100 万行，因为如果你正在做一个类似 Tinder 的应用程序，你可以重新匹配人。因此，我建议您添加一个日期列，以了解何时可以删除该行以及可以执行以清理过期关系的存储过程。

使用此列，行将不会堆叠，并且您将永远不会拥有数百万行。

当人们喜欢在一起时，你也不需要存储。

编辑：为什么不使用 CHECKSUM() 来存储每个关系的哈希值？会更轻。

EDIT2：不要忘记这是一个爱情应用程序。人们并不因为有性取向而与每个人都匹配。