nuomiphp
正在加载…
请使用更现代的浏览器并启用 JavaScript 以获得最佳浏览体验。
加载论坛时出错,请强制刷新页面重试。
请教一下聊天消息应该用什么数据库存储?
la2la
不考虑时序数据库么,本地缓存加线上时序数据库持久化。理论上线上存储的消息应该是加密的的吧?
paouke
公司有搭好的 hbase 就用 hbase ,没有用 mysql ,mongo 也能撑得住,ck 肯定是不太行,ES 用来全文索引还行,主存储不太行吧
aitaii
clickhouse 1000 个并发撑死了
ThinkCat
前公司用的是 mysql ,后面数据量实在过大,用了阿里的 OTS ,但是这个东西太贵了。IM 的热数据不多的话,可以用 mysql ,做好分表和冷热隔离。其实最好的,是楼上讲的时序数据库,较适合 IM 特性,不过这个没用过。
binge921
查询肯定 es 存储肯定 hbase
flycloud
说用 ES 的真是人才,还全文索引。。。
“客户端需要频繁的查询聊天数据” 意思是用户需要拉取和其他用户会话的聊天消息,而不是去全文索引查询某个关键字。
mongodb shard 再适合不过了,设计好 shard key ,保证两个用户之间的会话消息落入某一个分片中,不同的会话消息均匀分布到各个分片。比如 {sessionId: "hashed", msgId: 1},如果有群聊天也是一样的,分配一个 sessionId ,msgId 递增,以支持按会话批量按序拉取消息。
再设置一个字段自动过期删除。
Huelse
flycloud
#65 搜索聊天记录中的关键词是有这种需求的
flycloud
Huelse
是有这种需求,但是注意审题啊,是客户端查询。第一种:本地有存储消息,直接客户端本地搜索啊。第二种:客户端本地不存储消息,应该是没有什么 IM 应用会在所有会话中查询某个关键字吧,而是在某个会话里查询,直接拉取某个会话的历史消息来搜索,不就可以了?当然也会有在后台查询关键字的情况,多半也是会指定某两个用户之间消息查询。实在想不出来在所有用户的所有会话里查询关键字这种需求的意义,所以觉得 ES 没有适用场景。
flycloud
“频繁的查询聊天数据”
其实很多是无效请求,根本没有新增消息,可以在 redis 中设置标记,真正有新消息时才去读取 DB ,可以很大成都降低 DB 压力。
podel
不如所有的消息都是日志 /FILE 。以时间递增序列进行保存。
服务器只存储。
所有消息查询功能都要根据时间戳,从服务器下载下来 SYNC 后。在本地进行计算。比如说搜索之类的。
(服务器只承担存储功能,不承担任何查询功能)
playtomandjerry
Smilencer
也信
jitongxi
说 es 的确实扯淡的,es 的缓存对于非公用的内容查询, 缓存空间估计就炸裂了。
查询确实只是给客户端做的事,服务端只负责存储。
sunmacarenas
公司有钱就上 SAP HANA
hopingtop
1.如果在都能满足功能的情况下,一定要选择团队熟悉的!!!
2.这里 2 亿数据确实不多,而且也不用依赖 mongodb 本身的分片,可依据时间自行管理分片,这样在扩容很有优势
3.mongodb 在查询方面性能还是很不错的,你的查询场景一般还带有时间限制。
4.楼上也说了参考 头部 ,Discord 当初在 2015 年就选择了 mongodb ,(2022 年的 mongodb 更强大了) 为什么不选择其他?当你数据量真的到达扛不住的量级了,我想肯定是很赚钱的了,这个时候人手和资源又不一样了!很多事情本就不可一步到位。
5.需要频繁查询聊天数据,这个需求一般只是 存在运营这个角色, 如果真到 DB 性能不够,那么你完全可以经过角色同步数据的概念到本地进行查询,然后,如果有必要再去服务器去获取上下文。
WOLFRAZOR
c332030
这是没做优化的问题吧。优化之后不可能这样的。
c332030
WOLFRAZOR
#74 微信都迭代这么多个版本了
zmzeng12
写多读少,又不涉及修改消息。
数量不大用 SQLite ,数量大用 RocksDB 。
RocksDB 的话,服务器存全量 sstable 作为 single of truth ,客户端按需拉取查询时间范围内的 sstable 文件,Client 本地完成查询。
remember5
个人猜测,本地查询 sqllite + 后台 hbase
changdy
clickhouse 去掉 .不是干这个的 其次 时序数据库 了解的不多 .但是 也比较赞同
joesonw
的说法es 我觉得有几个问题吧.基于分词,无法保证查询结果 数据难分表. 不分表冷热数据混在一起也有点小问题.感觉 im 这个场景还是挺大的 ,最好还是和产品一起商量下如何优化 使用体验.
documentzhangx66
淘宝这么多年现成的方案,都不用?
直接按用户进行分库。
首先按用户热度,分为冷热用户集群。
热集群高配置,大内存,SSD 。冷集群低配置,小内存,HDD 。
每个集群由一大堆 Mysql 节点组成,每个 Mysql 节点负责一部分用户。节点散列策略按用户 IO 数量来进行负载均衡。
这样实现了几个好处:
1.对于一个用户,所有数据集中在一台 Mysql 里。
2.实现了基于性价比的冷热数据分离。
3.如果一些 Mysql 节点坏了,只会影响一小部分用户,不会影响整体业务。
4.如果一些用户的冷热度发生变化,方便做自动迁移。
5.每个 Mysql 节点的数据量小,能够支持 LIKE 进行高精度搜索。
djoiwhud
monkeydream
#30 。你的需求选 mysql 或者 pg 就可以了。热数据放 redis 里面。实在想折腾新方案,想永久保存聊天记录,考虑 hbase 或者 hive 。本人做过 IM 类的需求产品,我负责的说,这个需求用 es 是个错误。
« 上一页
下一页 »