对一个订单表分片, 分成分布在好几个节点里面每个节点就一个库,库里面就一个订单表类似mysql分区表:
不同点是:分区表是 同一个节点上同一个数据库内建立的
分片是: 分了以后存放在不同的物理节点上
尽量不分片
一个表分不同的节点, 很难
一般不这么干,还是先调sql
更好的应用,数据库设计, 调优
分片后还会变得难以维护
选择[分区键]
分区键: 决定如何分片, 分片后如何查询数据
分区键的选择 直接觉得了分区后的性能
- 尽量避免 跨分片查询,
不可能完全没有, 因为要统计分析 会出现跨分片,
对OLTP应用要尽量避免
- 尽量避免 跨分片查询,
当今的数据处理大致可以分成两大类:
联机事务处理OLTP(on-line transaction processing)、
联机分析处理OLAP(On-Line Analytical Processing)。
OLTP是传统的关系型数据库的主要应用,主要是基本的、日常的事务处理,例如银行交易。
必须分别查询, 再把查询结果合并到一起,性能会比原来不分片都差
比如, 按博客号hash分片, 每个人博客的显示就要跨分片了 ,不如按作者分
- 数据平均,访问平均
如:订单数据库 按用户分片
要注意不要活跃用户都在同个分片
如果每个查询都包含分区键 用hash分区最平价
存储无需分片的表
-
每个分片都存一份
适合数据少,不怎么变的,经常用到的, 又需要关联查询 如字典
这就要维护一致性, 用多写的方式 ,
这样的更新不会在一个事务中, 因此需要对数据进行检查 -
额外的节点 统一存储
不冗余, 也不用维护多分数据
如果分片的表要和它关联查询, 只能分表查询 程序合并
这3个各自的弱点
1.hash: 比较平均,但是难以人为控制哪个数据去哪
2.访问: 知道哪个数据去哪: 可能不平均:数据量,访问量
3.映射表: 一般.这张表压力很大,放内存
如何生成唯一id
-
调整mysql自增步长,auto_increment_increment =分片数 autoincrement_offset
-
全局表,专门生成唯一id,但这个表可能成为性能瓶颈
-
全局表放redis这种缓存
网友评论