保存成功
订阅成功
保存失败,请重试
提交成功
58沈剑

58沈剑

互联网架构师
“架构师之路”公众号作者,58到家高级总监,技术委员会主席。前百度高工,58同城高架,技委主席。...更多
创作文章10

后语:除了水平切分,数据库架构设计还经常遇到哪些问题

这是一个总结,在互联网数据库架构设计中,除了遇到水平切分类问题,还会遇到可用性、读性能、一致性、SQL等众多问题,这些问题的解决思路是什么,且听后文分解。
严选数据库
1549 订阅

从订单中心开始,聊“多KEY”类业务数据库水平切分架构实践

有一类“多KEY”特征的业务,典型代表是“订单中心”,业务查询维度会覆盖`order_id/buyer_id/seller_id`,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对订单中心业务进行水平切分是本章的重点: 1. “多KEY”类业务的特点与场景。 2. “多KEY”类业务如何进行水平切分核心指导思想。 3. “多KEY”类业务水平切分后遇到的潜在问题(最典型的问题->通过`order_id`来切分,`buyer_id/seller_id`上的查询怎么办?)。 4. “多KEY”类业务水平切分最佳实践。 **实录提要:** - 两种方案的综合方案,能具体说下这个方案的具体玩法吗? - 单日 5000 万的 Log 可以设计在 MySQL 里吗? - 若是已在线使用的业务系统中的“多 key ”表应该如何着手进行拆分? - 多库的分页和数量 count 统计,如何做是每个库进行统计和查询? - 用客户端分库分表与服务器端分库分表各有什么好处,怎么选型? - 最终一致性有什么好的中间件软件吗?算法自己实现起来要花很多时间吗?
严选数据库
1054 订阅

从好友关系开始,聊“多对多”类业务数据库水平切分架构实践

有一类“多对多”特征的业务,典型代表是“好友关系”,1个用户能加多个好友,1个用户又能被多个人反加好友,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对好友关系业务进行水平切分是本章的重点: 1. “多对多”类业务的特点与场景。 2. “多对多”类业务如何进行水平切分核心指导思想。 3. “多对多”类业务水平切分后遇到的潜在问题(最典型的问题->通过user_id来切分,friend_id上的查询怎么办?)。 4. “多对多”类业务水平切分最佳实践。 **实录提要:** - 类似用户表、权限表、部门表,做微服务需要做冗余吗? - 做冗余的目的是为了解决数据量大时候的查询性能? - 多对多关系除了冗余数据,还有其他处理办法吗? - 分布式开发,多对多数据,如何封装可用的 API?加密解密的安全性怎么办? - 现在 58 到家内部是用自己开发的 rpc,还是用 springcloud+springboot? - 信息脱敏在 58 是如何设计的?
严选数据库
982 订阅

从帖子中心开始,聊“1对多”类业务数据库水平切分架构实践

有一类“1对多”特征的业务,典型代表是“帖子中心”,1个帖子对应1个发布用户,1个发布用户能够发布多个帖子,这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对帖子中心业务进行水平切分是本章的重点: 1. “1对多”类业务的特点与场景。 2. “1对多”类业务如何进行水平切分核心指导思想。 3. “1对多”类业务水平切分后遇到的潜在问题(最典型的问题->通过tiezi_id来切分,user_id上的查询怎么办?)。 4. “1对多”类业务水平切分最佳实践。 **实录提要:** - 有一类典型操作是列表页操作,这个过程是怎样的?对分库分表策略有什么影响? - 元数据是什么意思,是数据库的基础数据?还是指的是注解编程模式? - 数据库要分片前期的准备工作是什么,怎么区分这表要分片? - 文章中的库对于不同的数据库软件分别是指什么? - 分布式事务如何处理? - 分库分表在微服务模式下怎么配合使用?
严选数据库
958 订阅

从用户中心开始,聊“单KEY”类业务数据库水平切分架构实践

有一类“单KEY”特征的业务,典型代表是“用户中心”这个业务场景,随着用户数据量越来越大,数据库性能显著降低,如何来对用户中心业务进行水平切分是场Chat的重点: 1. “单KEY”类业务的特点与场景。 2. “单KEY”类业务如何进行水平切分核心指导思想。 3. “单KEY”类业务水平切分后遇到的潜在问题(最典型的问题->通过user_id来切分,user_name上的查询怎么办?)。 4. “单KEY”类业务水平切分最佳实践。
严选数据库
982 订阅

前言:数据库典型架构实践

这是一个引子,在互联网数据库架构设计中,水平切分技术相关的概念与释疑:什么是水平切分,垂直切分,什么是分组,什么是分片,什么是路由规则,有哪些常见的路由规则,各自的优缺点是什么,水平切分的方法论,经常遇到的困难是什么,为后续的四场做一个铺垫。 覆盖90%互联网业务特性的四类业务,用户中心(“单KEY”类业务),帖子中心(“1对多”类业务),好友关系(“多对多”类业务),订单中心(“多KEY”类业务)分别如何实施水平切分。
严选数据库
1646 订阅

互联网“平滑数据迁移”架构技术实践

互联网架构,很多时候面临这样的需求: 1. 几千万的数据表结构变更。 2. 水平拆分成3库,要进一步拆分成5库。 3. 底层存储切换,MongoDB 换成 MySQL。 种种需求,都需要进行数据迁移,如何平滑迁移数据,迁移过程不停机,保证系统持续服务,是本场 Chat 将要讨论的问题。 **实录提要:** - 双写写新库的时候是同步写还是交给 MQ 之类的异步写? - 平滑数据迁移,核心代码会有侵入吗? - MySQL 的分区表是什么? - MySQL 在表 DDL 变更时长与表数量级,有没有一个合适的比例? - 58 这边 MySQL 最高单表数据量可以到多少? - 分库后,有做数据归档吗?还是一直水平扩展? - 说一下 rpc 链路监控,日志这一块呢,有序性如何解决? - 58 生产环境上,唯一性 ID 的生成用的是什么方案? ------ **往期回顾:[互联网数据库“跨库分页”架构技术实践](http://gitbook.cn/m/mazi/activity/5896c2e7f2b669527d7a7c8a)**
严选
324 订阅

互联网数据库“跨库分页”架构技术实践

1. 如何实现数据“分页”。 2. 数据量过大,分库后,“跨库分页”存在什么问题。 3. 常见“跨库分页”架构优化方案。 4. 价值年薪50w的“跨库分页”无损方案。 **实录提要:** - 目前准备做数据库水平切分,需要注意什么关键问题? - 可以通过搜索引擎解决分页的问题吗? - 这些分页方案的性能有多大差距? - 如果分库分表的情况下碰到要对一个表或多个表关联并且按多个字段为条件进行检索的情况下怎么办呢? - 据说 mycat 可以解决分库的 join 问题,就是不知道性能如何? - 单表多大数据量时才考虑分库分表?
严选数据库
667 订阅

互联网高并发架构技术实践

这是我在GitChat上发布的第二个话题,第一场Chat关于“高可用”,大伙可以直接查阅,第二场关于“高并发”,主要应读者要求撰写。常见互联网高并发站点架构,分为反向代理层、站点层、服务层、数据层(固化存储db层,内存存储cache层),各层如何保证架构高并发,以及常见的高并发架构技术,是本主题将要讨论的内容。 **实录提要:** - 在服务的水平扩展这一块,是否有成熟的自动伸缩方案可以参考? - 作为产品经理该以何种姿势提需求更为合理呢? - 分布式锁一般怎么选?MQ 的选型以及依据,有案例更好? - 混合式数据库各自得分工是什么? - 从库同步主库延时一般怎么处理? - 在高并发中队列可以发挥一些作用吗? - 关于用户表的水平切分, 有什么比较好的实现方式么?
严选
332 订阅

互联网高可用架构技术实践

常见大数据量,高并发站点架构,分为反向代理层,站点层,服务层,数据层(固化存储db层,内存存储cache层),各层如何保证架构高可用,以及常见的高可用架构技术,是本主题将要讨论的内容。 **实录提要:** - 如果不允许 cache miss 的 case 下怎么做 rehash 且尽可能少脏数据? - 如何避免服务挂掉之后,rpc client 在转移 server 的时候导致集群中的惊群效应? - 58 到家在灰度发布和 A/B 是怎么样的一个落地方案? - 58 消息中间件是基于什么技术(什么开源产品)? - 关于缓存和数据库分布式后,重新分区后的数据迁移是否有好的方案? - 云环境下数据库高可用怎么做?没有 vip 怎么做? - 分布式系统里面唯一全局 ID 的生成规则有什么好的方式么? - 58 的服务降级如何做的?
严选
387 订阅
微信扫描登录