nuomiphp
正在加载…
请使用更现代的浏览器并启用 JavaScript 以获得最佳浏览体验。
加载论坛时出错,请强制刷新页面重试。
请教一下聊天消息应该用什么数据库存储?
monkeydream
tairan2006
ES 可以考虑下;时序数据库没接触过,不太敢用。
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 这个场景还是挺大的 ,最好还是和产品一起商量下如何优化 使用体验.
yangzhuowork
某办公 IM 大厂早期用的是 mysql 写扩散。 后面量大了。就扛不住了。 架构升级成 类 Hbase 的 OTS ( tableStore ) IM 业务核心特性之一是,基本上很少修改数据(撤回,删除等)。另外要核心关注一下 读写扩散模型的问题。 大群治理。 现代的 IM 都不是单纯的读扩散或者写扩散了。
MongoDB 不太建议。MongoDB 最贴合的应该是数据 schema 多变的这种业务类型 。IM 业务的表基本不会有啥变化。不适合。clickHouse 不了解。
realrojeralone
钉钉用的 TableStore https://help.aliyun.com/document_detail/430700.html#p-1dc-ajj-at1
pengtdyd
就没人推荐 postgresql 吗?
首先是场景:聊天记录需要频繁查询吗?拿微信来说,本地先有一份,同时同步多端消息,但是需要发送查询到服务器本身并不是一个高频的场景,聊天应用本地需要一个数据库,查询不到本地或者轮询同步的时候才需要和服务器进行交互。
lmshl
聊天场景的话,主要是写多读少,几乎不修改,而且顺序性明显
那我推荐 Cassandra ,以 Channel/Group 为 partition key ,timeuuid 为 clustering key ,写入每 key 几万且支持水平线性扩展,以 partition key 读取也是顺序读,速度不需要担心。
lmshl
接 #35 Cassandra 还支持过期时间 (TTL).
你想存储几个月就存储几个月,过期后不需要手动清理
demon1991yl
mongodb 吧,我们的私信、im 消息目前都是存在 monodb 里面的,规模都是上百亿条,而且根据楼主的描述,数据量 2 亿不算多,存 mongo 的话,也方便后续扩展,,而且基本也是一些在线索引查询。ES 、CK 等对于 TP 类业务实时性不一定能保证
« 上一页
下一页 »