磁盘数据库 DRDB

磁盘数据库定义

磁盘数据库(DRDB) 需要频繁地访问磁盘来进行数据的操作,由于对磁盘读写数据的操作一方面要进行磁头的机械移动,另一方面受到系统调用(通常通过CPU中断完成,受到CPU时钟周期的制约)时间的影响,当数据量很大,操作频繁且复杂时,就会暴露出很多问题。 内存数据库数据处理速度比传统数据库的数据处理速度要快很多,一般都在10倍以上。

磁盘数据库代表

典型的磁盘数据库就是最常用的 Oracle,Mysql,Mongodb、postgresql等。

磁盘数据库优点

支持ACID事务特性,数据完整性好
数据库可用性高
发展时间较长,产品及配套工具成熟度高
磁盘数据库缺点
需要缓冲处理,占用大量系统资源
数据存取速度慢
数据存取时间不一致,且难以预测

磁盘数据库应用场景

对数据读写性能要求不高的常规场景

磁盘数据库和内存数据库,在安全和性能方面各有优劣。因此许多企业为满足多重约束, 主要采取“磁盘数据库+内存数据库”配套使用的解决方案,分别处理冷热数据。

数据集成和应用集成 你瞅啥?

数据集成和应用集成是组织利用来自不同系统的数据的方法,但它们满足不同的需求。它们经常被错误地视为相同,然而应用程序集成和数据集成的概念有很大的不同,尤其是在它们的使用方式和用途方面。

数据集成

数据集成是集成两个或多个数据库数据的过程(process)。关注于管理数据流,并且每个标准化的信息获取方式;是面向批处理的,它处理静态数据。换句话说,数据集成是对应用系统已产生并“落地”后的数据进行感知、抽取、传输、处理、加载到目标库的整个过程,即数据集成的任务开始时,源端应用系统的数据产生过程已完成了。

数据集成领域还包括一些特殊的应用场景,如异构数据库间的复制同步(即按事务边界实时复制Replicate)、 CDC(日志DML、DDL获取及同步)、 数据文件(txt、csv、excel等)加载数据库、以及非结化文件交换传输(文件目录、FTP、HDFS)等应用场景。

特征

  • 参与数据集成的各个应用系统与集成任务是互相独立的,应用系统无需知道运行中的数据集成任务;
  • 数据集成任务可以是实时的、准实时的、或批处理定时的;
  • 当交换的数据完成时,目标系统无需立即给源端系统反馈信息,因而往往是异步处理过程;
  • ETL、ELT、CDC技术往往用于数据集成场景中

应用集成

应用集成是指两个或多个应用之间的协同处理过程(process)。在两个或多个应用程序之间创建连接器,以确保它们可以一起运行。应用程序集成过程涉及实时处理小数据集;这使公司能够在与性能相关的问题、新信息等出现时加快响应速度。

特征

  • 参与应用集成的数据库无需知道运行中的应用集成过程(process);
  • 消费数据的应用系统在应用层保持之间的依赖性(耦合度相对高);
  • 应用集成是实时的且需要双向的握手(handshake);
  • 消费数据后,目标业务过程可以返回执行结果给源端应用,因而往往是同步的处理过程;
  • 被集成交换的数据可无需“落地”数据库,仅由用户界面使用数据进行展示;
  • 面向服务的架构(SOA)设计理念及ESB技术产品往往应用于应用集成领域。

LSM浅析

1、简介

定义:Log-Structured Merge Tree,简称 LSM-Tree.

遥想当年,谷歌发表了 “BigTable” 的论文, 它所使用的文件组织方式,这个方法更一般的名字叫 Log Structured-Merge Tree。

LSM是当前被用在许多产品的文件结构策略:比如 Apache HBase, Apache Cassandra, MongoDB 的 Wired Tiger 存储引擎, LevelDB 存储引擎, RocksDB 存储引擎等、 SQLite,甚至在mangodb3.0中也带了一个可选的LSM引擎(Wired Tiger 实现的)。

LSM 有趣的地方是他抛弃了大多数数据库所使用的传统文件组织方法,LSM把一棵大树拆分成N棵小树,它首先写入内存中,随着小树越来越大,内存中的小树会flush到磁盘中,磁盘中的树定期可以做merge操作,合并成一棵大树,以优化读性能。将对数据的修改增量保持在内存中,达到指定的大小限制后将这些修改操作批量写入磁盘,不过读取的时候稍微麻烦,需要合并磁盘中历史数据和内存中最近修改操作,所以写入性能大大提升,读取时可能需要先看是否命中内存,否则需要访问较多的磁盘文件。

磁盘和内存中的树合并

简单地说,LSM 的设计目标是提供比传统的 B+ 树更好的写性能。LSM 通过将磁盘的随机写转化为顺序写来提高写性能 ,而付出的代价就是牺牲部分读性能、写放大(B+树同样有写放大的问题)。

磁盘随机读写和顺序读写性能对比

从上图中我们可以直观的看出来,顺序读写磁盘(不管是SATA还是SSD)快于随机读写主存,而且快至少N个数量级。这就要我们在设计的时候要避免随机读写,最好是顺序读写。通常LSM-tree适用于索引插入比检索更频繁的应用系统。 而LSM-tree通过滚动合并和多页块的方法推迟和批量进行索引更新,充分利用内存来存储近期或常用数据以降低查找代价,利用硬盘来存储不常用数据以减少存储代价。

2、读性能优化

  • 二分查找: 将文件数据有序保存,使用二分查找来完成特定key的查找。
  • 哈希:用哈希将数据分割为不同的bucket
  • B+树:使用B+树 或者 ISAM 等方法,可以减少外部文件的读取
  • 外部文件: 将数据保存为日志,并创建一个hash或者查找树映射相应的文件

所有的方法都可以有效的提高了读操作的性能,都强加了总体的结构信息在数据上,数据被按照特定的方式放置,可以很快的找到特定的数据,但是却对写操作不友善,让写操作性能下降。更糟糕的是,当我们需要更新hash或者B+树的结构时,需要同时更新文件系统中特定的部分,这就是上面说的比较慢的随机读写操作。

3、权衡读写

LevelDB 为代表的 LSM 存储引擎实现的是优化后的 LSM,LevelDB 的写速度非常快,写操作主要由两步组成:

  • 写日志并持久化(Append Only)。
  • Apply 到内存中的 memtable(SkipList)。

基本的思路与原始的LSM类似,memtable 写“满”后,会转换为 immutable memtable,然后被后台线程 compaction 成按 Key 有序存储的 sst 文件(顺序写)。由于 sst 文件会有多个,所以 LevelDB 的读操作可能会有多次磁盘 IO(LevelDB 通过 table cache、block cache 和 bloom filter 等优化措施来减少读操作的磁盘 IO 次数)。

参考链接: http://www.benstopford.com/2015/02/14/log-structured-merge-trees/