高级数据库典型技术

标签: 数据库 典型 技术 | 发表时间:2014-10-09 21:18 | 作者:Androidlushangderen
出处:http://blog.csdn.net

            数据库作为计算机学科中一个比较重要的分支,也是一个对于程序员来说非常好的学习方向。平时我们用的最多的,同时也是接触最多的一定是增删改查语句,select,

update,delete等,当然,我不会拿这些再说一遍,这些都是老的掉渣的东西了。所以我们可以学习高级数据库中所以涉及的技术。换句话,其实就是抛开业务层的逻辑,从更加深层次的角度理解数据库。今天我主要提交3个技术点,

1.数据索引技术,典型的B+树索引系列

2.数据库故障恢复技术,我这里只提的是基于日志的恢复技术

3.数据库系统结构,讲讲时下流行的分布式数据库系统

          数据库索引技术关系着数据的查询速度,当数据量比较小的时候,响应是没有问题,当数据库中拥有百万,千万级数据量的数据时,建立索引是必须的。传统的数据查询操作时在海量数据中一条条的查询,在磁盘块中逐个寻找效率当然不高,如果是连续存储的还算运气好,如果是物理上不连续的,那结果可想而知。所以在这里我们引入了一个名叫“index”索引概念的东西,他不保存真实的数据,索引其实是一个指向真实数据记录的地址指针,要查询的数据的时候,先找到此索引值,然后根据此索引值,找到真实记录地址,因为不保存真实数据,索引查询的速度比较快。首先我们说说顺序索引,顺序索引的定义是当数据文件的存储顺序是按某个索引键值的顺序排列时,称该文件为顺序文件,为顺序文件建立索引的时候,一般此索引的建立以某个索引键一致,比如说某ID建立的索引为顺序索引,顺序文件的索引可以采用二分查找方法能够很快定位到相应的索引记录。B+树索引是以平衡树的结构构建的索引,B+树凭借其特殊的结构设计,一直保持着一种比较高的查询效率,在我之前的文章中也都提到过了。最后说的是散列索引,散列索引是利用哈希函数将搜索键值,分别映射到M个记录搜索键值存储地址的桶中,这样可以利用哈希算法直接检索,我们都知道哈希算法,的速度是相当快的哦,但是同时此时的一个好的哈希算法就显得至关重要了,最好能将索引记录均匀地分布到各个桶中。

        基于日志的恢复技术也是数据库容灾处理的一部分,这里的日志主要有3个,undo,redo,undo/redo三种。undo,从这个英文中我们也可大概知道他的意思是不要做,就是撤销操作的意思了,一般我们在操作未完全完成的情况下才会执行撤销动作,这样可以避免脏数据的诞生。undo的日志就是为了防止出现这个情况的。undo的日志记录结构为:

<T, X, V>

其中:T是更新数据的事务,X是T更新的数据元素,V是更新前的旧值,数据出错了就是拿这个值更新回去的,一个完整的undo日志记录如下:

<start T> //开启事务

<T, A, 10 >  //对数据A 进行了数据更改,把他的旧值记录下来

<T,B,10>  //对数据B进行了数据操作,把B的旧值也记录下来

<COMMIT T>  //事务执行成功,也记录

如果在commit 操作之前系统故障了,也就是<COMMIT T>没有写入记录中,也不知道数据操作到底对不对,日志统一从后往前逆序读取,首先遇到<T,B,10> ,将B更新到旧值10,然后又遇到<T,A,10> ,将A还原回到10,直到遇到<start T> ,说明事物恢复成功,又回到了事物的出发点日志恢复结束。undo日志的事务执行顺序为:

(1).写更新数据量元素的日志

(2).再写更新的数据元素

(3).最后写COMMIT,表明事务已经成功提交

但是在这里其实会暴露一个潜在的问题,此要求事务必须将所做的修改写到磁盘后才能提交事务,这无疑增加了I/O开销,实际上,我们可以将数据的修改操作暂缓写到磁盘上,等到缓冲区满时再写入磁盘,就可以节省很多I/O操作了,于是就有了redo日志的出现,redo日志的格式与undo日志略有区别:

(1).写更新数据量元素的日志

(2).再写COMMIT,表明事务已经成功提交

(3).最后写更新的数据元素

所以如果在2,3步骤直接出错,系统也当时值已经更新成功了,会重做操作的,<T, A, V>这里的V保存的就是新的值,用于重做操作时使用的,说明A,B的值可能延迟更长的时间才能写到磁盘中,如果这段时间系统出异常了,就redo操作,还有一种是undo/redo,模式相结合的,灵活性最强。所有的日志记录都要检查点的一个机制,检查点之前的记录都可以忽略不计了,每次都从新的检查点开始,检查点的2个标记为:

<START CKPT>

<END CKPT>

每次寻找到END CKPT,可以将上一个前的<START CKPT>的日志丢弃。

         最后来看看近年来随着分布式系统的出现,也出现了分布式数据库的概念,分布式数据库数据库系统可以看做一系列的集中式数据库的联合,在逻辑上属于同一系统,物理上是分布式,不连续的。他们之间的唯一联系就是----网络。一个数据库的查询可以涉及多地的分布式数据查询,与之相应的还有分布式事务管理,这个比分布式查询更为复杂,网络因素将成为影响分布式查询时间的最大的影响因素,在传统的本地数据库中,计算机的CPU处理速度会是影响查询速度的最主要因素,与现在的分布式数据库是截然不同的,所以分布式数据库的设计能设置成本地访问的就不要搞成分布式的查询,一般90%的查询可以用在本地查询,真到了那10%就通过分布式查询的方式,而且分布式的查询,也应该选择离自己最近的一个分布式数据库中。分布式数据的设计方法有自底向上和自顶向下2种,这个我就不展开了,比较复杂。

作者:Androidlushangderen 发表于2014-10-9 21:18:36 原文链接
阅读:0 评论:0 查看评论

相关 [数据库 典型 技术] 推荐:

高级数据库典型技术

- - CSDN博客推荐文章
            数据库作为计算机学科中一个比较重要的分支,也是一个对于程序员来说非常好的学习方向. 平时我们用的最多的,同时也是接触最多的一定是增删改查语句,select,. update,delete等,当然,我不会拿这些再说一遍,这些都是老的掉渣的东西了. 所以我们可以学习高级数据库中所以涉及的技术.

阿里双十一数据库技术

- - Hello Database
真的很抱歉,我的博客已经很久没有更新了,因为花了太多的时间在微博和微信上,当然最主要的原因还是工作实在太忙了,仅剩的那点业余时间都用来陪娃了. 从2012年开始,工作重心转移到了淘宝和天猫,我的技术方向也发生了改变,2012年和2013年,经历了两次双十一,在这个过程中学到了很多东西. 尤其是2013年的双十一,系统准备的非常充分,技术上有很多创新,团队也得到了成长.

oracle数据库同步技术

- - 数据库 - ITeye博客
项目上有一个需求,从外网的另一个库中的数据同步到其他网段中. 基于Oracle数据库的数据同步技术大体上可分为两类:Oracle自己提供的数据同步技术和第三方厂商提供的数据同步技术. Oracle自己的同步技术有DataGuard,Streams,Advanced Replication和今年刚收购的一款叫做GoldenGate的数据同步软件.

数据库压缩技术探索

- - 文章 – 伯乐在线
作者:雷鹏,Terark核心技术发明人. 曾就职奇虎360,负责搜索引擎核心研发;曾就职Yahoo. 北研所负责搜索广告、广告交易(AdExchange)等项目. 在数据库、高性能计算、分布式、系统架构上都深有造诣. 作为数据库,在系统资源(CPU、内存、SSD、磁盘等)一定的前提下,我们希望:. 存储的数据更多:采用压缩,这个世界上有各种各样的压缩算法;.

[转]内存数据库的几个典型应用场景

- - 小鸥的博客
近些年内存数据库(IMDB)技术发展迅猛. 除了与生俱来的高性能之外,IMDB本身越来越向着功能完整的独立DB的方向发展. 下面简单描述当前比较常见的几个IMDB应用场景,希望对有志于IMDB技术的同僚以启发——. IMDB最大规模的应用集中在电信领域,尤其以计费系统为主. 当然,近些年陆续开始向新的电信业务领域拓展,例如核心网、CRM、精确营销等.

年度技术回顾之数据库、NoSQL、开源软件

- kezhuw - DBA Notes
本文已经首发于InfoQ中文站,版权所有,原文为年度技术回顾之数据库、NoSQL、开源软件,如需转载,请务必附带本声明,谢谢. InfoQ中文站是一个面向中高端技术人员的在线独立社区,为Java、.NET、 Ruby、SOA、敏捷、架构等领域提供及时而有深度的资讯、高端技术大会如QCon、免费迷你书下载如《架构师》等.

数据库老兵:大数据时代NoSQL不是颠覆性技术

- - IT经理网
数年前,当人们谈论起新兴的NoSQL数据库技术时,相当一部分观点认为NoSQL在大数据市场取代传统关系型数据库只是个时间问题. 如今,这一预言并未兑现,Mitchell Kertzman的总经理Hummer Winblad认为,大多数情况下,NoSQL都没有展现出所谓的革命性. 作为数据库的老兵,以下是Kertzman在本周的视频 访谈的一些观点摘录:.

Spotify工程师讲述如何使用“无聊”技术完成服务发掘和数据库服务

- - InfoQ cn
Björn Edström是互联网音乐服务Spotify的工程师,在Spotify的官方博客中,他讲述了 Spotify为什么要使用一些“无聊”技术的原因. 在Spotify的后端服务和架构中,我们使用了这些成熟和经过验证的技术,我会说明如何实现,以及这样做的原因. 此外,我们还会试图说明Spotify何时不会使用某些经过验证的技术,背后的原因以及它们的问题.

数据库sharding

- - 数据库 - ITeye博客
当团队决定自行实现sharding的时候,DAO层可能是嵌入sharding逻辑的首选位置,因为在这个层面上,每一个DAO的方法都明确地知道需要访问的数据表以及查询参数,借助这些信息可以直接定位到目标shard上,而不必像框架那样需要对SQL进行解析然后再依据配置的规则进行路由. 另一个优势是不会受ORM框架的制约.

数据库索引

- - CSDN博客推荐文章
索引是由用户创建的、能够被修改和删除的、实际存储于数据库中的物理存在;创建索引的目的是使用户能够从整体内容直接查找到某个特定部分的内容. 一般来说,索引能够提高查询,但是会增加额外的空间消耗,并且降低删除、插入和修改速度. 1.聚集索引:表数据按照索引的顺序来存储的. 2.非聚集索引:表数据存储顺序与索引顺序无关.