数据库sharding（scale up to scale out）
sharding是将一个大数据库按照一定规则拆分成多个小数据库的一门技术.
当我们的应用数据量越来越多，访问量越来越大的时候，我们会作何选择？继续提升数据库服务器的性能还是采用一项技术让数据库平滑扩展？虽然伴随着服务器的更新换代，性能越来越好，更换更加豪华的服务器能暂时解决这个问题，但是无论是从花费和可控都无法让人满意。这时数据库sharding是一个更加可行的方案。
常用的sharding方案有以下几种，
1。按功能划分（垂直切分）
将不同功能相关的表放到不同的数据库中，譬如将用户管理相关表放到shard 1上，将blog相关表放到shard 2上。。。这样做的好处是非常直观，当需要用户列表时，我就到shard 1上获取。。。。这样也有一个问题，当某一部分的功能其数据量或性能要求超出了可控的范围，我们就需要继续对其进行深入的sharding。
2。按表中某一字段值的范围划分（水平切分）
当伴随着某一个表的数据量越来越大，以至于不能承受的时候，就需要对她进行进一步的切分。一种选择是根据key的范围来做切分，譬如userID为1-10000的放到shard 10上，userID为10000到20000的放到shanrd 11上。。。这样的扩展就是可预见的。另一种是根据某一字段值得来划分，譬如根据用户名的首字母，如果是a-d，就属于shard 20，e-h就属于shard 21。。。这样做也存在不均衡性，当某个范围超出了shard所能承受的范围就需要继续切分。还有按日期切分等等，
3。基于hash的切分
类似于memcached的key hash算法，一开始确定切分数据库的个数，通过hash取模来决定使用哪台shard。这种方法能够平均的来分配数据，但是伴随着数据量的增大，需要进行扩展的时候，这种方式无法做到在线扩容。每增加节点的时候，就需要对hash算法重新运算，数据需要重新割接。
4。基于路由表的切分
前面的几种方式都是跟据应用的数据来决定操作的shard，基于路由表的切分是一种更加松散的方法。它单独维护一张路由表，根据用户的某一属性来查找路由表决定使用哪个shard，这种方式是一种更加通用的方案。譬如我们在系统中维护一张表-（用户所属省-〉shard），这样每个用户我们知道是哪个省的，去路由表查找，就知道它所在的shard。因为每次数据操作的时候都需要进行路由的查找，所以将这些内容存储到一台独立cache上是一个非常好的方式，譬如memcached。这种切分的方式同时也带来了另一个好处，当需要增加shard的时候，可以在不影响在线应用的情况下来执行，当然这也跟应用程序的架构设计相关，你的设计必须适用这种增加。
最新文章
- VS2015 编译 Qwt6.1.3
- 关于eclipse保存代码很慢,提示the user operation is waiting的问题
- guava之Joiner 和 Splitter
- eclipse安装spring插件
- Atitit. Atiposter 发帖机 新特性 poster new feature   v7 q39
- java加解密操作过程中的中文乱码问题
- Java通过Executors提供四种线程池
- SQL学习笔记——SQL初入门，Ubuntu下MySQL的安装
- jQuery中的DOM操作总结
- 【异常处理】java.lang.NoClassDefFoundError
- 解决alaert.builder二次调用报错的bug
- 关于使用Xcode9.0使用[UIImage imageNamed:]返回null的问题
- Spring 学习笔记 Bean的作用域
- Windows密钥容器和证书的关系
- WPF中定时器与进度条的配合使用
- Android精通之Handler讲解
- 深度学习环境配置:Ubuntu16.04安装GTX1080Ti+CUDA9.0+cuDNN7.0完整安装教程（多链接多参考文章）
- iptables防火墙详解（一）
- PLSQL Developer连接Oracle
- [No0000136]6个重要的.NET概念:栈,堆,值类型,引用类型,装箱,拆箱