在Firebase实时数据库上存储聊天日志的最可扩展且性能最高的解决方案是什么？

Question

我正在使用Firebase实时数据库作为数据库的聊天客户端。当前的工作方式是将两个人之间的聊天记录保存在一个聊天集合中，每个条目的格式都为<uid>-<uid>。这非常有用，因为它只查找您的uid和您要与之聊天的人的uid，然后对其进行排序，因此它始终是一致的格式，然后查看该条目是否存在于chat集合中，如果存在，它只会添加到该条目。否则，它将创建一个新的。

这很棒。我想尽早考虑一下，如果我们希望能够让多个人像闲暇一样一起聊天。我可以只添加3个或什至4个用户的uid作为键，但是最终它将非常长。 Firebase密钥的限制为768字节。显然，它介于500到700个字符之间。我怀疑我们的密钥会花这么长的时间，但是如果我们能找到一个现在可扩展性更高的解决方案，并且以后又不需要我们修复数据，那我宁愿这样做。 我当时在想，每个聊天条目都可以有一个参与者数组，其中包含该聊天中所有用户的uid。然后，如果您想与某人聊天，我们将需要查询 all 聊天条目，并检查它们中每个数组中的当前用户uid和他们想要聊天的人的uid。用。但这似乎不是很有效。

关于哪种实现更好/更具可扩展性/高性能的任何想法？还是对另一种实现的建议？

Answer 1

简单地使用所生成的UID串联的哈希值怎么样？

或者：

1. 使用您自己的唯一房间钥匙，例如使用推送ID。

2. 使用chatroom-keys创建一个新的顶级节点，并将串联的UID存储为其中的值：

   聊天室钥匙   push-id1：uid1-uid2-uid3   push-id2：uid1-uid2-uid3-uid4-uid5-uid6   push-id3：uid3-uid4-uid5-uid6-uid7-uid8-uid8-uid10

在此结构中，您可以通过以下方式查找一组参与者的房间钥匙：

firebase.database().ref("chatroom-keys").orderByValue().equalTo("uid1-uid2-uid3")