nuomiphp
正在加载…
请使用更现代的浏览器并启用 JavaScript 以获得最佳浏览体验。
加载论坛时出错,请强制刷新页面重试。
请教一下聊天消息应该用什么数据库存储?
monkeydream
awanganddong
多谢。
coderxy
monkeydream
我们是仿照钉钉走的拉模式,全部都是走数据库,反正 hbase 稳得很(请求量大了或者数据量大了都会自动分片)。mongodb 的话,如果你用分片集群,提前做好压测,应该也没啥问题。
tairan2006
你要做线上查询的话,肯定推荐 es 吧。
不然的话推荐用时序数据库,或者 hbase 这些方案也能用。
monkeydream
tairan2006
ES 可以考虑下;时序数据库没接触过,不太敢用。
monkeydream
coderxy
多谢;那我们估计优先考虑 mongodb ,因为目前项目中已经有些应用在尝试使用 mongodb 数据库。
masterclock
公司有 10 万人?买一套不好吗?为啥要浪费时间开发?
monkeydream
masterclock
IM 聊天是我们 SAAS 产品的一部分;不只是我们公司自己用。
coderxy
masterclock
第三方的各种限制,而且也不便宜。 有能力的话自研一下其实成本不高的。
coderxy
monkeydream
可以的,符合自己需求的才是最好的。 毕竟 hbase 这一类数据库用的人少,维护起来也比较麻烦。IM 领域真正麻烦的是超大群,其它都还好。
di1012
要不试试时序数据库?
monkeydream
di1012
你们实际项目生产上有使用过吗?我们没接触过这块,怕坑太多。
onlyhuiyi
为什么要用 mongo 呢,我们公司 mongo 都不再支持新的接入了
monkeydream
onlyhuiyi
为啥不接入了? mongo 写入查询效率还可以吧?这么多年了也比较成熟,也可以进行分片存储大数据。比存 mysql 肯定要强不少吧。
demon1991yl
onlyhuiyi
为啥不接 mongodb 了呢,我们挺多业务再用,还有很多 mysql 转过来的呢
wxf666
monkeydream
3 天前的 [这个帖子]( https://www.v2ex.com/t/882773 ) 里,有很多人反映,MySQL 单表存 1~2 亿(#11 楼 #16 #18 #19 #21 #35 )、4 亿(#27 )、10 亿(#35 )、20 亿(#28 )都没问题诶,查询也很快(几十 ms ,#27 #28 )MySQL 真的不行吗?
liuhan907
monkeydream
聊天数据,你要搜索要全文搜索,除了 ES 你还想自己实现倒排索引?
Singular
System Design 的书介绍设计 Facebook Messenger 用的是 Hbase 这类宽表存储 DB
F.Y.I.: https://akshay-iyangar.github.io/system-design/grokking-system-design/system-design-problems/facebook-messenger.html
AnLuoRidge
Singular
这个附的链接 404 了
monkeydream
wxf666
主要考虑不仅仅是数据量存的问题,还有并发读。最终还是要做个压测对比下。
b123405060
wxf666
mysql 单表一般不超过 500w, 单表上亿的数据? mysql 这么强大吗
monkeydream
liuhan907
不是全文检索,是多端数据同步,要实现消息拉取。
wxf666
b123405060
超过 500w 会怎样? B+ 树从 3 层 变为 4 层?然后由于内存只能完整缓存前两层(前两层代价是 20~30 MB 内存,前三层代价是 20~30 GB ),所以 3 层变为 4 层,会导致实际 IO 由 1 次 变为 2 次,即速度下降 50%?还是怎么个逻辑?数据库新人,求指教
wxf666
monkeydream
你要并发读多少啊?那个帖子里反馈,MySQL 单表这么多亿,单次查询也能 10- ms 啊(噢,26 楼写错了)
liuhan907
monkeydream
所以你是要做 IM 消息存储和消息本身的检索?那这个 2E 的量基本随便了吧,拿个 pgsql 硬件规格拉高一些单机大概都够。不放心就找一个分布式数据库一把梭。
wxf666
monkeydream
我大概算算 MySQL 单表,受限于 IO 的读并发吧:假设:- B+ 树 4 层 *(若 InnoDB 、Dynamic 、16 KB 每页、8 字节主键、1 KB 一条消息,可容纳 110 亿)*- 缓存前两层 *( 14 MB 内存代价)*- 有 `(uid 4 字节, time 5 字节)` 索引- 每个用户每次获取不超过 700 条消息 *(此时索引只需读一个叶节点)*- **不缓存实际消息** *(就当所有用户都在获取历史消息吧。因为每个叶节点可能存着 15 个不同用户的消息,太散了,不会算『每次一个用户获取一堆消息时,能利用上多少缓存』,直接按最差情况算)*设每秒有 x 人请求,平均每人有 y 条消息要获取,硬盘有 z 个 16 KB 的 IOPS ,那么:2x (每人消耗 2 次 IO 去索引读取自某个时间以来的消息 ID 列表) + 2xy (每条消息都要 2 次 IO 去消息表读取) <= z如,我的垃圾固态,16 KB 有 25000 IOPS (也就 400 多 MB/s )。那么:每秒 100 人要获取消息时,平均每人能得到(不在缓存中的) 124 条历史消息?(数据库新手,算的不对,恳请指出)
djoiwhud
monkeydream
#30 。你的需求选 mysql 或者 pg 就可以了。热数据放 redis 里面。实在想折腾新方案,想永久保存聊天记录,考虑 hbase 或者 hive 。本人做过 IM 类的需求产品,我负责的说,这个需求用 es 是个错误。
onlyhuiyi
monkeydream
我也不知道为啥,提申请页面都写着不再接新的实例了。应该是内部用的少吧,不想浪费人力去维护这部分了,主要还是用 mysql ,ES ,redis 等,最近越来越多用 clickhouse 。接触的系统很少用 mongo 。
joesonw
时序是存数字的,每条记录存的是差值来优化空间和统计。聊天记录这种文本的完全和时序没半毛钱关系。一般查询是本地的,服务器只是留档不检索的话,按时间存对象存储就好了。用户同步到本地 sqlite 再查询。
changdy
clickhouse 去掉 .不是干这个的 其次 时序数据库 了解的不多 .但是 也比较赞同
joesonw
的说法es 我觉得有几个问题吧.基于分词,无法保证查询结果 数据难分表. 不分表冷热数据混在一起也有点小问题.感觉 im 这个场景还是挺大的 ,最好还是和产品一起商量下如何优化 使用体验.
« 上一页
下一页 »