nuomiphp
正在加载…
请使用更现代的浏览器并启用 JavaScript 以获得最佳浏览体验。
加载论坛时出错,请强制刷新页面重试。
请教一下聊天消息应该用什么数据库存储?
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 读取也是顺序读,速度不需要担心。
wxf666
b123405060
超过 500w 会怎样? B+ 树从 3 层 变为 4 层?然后由于内存只能完整缓存前两层(前两层代价是 20~30 MB 内存,前三层代价是 20~30 GB ),所以 3 层变为 4 层,会导致实际 IO 由 1 次 变为 2 次,即速度下降 50%?还是怎么个逻辑?数据库新人,求指教
lmshl
接 #35 Cassandra 还支持过期时间 (TTL).
你想存储几个月就存储几个月,过期后不需要手动清理
wxf666
monkeydream
你要并发读多少啊?那个帖子里反馈,MySQL 单表这么多亿,单次查询也能 10- ms 啊(噢,26 楼写错了)
demon1991yl
mongodb 吧,我们的私信、im 消息目前都是存在 monodb 里面的,规模都是上百亿条,而且根据楼主的描述,数据量 2 亿不算多,存 mongo 的话,也方便后续扩展,,而且基本也是一些在线索引查询。ES 、CK 等对于 TP 类业务实时性不一定能保证
demon1991yl
onlyhuiyi
为啥不接 mongodb 了呢,我们挺多业务再用,还有很多 mysql 转过来的呢
onlyhuiyi
demon1991yl
我也不知道为啥,用的人少,不值得安排人来维护吧。
fengjianxinghun
实时查询用 ES ?都是 ppt 架构师?
fengjianxinghun
fengjianxinghun
还是都是个位数并发?
hahasong
肯定用 hbase 我之前就做过这个。消息都是时序写入,hbase 轻松无压力。只有硬盘到位,永久存都行
microxiaoxiao
2 亿条消息也不大吧,直接存内存相关的数据库吧。持久化随便选一个。200000000*1k/1024/1024/1024=190GB 。图片,视频另外存
tt67wq
热 tidb + 冷 hbase
helloxiaofan
MySQL 不行吗,我们之前每天 400w 左右,可以分库分表
shot
建议参考头部玩家的技术选型,比如 Discord 的数据库迁移历程:MongoDB → Cassandra → ScyllaDB
《 How Discord Stores Billions of Messages 》
> In July, we announced 40 million messages a day, in December we announced 100 million, and as of this blog post we are well past 120 million.
> The messages were stored in a MongoDB ……, we reached 100 million stored messages and…… see the expected issues appearing: the data and the index could no longer fit in RAM and latencies started to become unpredictable.
https://discord.com/blog/how-discord-stores-billions-of-messages
《 Discord Chooses ScyllaDB as Its Core Storage Layer 》
https://www.scylladb.com/press-release/discord-chooses-scylla-core-storage-layer/
cp19890714
首先排除 clickhouse 。clickhouse 主要用于 OLAP ,不适合 OLTP 。并发能力很弱,不适合你的场景。
mongodb 分片、写入并发、数据压缩、数据过期自动清理 都挺适合你的场景。数据量 2 亿真不多。
ES 我只是简单使用过,没有太多了解。不过,实时查询好像不是太快,而且服务器成本比 mongodb 高。
cp19890714
cp19890714
不过,如果要做聊天记录查询,那么全文索引又必然是用 ES 了
defage
clickhouse 肯定是不合适的,这种端上的场景不是 clickhouse 的场景。
数据量级一大,要考虑综合做法,不一定是单个存储。 比如 db 分表+hbase 存详情,用户维度的列表从 db 查,详情回表用 hbase 构建出来。
liuhan907
monkeydream
所以你是要做 IM 消息存储和消息本身的检索?那这个 2E 的量基本随便了吧,拿个 pgsql 硬件规格拉高一些单机大概都够。不放心就找一个分布式数据库一把梭。
« 上一页
下一页 »