Redis 数据存储的发展史

1.磁盘时代

很久之前，我们的数据存储方式是磁盘存储，每个磁盘都有一个磁道。每个磁道有很多扇区，一个扇区接近512Byte。

磁盘的寻址速度是毫秒级的，带宽是GB/M的。内存是ns级的，带宽也比磁盘大上好几个数量级。总体来说，磁盘比内存在寻址上慢了接近10W倍。

在这段历史中，我们的面临的问题是，I/O问题。在读写文件时，我们常常面临很大的I/O成本问题。但是最初有个最初的解决方案是加一个buffer。

科普：什么是buffer？
  buffer是指一个缓冲区，我们在缓冲区来进行一个暂时的存放，之后统一运输给内存，这样会使得I/O的性能有略微提升。

2.数据库的产生

任何技术都不会平白无故产生。

我们数据库技术就是由于磁盘的I/O瓶颈。为了解决这个问题，我们将磁盘扇区分为4K的一个个小的分区，构成索引。有了这些索引值，我们能通过索引，进行更加便捷的查找。为了我们能够更快的查找，我们将索引使用B+树进行存储。

科普：B+树是什么？
  我们普通的1-0树，又称二叉查找树（二叉排序树），二叉查找树和排序树是同一种树，就是单纯的1-0树，按照中序遍历的存储方式进行从小到大（从大到小）进行存储。（初学者可能误以为两种树，包括我刚开始学习数据结构的时候）。
  二叉查找树（二叉排序树）由于在插入和删除的时候，容易出现不太ok的情况，例如，可能在删除过程中删除为一个链表，这样查找效率依旧会变得很低。所以，我们使用旋转，通过左右旋转，将这种“链表”式（极端情况下）的树转化为左右平衡的树，这就是所谓的B-树。（注意误区，B树和B-树是一个树么？初学者认为后面一种是B减树，实际不是，是翻译过来的时候加的分隔符。B为Balance平衡的意思）
  当然，我们的数据库文件不是二叉的，文件系统也不是，所以，我们多叉的查找树，就是所谓的B+树。+号代表每个节点不止二叉的意思。
  
  （用自己的话粗略总结，详细还是看B-tree，B+tree的定义）

在我们数据库的查找中，我们遇到一个问题？那就是字节宽度问题。我们建库的时候必须给出schema，我们行级存储，即使是该列为空，依旧要占位，那么，数据量庞大的时候，将会浪费很大的存储空间。但是这样的好处是，我们可以在update的时候不需要移动数据的位置。

3.key-value数据库的产生

任何技术都不会平白无故产生。

我们将数据库发展到极致，产生出类似SAP公司的HANA数据库。这种数据库，硬件需求大，内存约2T，硬件软件服务总和约2亿一个套餐。

随着互联网的发展，我们面临了一个新的问题。如何才能抵挡高并发，以及大数据导致的查找变慢呢？（注意，数据量变大，仅仅影响多数据查找，单数据查找并不会影响性能。我们的业务逻辑，通常是多条数据查找，所以才会有瓶颈）

于是我们的k-v数据库产生了，这依赖于两个基础设施。冯诺依曼体系的硬件，以太网，和tcp/ip网络。