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

时间:2016-04-03 12:58:07

标签: ravendb rdbms database nosql

几天前我开始玩RavenDB。我到目前为止都喜欢它,但我对整个NoSQL世界都很陌生。我试图考虑 patterns 何时比传统的RDBMS更喜欢它(或任何其他DocumentDB或任何其他NoSQL类型的数据存储)。我确实理解"当您需要存储文档或非结构化/动态结构化数据时,选择DocumentDB"但这感觉太过笼统。

为什么呢?因为从我所读过的内容来看,人们一直在为#34;文件"例如电子商务应用程序中的订单详细信息和工作流管理应用程序的表单详细信息。但这些已经与RDBMS一起开发了很长时间而没有太多麻烦 - 例如,订单的细节,如数量,总价,折扣等,都是完美的结构。

所以我认为这里有重叠。但是现在,我并没有要求一般建议什么时候使用什么,因为我相信对我来说最好的是通过实验自己弄明白;所以我只想问一个具体案例以及我的担忧。

所以,让我们说我开发了一个即时消息应用程序,它可以存储消息,就像Facebook的消息传递系统一样。我认为在这里使用RDBMS并不合适。我的理由是,大多数人都使用这样的即时通讯系统:

  • A:嗨
  • B:嘿
  • A:你好吗?
  • B:好,你呢?
  • A:me 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是更好的选择,如果没有,那么我不确定。所以请通过回答前一段中提到的问题以及有关DB模型最适合这种情况的任何建议来帮助我清理它。 RDBMS的? DocDBs?也许别的什么?

感谢。

1 个答案:

答案 0 :(得分:1)

我想说的主要区别是:

  • 您的应用程序是否使用JSON中的数据? - 然后将其存储为JSON(在文档数据库中)并避免序列化/反序列化。
  • 您是否需要对数据运行分析工作负载? - 然后使用SQL
  • 您需要什么样的一致性水平? - SQL具有高一致性,docDB针对较低的一致性进行了优化
  • 您的架构是否发生了很大变化? - 然后使用(无架构)docDB
  • 您期待的规模是多少? - docDB通常更容易扩展

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