数据存储的发展历程

记录一次学习总结——数据存储的发展历程

文件存储

早期一般都是文件存储，存在磁盘上，磁盘的读写是线性的、速度在毫秒级别，所以随着数据量的增大，会越来越慢，它的瓶颈在于磁盘。文件存储分为顺序读写与随机读写

• 顺序读写：属于线性O(n)，它的速度随着数据量的增大，会越来越慢
• 随机读写：它的速度相当慢，可能也就在kb级别

数据库

介于文件存储的问题，引入了数据库，数据库同样是存储在磁盘上，瓶颈当然也还是磁盘IO。
数据库怎么解决这个问题的呢？
分治，把一个大的文件存储拆分为一个个dataPage页（mysql默认的16KB），文件拆分小了，但是要是没有可以跨页查找的指针，同样是O(n)。索引由此产生，虽然索引也需要占据磁盘空间，但是索引的占据的磁盘的空间时很小的，叶数据存储的是整列的数据，而索引只需要一列，最多再存一个指向下一个的指针。
小结一下：数据库是采用 分页+索引 来解决这个问题

这里会有一个面试问题：假设一张表有几千万的数据，那么读写速度如何呢？
写的速度是一定会慢，读呢，如果是索引命中，查询量比较少，那么速度还行。但是这里会有一个问题是，如果在高并发的情况下，而且大家查的数据都是不同的，那么这个时候吞吐量肯定会低，前面数据可能1s返回了，后续的时候至少1s以上了。

基于内存的关系型数据库-<k,v>

redis

前两者的瓶颈都在于磁盘，那么有人就说了，可以基于内存去做呀，内存的读写速度是在纳秒级别（秒->毫秒->微妙->纳秒），内存当然非常快，相当于磁盘的100万倍，但是你以为公司都富到这程度了，内存多贵啊！

当当当当~ redis应运而生
redis key-value形式相当于hashMap，noSQL，单线程，基于内存（一秒的读写速度在100万次），淘汰策略，但是redis禁止使用集合操作，需要一个集合把两个操作进行交并差积。

redis6.x以后推出IO thread，一个线程先把IO数据从内核拷贝到用户空间，work线程还是单线程处理

所以使用redis+mysql能解决一般公司的绝大多数问题，冷热数据分别存于数据库和redis中，redis一般是用于缓存

memcache

同样是<k,v>形式，但是无类型，都是string。所以读取数据只能是全量读到后，再进行解析，势必会有服务端到客户端数据的全量移动，并且客户端要自己计算。

分布式数据库-hbase，HDFS

HDFS

分布式需要角色，而角色中必须有协调者与工作者，那么就会有主从（干的活不一样），主备（主挂了，备机器上）
什么是分布式的，就是存在不同的机器中。如果未来想找这个数据在哪？那么就需要映射mapper，这里叫元数据（namenode），从机器（datanode）来真正存数据
角色之间需要通讯：namenode通知来存数据，datanode实际存数据，存储完成后需要告诉namenode，我存在哪了
流水线变种的并行：把一个大的包切为一个个小数据包，达到并行目的
如果一台服务器是datanode，第一副本存本地，没走网卡，第二个通过网卡keepline存备份

hbase

介于big table -> 慢，推出hbase
表如果变大会变慢，那么进行垂直和水平拆分
分表痛点在于关联查询

天生分布式，以列族为单位，形成一个文件，相当于一个垂直切分的范式
水平有一个region对应rowkey（比如1-25行），还有一个时间戳的概率

regionServer 将不同的数据放在不同区中，它借用了redis的特征，热数据放于缓存中
如果内存存满了，存于磁盘，借用HDFS，主从加数据备份

选型

做一个文件系统，提供一个根据各个应用创建的对应分发 /E/ES(检索)，/H/hbase(分布式　big table)，/M/memcache（无类型），/H/HDFS（主从，数据备份），客户端根据约定的格式进行解析