Mongodb 在一个类似打火机的基于滑动的应用程序中，滑动/匹配的后端是如何工作的？

我正在尝试开发一个应用程序，它可以复制类似于打火机的基于滑动的提要。该应用程序的理念与tinder非常相似，还具有向右滑动和向左滑动的匹配功能

我到目前为止所做的事情- 我在MongoDB中创建了一个刷卡集合，它将用户的刷卡存储在以下模式中-

swipedBy : {type:Schema.ObjectId},
swipedUser : {type:Schema.ObjectId},
status: {type:String, default:"left"}

当用户向右滑动时，我正在呼叫DB。对于每一次滑动插入，我都会在说出匹配项或将其存储在DB中之前，尝试找出一个用户是否被另一个用户正确滑动。一定有更好的办法

可能的解决方案

我希望使用诸如Redis之类的内存数据库来存储类似的信息，并根据滑动来查找用户之间的匹配。如果有人能解释tinder是如何做到这一点的，那么它也会很有帮助。 我在Redis中的模式如下所示-

HSET for each user with 
- userId as field, and 
- status as swipe status

但这种方法的问题是，我无法跟踪用户是否已经在订阅期间刷过某个特定的人。解决这个问题可以做的一件事是，我可以更新集合并维护已刷卡用户的列表

如果在此过程中有任何其他数据库/方法可以帮助我，请也提出建议

编辑：

---

我没有遇到任何瓶颈。我只是想确认一下我是否做对了。迭代列表以确定用户是否被另一个人刷到了正确的位置是一个线性时间解决方案。我想知道我是否可以做得更好，通过DB或其他我应该尝试的东西。

我不知道这是否真的解决了您的查询，但您可以尝试一下

• 有一个单独的布卢姆过滤器来检查它是否匹配。。。可能会出现误报，但由于大多数将“尚未匹配”，这将节省大量数据库查询
• 如果它还不是一个匹配项，并且您需要存储刷过的数据条目，请在内存/redis中保留多个这样的条目一段时间，然后在数据库中大容量插入
• 实时更新bloom filter（注意：在批量插入完成之前，bloom和数据库之间可能存在暂时的不匹配。）

---

为什么一定要有更好的方法？你有什么问题吗？（打太多电话给DB？为什么这对你很重要？）是的，我担心打太多电话给DB@CodyG.ok，那为什么这对你很重要？也就是说，你是否遇到了瓶颈？您想要达到什么样的性能要求？您测试了什么——即，您证明您可以使用Mongodb编写多少事务？为什么这还不够？@CodyG。我没有遇到任何瓶颈。我只是想确认一下我是否做对了。迭代列表以确定用户是否被另一个人刷到了正确的位置是一个线性时间解决方案。我想知道我是否可以做得更好，通过DB或其他我应该尝试的东西。仅出于这个原因，我还提到了我对这项任务的解决方案。你找到更好的解决方案了吗？