数据库的发展

一些常识

• 磁盘
  • 寻址：ms（比内存慢了十万倍）
  • 带宽：G或者M
• 内存（线性地址空间）
  • 寻址：ns
  • 带宽：G
• I/O buffer
  • 磁盘与磁道：一个扇区有512Byte，使得索引成本变大。所以，不论你读多少，操作系统从磁盘最少读取4k数据。
  • 在最开始，数据时存放在文件里面的。随着文件变大，读取速度变慢，会受到硬盘的影响（硬盘I/O成为瓶颈），所以出现了数据库。
  • PS：4K大小取决于上层应用是I/O密集型（可以增大）还是存取一些小文件。
• 数据库
  • data page：4k（符合磁盘的一次I/O，空间可以比4K大，小了会浪费）。
  • 只有4k大小的data page，效率还是和磁盘I/O差不多。因为还是需要从头开始读取到内存查找（全量I/O）。需要建立索引。
  • 索引：数据库的data page是一行一行的数据，索引是其中一列以及这一列指向数据库中的那个data page。数据和索引都是存储在硬盘中的，查询的时候在内存中有一个B+树，叶子是索引的data page（硬盘中），树干（区间）在内存中。sql的where条件如果命中索引，在B+树通过树干找到叶子结点，将叶子结点从磁盘读取到内存，解析过后之后就知道下次读取哪个data page（数据库）的数据了。
  • 总结：内存速度快，使用数据结构可以加快查找速度，磁盘可以存储很多东西，所以数据存储在磁盘。减少了I/O的流量，因为磁盘有很多缺点，所以不发生大的I/O，以及减少寻址的过程。充分利用了内存以及磁盘的优点。
  • 数据库的表数据量很大时，性能下降？如果表有索引，增删改变慢（增删改时会修改索引，即维护索引，导致时间变慢），查询速度有两种可能，命中索引时，1个查询或者少量查询依然很快（依然读取一个data page）。如果是并发情况，会受到硬盘带宽影响速度，查询时不是获取一个data page到内存了，会读取很多data page到内存（一个一个的读取），这时有些请求会等待之前的之前数据的读取。
  • PS：关系型数据库建表时需要给出schema（数据类型，多少列），来确认字节宽度。数据库每行的宽度可以确定，插入数据时，如果只给了一部分数据，会用空数据补充这些字节（存的时候倾向于行级存储）。这样的好处是增删改时不需要移动数据，使用新数据覆盖原位置。
• 数据库数据量特别大时，增删改查速度会有不同程度的变慢，尤其在并发情况下，如何解决这种问题呢？
  • 一个极端：SAP公司的HANA数据库，一个内存级别的关系型数据库。
    • 数据在磁盘和内存的体积不一样。使用索引时，索引里面也有一份数据（也就是存了两次）。HANA数据库体积会小很多。
  • 一个折中的方案：缓存。memcached，redis。
    • 两个基础设施：1，冯诺依曼体系的硬件（限制了磁盘性能）、2，以太网，TCP/IP网络（不稳定）。
• 数据库信息百科：https://db-engines.com/en/