为什么 MySQL 选择 B＋树作为存储引擎索引结构( 二 )

4. 采用性价比高的存储
接下来我们一一对其进行解释，因为如果上述四个背景如果不成立的话，说明我们一开始的出发点就错了，后面的回答都是无稽之谈。
1.1 处理读多写少的场景
提起这个话题，我们就不得不说，在互联网发展起来的早期，大部分的系统主要处理的是
读多写少
的场景。例如早期的bbs内容、博客、门户网站、电商的商品入库等等，这些场景都可以划分为读多写少。他们通过有限次的写操作将数据写入到数据库中，然后供用户多次浏览、阅读。发展到今天的互联网，面向用户的很多系统仍然是属于读多写少的范畴。所以
读多写少
这是一个早期存储引擎在数据读写时面临的最大的背景。
1.2 关系型数据库按照行组织
早期的时候存储引擎这个概念主要还是出现在关系型数据库中，大部分人接触这个概念估计也是因为 MySQL ， MySQL中经常提到存储引擎这个词。在关系型数据库中，数据往往通过
数据库->表(多列)-->行
的方式来组织。最终落到存储引擎这一层时，数据已经按照行的格式来组织了。广义来看其实也就是类似于 key-value 的存储了，只不过在关系型数据库中，到达存储引擎这层的 value 是一行记录按照指定的格式来扁平化组织而成，具体的格式大同小异。这儿不再展开赘述。大家可以自行搜索资料查阅，此处主要是抛出来在关系型数据库中
数据按照行格式来存储
这个背景。
为了方便介绍，在后续的内容中，存储引擎存储的数据我们就统一按照 key-value 来讨论了。此处的 key 大家暂且可以直观的理解为主键。
1.3 存储千万级量级数据
随着互联网的迅速发展，数据存储的量级日益增长，很快就达到了
存储千万级量级数据
这个量级。很明显这个背景从需求的角度看，其实是属于不断迭代的过程。不可能初期互联网一起来，马上就面临这个量级。但是我们也知道在计算机软件的世界中，
可扩展性
是大家耳熟能详的词语。所以在设计存储引擎时，自然而然肯定会考虑这个问题。所以此处，我们将
存储千万级数据量级
这个作为第三个背景。
1.4 采用性价比高的存储
接着第三个背景，自然而然就引出了数据存储在哪里的问题。回答这个问题，必须就得引出一个成本问题了。如果不考虑成本来存储，那自然问题就简化了。但是千万级量级的数据存储时，有了成本的限制，就得思考了。
我们的目标是要找到一个成本相对廉价，但又能支持千万级数据量级的存储介质。
对于计算机中，存储数据的媒介整体可以分为两大类：