ravendb - 用于存储即时消息的关系数据库或文档数据库？也许别的什么？

Question

我几天前开始使用 RavenDB。到目前为止我很喜欢它，但我对整个 NoSQL 世界还很陌生。我正在尝试考虑模式 什么时候更喜欢它(或任何其他 DocumentDB 或任何其他 NoSQL 类型的数据存储)而不是传统的 RDBMS。我确实理解“当您需要存储文档或非结构化/动态结构化数据时选择 DocumentDB”，但这感觉太笼统了，难以理解。

为什么？因为据我所知，人们一直在为“文档”编写示例，例如电子商务应用程序中的订单详细信息和工作流管理应用程序的表单详细信息。但是这些已经使用 RDBMS 开发了很长时间，没有太多麻烦 - 例如，订单的详细信息，如数量、总价、折扣等，结构完美。

所以我认为这里有重叠。但是现在，我不寻求关于何时使用什么的一般建议，因为我相信对我来说最好的办法是通过实验自己弄清楚；所以我只想问一个具体的案例以及我的担忧。

假设我开发了一个即时消息应用程序，它可以像 Facebook 的消息传递系统一样将消息存储到很久以前。我认为在这里使用 RDBMS 是不合适的。我这样做的原因是大多数人使用这样的即时消息系统:

• 答:你好
• 乙:嘿
• A:你怎么样？
• B:很好，你呢？
• A:我2
• ...

需要注意的是大多数消息都非常短，因此将每个消息都存储在具有这种结构的一行中:

Messages(fromUserId, toUserId, sent, content)

感觉非常低效，因为“实际有用的信息(内容)”非常小，而表将包含大量的行，因此索引会变得巨大。加上消息发送非常频繁的事实，索引的大小会对性能产生巨大影响。因此，必须管理和存储大量的行，而每一行都包含最少量的实际信息。

在 RavenDB 中，我会使用这样的结构:

// a Conversation object
{
    "FirstUserId": "users/19395",
    "SecondUserId": "users/19396",
    "Messages": [
        {
            "Order": 0,
            "Sender": "Second",
            "Sent": "2016-04-02T19:27:35.8140061",
            "Content": "lijhuttj t  bdjiqzu "
        },
        {
            "Order": 1,
            "Sender": "Second",
            "Sent": "2016-04-02T19:27:35.8200960",
            "Content": "pekuon  eul co"
        }
    ]
}

使用这种结构，我只需要找出我要查找的对话:用户 A 和 用户 B 之间的对话。 用户 A 和 用户 B 之间的任何消息都存储在这个对象中，无论是 用户 A 还是 用户 B是发件人。因此，一旦我找到他们之间的对话 - 对话比实际消息少得多 - 我就可以抓取与之相关的所有消息。

但是，如果两个参与者交谈很多(假设消息存储了 3 年)，则一次对话中可能包含数万条消息，导致对象变得非常大。

但是有一件事我不知道它在 RavenDB 中是如何工作的(特别是)。它的内部存储和查询机制是否允许(数据库引擎，而不是客户端)只获取(例如)50 条最新消息而不读取整个对象？毕竟，它使用对象属性的索引，但我还没有找到任何关于是否可以在数据库端读取对象的部分的信息。 (也就是说，没有数据库引擎从磁盘读取整个对象，解析它，然后只将所需的部分发送回客户端)。

如果可能，我认为在这种情况下使用 Raven 是更好的选择，如果不能，那么我不确定。因此，请通过回答上一段中提到的问题以及有关哪种数据库模型最适合此特定场景的任何建议来帮助我清理它。 RDBMS？文档数据库？或许还有别的？

谢谢。

Answer 1

我想说的主要区别是:

• 您的应用程序是否使用 JSON 格式的数据？ -- 然后将其存储为 JSON(在文档数据库中)并避免对其进行序列化/反序列化。
• 您是否需要对数据运行分析工作负载？ -- 然后使用SQL
• 您需要什么一致性级别？ -- SQL 为高一致性而生，docDB 为低一致性而优化
• 您的架构变化很大吗？ -- 然后使用(无模式)docDB
• 您预计的规模是多少？ -- docDB 通常更容易横向扩展

另请注意，许多现代云文档数据库(如 Azure DocDB)可以为您提供两全其美的功能，因为它们支持异地复制、无架构文档、自动索引、有保证的延迟和 SQL 查询。 SQL 数据库(如 AWS Aurora)可以处理巨大的吞吐率，但通常仍需要 DBA 的更多帮助。