这是我参与「第三届青训营 -后端场」笔记创作活动的第二篇笔记
一、前言
由于我们小组项目选择了搜索引擎，涉及到一亿数据量的存储，因此需要考虑如果存储这海量数据。
二、MySQL测试
平时MySQL使用得比较多，因此先考虑使用MySQL的方案，单表插入五百万数据，花了两个多小时
进行查询，走索引0.03s左右
不走索引，全表扫描2s多
三、分表问题
对于关系型数据库MySQL来说，存储1亿数据想要提升性能就得分库分表了，而分库分表主要会带来以下问题：
1、ID问题：自增主键可能重复、用完等，分库分表需要有一个全局唯一ID来标识一条数据，即分布式ID
2、事务问题：分库分表后就成了分布式事务了。如果依赖数据库本身的分布式事务管理功能去执行事务，将付出高昂的性能代价； 如果由应用程序去形成程序逻辑上的事务，又会造成编程方面的负担
3、跨库join、count、聚合、排序等问题
针对项目需求，主要解决id问题，可采取的方案有：
- 基于UUID：UUID有着全球唯一的特性。但不具备趋势自增特性，主键过长
- 基于Mysql自增ID：需要一个ID的时候，向表中插入一条记录返回主键ID。但访问量激增时MySQL本身就是系统的瓶颈
- 基于Mysql集群：多个数据库分步生成ID。但难以扩容
- 基于Mysql号段：从数据库选出一个号段范围批量获取自增ID。采用版本号version乐观锁方式更新
- 基于Redis：利用redis的incr命令实现ID的原子性自增。需考虑redis持久化的问题
- 基于雪花算法(Snowflake)：Long类型的ID，占8个字节
后续：项目没有采用MySQL方案，用到了雪花算法生成唯一id，不过探索的过程中也学习到不少知识。
