为什么NoSql快--磁盘顺序写

数据写入方式

1.  update-in-place原地更新

2.  append-only btree/copy on write tree顺序文件末尾追加

数据被按照特定方式放置,提升读性能,但写性能下降,对b+树和hash更新时需要随机读写:

1. 二分查找,将文件数据有序保存,使用二分查找来完成指定key的查找

2. 哈希,用哈希将数据分割为不同的bucket

3. B+树,减少外部文件的读取

4. 外部文件,将数据保存为日志,并创建一个hash或者查找树映射相应的文件

存储结构(磁盘因为寻道等因素,顺序读取比随机读取块N个数量级):

将整个磁盘就看做事一个日志,在日志中存放永久性数据及其索引,每次都添加到日志末尾;

通过将很多小文件的存储转换为连续的大批量传输,是的对于文件系统的大多数存取都是顺序性的,从而提高磁盘宽带利用率,故障恢复速度快。

简单来说分为一部分常驻内存,可以为任何方便键值查找的数据结构,另一个常驻硬盘,与B-Tree类似,这部分经常访问的节点也会被缓存在内存中

首先将日志文件写入插入操作日志。然后写入内存部分。当内存接近阈值则滚动合并到硬盘。

将数据添加到文件,因为完全顺序,所以写操作性能优秀,但从日志文件读一些数据将比写操作消耗更多的时间,需要倒序扫描,知道找到所需内容。

日志适用的场景:

  • 数据是被整体访问,WAL(write-ahead-log)
  • 知道明确的offset,kafka

Log-Structured Merge-Tree,LSM-tree

将之前使用的一个大的查找结构变换为将写操作顺序的保存到一些相似的有序文件(sstable)中。每个文件包含了短时间段内的一些改动,因为文件有序,后续查找也会很快。文件不可修改,永远不会更新,新操作只会写到新文件中,读写检查所有文件,通过周期性的合并来减少文件的个数。保持了日志文件的写性能,让操作顺序化,不断追加而不是修改,延迟更新,批量写入硬盘,适合于大量插入环境

写操作被分批处理,只写到顺序块上,周期性合并会影响IO,都操作有可能访问大量的文件(散乱的读)

  • 更新操作-》内存缓存(memtable)中使用树结构来保持key有序-》WAL写磁盘防丢/恢复/-》达到一定规模刷到磁盘上一个新文件里,这里简单生成新文件没有编辑,所以是顺序写,速度快

越多的数据到存储系统中,就会有越多的不可修改的顺序sstable文件被创建,他们代表了小的,按时间顺序的修改,系统周期性发起compaction,合并文件删除重复冗余,减少文件个数,保证都操作的性能,因为sstable是有序结构,所以合并非常高效

  • 读操作-》先检查内存数据(memtable)-》没有这个key-》逆序一个个检查sstable直到找到。

因为需要遍历所有sstable,当数量过多性能就会下降,一方面系统周期性合并sstable,用cache等技术,另一方面使用bloom来避免大量的读文件操作。

周期合并(按层/按文件大小):为了保证LSM读取速度,所以需要维护并减少sstable文件个数

时间: 2024-07-28 19:25:52

为什么NoSql快--磁盘顺序写的相关文章

磁盘IO单线程顺序写时最快的,如果多线程写,磁盘的磁头要不断重新寻址,所以写入速度反而会慢

(1) 读写最好还是不要多线程,硬盘读写的速度有限,单线程时已经满负荷了,多线程又会增加线程之间的切换,会增加时间. 如果想增加读写速度,应该增加硬盘,做raid (2)首先是硬盘的写入是串行的,CPU的计算才是并行的,如果你偏重计算那么多线程能提高,要不怎么叫做并行计算呢: 如果侧重存储,除非数据量达到足以体现优势的程度,否则加上线程之间切换的损耗当然会效率更加地下. (3)这个是按照算法来说的,目前来说大多数的算法都是很快的,瓶颈都在磁盘的IO上,我们针对大多数的算法都进行过测试,基本一半以

SQL Server Log文件对磁盘的写操作大小是多少

原文:SQL Server Log文件对磁盘的写操作大小是多少 SQL Server 数据库有三种文件类型,分别是数据文件.次要数据文件和日志文件,其中日志文件包含着用于恢复数据库的所有日志信息,SQL Server总是先写日志文件ldf,数据变化写入mdf则可以滞后,所以日志写入的速度在一定程序上决定了SQL Server所能承载的写事务量,那么ldf写入大小是多少呢? 要知道SQL Server写 Log的大小,这里使用工具Process Monitor 这里设置一个Filter,以满足只收

XEvent – SQL Server Log文件对磁盘的写操作大小是多少

原文:XEvent – SQL Server Log文件对磁盘的写操作大小是多少 本篇是上一篇SQL Server Log文件对磁盘的写操作大小是多少的续,使用XEvent收集SQL Server Data文件和Log文件的写大小,脚本如下: ? 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45

SSD 为什么顺序写比随机写性能更好?

SSD以Page为单位做读写,以Block为单位做垃圾回收,Page一般有16KB大小,Block一般有几十MB大小,SSD写数据的逻辑是: 1)将该块数据所在的Page读出 2)修改该Page中该块数据的内容 3)找出一个新的空闲Block将2)中的Page写入,并将1)中提到的Page所在的Block中的Page标志为脏 理解了写原理,也就明白了为什么顺序写比随机写好了.四个字:垃圾回收!写相同数据量的情况下,顺序写制造更少的垃圾Block,所以比随机写有更高的性能. 这篇文章有详细的描述:

Spring Data Redis 让 NoSQL 快如闪电(2)

[编者按]本文作者为 Xinyu Liu,文章的第一部分重点概述了 Redis 方方面面的特性.在第二部分,将介绍详细的用例.文章系国内 ITOM 管理平台 OneAPM 编译呈现. 把 Redis 当作数据库的用例 现在我们来看看在服务器端 Java 企业版系统中把 Redis 当作数据库的各种用法吧.无论用例的简繁,Redis 都能帮助用户优化性能.处理能力和延迟,让常规 Java 企业版技术栈望而却步. 1. 全局唯一增量计数器 我们先从一个相对简单的用例开始吧:一个增量计数器,可显示某网

结合shell脚本解决macbook没法对ntfs移动磁盘进行写操作的问题

mac的系统是一套Unix基础的操作系统,包含两个主要的部份:核心名为Darwin,是以FreeBSD源代码和Mach微核心为基础,由苹果公司和独立开发者社群协力开发:及一个由苹果计算机开发,名为Aqua之专有版权的图形用户界面. mac电脑中直接接入ntfs类型的磁盘没法进行写操作,可以先取消自动挂载,然后手动挂载来解决. #/bin/bash newDev=$(mount | grep ntfs|awk -F ' ' '{print $1}') echo "新设备 : "$newD

2017-7-5 : 快下班了写点东西

一直就想写点东西来记录自己生活中的点滴,工作中的积累,为以后留点纪念. 7月开始,一个月的时间马上就过去了,借了一本书,本来想着半个月的时间就看完,来提高自己的专业技能,由于一些原因,还没有来得及看,一直都耽误. 给自己定一下 7月份的学习目标: 1. <web接口开发与自动化测试>这本书在这一个月的时间内看完. 2.  练习去学习 web开发的接口 3. 提高 自动化测试的 水平 4. 养成一个良好的写博客习惯争取每天都可以凑出一点时间来写. 最后总结今天: 今天测试东西挺多,心细逐渐慢慢养

算法总结--排序(快排未写)

算法第四版的简化的笔记!给自己看的 数据,一个长度为n的无序数组 api exch([]a,i,j) 交换数组i与j位置的元素 less(i,j) 判断大小:数组元素i<j?true:false 一 选择排序 selection i=0:从i~n中选取最小值与i交换位置:i++ :循环: 特点 运行时间与输入无关(无论多么乱,或者元素全部一样) 排序时间是一样的. 数据移动是最少的,每个元素只交换一次. public static void sort(Comparable[] a) { int

几款主流 NoSql 数据库的对比

最近小组准备启动一个 node 开源项目,从前端亲和力.大数据下的IO性能.可扩展性几点入手挑选了 NoSql 数据库,但具体使用哪一款产品还需要做一次选型. 我们最终把选项范围缩窄在 HBase.Redis.MongoDB.Couchbase.LevelDB 五款较主流的数据库产品中,本文将主要对它们进行分析对比. 鉴于缺乏项目中的实战经验沉淀,本文内容和观点主要还是从各平台资料搜罗汇总,也不会有太多深入或底层原理探讨. 本文所引用的资料来源将示于本文尾部.所汇总的内容仅供参考,若有异议望指正