网站制作软件下载安装,怎样在百度上做网站,博物馆网站 微信 微博 建设,旅游网站策划书范文随着使用数据库的深度和理解能力的提升#xff0c;有一个问题硬件的提升,与数据量的变化是否对数据库底层的架构有冲击。 我们公认的BTREE BTREE 是否还能面对现在的硬件的变化。 BTREE 到底是为那种硬件逻辑来服务的#xff0c;这点是需要搞清楚的在MYSQL 中使用的BTREE的改… 随着使用数据库的深度和理解能力的提升有一个问题硬件的提升,与数据量的变化是否对数据库底层的架构有冲击。 我们公认的BTREE BTREE 是否还能面对现在的硬件的变化。 BTREE 到底是为那种硬件逻辑来服务的这点是需要搞清楚的在MYSQL 中使用的BTREE的改进版中底层的数据也是有指针的便于数据顺序的读取和查找。但在怎样写入一次数据需要分两次写入这是BTREE本身结构所需要的。在数据的读取中磁头读取数据的速度是非常快的纳秒基本上服务器级别的磁盘是可以达到的但慢在磁头的移动最近忘记哪家公司了希捷还是西数发明了双向磁头宣称数据读取的速度提高了200%. 所以BTREE 要解决的主要问题就是我们的传统磁盘的性能问题通过优化数据结构来提高一次数据的尽量不要偏移磁头一次磁头能读取的数据越多越准确越好。所以无论是ORACLE ,SQL SERVER ,PG , MONGODB , MYSQL 的数据块的索引均都支持 BTREE的类型并且有点数据库就仅仅有这一种数据结构。时代不同了SSD 已经很多年了虽然价格和传统磁盘相比还是太高但你敢说你最近两年内买的笔记本上没有他的身影。硬件的变化并不是和部分人想的仅仅是系统性能的提高数据的读取的效率提高。 硬件推动的很可能是某个工作的消失甚至是某种数据结构的淘汰。例如原先某个SQL 优化的工作由于更换了更快的CPU ,更大的内存 SSD 磁盘系统原先很烂的SQL 不在是问题你优化的“事业”就此葬送在硬件的更新换代上。所以害死?的并不一定是卖猪肉的很可能是因为牛肉更便宜了。BTREE 是为传统磁盘来服务的那SSD 磁盘对于 BTREE的方式可能并不感冒如果你使用的SSD 磁盘 POSTGRESQL 中的某些配置文件中的某些参数都有可能要大动干戈。 Unfortunately, standard disk-based index structures such as the B-tree will effectively double the I/O cost of the transaction to maintain an index such as this in real time, increasing the total system cost up to fifty percent. Clearly a method for maintaining a real-time index at low cost is desirable. The Log-Structured Merge-tree (LSM-tree) is a disk-based data structure designed to provide low-cost indexing for a file experiencing a high rate of record inserts (and deletes) over an extended period. LSM tree 的目的上面的截图的文字中BTREE 会连浪费I/O COST 所以LSM tree 这样的数据结构为了就是高并发的写入而准备的。下面就引入一个Knowledge Sharing Why LSM Tree Fast首先我们需要确认LSM 要解决一个什么问题更快速的写更快速的读并且是大量的数据的情况下。LSM 的主体思想可以这样来表达数据首先写入到buffer 然后当达到一个阈值的情况下将数据顺序整理后刷新到磁盘中。(由于在内存中预先整理所以顺序写的速度在传统磁盘中也是很快的)那这样的情况下就会产生另外一个问题读数据的困难写是有序写入并且有内存进行批量的数据刷新这放到哪个地方都是提升写性能的一种方式但数据要被读取的时候就会产生一个问题我怎么去找到我的数据。如果顺序的去查找那将.......那么怎么提升读的性能就是LSM TREE 要考虑的事情我们可以利用bloom 过滤器bloom 过滤器常常用在大数据量中的数据排除的活动这是Bloom 过滤器的特性(之前写过一篇关于bloom 过滤器应该是和postgresql有关的一篇文字)这里简单的一句话bloom说你要查找的值没有他一定没有但如果他说有有可能是错误但问题是他的速度是非常快的所以通过bloom过滤器加上一个内存buffer 指针(保存实际的数据的物理地址这里可以理解为index)来进行数据的读取原则上是可以增加数据的读取的速度和准确度并且在这个期间是要对磁盘中的文件进行merge的如何merge 以及 merge的 频率就会直接影响整套系统的是更偏向于写入的性能还是读取的性能这里稍微的小结一下Btree 我们知道由于数据的插入需要符合BTREE的原理的所以一定会有数据的空点(页面会split or merge)但LSM TREE 对数据空间的利用率要比BTREE 干脆的多。具体LSM tree 在磁盘上的文件的实现SSTable相信稍微懂一点cassandra的同学对这个名词是不会陌生的SSTABLE可以理解为是磁盘驻留的有序不可变数据结构。从结构上看SSTable分为两部分:数据块和索引块(请看下图)数据块由按键顺序写入的唯一键/值对组成。索引块包含映射到数据块指针的键这些键指向实际记录所在的位置。索引可能是B-tree或者散列表来实现查询。SSTable中的每个值项都有一个与之关联的时间戳标记了插入时间。SSTables是从键到值是持久的、有序的、不可变的映射其中键和值都是任意的字节字符串由于SSTable是不可变的插入、更新或删除操作将需要重写整个文件主要它是针对读、顺序写进行优化的没有预留空间允许任何就地修改用大白话讲就是这个SSTABLE 的磁盘数据存储的结构会跟随着数据的变动不停的进行刷新合并操作。所有的Insert 操作还是Insert 操作所有的UPDATE 操作也可以理解为insert NEW 的操作,delete 的操作也是记录一个标记在下次文件合并的过程中会将其去也可以称这个过程叫压缩。(也就是一KEY VALUE数据会有多个版本)此时会重提上面提到的两个问题1 为什么要有时间戳的概念时间戳的概念主要是在合并时如有相同的数据以时间戳最后的为准 2 合并会增加数据的顺序性让后面的数据查找更快速。写到这里不能不终止了因为没有人愿意去看一篇长篇大论并且毫无乐趣因为一篇文字是需要点冲突点来引起人们阅读的兴趣。那下面的冲突点 LSM TREE 和 BTREE 之间的不同点在哪里1 BTREE 是固定一个页面可以从2KB - 32KB大小具体要和磁盘的结构吻合。2 LSM TREE 则设计是没有这样固化的概念1 BTREE 可以在PAGE 页内部进行修改更新删除。2 LSM-TREE 的操作可以理解为 insert new , append one1 BTREE 对数据读取的支持是高效的尤其对于顺序读的操作维护BTREE的操作会不断的分裂和合并随机的读写的操作的性能随着数据的增加会降低2 LSM-TREE 本身写入的特点支持高容量的高并发的写操作这是一个分布式系统可能更加看重的本身读取数据的效率是随着相关索引的优化来进行改变的理论上读的碎片也可以接近于 BTREE。这里就引出了另一个话题LSM-TREE的合并操作会占用大量的CPU 和I/O 这难道不会影响系统性能OK 所以及回到这篇文字的开头一个硬件的是可能改变一个数据库的底层架构让其在某些情况下让某些不可能变为可能。
