海量数据存储基础

• 适合存储结构化数据

• 查询语言SQL，insert delete update select

• 主流关系型数据库多是持久化存储系统，系统性能与机器性能相关性较大

• 几类主流的 关系型数据库

• • MySQL

  • Oracle

  • DB2

  • SQL Server

• 性能

• • 局限于服务器性能，与其是磁盘性能

  • 局限于数据复杂度

  • 常见的SSD磁盘服务器，单机读取性能可达万级/s

    大型互联网服务大多采用MySQL进行作为关系型数据库，微博平台的核心业务(如微博内容用户微博列表)也同样如此

        本次培训也会着重介绍MySQL及其分布式架构方案。

• 存储非结构化数据、半结构化数据

• 性能

    业界使用的NoSQL多为内存集中型服务，受限于I/O及网络，通常请求响应时间在毫秒级别，单机QPS在10万级别(与数据大小及存储复杂度相关)

• 常见的几类NoSQL产品

   web2.0时代，NoSQL产品在互联网行业中的重要性随着互联网及移动互联网的发展而与日剧增       大型互联网应用， 为应对大规模、高并发访问，大多都引入了NoSQL产品，其中Memcached、Redis以其高成熟度、高性能、高稳定性而被广泛使用。微博平台也具 备千台规模的NoSQL集群，微博核心的Feed业务、关系业务也都依赖Memcached及Redis提供高性能服务

  本次培训，会着重介绍Redis及其分布式架构

• MySQL是一个关系型数据库系统RDBMS

• 使用SQL作为查询语言

• 开源

• 存储引擎

• 满足ACID特性

• 主键、唯一键、外键(大规模系统一般不用)

• Transaction，事务即一系列操作，要么完全地执行，要么完全地不执行

• 服务、端口、实例，都是指 服务端启动的一个MySQL数据库

• 性能

• 

• 业务上线初期，web服务规模较小，一般具备以下特点

• • 服务原型时期,用户基数小,多种业务公用资源,日均写入百万级别,读取千万级别

  • 数据规模小，单机性能能够满足需求

  • 用户规模小，开发重心偏向迭代速度

    考虑到上述小型业务特点，为节约资源成本及开发成本，可以采用多个业务混合部署形式

    

• 当用户增多，数据量、访问量升高(2倍以下)，数据库压力较大，怎样在有限程度提高MySQL吞吐量呢？

• • SQL优化

  • 硬件升级

  压力还在有限的范围内增长，通过简单、低成本优化，可以一定成都上提高有限的服务性能

• 业务持续发展，读取性能出现瓶颈&&各业务互相影响，多个业务出      现资源抢占，如何快速解决业务抢占问题以提高服务性能？

• • 垂直拆分——按业务进行数据拆分

    

          按业务进行拆分，以使业务隔离，timeline的压力增加，不会影响content数据库服务性能；进行拆分后，资源增加，服务性能也相应提升。

• 随着业务的继续发展，读取性能出现瓶颈,读写互相影响，如何确保读请求量的增加，不要影响写入性能？相反写入请求量增加如何确保不影响读取性能？(写入性能出现问题会造成数据丢失)

• 一台/一对M-S服务器性能终归是很有限的，当单实例服务性能无法承载线上的请求量时，如何进行优化？

• • 升级为一主多从架构

  • 一个master承载所有写入请求，理论上master性能不变

  • 多个slave分担读取请求，读取性能提升n倍

    

• 随着业务量的增长，服务出现如下变化：

        业务经历数据量的增长、读写请求量的增长，数据库服务已经演进为分布式架构，一个业务的数据，怎样合理的分布到上述复杂的分布式数据库是下一个需要解决的问题

• 分布式数据库设计

• 逻辑库设计

• • 逻辑库是相对与物理库而言的概念：物理库只数据库服务的实例；逻辑库指在一个数据库实例上创建的多个database

  • 定义逻辑库的目的是便于扩容。假如4台数据库服务器，每台上的物理库包含8个逻辑库，当系统出现容量、写入量瓶颈时，可以新增一倍即4台服务器，直接以同步方式同步数据库，而不需要单独编写应用程序利用进行导入

    

• hash拆分方式：按hash规则将一个数据库的数据，分散hash到多张表中

• 

  • 适合数据规模有限的数据集

  • 适合增长速度可控的数据集

  结合数据库的hash模型如图：

  

  • 根据uid hash到uid所在到数据库，然后再hash到数据库_1下的tb_5表

• 按时间拆分方式，按时间规则将同一时段的数据存储在一张表，多个时段时间存储在多张表。例如按月划分，每个月表存储一个月的数据，如果需要获取全部数据需要跨越多个月表

• 

  • 适合存储增速较快的数据集

  • 但查询数据需要跨越多个时间段的表

  结合数据库的hash模型如图：

  

  • 根据uid hash到所在的数据库db_1，然后再查找201507 201506获取两个月的数据

  思考一个问题：如何能够快速定位，一个人的第1000条到1100条数据呢？

• 二级索引快速定位(一级)索引位置

• • 描述数据在以及索引中的分布状况

  • 用于快速定位/缩小查询范围

  • 一般情况字段列表：uid, date_time, min_id, count

  • 

• Slave(一主多从)宕机？

  • 剩余健康Slave无风险，则无需紧急操作，例行修复

  • 切换流量到容灾机房(如果具备容灾机房)

  • 紧急扩容[优先]、重启、替换

  • 有损降级部分请求

• Master宕机？

• 由于master数据的唯一性，致使master出现异常会直接造成数据写入失败

  

• • 快速下线master

  • 下线一台salve的读服务(如果slave性能有风险，则同时快速扩容)

  • 提升slave为master

  • 生效新master与slave的同步机制

  多数使用分布式数据库服务的团队，都有各自实现的数据库Client组件，微博平台采用如下几个层级的组建来进行分布式数据库操作

• 获取TableContainer，获取所有表定义规则

• 通过table name从TableContainer中获取指定的TableItem

• TableItem关联多个JdbcTeplate－DataSource

• 通过TableItem结合uid、id、date获取经过hash计算得到正确的JdbcTemplate及SQL

• 使用JdbcTemplate进行SQL操作

• MySQL设计应该注意的问题

  • 表字符集选择UTF8

  • 存储引擎使用InnoDB

  • 使用Varchar/Varbinary存储变长字符串

  • 不在数据库中存储图片、文件等

  • 每张表数据量控制在20000W以下

  • 提前对业务做好垂直拆分

• MySQL查询应该遇到的问题

• • 避免使用存储过程、触发器、函数等

  • • 让数据库做最擅长的事

    • 降低业务耦合度避开服务端BUG

  • 避免使用大表的JOIN

  • • MySQL最擅长的是单表的主键/索引查询

    • JOIN消耗较多内存,产生临时表

  • 避免在数据库中进行数学运算

  • • MySQL不擅长数学运算

    • 无法使用索引

  • 减少与数据库的交互次数

  • • select条件查询要利用索引

    • 同一字段的条件判定要用in而不要用or

• 设计一个每秒2000qps，1亿条数据的用户基本信息存储数据库。完成数据库设计，数据库搭建，web写入查询服务搭建。

• 定义用户信息结构：uid，name，age，gender

  

• 给定2个mysql实例，每个实例创建2个数据库

• 每个数据库创建2长表

• 编写代码，以hash形式，实现对数据库、表的数据操作

• Redis是一个支持内存存储及持久化存储的K-V存储系统

• 支持复杂数据结构，相比与Memcached仅支持简单的key-value存储，Redis原生支持几类常用的存储结构，例如

• • hash：存储哈希结构数据

  • list：存储列表数据

• 单线程

• 原生支持Master-Slave

• 过期机制

• Redis的字典表结构

• • 

  • Key字典表hash table结构，有hash结构就意味着需要按需进行rehash，rehash的时间段内，对内存是有成倍开销的

  • Value结构，存储Key对应的value

  • Expire表结构，存储key的过期时间

  • 额外开销60B+

  • 持久化方式

  • • AOF

    • Snapshot——RDB文件快照

• 与MC的差异

  

• 平台的定制CounterService

• • 修改hash table为，增量扩展式的hash tables，例如每1亿个key存储在一个table中，数据超过1亿(或者一个临界比例)则开辟下一个1亿空间的table

  • 废弃expire，Redis的主动过期策略无法像MC的LRU策略确保热数据留存在内存中，冷数据从缓存剔除，我们多数场景需要控制Redis中的数据量不突破内存限制

• String (key－value)

• Hash (key－field－value)

• List(key－values)

• Set(key－members)

• SortedSet(key－member－score)

• Reids由于其M-S特性与MySQL类似，因此分布式部署方案同MySQL相当

• 单实例——小型业务 or 业务初期

• 主从——HA、读写分离

• 一主多从——读取性能出现瓶颈

• 数据水平拆分——容量不足｜写入性能瓶颈

• 常用的分布式部署方案

  

• 采用M-S高可用方案，原因也式由于其Master-Slave的特性

• 服务域名化是必要的，目前大型的Redis集群应用大多采用域名方式

• 空间＝key数量＊单条占用(K-V占用＋额外空间) 用户空间＝5亿用户＊200B(平均)＝100G 微博计数器＝(500亿+预期2年新增300亿)＊10B＝800G

• 访问量＝服务访问量＊单次访问对资源的hit量 微博计数器Feed访问量＝10000/s * 20 ＝ 20万/s

• 优化存储空间

• 采用分段哈希桶的形式，进行存储，避免rehash (分段存储要求key为递增序)

  

• 空间占用优化效果

• key：8B

• value：自定义

• Reids具有多个开源的client支持，我们所使用的是Jedis

• Jedis除了提供client外，还提供了操作封装以及M-S组件

• 我们所使用的Redis系列组件如下：

  

• 使用Redis，实现用户受到的赞列表及赞计数功能

• 使用测试环境，启动两个Redis实例

• 使用Redis存储用户受到的赞列表[{uid, time}..]及赞计数uid-count

• 完成赞操作业务逻辑，包括赞、取消赞、查看赞列表、查看赞计数

• Redis满了会发生什么？如何避免发生上述问题呢？

• 为什么我们的定制Redis会废弃expire表？

• 数据冷热？

• 数据大小？

• 数据量级？

• 数据增长速度？

• 是否持久化？

• 访问量(read/write)？

• 请求性能要求？