非关系型数据库出现的推导:
对一个比较大的文件或者存储在硬盘的数据,进行查找,这个时候速度会很慢!
这是因为,计算机进行的是全量扫描.
根据硬件的常识,触发全量扫描的时间就越久.
这就引发了数据库的出现
数据库较之硬盘存储数据快的原因:
①分治: 数据库底层存储是分为datapage的数据单元(但是当查找时依然是全量扫描)
②索引
数据库:
索引: 同样可以看作是数据,但是比表中的数据小, 但是如果索引没有自己的结构,这里仍然需要对自己进行全量扫描
这里为了规避他的全量扫描,采用B+T的数据结构 将他看作树叶,将其树干放置在内存中.
但是如果某个表的数据很多 ,几百亿的 数据,这时候CRUD就会变慢
CRUD 可以看作就是 读和 写
当表很大的时候 写肯定会变慢,因为牵扯到索引的变化
读一定会变慢吗?
这里看场景!
只有一个连接连到数据库,只有一个或者很少很少的客户端发送带着查询条件的请求,且索引命中了,这个时候他的查询时间依然是毫秒级别的.
但是如果并发很大, 大量的数据就挑战你的硬盘 内存的吞吐了 当大到查过吞吐量,就崩溃了呗.
这个时候,考虑下 ,硬盘相比内存,是要慢很多很多. 是不是可以找到一个 关系型的 sql查询的 内存数据库?
hana数据库:是一个内存关系型数据库
但是太贵了….
这个时候就需要非关系型数据库了
折中考虑将并发需求大经常使用的数据放在内从中,将不常用的数据或者全量数据放在硬盘中.
这里就将全量数据分成两部分.
这个时候,频繁使用的数据依然查询很快,对于用户的体验度就提高了
小常识:
最重要的两个指标
硬盘:
带宽 吞吐: 查找数据 单位 百兆 G
寻址时间 : ms级别
内存: 寻址时间: ns级别 比之硬盘快10W倍
在数据库中数据是一个T的数据 在内存中的数据会变小 ,因为内存中可以将常量放置在常量池中统一调用