【问题标题】:NoSQL recommendation for a project (text streaming)项目的 NoSQL 推荐(文本流)
【发布时间】:2012-04-10 08:41:58
【问题描述】:

我正在寻找 NoSQL DB 推荐...这是我正在做的工作:

我正在编写一个基于 Web 的客户端,用于向大量消费者提供文本流(基本上是实时字幕)。一旦事情完全升级,任何特定时刻都可能发生 100 多个事件。许多会很小(

在每个事件的过程中,文本将以每分钟几字到每分钟 200 多个字的速度积累。每个消费者都将运行一个 Web 客户端(台式机/笔记本电脑/平板电脑/智能手机上的浏览器),该客户端将定期轮询它尚未收到的任何文本。给定的用户也可以在他们提出请求之前询问事件的全文。已完成的事件必须保留一段时间,但会在完成后约 24-36 小时内被移除。

我的第一个想法是使用 Redis,它具有附加到数据存储中的文本值的方法以及对从文本值末尾获取子字符串的内置支持(即客户端可以只保存字符它接收到的最后一个字符的偏移量,并将其传递给客户端 API,并将用于从事件文本中提取子字符串)。我担心包含事件文本的字符串的增长可能是 Redis 的不寻常使用,可能会给我带来一些问题。

那么...是否有一个 NoSQL DB 似乎特别适合这种应用程序?有什么重要的理由不使用 Redis 来做这样的事情吗?

【问题讨论】:

  • 我建议继续使用 Redis,看看它的性能如何。我们将 Redis 用于每 40K+ 请求的非字符串对象,并且负载最小。

标签: nosql redis


【解决方案1】:

一个潜在的悬而未决的问题是如何处理新客户。例如,假设一个事件已经开始并且有人连接了几分钟。他们是从一开始就需要一切,还是从他们连接时就需要?

如果是后者,我建议使用消息系统,而不是将字符串附加到字符串。一种方法是改用 Redis 的Pub/Sub。总体而言,这似乎更合适,尤其是如果新连接从一开始就不需要一切。对于长期存储,与任何其他和存档条目一样侦听的客户端 - 最好通过本地缓存,然后在完成或正在进行时上传完成的脚本。我会将实时需求和代码与请求历史记录和档案分开。

另一种方法是使用有序集,使用输入时间的时间戳。结果,客户端仅跟踪上次更新并从那时起检索任何内容。可以在here 找到有序集文档。此方法还提供了从转录本中选择时间区域的能力。通过一些数学运算,您甚至可以从成绩单的角度重播该事件,就好像它是现场直播一样。如果您有成千上万的客户在每次民意调查中提取整个成绩单

时间戳有序集的另一个优点是字符串编码。当使用 Redis 字符串和 getrange 时,您必须使用固定宽度的编码。范围是字节偏移,而不是字符偏移。如果您需要支持 UTF-8 的能力,这对您来说可能是个问题。

第三种选择是将文本字符串附加到列表中。这类似于排序集,除了您的客户端存储最后一个索引(列表的大小)并且在每次轮询时尝试获取从 lastIndex+1 到末尾的任何内容。

【讨论】:

  • 它对新客户的工作方式是他们会收到一些,但不一定是全部,事件的文本......我们可能会提取最后几百个字符事件文本并在第一个请求中返回。在那之后,它只是交付的新文本。我考虑过发布/订阅的可能性,但客户端在这方面非常有限。我们只关注 Web 客户端,并且 Web 套接字总体上没有得到很好的支持。也许在几年后......我也想到了长字符串与排序集的想法......我可以尝试两者并进行比较......
猜你喜欢
  • 2017-08-19
  • 2023-03-23
  • 2020-12-14
  • 1970-01-01
  • 2017-12-05
  • 2022-06-11
  • 2011-07-24
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多