存储系统_存储系统包括 - CSDN
精华内容
参与话题
  • 计算机系统基础知识_存储系统

    千次阅读 2019-04-07 01:06:49
    文章目录概述存储系统的层次结构存储器的分类相联存储器高速缓存(Cache)高速缓存地址映射方法直接映射全相联映射组相联映射替换算法性能分析外存储器磁存储器光盘存储器固态硬盘磁盘阵列技术 概述 计算机系统由 硬件...

    概述

    计算机系统由 硬件软件 组成,这篇文章主要简单介绍计算机的硬件系统。硬件系统由5大基础设备组成:运算器、控制器、存储器、输入设备、输出设备

    ComputerBasicParts

    存储器作为系统五大基础部件,本文主要简单介绍一下存储的结构、类型。然后着重介绍现代CPU中都配备的高速缓存。

    存储系统的层次结构

    一个计算机系统中可能存在各种各样的存储器,有CPU内部的寄存器、CPU内的Cache,CPU外的Cache,主板上的主存(内存),主板外的磁盘存储器等等。它们之间通过适当的形式连接起来一起形成计算机的存储体系。其中Cache与主存之间的交互全由硬件实现,而主存与更低层级的交互通过软硬结合实现。如下图所示:

    Storage Struct

    图片来自《计算机组成原理与体系结构》王庆荣, 北京交通大学出版社

    存储器的分类

    存储器有很多种分类方式,都先简单的看一下。

    1. 按所在位置分类
      • 内存,也叫做主存,指在主机内或板上,用于存储运行所需的程序及数据,相较于外存具备更快的速度。
      • 外存,也叫做辅存,通过连接置于主机板外的,相较内存一般外存具备更大的空间,但也会更慢,用于存储暂时不使用的大量信息,在使用时再调入内存。
    2. 按材料分类
      • 磁存储器,用磁性介质的存储器,如磁鼓、磁带、磁盘等,现在的机械硬盘就是磁存储器。
      • 半导体存储器,用晶体管制成的存储器,又分为双极半导体和MOS半导体存储器,内存、Cache、固态硬盘都是半导体存储器。
      • 光存储器,用光学来读写数据的存储器,如光盘。
    3. 按工作方式分类
      • 读写存储器,既能读又能写的存储器。
      • 只读存储器
        • 固定只读存储器(ROM, Read Only Memory),生产时写好数据的存储器,只能读出不能改变,一般存放BIOS和微程序使用。
        • 可编程只读存储器(PROM, Programmable Read Only Memory),与ROM相比不同的是可以由用户一次性写入。
        • 可擦写可编程只读存储器(EPROM, Erasable Programmable Read Only Memory),与PROM相比不同的是可以用一定方法来擦除改写其中的数据,一般是由紫外线照射一定时间来擦除所有信息。
        • 电擦除可编程只读存储器(EEPROM, Electrically Erasable Programmable Read Only Memory),与EPROM相比不同的是可以用电信号来擦除数据。
        • 闪速存储器(Flash Memory),又叫做闪存,它特性介于EPROM和EEPROM之间,也是利用电信号擦除,但只需要几秒钟内就可以擦除所有数据,速度远快于EPROM。
    4. 按访问方式分类
      • 按地址访问存储器
      • 按内容访问存储器
    5. 按寻址方式分类
      • 随机存储器(RAM, Random Access Memory),这种存储器就是现在计算机上的内存(主存),可以对任一存储单元进行读写,并且访问任一单元所需时间相同。
      • 顺序存储器(SAM, Sequentially Addressed Memory),访问数据所需要的时间与数据所在位置有关,曾经的磁带就是经典的顺序存储器。
      • 直接存储器(DAM, Direct Addressed Memory),介于上两者之间,现在的磁盘某种程度来说就是DAM,它对磁道寻址是随机的,但磁道内寻址是顺序的。

    相联存储器

    这是一种按内容访问的存储器,其原理是把数据或其中的一部分作为关键字,按顺序写入信息,在读取时并行将该关键字与存储器中每个单元比较。非常适于信息的检索和更新。它比较特殊,因此单独介绍一下,有点类似于程序中的键值表。

    其结构如下图所示:

    在这里插入图片描述

    其中,输入检索寄存器存放关键字;屏蔽寄存器屏蔽不参与检索的字段;比较器则是用关键字与存储体每一单元进行比较,为了提高速度,比较器数量应设置巨大,如果是位比较器则每位应设置一个,应有2m×N2^m \times N个,如果是字比较器则应有2m2^m个;匹配寄存器用于存放结果,应有2m2^m位大小,存放比较器比较的结果。

    相联存储器主要用于高速缓冲存储器中,或用于虚拟存储器中。

    高速缓存(Cache)

    位于CPU和主存之间的就是Cache,它主要用于存放最活跃的程序和数据,容量一般在几千字节到几兆字节之间,速度比内存快10倍左右。对程序员来说是不可见的。

    Cache的部分用于存放内存中的内容的副本,控制部分会判断要访问的信息是否在Cache中,有则称作命中,直接对Cache寻址;若未命中则需要按照替换原则来替换Cache中的副本。

    一般来说,现代CPU中的Cache对分为多级,常说的L1\L2\L3缓存就是多级的Cache缓存。通常,越靠近CPU的Cache速度越快,空间越小。在多级结构中,需要自低往高逐级访问,全都不命中时才会访问主存。

    高速缓存地址映射方法

    CPU工作室,给出的是主存单元的地址,如果需要对Cache中的数据进行读写,则需要一个方法来将主存地址映射为Cache地址,一般的有三种方法,一一简单介绍。

    直接映射

    即主存的块与Cache块对应关系固定不可变,在这种映射方式下,只要主存地址中的区号和Cache中记录的区号相同,则表明Cache命中。

    其优势在于地址映射十分简单,但缺点也同样明显,即不同区的同块号无法同时调入Cache中,即使此时Cache未满,同时,主存的块数只能是Cache块数的整数倍。其映射详看下图:

    Cache Direct Mapping

    图片来自《计算机组成原理与体系结构》王庆荣, 北京交通大学出版社

    在这种方式下,CPU访问主存地址需要主存块号M,块內字号W,但实际上,主存块号M会被拆分成标识号T及Cache块号C。

    当主存被调入Cache中时,同时会将主存的标识号T存入Cache中。在需要访问主存时,会直接查看拆分后的Cache块号对应的Cache块中保存的标识号T是否与拆分后的标识号一致,若一致则代表命中。

    Cache Direct Mapping Method

    图片来自《计算机组成原理与体系结构》王庆荣, 北京交通大学出版社

    这里的T可能容易产生模糊,上面提到,主存被分解成N个区块,每个的大小都与Cache大小相当。因此这个T实际上就是用于标识当前该块映射的是主存中的哪一区块(注意区块与块的区别)。

    全相联映射

    主存与Cache均分成大小相同的块,这样映射就可以允许任意主存的块被放入Cache的任一块中,如下图:

    Cache Full Mapping

    图片来自《计算机组成原理与体系结构》王庆荣, 北京交通大学出版社

    在这种方式下,CPU访问主存地址需要主存块号M,块内字号W。而访问Cache的地址需要Cache的块号C,块内的字号W。

    实际上即主存块号和Cache块号需产生联系,在Cache中存在映射时需能访问。这就需要建立一个表,一般使用的方式即前面提到过的相联存储器。结构如下图:

    Cache Full Mapping Method

    图片来自《计算机组成原理与体系结构》王庆荣, 北京交通大学出版社

    如:设主存为64MB,Cache为32KB,块的大小为4KB(块内地址需12位),因此主存分为64MB/4Kb = 16384块,其块号从0~16383,为了表示块号需14位,Cache分为8块,块号0~7,表示Cache块号需3位。

    存放主存块号和Cache块号的相联存储器需要有和Cache块个数相同的单元,相联存储器中每个单元记录均主存块块号,表示该Cache块现为哪个主存块的映射。

    在需要访问主存时查询相联存储器,若比较发现相联存储器单元中存放的主存块号与该操作访问的主存块号一致则代表Cache命中,直接访问Cache块。

    组相联映射

    以上两种方式的优缺点正好相反,而组相联是前两种方法的综合。因此绝大部分都使用这一方案。

    它将Cache中的块再次分组,假定Cache共有16块,每两块为一组,则共分得8组。同样的将主存按每个区分为16块,其中也是每两块分为一组,也是共分得8组。

    组相联的规定就在于,对于组采用的是直接映射,对于块采用全相联映射。也就是说,主存中任何分区的第N组同样只能放入Cache中第N组,但组内的任意一块都可以放入Cache中同一组的任意一块。

    其映射结构如下图:

    Cache Group Mapping

    图片来自《计算机组成原理与体系结构》王庆荣, 北京交通大学出版社

    替换算法

    替换算法的目标只有一点,使Cache有尽可能高的命中率,一般采用如下几种方式:

    1. 随机替换,随机抽出一个要被替换的Cache块
    2. 先进先出,最先进入Cache的块先被替换
    3. 近期最少使用,最少使用的Cache块优先被替换
    4. 优化(统计)替换,这种方式需要执行一遍程序,统计Cache的首次命中率,针对这些信息优化第二次的替换。

    性能分析

    Cache的性能即计算机性能的重要组成部分,命中率是Cache非常重要的指标。其设计目标是在成本允许的前提下达到较高的命中率,使存储系统整体有最短的平均访问时间。

    HCH_C为Cache命中率、TCT_C为Cache存取时间、TMT_M为主存的访问时间,则Cache存储器等效加权平均访问时间TAT_A为:TA=HCTC+(1HC)TM=TC+(1HC)(TMTC)T_A = H_C T_C + (1-H_C) T_M = T_C + (1-H_C) (T_M - T_C)​

    上面假设的Cache访问和主存访问是同时启动的,其中TCT_C为Cache命中时的访问时间,(TMTC)(T_M - T_C)为失效访问时间。如果Cache不命中时才启动主存则:TA=TC+(1HC)TMT_A = T_C + (1-H_C) T_M

    在指令流水线中,Cache是流水线中的一个操作阶段,因此降低Cache失效率是提高Cache性能的一个重要方法。

    实际上,容量因素在Cache是失效中占较大比例,Cache容量越大命中率则越高,最终能使失效率收敛至接近0%,但是增加容量意味着成本和命中时间的上升。

    除了增加容量外,还可以通过选择适当的块大小和提高相联度的方式。

    外存储器

    以文件的形式存储暂时不用的程序和数据,CPU无法直接访问其中的数据,只有被调入主存后才可访问。一般外存储器主要为磁存储器和光存储器,但现在半导体存储器(固态硬盘)也开始流行。

    磁存储器

    现在磁存储器中普遍主要使用磁盘,它具有较大的存储容量,较好的速度。它由盘片、驱动器、控制器很接口组成。盘片用于存储信息;驱动器驱动磁头沿盘面径向运动寻找目标磁道及驱动盘片以额定速率稳定旋转,还控制数的写入和读出;控制器接受主机发来的命令,转换成磁盘驱动器的命令,实现主机与驱动器间的数据交换。一个控制器可以控制多个驱动器;接口则是主机与磁盘间的连接逻辑。

    硬盘就是最常用的外存储器,一个硬盘内可装有多个盘片,组成盘片组,每个盘片配备独立的磁头。所有记录面上相同序号的磁道组成一个圆柱面,它的编号与磁道编号相同。通常文件存储在硬盘上会尽可能放在同一或相邻柱面上,可以缩短寻道的时间。Windows内置的碎片整理工具就是利用这个特性来优化文件的读取效率。

    硬盘盘片会划分为多个同心圆,将其称为磁道(Track)由外往里编号,最外圈为0。沿径向单位距离的磁道数称为道密度,道密度单位为每英寸磁道数(TPI);将一个磁道沿圆周等分为若干段,每一段称为一个扇区(Sector) ,每个扇区内可存放一个固定长度的数据块;磁道上单位距离可以存放的数据位数称为位密度,单位为每英寸位数(BPI);因为每条磁道上的扇区数量是相同的,而每个扇区存放的数据块大小也是相同的,又因为外圈磁道比里圈磁道要长,因此里圈磁道的位密度要比外圈的高,最内圈的磁道位密度称为最大位密度。其结构如下图所示:

    Hard Disk Structure

    上图来自互联网

    硬盘寻址信息由硬盘驱动号、圆柱面号、磁头号(记录面号)、数据块号(扇区号)及交换量组成。

    硬盘的指标有两种:

    1. 非格式化容量 = 面数 * 每面磁道数 * 内圆周长 * 最大位密度
    2. 格式化容量 = 面数 * 每面磁道数 * 每磁道扇区数 * 每扇区字节数

    光盘存储器

    采用聚焦激光在盘式介质上非接触的记录信息的存储器,根据性能和用途,光盘又分为只读光盘(CD-ROM)、只写一次光盘(WORM)及可擦写光盘。

    只读型光盘和ROM一样,是厂家在生产时就用激光蚀刻上去的信息;而只写一次是由用户自己使用刻录机一次性写入的光盘。写入方法也是利用高能激光蚀刻盘面实现的。

    光盘存储器的最大特点在于记录密度大、非接触式读写及寿命较长(10年以上),且其制造成本低廉。

    固态硬盘

    固态硬盘是利用Flash或DRAM作为介质的存储设备,绝大部分固态硬盘是基于闪存实现的。固态硬盘由主控芯片、缓存芯片及闪存芯片组成。

    主控芯片是固态硬盘的核心,其作用主要是合理分配各闪存的负荷,二则是负责数据中转,连接闪存芯片与外部的SATA接口。不同的主控芯片能力相差十分巨大,会直接导致产品在性能上的差距。

    现今固态硬盘的接口规范、定义、功能和使用方法上与硬盘类似,具有机械硬盘不具备的读写速度、整体质量轻、能耗低等特点。但固态硬盘硬件一旦损坏,数据就难以恢复。

    磁盘阵列技术

    因为速度和安全性的需要,推出了磁盘阵列,它是由多个存储器共同组成的一个快速、大容量的子系统。现在最常用的磁盘阵列为独立冗余磁盘阵列(RAID, Redundant Array of Independent Disk),它曾经叫做廉价冗余磁盘阵列(RAID, Redundant Array of Inexpensive Disk)

    RAID有多种不同的阵列方式,见下表:

    RAID级 说明
    RAID 0 该级别的阵列不具备容错能力,由N个磁盘组成,它的读写速度可达到单个磁盘的N倍,但其故障间隔时间仅有单个磁盘的1/N。
    RAID 1 采用镜像容错,改善可靠性,两组磁盘间完全存放相同的内容,因此空间并不会因为磁盘数量增加而增加。
    RAID 2 采用海明码进行磁盘错误检测的阵列。
    RAID 3 减少用于校验的磁盘个数,提高阵列的有效容量,一般仅有一个磁盘用于校验。
    RAID 4 可以单独对组内磁盘进行读写,一般也仅有一个磁盘用于校验。
    RAID 5 是RAID 4的改进,它不用单独的磁盘校验,而是存放数据的同时也存放校验信息,解决多个磁盘同时争用单个校验盘的问题。

    除了上面的说明,RAID还可以组合不同级别使用,如现在最常用的RAID10,即1和0的组合,即提升了速度又提升了可靠性。

    展开全文
  • 存储系统

    2019-08-06 01:02:20
    存储系统 MB 1MB=1*1024KB=1024*1024B=1048576B=8388608bit MAR memory address register 地址寄存器 MDR memory data register 数据寄存器 位扩展 位数(地址线多少根)在进行内存容量扩充时,并联地址线可...

    存储系统

    MB

    1MB=1*1024KB=1024*1024B=1048576B=8388608bit

    MAR

    memory address register 地址寄存器

    MDR

    memory data register 数据寄存器

    位扩展

    位数(地址线多少根)在进行内存容量扩充时,并联地址线可进行位扩展。数据线串联

    字扩展

    字长,由数据线决定。并线数据线进行子扩展。地址线串联

    字位扩展

    数据线和地址线都要并联

    cache

    缓存器,主存与CPU之间的数据桥梁。

    直接映像

    让主存中的一个人块只能映像到cache中的某 一个特定的地址块的方式。

    硬件实现简单,不需要进行地址变换,访问速度比较快,但是这种方式u缺点是cache块冲突率较高,当主存中的两个或两个以上经常使用的块都映像到cache的同一个块时,cache的

    命中率下降,这是即使cache中有其他空闲块,也因为固定的地址映像关系而无法使用。

    全相联映像

    指主存中的任意一块可以映像到cache中的任意 一块的位置上,这种映像方式也允许从已经占满的cache中替换任意一旧字块。

    全联映像和变换方式块的冲突率最低,cache的利用率最高,缺点是访问速度最慢,成本太高,影响了cache的访问速度。

    组相联映像

    组相联映像结合了直接相联和全相联的优点,将主存地址分区,每一区的容量与cache相同,再将主存、cache分组,每组块数相同,区内的各组只能对应

    cache中特定的组,形成主存组对cache组的直接映像,组内块之间全相联映像。这样,cache中指定组的空间只能存放在主存相同组号的存储快中,至于

    该数据块存放在cache中指定组中的哪一块是任意的。

     

    虚拟存储器

    指虚拟存储系统,即虚存。不是一个实际的物理地址存储器,而是一个逻辑模型,它是在主存-辅存层次,增加部分软件和必要的硬件支持,使其形成一个有机的整体,获得

    一个比物理主存大得多的具有整个虚拟空间的存储器。它不仅扩大了主存的容量,解决了存储器容量和存储速度的矛盾,也是管理存储设备的有效方法。虚拟存储系统一般由

    操作系统实现,应用程序员无须考虑存储问题。

    存储器的基本组成部分,作用

    存储器是由存储体、地址寄存器、地址译码驱动电路、读/写控制逻辑、数据寄存器、读/写驱动器等六个部分组成。

    (1)存储体是存储器的核心,是存储单元的集合体。

    (2)地址寄存器用于存放CPU访问存储单元的地址,经译码驱动后指向相应的存储单元。

    (3)译码器将地址总线输入的地址码转换成与其对应的译码输出线上的高电平或低电平信号,以表示选中了某一单元,并由驱动器提供驱动电流去驱动相应的读/写电路,完成对被选中单元的读/写操作。

    (4)读/写驱动器用以完成对被选中单元中各位的读/写操作,包括读出放大器、写入电路和读/写控制电路。

    (5)数据寄存器用于暂时存放从存储单元读出的数据,或从CPU输出I/O端口输入的要写入存储器的数据。

    (6)读/写控制逻辑接收来自CPU的启动、片选、读/写及清除命令,经控制电路综合处理后,发出一组时序信号来控制存储器的读/写操作。 

    存储器的主要技术指标,含义

    (1)存储容量

    (2)存储速度

    (3)存储器的可靠性

    (4)性价比

    存储器的主要功能,为什么要把存储系统分层

    同一个存储器中大容量、高速度、低成本很难集成一起。只能采用存储器系统的层次结构,即利用存储系统原理

    来构成基于不同速度和容量的存储结构,而不是仅仅依赖某一个存储部件。

    存储器的分类

    1、按存储介质:TTL、CMOS

    2、按存取方式:只读ROM、随机RAM、串行访问存储器(顺序存取SAM、直接存取DAM)

    3、按作用:主存、附存、缓冲存储器

    为什么计算机系统要设置高速缓冲存储器

    CPU访问主存的速度受到限制,需要进行突破。尤其现在计算机采用超标量、超流水技术使CPU

    所需要的访问访问速度比实际所提供的相差数百倍。因此为了解决CPU与内存速度不匹配de问题

    采用高速缓冲存储技术。

    在什么情况下,cache需要采用替换策略,有几种,优缺点

    当发生cache块失效时,需要从主存调入要访问的cache块,如果此时在cache中出现块冲突,则

    需要采用替换策略。

    1、随机替换

    2、FIFO算法

    3、近期最少使用(LRU)

    段式虚拟存储器、页式虚拟存储器、段页式虚拟存储器方式的优缺点

    1、段氏

    按照程序内容将主程序分段,程序段可以是主程序、子程序或过程,也可以是数据块。

    2、页式

    把虚拟空间和主存空间划分为一个个固定的页,分别成为虚页和实页。页是一种逻辑上

    的划分,可以由系统管理软件指定,但必须是0.5KB的整数倍,一般为4KB~6KB.

    3、段页式

    综合两种模式的优点,模块性和主存利用率高。把实存分为固定大小的页,之后程序先

    按模块分段,再把每段分成与实存页面大小一样页。

    虚拟存储器和一般主存—辅存有何区别

     

    虚拟存储器和cache的区别(转载自http://blog.csdn.net/hengbao4/article/details/50128283)

    相同点

    1. 都是基于程序局部性原理,把程序中最近常用的部分驻留在高速存储器中
    2. 一旦这部分程序不常用,把它们送回到低速存储器中
    3. 这种换入、换出操作是由硬件或操作系统完成,对用户透明
    4. 都力图使存储系统的性能接近高速存储器,而价格接近低速存储器。

    不同点

    1. cache是用硬件实现的,对操作系统透明;虚拟存储用操作系统与硬件结合的方式实现。
    2. cache是一个物理存储器,而虚拟存储器是一个逻辑存储器,其物理结构建立在主存-辅存的结构基础上。
    3. 在虚拟存储中未命中的性能损失要大于cache系统中未命中的损失

                                                                      以上内容出自蔡启先等编写清华大学出版社出版的

                                                                      《计算机组成与汇编语言》

    转载于:https://www.cnblogs.com/tag0811/p/6214084.html

    展开全文
  • 存储系统的分类

    千次阅读 2017-10-31 13:27:58
    存储系统的分类 之前收集了一些存储产品,最近又重新整理了一下,对他们进行了简单的分类。每个对存储的分类可能不仅相同,我的分类完全按照自己的喜好来分,如和您的分类不同,仅供参考。只是做了搜集和...
    存储系统的分类

    之前收集了一些存储产品,最近又重新整理了一下,对他们进行了简单的分类。每个对存储的分类可能不仅相同,我的分类完全按照自己的喜好来分,如和您的分类不同,仅供参考。只是做了搜集和分类,少量产品加了写介绍,希望以后有时间,加更多更详细的介绍。

    [TOC]

    1.存储引擎

    1.1 Hash Table

    1.1.1 dbm (database manager)

    https://en.wikipedia.org/wiki/Dbm

    The dbm library stores arbitrary data by use of a single key (a primary key) in fixed-size buckets and uses hashing techniques to enable fast retrieval of the data by key.

    1.2 btree

    1.2.1 berkerlydb

    https://en.wikipedia.org/wiki/Berkeley_DB

    http://baike.baidu.com/view/1281930.htm

    Key/value数据模型

    Berkeley DB最初开发的目的是以新的HASH访问算法来代替旧的hsearch函数和大量的dbm实现(如AT&T的dbm,Berkeley的 ndbm,GNU项目的gdbm)

    oracle

    Written in C, java

    BTREE, HASH, QUEUE, RECNO storage

    https://www.oracle.com/database/berkeley-db/db.html

    http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/overview/index.html

    1.2.2 LMDB (Lightning Memory-Mapped Database)

    LMDB is a Btree-based database management library modeled loosely on the BerkeleyDB API, but much simplified. The entire database is exposed in a memory map, and all data fetches return data directly from the mapped memory, so no malloc's or memcpy's occur during data fetches.

    https://symas.com/products/lightning-memory-mapped-database/

    https://github.com/LMDB/lmdb

    http://www.lmdb.tech/doc/

    1.2.3 BoltDB

    Bolt is a pure Go key/value store inspired by Howard Chu's LMDB project.

    https://github.com/boltdb

    https://github.com/boltdb/bolt

    1.3 LSM

    1.3.1 LevelDB

    https://github.com/google/leveldb

    C++, google

    1.3.2 RocksDB

    http://rocksdb.org/

    https://github.com/facebook/rocksdb/

    C++/java

    1.3.3GoLevelDB

    https://github.com/syndtr/goleveldb

    1.3.4gorocksdb

    https://github.com/tecbot/gorocksdb

    Go wrapper for RocksDB

    1.3.5 levigo

    Go wrapper for LevelDB

    https://github.com/jmhodges/levigo

    1.3.6 mongo-rocks

    RocksDB Storage Engine Module for MongoDB

    https://github.com/mongodb-partners/mongo-rocks

    C++

    1.4 LSH

    1.4.1 bitcask

    https://github.com/basho/bitcask

    采用bitcask模型的有:beandb, Riak

    erlang

    日志结构的key/value存储系统Bitcas

    http://blog.chinaunix.net/uid-20196318-id-154750.html

    Bitcask存储模型

    http://blog.csdn.net/qq910894904/article/details/37756377

    1.5 FractalTree

    1.5.1 PerconaFT

    https://github.com/percona/PerconaFT

    https://www.percona.com/doc/percona-server-for-mongodb/perconaft.html

    https://github.com/percona/PerconaFT/wiki

    Mysql存储引擎之TokuDB以及它的数据结构Fractal tree(分形树)

    http://www.fxysw.com/thread-5061-1-1.html

    https://en.wikipedia.org/wiki/Fractal_tree_index

    TokuDB的索引结构–分形树的实现

    http://www.cnblogs.com/chaosheng/p/5250037.html

    1.6 dbm系列

    1.6.1 QDBM (Quick DataBase Manager)

    http://sourceforge.net/projects/qdbm/

    http://qdbm.sourceforge.net/

    http://qdbm.sourceforge.net/benchmark.pdf

    used by nmdb

    1.6.2 ndbm (New Database Manager)

    https://en.wikipedia.org/wiki/Ndbm

    http://infolab.stanford.edu/~ullman/dbsi/win98/ndbm.html

    ndbm (standing for New Database Manager) is a Berkeley produced version from 1986 of the AT&T dbm database.

    ndbm stores arbitrary data by use of a single key in fixed-size buckets.

    1.6.3 SDBM (Substitute Database Manager)

    Substitute Database Manager

    https://github.com/davidar/sdbm

    http://www.cse.yorku.ca/~oz/sdbm.bun

    1.6.4 GDBM (GNU Database Manager)

    GNU Database Manager

    http://www.gnu.org.ua/software/gdbm/

    1.6.5 tdb (Trivial Database)

    Trivial Database

    http://sourceforge.net/projects/tdb/

    http://tdb.sourceforge.net/

    1.6.6 CDB

    http://cr.yp.to/cdb.html

    1.6.7 TinyCDB

    Tiny Constant Database

    http://www.corpit.ru/mjt/tinycdb.html

    1.7 双类型

    1.7.1 Wiredtiger (btree, LSM)

    C语言的

    WiredTiger 本身也支持 LSM option (默认是 btree )

    mangodb

    https://github.com/wiredtiger/wiredtiger

    http://www.wiredtiger.com/

    http://source.wiredtiger.com/2.8.0/architecture.html#cache

    1.7.2 Tokyo Cabinet and Kyoto Cabinet (B+tree,hash table)

    http://baike.baidu.com/view/2640411.htm

    http://fallabs.com/tokyocabinet/

    https://en.wikipedia.org/wiki/Tokyo_Cabinet_and_Kyoto_Cabinet

    Tokyo Cabinet and Kyoto Cabinet are two libraries of routines for managing key-value databases.

    Kyoto Cabinet is the designated successor of Tokyo Cabinet

    Tokyo Cabinet 是一个DBM的实现

    Tokyo Cabinet features on-disk B+ trees and hash tables for key-value storage

    Used by nmdb,Kyoto TreeDB

    1.7.3 RaptorDB key value store (B+ 树 或者 MurMur 哈希索引)

    一个很小的、快速的嵌入式 NoSQL 存储模块,使用 B+ 树 或者 MurMur 哈希索引

    Implemented in .NET

    http://raptordbkv.codeplex.com/

    http://www.codeproject.com/Articles/190504/RaptorDB

    http://www.codeproject.com/Articles/316816/RaptorDB-The-Key-Value-Store-V

    1.8 SQL引擎类

    1.8.1 InnoDB

    http://www.oschina.net/p/innodb/

    http://baike.baidu.com/view/1238935.htm

    https://en.wikipedia.org/wiki/InnoDB

    1.9 document类

    1.9.1 RaptorDB document store

    http://raptordb.codeplex.com/

    http://www.codeproject.com/Articles/375413/RaptorDB-the-Document-Store

    2 嵌入式

    https://en.wikipedia.org/wiki/Embedded_database

    2.1 SQLite

    https://en.wikipedia.org/wiki/SQLite

    2.2 UnQLite

    盘点移动开发中最流行的5个数据库

    http://www.evget.com/article/2014/11/21/21843.html

    3 单机存储

    3.1 单值KV存储

    3.1.1 Memcache

    3.1.2 nmdb

    https://blitiri.com.ar/p/nmdb/

    use qdbm, berkeley db, tokyo cabinet or tdb as database backends

    C语言

    3.1.3 Memcachedb

    C语言,新浪

    http://memcachedb.org/

    a distributed key-value storage system designed for persistent
    It conforms to memcache protocol
    uses Berkeley DB as a storing backend

    write 18868 w/s
    read 44444 r/s

    using replication for master/slave
    6 policy for replication:

    http://memcachedb.org/memcachedb-guide-1.0.pdf

    3.1.4 Kyoto Tycoon

    http://fallabs.com/kyototycoon/

    C/C++,FAL Labs

    Kyoto Tycoon is a lightweight database server with auto expiration mechanism, which is useful to handle cache data and persistent data of various applications. Kyoto Tycoon is also a package of network interface to the DBM called Kyoto Cabinet.

    3.1.5 ThruDB

    建立在Apache Thrift framework下的简单服务

    支持多个数据存储后端,包括BerkeleyDB、Disk、MySQL,还拥有Memcache和Spread集成

    http://code.google.com/p/thrudb/

    Thrudb is a set of simple services built on top of the Apache Thrift framework that provides indexing and document storage services

    3.2 结构化KV存储

    3.2.1 Redis

    3.2.2 ssdb

    https://github.com/ideawu/ssdb

    http://ssdb.io/zh_cn/

    http://ssdb.io/docs/replication.html

    http://ssdb.io/docs/config.html

    https://github.com/ideawu/ssdb/blob/master/ssdb.conf

    采用ssd,使用leveldb作为存储引擎,兼容redis接口

    C/C++

    3.2.3 ssdb-rocks

    https://github.com/ideawu/ssdb-rocks

    ssdb的另一个版本,采用ssd,使用rocksdb作为存储引擎,兼容redis接口

    3.3.4 ardb

    https://github.com/yinqiwen/ardb

    redis-protocol compatible persistent nosql, it support multiple storage engines as backend like Google's LevelDB, Facebook's RocksDB, OpenLDAP's LMDB, WiredTiger, the default backend is Facebook's RocksDB.

    C++

    http://yinqiwen.github.io/ardb/2014/08/23/ardbintroduction/

    3.2.5 (reborndb)QDB

    兼容redis协议

    Rocksdb and LevelDB

    https://github.com/reborndb/qdb

    3.2.6 Pika

    Pika 的存储引擎, 基于Rocksdb 修改. 封装Hash, List, Set, Zset等数据结构

    https://github.com/Qihoo360/pika

    http://git.oschina.net/baotiao/pika

    http://www.jianshu.com/p/d4f23120cbe4

    首发丨360开源的类Redis存储系统:Pika

    https://mp.weixin.qq.com/s?__biz=MzAwMDU1MTE1OQ==&mid=2653547160&idx=1&sn=befd195e2aa788775aaf1cc3b6f6fab3&scene=1&srcid=0512FqLKcLjVNH0zbKVlVBSO&key=b28b03434249256b1da1489d74564ea1a9d5b15207160026adc2a6ce0622b47c084d23b75e909dfe14f6173662cbdf5b&ascene=0&uin=MjMxMzM3NjIyMw%3D%3D&devicetype=iMac+MacBookPro12%2C1+OSX+OSX+10.11.4+build(15E65)&version=11020201&pass_ticket=WU1aAnx4aVkuID0Quq0HGuKNQB68CvjQzaTnnIhjJFZwLcPqGk1zilYX4uRvF9sd

    首发丨360开源的类Redis存储系统:Pika

    https://media.weibo.cn/article?id=2309403974295628970629

    3.2.7 LedisDB

    A high performance NoSQL like Redis powered by Go

    LevelDB, goleveldb, LMDB, RocksDB, BoltDB or Memory

    http://ledisdb.com/

    https://github.com/siddontang/ledisdb

    3.3 文档型

    3.3.1 SisoDB

    C#编写的,专门提供给SQL Server面向文档的db-provider

    http://www.sisodb.com

    3.4 SQL

    3.4.1 MySQL

    3.4.2 innostore

    https://github.com/basho/innostore

    Innostore is a simple Erlang API to Embedded InnoDB

    4 单机存储的proxy集群方案

    4.1 KV/Redis类

    4.1.1 Twenproxy

    http://www.oschina.net/p/twemproxy

    https://github.com/twitter/twemproxy

    静态的分布式Redis方案

    4.1.2 Reborndb

    https://github.com/reborndb

    https://github.com/reborndb/reborn/blob/master/doc/tutorial_zh.md

    4.1.3 Codis

    http://www.oschina.net/p/codis

    https://github.com/wandoulabs/codis

    https://github.com/CodisLabs/codis

    4.1.4 Netflix Dynomite

    https://github.com/Netflix/dynomite

    基于dynamo的思想

    Dynomite: NetFlix对dynamo的开源通用实现

    http://www.infoq.com/cn/news/2014/11/dynomite-netflix-dynamo

    Netflix open sources Dynomite to make any datastore distributed

    https://gigaom.com/2014/11/03/netflix-open-sources-dynomite-to-make-any-datastore-distributed/

    A generic dynamo implementation for different k-v storage engines
    inspired by Dynamo whitepaper

    4.1.5 dbcached

    http://code.google.com/p/dbcached/

    a distributed key-value memory caching system for QDBM or Berkeley DB base on Memcached and NMDB

    4.2 SQL类

    4.2.1 Mycat

    http://www.mycat.org.cn/

    MyCat:开源分布式数据库中间件
    http://mp.weixin.qq.com/s?__biz=MzAwNjMxNjQzNA==&mid=208187004&idx=1&sn=60aba39c148711e95f00ec7ca2e13bb1&scene=0#rd

    4.2.2 MySQL Fabric

    4.2.3 TDDL

    4.2.4 Cobar

    4.2.5 Atlas

    4.2.6 Heisenberg

    4.2.7 Vitess

    5 KV存储

    5.1 riak

    http://www.oschina.net/p/riak/

    https://github.com/basho/riak

    采用bitcask模型

    Riak的实现是基于Amazon的Dynamo论文

    erlang

    Riak是以 Erlang 编写的一个高度可扩展的分布式数据存储,Riak的实现是基于Amazon的Dynamo论文,Riak的设计目标之一就是高可用。

    http://docs.basho.com/riak/kv/2.2.3/

    5.2 beandb

    https://github.com/douban/beansdb

    https://github.com/douban/beanseye

    采用bitcask模型

    distributed key-value storage system

    took the ideas from Amazon's Dynamo

    5.3 Project Voldemort

    http://www.project-voldemort.com/voldemort/

    Voldemort is a distributed key-value storage system

    http://www.project-voldemort.com/voldemort/design.html

    https://github.com/voldemort/voldemort

    BDB-JE, MySQL, Read-Only

    LinkedIn

    5.4 Scalaris

    http://scalaris.zib.de/

    分布式key value

    erlang

    supported the ACID properties for multi-key transactions

    http://code.google.com/p/scalaris/

    5.5 Aeospike

    www.aerospike.com

    http://www.aerospike.com/technologies/

    http://www.aerospike.com/docs/

    http://www.aerospike.com/docs/architecture/index.html

    5.6 Tair

    http://code.taobao.org/p/tair/

    http://www.oschina.net/p/tair/

    https://github.com/alibaba/tair

    c/c++, 自研的mdb,fdb

    5.7 dynomite

    https://github.com/moonpolysoft/dynomite/wiki

    http://www.oschina.net/p/dynomite/

    6 文档型存储

    6.1 MongoDB

    6.2 CouchDB

    CouchDB是文档型存储

    http://couchdb.apache.org/

    6.3 Membase / Couchbase

    http://www.couchbase.com/

    http://www.oschina.net/p/membase

    http://www.oschina.net/p/couchbase-server

    https://en.wikipedia.org/wiki/Couchbase_Server

    http://www.couchbase.com/wiki/display/couchbase/Home

    面向文档的 NoSQL 数据库管理系统

    6.4 SequoiaDB

    一个类mongodb的文档型存储
    http://www.sequoiadb.com/cn/

    6.5 RavenDB

    http://ravendb.net/
    a .net document database built on the Windows ESENT storage system

    支持Linq,可以使用C#的Linq语法查询数据

    6.6 OrientDB

    虽然是文档型数据库,但是它的关系管理方式却和图形数据库相类似

    http://www.orientechnologies.com/

    http://orientdb.com/orientdb/

    Distributed Graph Database with the flexibility of Documents

    是兼具文挡数据库的灵活性和图形数据库管理链接 能力的可深层次扩展的文档-图形数据库管理系统。可选无模式、全模式或混合模式下。支持许 多高级特性,诸如ACID事务、快速索引,原生和SQL查询功能。可以JSON格式导入、导出文档。若不执行昂贵的JOIN操作的话,如同关系数据库可在 几毫秒内可检索数以百记的链接文档图

    Even if it is a document-based database, the relationships are managed as in graph databases with direct connections between records.

    It supports schema-less, schema-full and schema-mixed modes.

    6.7 RethinkDB

    http://www.rethinkdb.com/

    https://en.wikipedia.org/wiki/RethinkDB

    http://baike.baidu.com/link?url=IaJEn3OOWg3i_q4HSIyqBfxRUATc2bpsoNfzcHdyAVa7vbs02R6PsIIyR4F2V4zZy9Wq3FJYW550B-d6IF6MV_

    RethinkDB 1.14 (Brazil) 发布,分布式数据库
    http://www.oschina.net/news/54771/rethinkdb-1-14-brazil

    7 列式存储

    7.1 HBase

    7.2 Cassandra

    7.3 Accumulo

    https://accumulo.apache.org/
    Apache Accumulo is based on Google's BigTable design and is built on top of Apache Hadoop, Zookeeper, and Thrift.

    7.4 Hypertable

    http://hypertable.org/
    an open source database system inspired by publications on the design of Google's BigTable.
    Hypertable runs on top of a distributed file system such as the Apache HDFS, GlusterFS or the Kosmos File System (KFS).

    7.5 Scylla

    http://www.scylladb.com/
    https://github.com/scylladb/scylla

    8 NewSQL

    8.1 Actordb

    http://m.oschina.net/p/actordb

    http://www.actordb.com/

    https://github.com/biokoda/actordb

    8.2 Cockroachdb

    Go语言

    https://www.cockroachlabs.com/

    https://github.com/cockroachdb/cockroach

    https://groups.google.com/forum/#!forum/cockroachdb-users

    https://groups.google.com/forum/#!forum/cockroach-db

    https://www.cockroachlabs.com/docs/

    Design Documents
    https://github.com/cockroachdb/cockroach/blob/master/docs/design.md

    8.3 FoundationDB

    https://github.com/FoundationDB

    https://foundationdb.com/

    8.4 Oceanbase

    https://github.com/alibaba/oceanbase

    OceanBase架构介绍
    http://wenku.baidu.com/link?url=cknPHaARI1_Z6tHGeFfF4Vn_hDjAsfHElNu8yOX_jX2qX4eIKaf4UrY2e02TcCf5ib7GOUf437IulU5lUPrixrrgMFOnEJUMUIkBDP__jA7

    8.5 SnappyData

    8.6 TiDB

    https://github.com/pingcap/tidb
    Go 语言

    https://github.com/pingcap/tikv
    Rust语言

    https://github.com/pingcap/tidb/blob/master/docs/QUICKSTART.md

    从零开始写分布式数据库

    https://github.com/ngaut/builddatabase

    9 图数据库

    9.1 Neo4j

    9.2 Infinite Graph

    http://www.objectivity.com/products/infinitegraph/

    an enterprise distributed graph database

    10 File存储

    10.1 Ceph

    http://ceph.com/

    https://github.com/ceph

    Ceph:一个 Linux PB 级分布式文件系统

    http://www.ibm.com/developerworks/cn/linux/l-ceph/

    10.2 FastDFS

    http://code.google.com/p/fastdfs/

    10.3 HDFS

    10.4 MogileFs

    https://github.com/mogilefs/

    10.5 MooseFS

    http://www.moosefs.org/

    a fault tolerant, network distributed file system

    10.6 TFS

    http://tfs.taobao.org/

    10.7 GlusterFS

    http://www.gluster.org/

    GlusterFS:异地备份(Geo-replication)源码分析

    http://blog.chinaunix.net/uid-22166872-id-4392777.html

    Gluster Geo-replication工作原理[转载]

    http://blog.163.com/szy8706@yeah/blog/static/62713185201363163131800/

    http://disclu.blogspot.com/2012/11/gluster-geo-replication.html

    10.8 kosmosfs

    http://code.google.com/p/kosmosfs/

    11 In-Memory 存储

    11.1 Redis cluster

    11.2 Mysql cluster

    11.3 Gemfire/Gemde

    11.4 VoltDB

    http://voltdb.com/

    内存数据库

    12 私有存储

    12.1 Amazon

    12.1.1 Amazon Dynamo

    Key-value

    http://www.allthingsdistributed.com/files/amazon-dynamo-sosp2007.pdf

    Amazon’s Dynamo paper

    Merkle trees

    Gossiping of membership

    Gossiped synchronization of partitions

    12.2 Google

    12.2.1 BigTable

    Bigtable: A Distributed Storage System for Structured Data

    http://static.googleusercontent.com/media/research.google.com/en//archive/bigtable-osdi06.pdf

    12.2.2 F1

    F1: A Distributed SQL Database That Scales

    http://research.google.com/pubs/pub41344.html

    http://static.googleusercontent.com/media/research.google.com/en//pubs/archive/41344.pdf

    12.2.3 Spanner

    http://research.google.com/archive/spanner.html

    Spanner: Google’s Globally-Distributed Database

    http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/zh-CN//archive/spanner-osdi2012.pdf

    Exclusive: Inside Google Spanner, the Largest Single Database on Earth

    http://www.wired.com/2012/11/google-spanner-time/all/

    解析全球级分布式数据库Google Spanner

    http://www.csdn.net/article/2012-09-19/2810132-google-spanner-next-database-datacenter

    12.2.4 Megastore

    Megastore: Providing Scalable, Highly Available Storage for Interactive Services

    https://research.google.com/pubs/pub36971.html

    https://static.googleusercontent.com/media/research.google.com/en//pubs/archive/36971.pdf

    12.3 Baidu

    12.3.1 Baidu Mola

    Key-value

    12.3.2 Baidu BDRP

    12.3.3 Baidu DDBS

    12.4 腾讯

    单机MySQL到NoSQL集群 腾讯存储进阶路

    http://tech.it168.com/a2017/0322/3105/000003105672.shtml

    腾讯十多个人管理一万多台NoSQL存储服务器的秘密

    http://m.techweb.com.cn/article/2016-01-06/2253310.shtml

    12.4.1 腾讯CKV

    腾讯CKV海量分布式存储系统

    http://www.csdn.net/article/2014-03-11/2818723

    12.4.2 QuorumKV

    微信PaxosStore内存云揭秘:十亿Paxos/分钟的挑战

    http://mp.weixin.qq.com/s?__biz=MzI4NDMyNTU2Mw%3D%3D&mid=2247483804&idx=1&sn=a6629ebdaefbc2470c2ecbf12577daff

    12.6 京东

    12.6.1 京东JIMDB

    解读JIMDB 京东分布式缓存与高速KV存储

    http://m.chinabyte.com/storage/463/13344963_mi.shtml

    解读JIMDB 京东分布式缓存与高速KV存储

    http://m.it168.com/article_1720792.html

    12.7 滴滴

    12.7.1 滴滴Rockstable

    滴滴高性能KV存储系统实践

    http://m.it168.com/article_3091989.html

    12.8 美团

    12.8.1 Cellar

    基于tair研发的新一代KV存储服务

    美团cellar讲座笔记

    http://blog.leanote.com/post/yuannight/cellar%E8%AE%B2%E5%BA%A7%E7%AC%94%E8%AE%B0

    12.9 360

    12.9.1 360 Bada

    Key-value

    360自研分布式存储系统Bada的架构设计和应用

    http://www.chinacloud.cn/wap.aspx?cid=16&nid=21103

    1.9.2 HustStore

    https://github.com/Qihoo360/huststore

    HustStore 360高性能分布式存储服务

    http://www.oschina.net/p/huststore?fromerr=ug3CEPNP

    13 云产品

    13.1 Amazon DynamoDB

    13.2 AWS Aurora

    https://aws.amazon.com/cn/rds/aurora/

    2.3 Google云

    2.4 阿里云

    2.5 美团云

    Mangix:分布式对象存储

    Mangix: 美团云分布式对象存储系统

    http://docs.huihoo.com/infoq/qconbeijing/2016/day2/%E4%BA%91%E5%B9%B3%E5%8F%B0%E6%9E%B6%E6%9E%84%E4%B8%93%E9%A2%98/2-6-%E7%BE%8E%E5%9B%A2%E4%B8%87%E4%BA%BF%E7%BA%A7%E5%AF%B9%E8%B1%A1%E5%AD%98%E5%82%A8%E7%B3%BB%E7%BB%9F-%E6%9D%8E%E5%87%AF.pdf



    展开全文
  • 各类分布式存储系统简介

    万次阅读 2017-10-23 15:49:51
    本地文件系统如ext3,reiserfs等(这里不讨论基于内存的文件系统),它们管理本地的磁盘存储资源、提供文件到存储位置的映射,并抽象出一套文件访问接口供用户使用。但随着互联网企业的高速发展,这些企业对数据存储...

    分布式文件系统原理

    本地文件系统如ext3,reiserfs等(这里不讨论基于内存的文件系统),它们管理本地的磁盘存储资源、提供文件到存储位置的映射,并抽象出一套文件访问接口供用户使用。但随着互联网企业的高速发展,这些企业对数据存储的要求越来越高,而且模式各异,如淘宝主站的大量商品图片,其特点是文件较小,但数量巨大;而类似于youtube,优酷这样的视频服务网站,其后台存储着大量的视频文件,尺寸大多在数十兆到数吉字节不等。这些应用场景都是传统文件系统不能解决的。分布式文件系统将数据存储在物理上分散的多个存储节点上,对这些节点的资源进行统一的管理与分配,并向用户提供文件系统访问接口,其主要解决了本地文件系统在文件大小、文件数量、打开文件数等的限制问题。


    分布式存储系统典型架构

    目前比较主流的一种分布式文件系统架构,如下图所示,通常包括主控服务器(或称元数据服务器、名字服务器等,通常会配置备用主控服务器以便在故障时接管服务,也可以两个都为主的模式),多个数据服务器(或称存储服务器,存储节点等),以及多个客户端,客户端可以是各种应用服务器,也可以是终端用户。

    分布式文件系统的数据存储解决方案,归根结底是将将大问题划分为小问题。大量的文件,均匀分布到多个数据服务器上后,每个数据服务器存储的文件数量就少了,另外通过使用大文件存储多个小文件的方式,总能把单个数据服务器上存储的文件数降到单机能解决的规模;对于很大的文件,将大文件划分成多个相对较小的片段,存储在多个数据服务器上(目前,很多本地文件系统对超大文件的支持已经不存在问题了,如ext3文件系统使用4k块时,文件最大能到4T,ext4则能支持更大的文件,只是受限于磁盘的存储空间)。

     

    理论上,分布式文件系统可以只有客户端和多个数据服务器组成,客户端根据文件名决定将文件存储到哪个数据服务器,但一旦有数据服务器失效时,问题就变得复杂,客户端并不知道数据服务器宕机的消息,仍然连接它进行数据存取,导致整个系统的可靠性极大的降低,而且完全有客户端决定数据分配时非常不灵活的,其不能根据文件特性制定不同的分布策略。

     

    于是,我们迫切的需要能知道各个数据服务器的服务状态,数据服务器的状态管理可分为分散式和集中式两种方式,前者是让多个数据服务器相互管理,如每个服务器向其他所有的服务器发送心跳信息,但这种方式开销较大,控制不好容易影响到正常的数据服务,而且工程实现较为复杂;后者是指通过一个独立的服务器(如上图中的主控服务器)来管理数据服务器,每个服务器向其汇报服务状态来达到集中管理的目的,这种方式简单易实现,目前很多分布式文件系统都采用这种方式如GFS、TFS(http://code.taobao.org/p/tfs/wiki/index/ )、MooseFS (http://www.moosefs.org/ )等。主控服务器在负载较大时会出现单点,较多的解决方案是配置备用服务器,以便在故障时接管服务,如果需要,主备之间需要进行数据的同步。


    问题及解决方法

    本文主要讨论基于上图架构的分布式文件系统的相关原理,工程实现时需要解决的问题和解决问题的基本方法,分布式文件系统涉及的主要问题及解决方法如下图所示。为方便描述以下主控服务器简称Master,数据服务器简称DS(DataServer)。

    主控服务器

    l 命名空间的维护

    Master负责维护整个文件系统的命名空间,并暴露给用户使用,命名空间的结构主要有典型目录树结构如MooseFS等,扁平化结构如淘宝TFS(目前已提供目录树结构支持),图结构(主要面向终端用户,方便用户根据文件关联性组织文件,只在论文中看到过)。

    为了维护名字空间,需要存储一些辅助的元数据如文件(块)到数据服务器的映射关系,文件之间的关系等,为了提升效率,很多文件系统采取将元数据全部内存化(元数据通常较小)的方式如GFS, TFS;有些系统借则助数据库来存储元数据如DBFS,还有些系统则采用本地文件来存储元数据如MooseFS。

     

    一种简单的实现目录树结构的方式是,在Master上存储与客户端完全一样的命名空间,对应的文件内容为该文件的元数据,并通过在Master上采用ReiserFS来进行小文件存储优化,对于大文件的存储(文件数量不会成为Master的瓶颈),这种方式简单易实现。曾经参与的DNFS系统的开发就是使用这种方式,DNFS主要用于存储视频文件,视频数量在百万级别,Master采用这种方式文件数量上不会成为瓶颈。

    l 数据服务器管理

    除了维护文件系统的命名空间,Master还需要集中管理数据DS, 可通过轮询DS或由DS报告心跳的方式实现。在接收到客户端写请求时,Master需要根据各个DS的负载等信息选择一组(根据系统配置的副本数)DS为其服务;当Master发现有DS宕机时,需要对一些副本数不足的文件(块)执行复制计划;当有新的DS加入集群或是某个DS上负载过高,Master也可根据需要执行一些副本迁移计划。

     

    如果Master的元数据存储是非持久化的,则在DS启动时还需要把自己的文件(块)信息汇报给Master。在分配DS时,基本的分配方法有随机选取,RR轮转、低负载优先等,还可以将服务器的部署作为参考(如HDFS分配的策略),也可以根据客户端的信息,将分配的DS按照与客户端的远近排序,使得客户端优先选取离自己近的DS进行数据存取.

    l 服务调度

    Master最终的目的还是要服务好客户端的请求,除了一些周期性线程任务外,Master需要服务来自客户端和DS的请求,通常的服务模型包括单线程、每请求一线程、线程池(通常配合任务队列)。单线程模型下,Master只能顺序的服务请求,该方式效率低,不能充分利用好系统资源;每请求一线程的方式虽能并发的处理请求,但由于系统资源的限制,导致创建线程数存在限制,从而限制同时服务的请求数量,另外,线程太多,线程间的调度效率也是个大问题;线程池的方式目前使用较多,通常由单独的线程接受请求,并将其加入到任务队列中,而线程池中的线程则从任务队列中不断的取出任务进行处理。

    l 主备(主)容灾

    Master在整个分布式文件系统中的作用非常重要,其维护文件(块)到DS的映射、管理所有的DS状态并在某些条件触发时执行负载均衡计划等。为了避免Master的单点问题,通常会为其配置备用服务器,以保证在主控服务器节点失效时接管其工作。通常的实现方式是通过HA、UCARP等软件为主备服务器提供一个虚拟IP提供服务,当备用服务器检测到主宕机时,会接管主的资源及服务。

     

    如果Master需要持久化一些数据,则需要将数据同步到备用Master,对于元数据内存化的情况,为了加速元数据的构建,有时也需将主上的操作同步到备Master。处理方式可分为同步和异步两种。同步方式将每次请求同步转发至备Master,这样理论上主备时刻保持一致的状态,但这种方式会增加客户端的响应延迟(在客户端对响应延迟要求不高时可使用这种方式),当备Master宕机时,可采取不做任何处理,等备Master起来后再同步数据,或是暂时停止写服务,管理员介入启动备Master再正常服务(需业务能容忍);异步方式则是先暂存客户端的请求信息(如追加至操作日志),后台线程重放日志到备Master,这种方式会使得主备的数据存在不一致的情况,具体策略需针对需求制定。


    数据服务器

    l 数据本地存储

    数据服务器负责文件数据在本地的持久化存储,最简单的方式是将客户每个文件数据分配到一个单独的DS上作为一个本地文件存储,但这种方式并不能很好的利用分布式文件系统的特性,很多文件系统使用固定大小的块来存储数据如GFS, TFS, HDFS,典型的块大小为64M。

     

    对于小文件的存储,可以将多个文件的数据存储在一个块中,并为块内的文件建立索引,这样可以极大的提高存储空间利用率。Facebook用于存储照片的HayStack系统的本地存储方式为,将多个图片对象存储在一个大文件中,并为每个文件的存储位置建立索引,其支持文件的创建和删除,不支持更新(通过删除和创建完成),新创建的图片追加到大文件的末尾并更新索引,文件删除时,简单的设置文件头的删除标记,系统在空闲时会对大文件进行compact把设置删除标记且超过一定时限的文件存储空间回收(延迟删除策略)。淘宝的TFS系统采用了类似的方式,对小文件的存储进行了优化,TFS使用扩展块的方式支持文件的更新。对小文件的存储也可直接借助一些开源的KV存储解决方案,如Tokyo Cabinet(HDB, FDB, BDB, TDB)、Redis等。

     

    对于大文件的存储,则可将文件存储到多个块上,多个块所在的DS可以并行服务,这种需求通常不需要对本地存储做太多优化。

    l 状态维护

    DS除了简单的存储数据外,还需要维护一些状态,首先它需要将自己的状态以心跳包的方式周期性的报告给Master,使得Master知道自己是否正常工作,通常心跳包中还会包含DS当前的负载状况(CPU、内存、磁盘IO、磁盘存储空间、网络IO等、进程资源,视具体需求而定),这些信息可以帮助Master更好的制定负载均衡策略。

     

    很多分布式文件系统如HDFS在外围提供一套监控系统,可以实时的获取DS或Master的负载状况,管理员可根据监控信息进行故障预防。

    l 副本管理

    为了保证数据的安全性,分布式文件系统中的文件会存储多个副本到DS上,写多个副本的方式,主要分为3种。最简单的方式是客户端分别向多个DS写同一份数据,如DNFS采用这种方式;第2种方式是客户端向主DS写数据,主DS向其他DS转发数据,如TFS采用这种方式;第三种方式采用流水复制的方式,client向某个DS写数据,该DS向副本链中下一个DS转发数据,依次类推,如HDFS、GFS采取这种方式。

     

    当有节点宕机或节点间负载极不均匀的情况下,Master会制定一些副本复制或迁移计划,而DS实际执行这些计划,将副本转发或迁移至其他的DS。DS也可提供管理工具,在需要的情况下由管理员手动的执行一些复制或迁移计划。

    l 服务模型

    参考主控服务器::服务模型一节


    客户端

    l 接口

    用户最终通过文件系统提供的接口来存取数据,linux环境下,最好莫过于能提供POSIX接口的支持,这样很多应用(各种语言皆可,最终都是系统调用)能不加修改的将本地文件存储替换为分布式文件存储。

     

    要想文件系统支持POSIX接口,一种方式时按照VFS接口规范实现文件系统,这种方式需要文件系统开发者对内核有一定的了解;另一种方式是借助FUSE(http://fuse.sourceforge.net)软件,在用户态实现文件系统并能支持POSIX接口,但是用该软件包开发的文件系统会有额外的用户态内核态的切换、数据拷贝过程,从而导致其效率不高。很多文件系统的开发借助了fuse,参考http://sourceforge.net/apps/mediawiki/fuse/index.php?title=FileSystems

     

    如果不能支持POSIX接口,则为了支持不同语言的开发者,需要提供多种语言的客户端支持,如常用的C/C++、java、php、python客户端。使用客户端的方式较难处理的一种情况时,当客户端升级时,使用客户端接口的应用要使用新的功能,也需要进行升级,当应用较多时,升级过程非常麻烦。目前一种趋势是提供Restful接口的支持,使用http协议的方式给应用(用户)访问文件资源,这样就避免功能升级带来的问题。

     

    另外,在客户端接口的支持上,也需根据系统需求权衡,比如write接口,在分布式实现上较麻烦,很难解决数据一致性的问题,应该考虑能否只支持create(update通过delete和create组合实现),或折中支持append,以降低系统的复杂性。

    l 缓存

    分布式文件系统的文件存取,要求客户端先连接Master获取一些用于文件访问的元信息,这一过程一方面加重了Master的负担,一方面增加了客户端的请求的响应延迟。为了加速该过程,同时减小Master的负担,可将元信息进行缓存,数据可根据业务特性缓存在本地内存或磁盘,也可缓存在远端的cache系统上如淘宝的TFS可利用tair作为缓存(减小Master负担、降低客户端资源占用)。

     

    维护缓存需考虑如何解决一致性问题及缓存替换算法,一致性的维护可由客户端也可由服务器完成,一种方式是客户端周期性的使cache失效或检查cache有效性(需业务上能容忍),或由服务器在元数据更新后通知客户端使cache失效(需维护客户端状态)。使用得较多的替换算法如LRU、随机替换等。

    l 其他

    客户端还可以根据需要支持一些扩展特性,如将数据进行加密保证数据的安全性、将数据进行压缩后存储降低存储空间使用,或是在接口中封装一些访问统计行为,以支持系统对应用的行为进行监控和统计。


    总结

    本文主要从典型分布式文件系统架构出发,讨论了分布式文件系统的基本原理,工程实现时需要解决的问题、以及解决问题的基本方法,真正在系统工程实现时,要考虑的问题会更多。如有问题,欢迎拍砖。


    HDFS 架构解析

    文以 Hadoop 提供的分布式文件系统(HDFS)为例来进一步展开解析分布式存储服务架构设计的要点。

    架构目标

    任何一种软件框架或服务都是为了解决特定问题而产生的。还记得我们在 《分布式存储 - 概述》一文中描述的几个关注方面么?分布式文件系统属于分布式存储中的一种面向文件的数据模型,它需要解决单机文件系统面临的容量扩展和容错问题。

    所以 HDFS 的架构设计目标就呼之欲出了:

    1. 面向超大文件或大量的文件数据集
    2. 自动检测局部的硬件错误并快速恢复

    基于此目标,考虑应用场景出于简化设计和实现的目的,HDFS 假设了一种 write-once-read-many 的文件访问模型。这种一次写入并被大量读出的模型在现实中确实适应很多业务场景,架构设计的此类假设是合理的。正因为此类假设的存在,也限定了它的应用场景。

    架构总揽

    下面是一张来自官方文档的架构图: 
    这里写图片描述

    从图中可见 HDFS 的架构包括三个部分,每个部分有各自清晰的职责划分。

    1. NameNode
    2. DataNode
    3. Client

    从图中可见,HDFS 采用的是中心总控式架构,NameNode 就是集群的中心节点。

    NameNode

    NameNode 的主要职责是管理整个文件系统的元信息(Metadata),元信息主要包括:

    • File system namesapce 
      HDFS 类似单机文件系统以目录树的形式组织文件,称为 file system namespace
    • Replication factor 
      文件副本数,针对每个文件设置
    • Mapping of blocks to DataNodes 
      文件块到数据节点的映射关系

    在上面架构图中,指向 NameNode 的 Metadata ops 主要就是针对文件的创建、删除、读取和设置文件的副本数等操作,所以所有的文件操作都绕不过 NameNode。除此之外 NameNode 还负责管理 DataNode,如新的 DataNode 加入集群,旧的 DataNode 退出集群,在 DataNode 之间负载均衡文件数据块的分布等等。更多关于 NameNode 的设计实现分析,后面会单独成文详解。

    DataNode

    DataNode 的职责如下:

    • 存储文件块(block)
    • 服务响应 Client 的文件读写请求
    • 执行文件块的创建、删除和复制

    从架构图上看到有个 Block ops 的操作箭头从 NameNode 指向 DataNode,会让人误以为 NameNode 会主动向 DataNode 发出指令调用。实际上 NameNode 从不调用 DataNode,仅仅是通过 DataNode 定期向 NameNode 发送心跳来携带回传的指令信息。

    架构图上专门标记了 Rack1 和 Rack2,表明了 HDFS 在考虑文件数据块的多副本分布时针对机架感知作了专门设计,细节我们这里先不展开,更多关于 DataNode 的设计实现分析,后面会单独成文详解。

    Client

    考虑到 HDFS 交互过程的复杂性,所以特地提供了针特定编程语言的 Client 以简化使用。Client 的职责如下:

    • 提供面向应用编程语言的一致 API,简化应用编程
    • 改善访问性能

    Client 之所以能够改善性能是因为针对读可以提供缓存(cache),针对写可以通过缓冲(buffer)批量方式,细节我们这里也先不展开,更多关于 Client 的设计实现分析,后面会单独成文详解。

    总结

    本来想在一篇文章里写完 HDFS 架构解析的,写着写着发现不太可能。作为分布式系统中最复杂的分布式存储类系统,每一个架构设计权衡的实现细节点,都值得好好推敲,一旦展开此文感觉就会长的没完没了,所以这里先总体过一下,针对每个部分的设计实现细节再以主题文章来详细解析。

    参考

    [1]Hadoop Documentation. HDFS Architecture
    [2]Robert Chansler, Hairong Kuang, Sanjay Radia, Konstantin Shvachko, and Suresh Srinivas. The Hadoop Distributed File System


    分布式存储系统sheepdog


    Sheepdog,是由NTT的3名日本研究员开发的开源项目,主要用来为虚拟机提供块设备。

    其架构如下:

     

     

     

    下面,我们将从架构、模块等几个方面来介绍下:

     

    一、架构图

    如上图:

    采用无中心节点的全对称架构,无单点故障,存储容量和性能可线性扩展;

    新增节点通过简单配置可自动加入(IP:PORT),数据自动实现负载均衡;

    节点故障时,数据可自动恢复;

    直接支持QEMU/KVM应用;

     

    二、模块

     

    如上图:

    由corosync,完成集群成员管理和消息传递;

    由Qemu作为Sheepdog的客户端,提供NBD/iSCSI协议支持;

    由gateway实现数据的DHT路由,由storage server数据数据本地存储;

     

    三、数据具体存储方式

     

    如上图:

    以VDI Object存储VM数据,向用户暴露的是一个块设备;

    包含4种数据对象:VDI、Data Object、属性对象和用于快照的VM实时状态数据对象;

    以4M的小文件方式实现OBS,但很容易基于此扩展,如使用使用库替代4M的小文件;

     

    四、集群管理

    1. 采用corosync,tot是em协议的一个开源实现。totem协议主要用来实现集群成员管理和可靠顺序传输。

    2. corosync通过提供一个CPG API来提供服务。

    首先,绑定一个fd到cpg_handle,并注册回调函数cpg_dispatch;

    然后将fd注册到epoll;

    corosync上消息会触发fd改变,通用epoll触发回调函数cpg_dispatch;

     

    这里主要有两个函数,cpg_deliver_fn和cpg_confchg_fn,分别对应sd_deliver和sd_confchg.

     其中,sd_deliver负责集群从corosync给本地发消息,主要是针对VDI进行操作;而sd_confchg主要是对node进行操作,用来监控集群成员变化。

     

    五、存储对象管理

    集群对象版本epoch;

    obj目录下,每个新的epoch要对应创建一个新的目录;

    可从epoch恢复数据;

     

    六、一致性模型

    通过epoll机制保证;

    通过数据操作实现强一致性(多副本的写同时成功时,才向client返回); 

     

    七、DHT路由

    代理路由方式;

    由ip:port生成节点编号,做一致性哈希;

     

    八、副本放置

    一致性哈希;

    虚拟节点;

     

    如需了解更详细信息,可参考其官网:http://www.osrg.net/sheepdog/



    文章转自:

    http://blog.csdn.net/it_yuan/article/details/8980849

    http://blog.csdn.net/kidd_3/article/details/8154964

    http://blog.csdn.net/mindfloating/article/details/47842495








    展开全文
  • 主存中通常包含ROM(用于存储操作系统的引导程序)和RAM(用来存储大部分数据) 2.辅助存储器:是主存储器的后援存储器,用来存放当前暂时不用的程序和数据,以及一些需要永远保存的信息,它不能与CPU直接交换信息,...
  • 开源分布式存储系统的对比

    万次阅读 2019-12-23 17:56:24
    我们在选型开源分布式存储系统框架之前需要对不同的框架进行调研。 所有的开源存储系统介绍链接 存储系统对比 目前比较热门的分布式文件系统有如下几种: Ceph,GlusterFS,Sheepdog,Lustre,Swift,Cinder,TFS,HDFS...
  • 存储系统科普——文件系统介绍

    千次阅读 2018-08-17 10:20:55
    简介 该篇blog只是存储系列科普文章中的第二篇,所有文章请参考: 博客所有文章 在工程架构领域里,存储是一个非常重要的方向,这个方向从底至上,我分成了如下几个层次来介绍... 单机引擎层:常见存储系统对应单...
  • 存储系统和结构

    千次阅读 2018-06-10 22:37:09
    很久没有在CSDN上面发文章了,最近...将两个或来两个以上速度、容量和价格各不相同的存储器用硬件、软件或硬件软件结合的方式连接起来形成存储系统。这个系统对应用程序员是透明,即从应用程序员角度来看,它是一...
  • 什么才是真正的存储系统

    千次阅读 2018-10-28 19:09:39
    在这个数据横行的时代,每个人的生活已经离不开数据信息。财富变成支付宝上的一串数字,一张身份证和一部手机就能行走天下,是因为我们能够随时随地取用...对于存储系统的理解,一般分为狭义的存储系统与广义的存...
  • 分布式存储系统

    千次阅读 2017-05-23 15:36:13
    (一)分布式存储系统应该具备的能力; (二)阿里云分布式存储系统盘古的介绍; (三)分布式系统技术展望。 分布式存储系统应该具备的能力 大数据同生活息息相关,大量数据的出现对分布式存储提出了更高的...
  • Ceph分布式存储系统

    千次阅读 2017-06-06 22:57:45
    Ceph是根据加州大学Santa Cruz分校的Sage Weil的博士论文所设计开发的新一代自由软件分布式文件系统,其设计目标是良好的可扩展性(PB级别以上)、高性能及高可靠性。Ceph其命名和UCSC(Ceph 的诞生地)的吉祥物有关,...
  • 分布式存储系统设计的若干原则

    万次阅读 热门讨论 2011-02-20 16:16:00
    分布式存储系统设计中很多指标是不可得兼的,必须根据需求有所取舍。CAP理论、最终一致性、BASE理论、I/O五分钟法则、Amdahl定律和Gustafson定律、摩尔定律等,就是分布式存储系统设计的的几个经典的指导法则。
  • 虚拟存储实现思路在实际运行过程,把有关作业的全部信息都装入主存储器后,作业执行时实际上不是同时使用全部信息的,有些部分运行一遍便再也不用,甚至有些部分在作业执行的整个过程中都不会被使用到(如错误处理部分...
  • 传统存储系统发展史调研

    千次阅读 2015-10-20 14:43:27
    *原创文章,转载请注明: 转载...每一个技术的进步势必伴随着市场需求的不断扩张,这里存储系统的技术演进和IT系统的需求息息相关,既有对于存储设备硬件本身的改善和演进,同样也有上层针对存储设备组织构建的存储系统
  • 基于Hadoop构建对象存储系统

    千次阅读 2011-03-09 10:16:00
    基于Hadoop构建对象存储系统By云深作者:Terry/Alen/Adam/SeymourZ转载请注明出处前言 l 云计算领域目前有两大代表性系统:Google和Amazon,它们各自的存储系统
  • 常见开源分布式存储系统

    万次阅读 2017-04-20 19:49:20
    系统整体对比 对比说明 /文件系统 TFS FastDFS MogileFS MooseFS GlusterFS Ceph 开发语言 C++ C Perl C C C++ 开源协议...
  • https://blog.csdn.net/enweitech/article/details/51445087 块存储和文件存储是我们比较熟悉的两种主流的存储类型,而对象存储(Object-based Storage)是一种新的网络存储架构,基于对象存储技术的设备就是对象...
  • 存储系统层次结构

    千次阅读 2015-09-28 08:44:06
    MDR 和 MAR分别是数据寄存器和地址寄存器。所谓的主存就是内存。我们印象中很重要的硬盘只算辅存而已。CPU只能直接访问内存、缓存,只能通过IO设备间接访问辅存。
  • 华科计算机组成原理存储系统实验(Logisim) 这篇是关于存储系统的实验,较于运算器实验难度提升了一大截,更加的注重原理
  • MongoDB的分布式文件存储系统

    千次阅读 2017-03-06 15:17:58
    对于MongoDB的存储基本单元BSON文档对象,字段值可以是二进制类型,基于此特点,我们可以直接在MongoDB中存储文件,但是有一个限制,由于...小文件存储系统与GridFS文件存储我们先看下MongoDB存储小文件系统的例子
1 2 3 4 5 ... 20
收藏数 2,352,925
精华内容 941,170
关键字:

存储系统