是一种水平切分相关的数据库架构
是无共享架构,是自治的
在应用程序级别进行实现
可以帮助促进水平扩展
以分散负载,允许更多的流量和更快的处理
加速查询响应的时间
通过减少宕机的影响,使得应用程序更稳定可靠
-
-
用户必须跨多个分片位置管理数据,可能会让某些团队存在工作混乱
-
分片最终会导致数据热点,要修复和重新分片才能实现更均匀的数据分布
-
一旦对数据库进行了分片,就很难将其恢复到未分片的架构
-
将需要经常查询的键作为主键并作为hash对象,根据hash后的值取模,存储到不同的片中.
Range Based Sharding 基于范围的分片
基于范围的分片的主要好处是，它实现起来相对简单。每个分片都包含一组不同的数据，但它们都具有相同的模式，以及原始数据库。应用程序代码只读取数据所属的范围，并将其写入相应的分片。
另一方面，基于范围的分片并不能预防数据不均匀分布的现象，而有可能会出现前面提到的数据热点现象。查看示例图，即使每个分片拥有相同数量的数据，特定产品比其他产品获得更多关注的可能性也会很大。相应的，各个的分片将接收不成比例的读取操作。
个人理解:
更适合按照时间,将范围分开,便于数据的查找
Directory Based Sharding 基于目录的分片
此处，Delivery Zone列被定义为分片键。将来自分片键的数据，连同每一行应该写入的分片写入查找表。这与基于范围的分片类似，但不是确定分片键的数据落入哪个范围，而是将每个键绑定到其自己的特定分片。如果分片键的基数很低，并且分片键存储键的范围没有意义，那么基于目录的分片比基于范围的分片要更好。请注意，它也不同于基于密钥的分片，因为它不通过散列函数处理分片键; 它只是根据查找表检查键值，以查看数据需要写入的位置。
基于目录的分片的主要吸引力在于其灵活性。基于范围的分片架构只能指定键值范围，而基于键的分片架构只能使用固定的哈希函数，如前所述，在以后更改该函数非常困难。另一方面，基于目录的分片允许您使用任何系统或算法将数据项分配给分片，使用这种方法动态添加分片也相对容易。
虽然基于目录的分片是这里讨论的最灵活的分片方法，但是在每次查询或写入之前连接到查找表，可能会对应用程序的性能产生不利影响。此外，查找表可能出现单点故障：如果查询表损坏或出现其他故障，它可能会影响数据库写入新数据或访问现有数据的能力。
需要创建第三张表来确定两者之间的关系,和基于范围分片的类似,选取一列作为分片键,每一行都不确定的分配到不同的范围中.
什么情况下需要分片
-
应用程序增涨到超过单个数据库节点的存储容量
-
对数据库的读写量,超过单个节点或只读副本可以处理的量,从而导致响应时间增加或超时
-
应用程序所需的网络带宽,超过单个数据库节点和任何只读副本可用的带宽,从而导致响应时间增加或超时
操作分片前 要优化的数据库项
-
设置远程数据库
-
实现缓存
-
创建一个或多个只读副本
-
升级到更大的服务器