数据存储分库分表优化技术

这是一个数据存储分库分表优化技术的思维导图，介绍了数据存储的分类和技术，其中数据存储的技术作了非常细致的介绍。

数据存储

• 分类
  • 持久化
    • rdbms/nosql/newsql
  • 缓存
    • memcache /redis /codis
• 技术
  • 分库分表
    • sharding
      • 分库分表要考虑业务
      • 分
        • 垂直分库 ：用户 /商品/交易
      • 合
        • 库的共享
          • 商品api微服务化
            • 商品库=》商品的写+读两个进程服务，交易库
            • 同一个商品库--两个进程，一读一些
        • DB进程共享：
          • 多库，一个大访问小/一个数据小访问当
            • 合并到一个进程访问
      • 水平分表：某个表数据量过大，例如用户表
        • mysql一张表存多少数据最佳
          • sizeof(row)>100B 1000万条
          • sizeof(row)<100B 5000万条
          • 5亿条，<100B,10张表==》16
        • partitionkey如何选择
          • 查询维度单一
            • 城市/时间/用户唯一标识**
              • 城市分表： 问题，分表后的存储量大小区别过大
              • 时间分表：问题，读写量问题
          • 多维度查询
            • 分析字段是否固定 例如uid/infoid/timestamp
            • uid固定/infoid生成/ uid变化的最后4位 在infoid最后4位设置相同就可以溯源， 基因法
            • uid固定/infoid固定 / 建个 uid<=>infoid的映射表 要注意1对多，还是1对1
              • 映射表也需要分表
            • timestamp==》看业务需求，如果是统计，实时要求不高，16个表查询都能接受 离线统计需求
            • timestamp 例如iphonex 哪个时间段的数量 区分数据库需求和 搜索引擎需求
      • 使用的组建
        • ORM MyBatis 3
        • Sharding-JDBC/Sphere
        • Merge /result merge
        • DataBase Connectiong Pool /DBCP (apache)
        • 连接池dbcp/c3p0/druid
        • 分表是多个表，表分区是一个表，oracle内部实现表分区
        • 分库分表 mycat不建议用，坑多 ，建议用Sharding-db
        • 分布式id生成器：snowflake雪花
    • 架构升级：db拆分架构+加入缓存cashe
    • 硬件升级：sas->ssd（pcie) 值得
    • 问题：跨数据库事务
    • 读写分离：分表 /应用层/写的时候，缓存也要delete
      • id查询，可以hash分表
      • 问题：非partitionkey问题，例如name查询就得遍历
    • sharding-jdbc:sphere
    • mysql Proxy +DB Proxy
      • 缺陷：db弱化为存储/跨db难事务/SQL聚合，join，子查询限制/实现全局id
      • 业务妥协
        • Partition key选择
          • 留言表多个查询维度
        • 业务多维度查询
          • 数据冗余
          • 数据强一致性难保证
        • 数据复制
          • 同步双写
          • 异步复制
      • 架构成本
        • 高可用扩展问题
          • MGR,PXC都各自问题
          • MHA 时间切换成本
        • 弹性再扩容成本大 128==》256，很难做
        • 全局基于时间点GID的恢复成本
      • 资源成本
        • 分少再扩容，分多浪费
        • 运维成本
          • Online DDL（改，改结构） /自动化运维成本高
        • OLTP/OLAP需要双份资源
          • 组建：FLume/Kafka/Spark/Hardoop
          • 人力成本高
          • 升级：HTAP 例如tidb
  • 优化
    • 架构层面/业务层面/schema层面/ 部署优化/sql层/索引层
      • 影响性能的因素
        • 业务需求，不合理的需求
          • 例如 论坛发帖的实时更新数
          • 深度翻页（冷数据，内存有限的情况下，加载到内存，而热数据被丢了swap）
          • 不断的需求升级，造成系统复杂，影响整体性能
        • 无用功能堆积
          • kpi需求，性能低下==》做减法
        • 过度重视用户体验
          • 非核心业务消耗过多数据资源
        • 数据库存放数据不合理，例如多媒体数据，超大文本数据
          • ceph/fastdns
        • 大表拆分
          • 水平拆分
        • 是否合理利用Cache机制
        • 数据层的实现是否最精简
          • 循环查询 用in,
        • 过度依赖数据库Query语句，效率低下
        • 对扩展性过度追求，导致对象拆分过于离散
        • 重复执行相同query
          • 缓存
    • 数据库设计阶段优化
      • 适度冗余，减少join
        • 用户名修改不频繁的情况下，联表查询改成单表查询
      • 大字段垂直拆分
        • 减少io访问（部分不需要查，拆分减少io）
  • 高可用设计方案
  • nosql:mongodb hbase 对事物要求不高 2008-2013
  • newsql：
    • spanner：有状态分布式 存储 +F1:无状态分布式 解析器
    • tidb 2013-- 可扩容分布式+支持事务
      • 基于rockdb
  • 数据库迁移
  • 缓存一致性问题
  • 子主题