58同城数据库架构实践
- 58同城数据库架构实践
- 关于数据库软件架构设计思路的分享，包括数据库架构设计如何保证可用性，如何提升读性能，如何保证数据一致性，如何保证高扩展性，以及大数据量下SQL的玩法。
- 分享中包含大量58同城数据库架构设计的实践。
- 主讲：沈剑，58同城高级架构师，技术委员会主席
- 时间：2015年9月13，上午10:00-11:00
- 地点：在线交流，会议网址报名接收后通知
- 费用：免费
- 限制人数：100人
f
分区表只是在单机sharding，而数据量大需要多机sharding
sharding 99%都是水平sharding ，无论是下面哪一种sharding方法
路由分组方法
1、range ： 简单，新注册的用户更活跃 如果旧注册的用户不活跃 导致负载不均衡 加范围加分组 扩展简单
2、hash ：l例如用户id uid取模 不能加范围加分组需要数据迁移 扩展困难，但是可以做到负载均衡，互联网公司多数用这种
3、上面两种的综合
分布式环境生成唯一ID 主键生成器：snowflake，autoincrement_id的缺点
58同城只用双主
主从其实可以建立不同的索引，主库可以不建索引，只在从库建索引，大部分人认为主从索引要一致
缓存双淘汰：
1、写请求立即淘汰缓存
2、不命中淘汰缓存
58同城sharding取模数据无交集，不需要迁移数据，秒级扩容，1-》2 ，2-》4，4-》8
倒库（导数据）秘诀：限速，每次导1000条，sleep xx秒 不能一次全部select出来不然旧库会容易挂掉，因为不需要停服，那么导数据时间长也无所谓
不用pt_online_schema_change的原因 核心是限速，可以回滚， 回滚速度快，毕竟是一个大的事务
记录写日志的方法：只需要记录有更改的主键key，比如id字段，在新库delete的记录，然后select，insert回去新库
字段扩容方法：
不要用alter table
1、追日志法：需要写3个小程序，记录日志程序，倒库程序，数据校验程序 （sqlserver发布订阅已经实现了记录日志程序，倒库程序，但是不能异构表）
sqlserver发布订阅不能对异构表发布订阅，但是我觉得应该可以修改存储过程，把记录到日志记录到一个中间表，倒数据，追日志，数据校验，切表
2、双写发：mongodb和mysql同时写，最后切库
两种方法的扩容优点：可以回滚，无论追日志法还是双写法，只要不切库中途有问题都可以随时回滚，重头做
58沈剑:uid uint64_t
58沈剑:uid long long
58沈剑:uid 64bit
随风:这个方法也很不错
58沈剑:uid 的最后2个bit，放到tid中去
大旧:嗯嗯，经验之谈
随风:呵呵
Maelk-liu:哈哈
Maelk-liu:数学技巧
全文检索倒排索引 ，反向cache，username-》主键id 在数据库的非聚集索引，可不可以拿出来放在cache里，例如memcached
key-value：主键id -》username
key-value：username-》主键id
冗余：必定会带来一致性问题
对比两边数据一致性：
1、扫binlog而不是扫全表数据
2、消息队列MQ
主键生成器 64bit long 主键id切分
58沈剑:10bit 机器号，机架号，机房id
阳光:拆分只能依据单个字段来拆的么，没有多个字段结合的？
58沈剑:12bit，同一个毫秒内多个id号
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
f
