Django在db中存储讨论的正确方法是什么？

Question

我使用带有postgresql的django 1.11作为数据库。我知道如何存储和检索数据库中的数据，但我找不到一个正确的方法来存储和检索两个用户的整个讨论的示例。你知道吗

这是我的简单想法：
两个用户连接到127.0.0.1，在这个页面中有一个文本区域窗体。两个用户都可以写入文本区域，然后按一个按钮发布内容。页面将重新加载，现在显示所有消息。你知道吗

我想知道的是，如果正确的存储和检索方法是：

one db row => single message user

如果两个用户交换，比如说15条消息，它将存储15行，并且要进行一个单音讨论，我可以在数据库中放入另一列类似于讨论“id”的内容，因此15行将具有相同的id和用户：

db row1 ---> "pk=1, message=hello there, user=Mike, id=45")  
db row2 ---> "pk=2, message=hello world, user=Jessy, id=45")

当页面在django中运行时：

discussion = Discussion.objects.all().filter(id=45)

检索讨论。你知道吗

只有两个用户可以私下讨论，所以每两个用户都有一个讨论页面，比如127.0.0.1/one、127.0.0.1/two等等。。你知道吗

如果这是存储和检索数据库的正确方法，那么我的问题是它将如何扩展？我是否可以依靠这种设计来高效地存储和检索数据库中的数据，否则不久的将来数据量会很大？我担心1000个用户可能会很快成长为10000行。你知道吗

Answer 1

因此，你的问题的答案取决于你未来打算如何使用这些数据，以及你需要如何处理这些数据。完全可以将N个用户之间的整个会话存储在一个列式数据库（如Postgres）中，作为每条消息的单独记录。但是，与所有编程问题一样，有多种范例可以回答您的问题。我将在这里探讨其中几个的优缺点（当然还有更多）。你知道吗

范例1每条消息的新记录（行）

优点：

1. 更简单地查询单个消息。你知道吗
2. 分析功能可以很容易地应用于消息级别（即某些用户的消息总数）
3. 记录大小（相对）较小

缺点：

1. 非常长的桌子尺寸
2. 随着表的增长，搜索变得非常耗时。你知道吗
3. 需要对集合进行后期处理（即会话中的所有记录）
4. 更多的工作转移到服务器上

范例2每个会话的新记录（行）

优点：

1. 更简单地查询个人对话
2. 较短的桌子尺寸
3. 需要对一个对象进行后期处理（即整个会话存储为一个JSON对象）

缺点：

1. 更大的行大小，它可以根据消息的数量和大小实质性地增长。你知道吗
2. 更难查询单个消息或消息中的文本（需要使用更昂贵的函数，如%on blobs of text=slow）
3. 不利于对消息执行任何类型的分析功能。你知道吗
4. 信息变成附加练习
5. 更多的工作转移到客户机/应用程序

哪个最好？基督教青年会

同样，可能有六种或更多的方法可以存储应用程序的消息，所有这些都取决于下游的需要。此外，我还建议您研究像Apache Kafka这样的项目，这些项目专门用于消息发布，作为一种潜在的可扩展的插入式解决方案。你知道吗

Answer 2

三项建议：

1. 如果您为PostgreSQL提供了相当数量的资源（例如，amazonm3.large实例），那么PostgreSQL数据库的“大量行”大约为1亿行（取决于具体情况）。这不是一个限制，它只是足够的行，您将不得不花一些时间来提高性能。所以假设聊天平均有100条信息，那就是100万次对话。因此，按照您所说的规模，每条消息只有一行并不是性能问题。你知道吗
2. 不要把数字PK作为你安排对话的主要方式（你可能还有一个，Django喜欢有一个）。有一个timestamptz列，它是如何重建会话顺序的。你知道吗
3. 在user上有一个惟一的索引timestamptz（因为用户不能同时发布两条消息），在conversation上有另一个惟一的索引timestamptz（这将允许您快速重建会话）。你知道吗
4. 您还应该有一个名为“conversations”的表，其中汇总了会话id和用户列表，因为这样可以很容易地回答“show me all my conversations”的请求。你知道吗

这能回答你的问题吗？你知道吗