Sharding
Horizontal Partitioning 当你剥离了用于装扮Sharding
许多美妙修饰的后
你会发现Sharding并不是什么新或高深东西它几乎等同于我们常说Horizontal Partitioning(水平切分)
我们可以认为他们就是同
个概念毕竟两个术语都没有确定严格定义区分反而容易把我们绕晕了 Sharding是
个非常规DB设计思路方法 那么正统
思路方法是什么？我们平常规规矩矩用基本都是平常我们会自觉按照范式来设计我们数据库负载高点可能考虑使用相关Replication机制来提高读写吞吐和性能这可能已经可以满足很多需求但这套机制自身缺陷还是比较显而易见首先它有效很依赖于读操作比例Master往往会成为瓶颈所在写操作需要顺序排队来执行过载话Master首先扛不住Slaves数据同步延迟也可能比较大而且会大大耗费CPU计算能力
write操作在Master上执行以后还是需要在每台slave机器上都跑次这时候Sharding可能会成为鸡肋了 Replication搞不定
那么为什么Sharding可以work呢？道理很简单它可以很好scale我们知道每台机器无论配置多么好它都有自身物理上限所以当我们应用已经能触及或远远超出单台机器某个上限时候我们惟有寻找别机器帮助或者继续升级我们硬件但常见方案还是横向Scale, 通过添加更多机器来共同承担压力我们还得考虑当我们业务逻辑不断增长我们机器能不能通过线性增长就能满足需求？Sharding可以轻松将计算存储I/O并行分发到多台机器上这样可以充分利用多台机器各种处理能力同时可以避免单点失败提供系统可用性进行很好
隔离 如何Sharding?
这里可以借鉴MySql partition设计
思想MySql partition可以算是物理存储层面sharding了在某些场景可能适合但是自身有明显缺点虽然我们可以把数据库存储放到SAN等存储网络上但是还是受到单台机器计算能力等限制业界更多是考虑根据自身业务逻辑来进行手工切分这样效果可能更好可以进行细腻度控制切分尽量做到每个分片(Shards)都能够很好独立彼此的间交互要尽量少使得个请求尽量通过个分片中就能提供服务 你可以根据
个KEY或范围来进行切分这些key往往是个确定小集合体例如大众点评网可以考虑将它每个大城市数据放在个单独数据库里而些小城市可以根据某些规则放在个数据库里这里思想和我在做个Lucene索引时碰到问题很相似这里用Lucene实际上算是数据库文本匹配查询个拓展模块当时有大概 7 8百万条数据要做index,如果做在个目录下面查询性能和index速度都很有问题我就考虑让每个城市索引结果放在单独目录下最后我index速度基本上可以达到每秒千左右个文档了也可容易地扩展成分布式搜索还遇到个地图应用我以前也大概谈到过这次切分<<.Net架构网站WebSite遇到大表该如何办？ >>在这个应用里我是根据数据经纬度坐标范围物理空间特性来进行切分主要切分区域是砍掉了中国地图鸡头鸡尾几个部分后剩下区域对这里面区域进行了进步细分像上海北京深圳几个地方进行更深层次切分这样切分以后我就可以像平常操作基本表那样来动这个大表了切分过后大部分应用请求也仅仅会涉及到个表边界条件或者其它业务需求才会并发操作多个表还可能有些应用你可以通过日期来切分例如0708年每年订单分拆成单独数据库更牛可能用个hash
思想也很容易理解不过选择好hash倒是不大容易你要想办法把数据划分均匀了具体可能还有很多细节需要考虑特别是对于某个shard过载如何进步对他进行切分但又不违反已有规则等等 Sharding小结
优点:
l High Availability
l 每个Shard里面维护着常见规模行数
数据这样容易操作管理备份 l 更高
读操作速度和并发量 l 提高写
throughput和性能,消除了很多潜在write bottleneck l 读写速度都快了
并发也大了当然可以承担更多用户更多负载了也就可以挣更多$了 l ……
缺点:
l 反范式导致潜在数据不
致风险 l 某些shard里
数据更新可能会使得操作很麻烦更新可能导致应当划分到新shard中你就需要删除原来shard中数据在新shard中加上条还有很多致性问题 l 重新切分某个Shard可能会很麻烦,可能会破坏你很多
已有设计 l 缺乏统
产品存在定项目风险 l Sharding会设计到跨多台机器
多个表所以统计分析等操作需要自己实现相应功能备份还原也相对比较麻烦 l ……
最新评论