LevelDb简介

  categories:java资料  tags:  author:

Leveldb是一个google实现的非常高效的kv数据库,目前的版本1.2能够支持billion级别的数据量了。 在这个数量级别下还有着非常高的性能,主要归功于它的良好的设计。特别是LMS算法。

LevelDb
说起LevelDb也许您不清楚,但是如果作为IT工程师,不知道下面两位大神级别的工程师,那您的领导估计会Hold不住了:Jeff Dean和Sanjay Ghemawat。这两位是Google公司重量级的工程师,为数甚少的Google Fellow之二。

Jeff Dean其人:http://research.google.com/people/jeff/index.html,Google大规模分布式平台Bigtable和MapReduce主要设计和实现者。

Sanjay Ghemawat其人:http://research.google.com/people/sanjay/index阅读全文

MyBatis的动态SQL详解

  categories:资料  tags:,   author:

MyBatis的动态SQL是基于OGNL表达式的,它可以帮助我们方便的在SQL语句中实现某些逻辑。

MyBatis中用于实现动态SQL的元素主要有:

  • if
  • choose(when,otherwise)
  • trim
  • where
  • set
  • foreach
if就是简单的条件判断,利用if语句我们可以实现某些简单的条件选择。先来看如下一个例子:
Xml代码
  1. <select id=”dynamicIfTest” parameterType=”Blog” resultType=”Blog”>
  2. select * from t_blog where 11 = 1
  3. <if test=”title != null”>
  4. and title = #{title}
  5. </if>
  6. <if test=”content != null”>
  7. and content = #{content}
阅读全文

PostgreSQL 9.1的新特性

  categories:资料  tags:  author:

著名的开源关系型数据库PostgreSQL本年度的发行版,也就是PostgreSQL 9.1的第一个beta版本,于五月二号正式出炉。而新版本所包含的许多新特性肯定会令世界上的数据库发烧友们欣喜若狂的。新特性如此之多,我们肯定不能在这篇文章中全部介绍,因此我挑选了四个比较有意思的新特性呈现给大家:

事务控制的同步复制

去年,PostgreSQL 9.0首次在PostgreSQL中引入了“异步二进制复制”。基于这个概念,9.1版本也包含了一个同步复制的选项。“同步复制”意味着直到被主服务器 和复制服务器均接收完事务时,事务才会返回给应用程序。这点就确保了即便在主服务器永久下线的情况下,任何已提交事务的数据都不会丢失。

通过NTT的开源和2ndQuadrant的努力,经过长达三年的开发,终于使这个特性最终达到顶峰,而这将使得日本的通信巨头NTT最终会把他们的大多数的Oracle服务器替换为PostgreSQL。PostgreSQL的集群项目PostgresXC是这个替换工作的另外一部分。

对于同步复制来说,事务在返回前需要被写到两个服务器的磁盘上,因此会在响应时间上带来很大的损失。为了缓解这种情况,PostgreSQL除了像 其它数据库系统一样提供同步复制功能外,还额外提供一个可以基于每一次事务提交而做出同步或异步复制的控制功能。这将使应用开发者通过把一些不可丢失的关 键数据(比如财务交易)和那些响应时间上要求高的不太关键的数据区分开,来优化系统系统的性能。

每一个复制节点(或“standby”)连接主机的时候,都会在它的recovery.conf文件中给自己指定一个名称:

    primary_conninfo = 'host=master01 user=replicator application_name=replica1'

然后主机会在它的postgresql.conf文件中为同步复制机设置一个优先级列表:

    synchronous_standby_names = 'replica1'

然后你就可以以同步或异步的方式提交事务了:

    -- commit synchronously to the standby
    SET synchronous_commit = 'on';
    UPDATE user_balance SET balance = 573.29 WHERE user_id = 
阅读全文

postgresql-slony-I同步复制配置步骤

  categories:资料  tags:  author:

主数据库: 172.16.254.21 端口:5432
从数据库: 172.16.254.22 端口:5432

步骤1:主从均安装slon
apt-get install slon-bin
步骤2:主从数据库配置权限,创建语言。
在主数据库中   vi /etc/postgresql/8.3/node/pg_hba.conf
添加一条记录    host    all         repl         172.16.254.22/32  md5

在主从数据库均执行以下操作:
shell>psql
node=#create role repl password ‘123456’ login superuser
#创建用户repl,赋予超级用户权限
node=# use node;
node=# create language plpgsql;
#创建语言plpgsql
步骤3:备份主数据库至从数据库并恢复
#在主数据库备份要复制的数据库… 阅读全文

greenplum数据库引擎探究

  categories:搜索资料  tags:  author:

Greenplum做为新一代的数据库引擎,有着良好的发展与应用前景。强大的工作效率,低成本的硬件平台对数据仓库与商业智能建设有很大的吸引力。要清楚的了解其特点最好从架构着手。

架构分析

Greenplum 的高性能得益于其良好的体系结构。Greenplum的架构采用了MPP(大规模并行处理)。在 MPP 系统中,每个 SMP 节点也可以运行自己的操作系统、数据库等。换言之,每个节点内的 CPU 不能访问另一个节点的内存。节点之间的信息交互是通过节点互联网络实现的,这个过程一般称为数据重分配 (Data Redistribution) 。与传统的SMP架构明显不同,通常情况下,MPP系统因为要在不同处理单元之间传送信息,所以它的效率要比SMP要差一点,但是这也不是绝对的,因为 MPP系统不共享资源,因此对它而言,资源比SMP要多,当需要处理的事务达到一定规模时,MPP的效率要比SMP好。这就是看通信时间占用计算时间的比 例而定,如果通信时间比较多,那MPP系统就不占优势了,相反,如果通信时间比较少,那MPP系统可以充分发挥资源的优势,达到高效率。当前使用的 OTLP程序中,用户访问一个中心数据库,如果采用SMP系统结构,它的效率要比采用MPP结构要快得多。而MPP系统在决策支持和数据挖掘方面显示了优 势,可以这样说,如果操作相互之间没有什么关系,处理单元之间需要进行的通信比较少,那采用MPP系统就要好,相反就不合适了。

Shared nothing架构

常见的OLTP数据库系统常常采用shared everything架构来做集群,例如oracle RAC架构,数据存储共享,节点间内存可以相互访问。

 

Oracle RAC架构

Greenplum 是一种基于postgresql(开源数据库)的分布式数据库。其采用shared nothing架构(MPP),主机,操作系统,内存,存储都是自我控制的,不存在共享。主要由master host,segment host,interconnect三大部分组成。

 

Greenplum架构图

了解完Greenplum的架构后,对其工作流程也就相对简单了。因greenplum采用了MPP架构,其主要的优点是大规模的并行处理能力,应该把精力主要放在大规模存储与并行处理两个方面。

大规模存储

Greenplum数据库通过将数据分布到多个节点上来实现规模数据的存储。数据库的瓶颈经常发生在I/O方面,数据库的诸多性能问题最终总能归罪到I/O身上,久而久之,IO瓶颈成为了数据库性能的永恒的话题。

Greenplum采用分而治之的办法,将数据规律的分布到节点上,充分利用segment主机的IO能力,以此让系统达到最大的IO能力(主要是带宽)。

在 greenplum中每个表都是分布在所有节点上的。Master host首先通过对表的某个或多个列进行hash运算,然后根据hash结果将表的数据分布到segment

阅读全文

高效率SQL的基础知识

  categories:资料  tags:  author:

一个高效率的数据库系统是从两个方面来评价的:响应时间和吞吐量。

在应用系统开发阶段,由于开发库上的数据比较少,在SQL语句的编写上感觉不出各种写法的性能差异,在将应用系统提交实际应用后,随着数据库中数据的增加,系统的响应速度就会成为最需要解决的主要问题之一。

缩短系统的响应时间,增加操作的并发度,可以提高系统的吞吐量。要缩短系统的响应时间,就需要可以高效率执行的SQL语句。高效SQL语句的基本原则,是充分合理的利用索引,避免表扫描。

1.理解索引

大多数情况下,数据库使用索引来检索表,优化器根据用户定义的索引来提高执行性能。但是,如果在SQL语句的where子句中写的SQL代码不合理,就会造成优化器忽略索引而采用全表扫描,而这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时需要了解优化器根据何种原则来使用索引,这将有助于写出高性能的SQL语句。

2.IS NULL IS NOT NULL

NULL值做条件时,将无法使用包含NULL值的列上的索引。即使索引有多列这样的情况下,只要这些列中有一列含有null,该列就会从索引中排除。也就是说如果某列存在空值,在使用… 阅读全文

MySQL table_cache优化

  categories:mysql资料  tags:,   author:

table_cache 参数设置表高速缓存的数目。每个连接进来,都会至少打开一个表缓存。因此, table_cache 的大小应与 max_connections 的设置有关。例如,对于 200 个并行运行的连接,应该让表的缓存至少有 200 × N ,这里 N 是应用可以执行的查询的一个联接中表的最大数量。此外,还需要为临时表和文件保留一些额外的文件描述符。
当 Mysql 访问一个表时,如果该表在缓存中已经被打开,则可以直接访问缓存;如果还没有被缓存,但是在 Mysql 表缓冲区中还有空间,那么这个表就被打开并放入表缓冲区;如果表缓存满了,则会按照一定的规则将当前未用的表释放,或者临时扩大表缓存来存放,使用表缓存 的好处是可以更快速地访问表中的内容。
执行 flush tables 会清空缓存的内容。一般来说,可以通过查看数据库运 行峰值时间的状态值 Open_tables 和 Opened_tables ,判断是否需要增加 table_cache 的值。其中 open_tables 是当前打开的表的数量, Opened_tables 则是已经打开的表的数量。下面我们的例子显示了这两个状态值的变化情况:
首先,清空表缓存:
mysql> flush tables;
Query … 阅读全文

mysql的binlog详解

  categories:mysql资料  tags:,   author:

什么是binlog,binlog日志用于记录所有更新了数据或者已经潜在更新了数据(例如,没有匹配任何行的一个DELETE)的所有语句。语句以“事件”的形式保存,它描述数据更改。

binlog作用
因为有了数据更新的binlog,所以可以用于实时备份,与master/slave复制

和binlog有关参数

log_bin
设置此参数表示启用binlog功能,并指定路径名称
log_bin_index
设置此参数是指定二进制索引文件的路径与名称
binlog_do_db
此参数表示只记录指定数据库的二进制日志
binlog_ignore_db
此参数表示不记录指定的数据库的二进制日志
max_binlog_cache_size
此参数表示binlog使用的内存最大的尺寸
binlog_cache_size
此参数表示binlog使用的内存大小,可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。
binlog_cache_use:使用二进制日志缓存的事务数量
binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量

max_binlog_size
Binlog最大值,最大和默认值是1GB,该设置并不能严格控制Binlog的大小,尤其是Binlog比较靠近最大值而又遇到一个比较大事务时,为了保证事务的完整性,不可能做切换日志的动作,只能将该事务的所有SQL都记录进当前日志,直到事务结束

sync_binlog
这个参数直接影响mysql的性能和完整性

sync_binlog=0:
当事务提交后,Mysql仅仅是将binlog_cache中的数据写入Binlog文件,但不执行fsync之类的磁盘        同步指令通知文件系统将缓存刷新到磁盘,而让Filesystem自行决定什么时候来做同步,这个是性能最好的。

sync_binlog=n,在进行n次事务提交以后,Mysql将执行一次fsync之类的磁盘同步指令,同志文件系统将Binlog文件缓存刷新到磁盘。

Mysql中默认的设置是sync_binlog=0,即不作任何强制性的磁盘刷新指令,这时性能是最好的,但风险也是最大的。一旦系统绷Crash,在文件系统缓存中的所有Binlog信息都会丢失

binlog的删除
binlog的删除可以手工删除或自动删除

自动删除binlog
通过binlog参数(expire_logs_days )来实现mysql自动删除binlog
mysql> show binary logs;
mysql> show variables like … 阅读全文

多级企业数据容灾解决方案对比(IBM?)

  categories:资料  tags:  author:

随着网络和信息技术的进步,企业在运营过程中对ERP系统的核心数据越来越依赖。如果说,财务困难有可能阻碍企业发展,那么核心数据的丢失就有可能直接摧毁一个企业。各种各样的灾难就像灰尘一样潜伏在企业周围,一时的疏忽就可能造成企业核心数据的丢失。因此,对于各级企业来说,结合自身规模和业务特性,选择合适的数据容灾解决方案,是确保业务连续性的必备手段之一。因为企业的规模大小不一,所需要采用的容灾方案模式也可不相同,在此我们仅对几种常见的容灾解决方案进行介绍。

http://www.mcplive.cn/index.php/article/index/id/9259/page/1

两地三中心方案

两地三中心方案(MGM)采用高性能、高容量的数据存储系统,结合磁盘层叠式(异步与同步结合)数据复制技术,用于向大型企业提供高性能、灵活、可扩展、高弹性的数据容灾备份。此方案的同城RPO(Recovery Point Objective,恢复点目标)=0,即可以确保在同城范围提供实时镜像数据备份恢复;异地RPO最短3秒至5秒,可以尽可能地降低数据丢失几率,根据灾难的情况还可以进行故障切换。

如下图所示,两地三中心方案由生产中心A、同城灾备中心B和异地灾备中心C构成。在本地生产中心A中,采用大型数据存储系统存储相应的业务数据,通过数据同步复制技术将数据复制到同城灾备中心B的数据存储系统中,实时保证数据的一致性。

wps_clip_image-6132
两地三中心方案的关系和构成

同时位于同城灾备中心B的数据存储系统还会以数据异步复制技术向异地灾备中心C进行数据镜像,实现异地的数据备份及保护。当同城灾备中心B发生故障时,生产中心A可以向异地灾备中心C通过数据异步复制技术同步数据,实现异地的数据备份及保护。当生产中心A所在地发生灾难时,生产中心A可将应用切换到同城灾备中心B或异地灾备中心C的备用数据服务器上,同时同城灾备中心B或异地灾备中心C的备用数据服务器接管灾备中心A的应用,恢复数据的访问及业务的连续性。

wps_clip_image-16895
两地三中心方案中的数据传递模式

异地双中心方案

异地双中心方案较三中心方案减少了一个同城灾备中心,采用类似的企业级数据存储系统,通过数据异步复制技术进行备份数据的传递。因为缺少一个近距离的同城灾备中心,所以异地双中心方案无法提供实时的镜像数据备份恢复,RPO最短3秒至5秒。这种情况下虽然可以保证数据一致性且可以实时切换,但是因此会有少量的数据丢失,因此只适用于对数据实时更新要求不高的企业。

wps_clip_image-19733
异地二中心方案的关系和构成

在本方案中,本地生产中心的数据存储系统存储着相应的业务数据,可以同异地灾备中心通过数据异步复制技术进行数据镜像,实现异地的数据备份及保护。当生产中心所在地发生灾难时,生产中心的应用将被切换到异地灾备中心的数据库服务器,异地灾备中心使用存储有数据镜像的存储系统,开始恢复数据的访问及业务的连续性。

wps_clip_image-13285
异地二中心方案中的数据传递模式

存储HA+异地灾备方案

两地三中心方案的部署成本太高,而异地双中心方案又无法做到数据无丢失,而存储HA+异地灾备方案则可以在前两个方案之间取得较好的平衡。这实际上是两地三中心方案的一个变通做法,即将保存实时数据镜像的灾备存储系统放在生产中心,从而实现同城灾备中心的部分功能。从而实现生产中心存储HA(高可用性),使得RPO=0,实现实时数据的一致性。

wps_clip_image-15411
存储HA+异地灾备方案的关系和构成

在生产中心中,企业用户需要放置两套企业级存储系统在本地生产中心存储相应的业务数据,并在生产中心通过数据同步复制技术实现数据的实时同步,实现存储的高可用性。任意一套存储系统的宕机,都不会影响业务的运行。同时,结合数据异步复制技术,将本地生产中心的一套存储系统同异地灾备中心的存储系统通过数据异步复制技术进行数据镜像,实现异地的数据备份及保护。

wps_clip_image-11837
存储HA+异地灾备方案中的数据传递模式

同城双中心方案

如果企业的业务主要集中在一地开展,或者希望在预算有限的情况下优先满足数据的一致性,那么前面提到的异地灾备方案就不是那么合适了,此时可以考虑同城双中心方案,即将生产中心和灾备中心安排在同一个地区。然后根据情况选择磁盘数据同步/异步复制技术,进行生产中心与灾备中心之间的数据备份传输,实现同城的灾难备份恢复,从而有效地管理风险、保证业务的连续运行,提高业务服务水平。

wps_clip_image-13234
同城二中心方案的结构和数据传递模式

本方案主要由服务器和存储备份系统两部分构成。在生产中心配备两套数据库服务器来保证业务访问的稳定、高性能、快速响应及高可用性,而响应的数据则存储在生产中心的一套企业级存储系统上。同时,此系统通过磁盘数据同步/异步复制技术将数据复制到同城灾备中心的存储系统上,生产中心与灾备中心的两套磁盘存储系统间建立磁盘镜像复制关系从而实现高可用性,保证关键数据的可恢复性与业务应用的可持续性。

写在最后

如果一块硬盘损坏,我们首先想到的是里面的数据怎么办,因为在我们看来这些数据也许比一块硬盘的价值更高。在企业数据领域,情况也是一样。黑客、病毒、断电、火灾、操作失误、自然灾害等灾难,都可能威胁到企业核心数据。如果不能对风险采取有效管理,一旦数据由于上述某种原因丢失,就有可能给整个企业造成运营上的重大不便和经济损失,企业的信誉也将受到影响。而采用数据容灾解决方案,正是为了避免这种情况,保证企业的业务连续运营及数据处理的高可靠性和高可用性。在以往,容灾方案更多属于大型企业的考虑范畴,不过随着企业对核心数据的日渐重视,以及虚拟化存储技术的发展和一体化解决方案的出现,我们相信,数据容灾系统将会成为每一个成熟企业的标准配置。毕竟,在信息化时代,核心数据就意味着竞争力!… 阅读全文

推荐九个容灾解决方案

  categories:资料  tags:  author:

由存储技术专家和行业应用专家组成的评析专家组对所征集到的方案进行了认真的评析和点评,向读者推荐9款优秀的容灾解决方案。本报在此摘登其内容概要,有兴趣的读者可登录计世网(ccw.com.cn)查询方案全文。

EMC容灾技术和业务连续性服务方案

某保险公司(以下简称客户)向EMC公司提出建立容灾方案的想法。但容灾技术和方案的设计极其复杂,客户不能提供具体需求的情况较为普遍。了解客户的初步设想后,EMC公司根据以往经过多次验证的经验和成熟的业务连续性服务集成方法论,帮助客户从评估现有服务水平入手,定义业务需求,调研高可用性和恢复技术,设计基础架构,进行技术测试和实施,开发业务连续性技术,实施容灾测试演习,建立更新与维护制度,建立资源管理、改进考评体系,使容灾方案真正做到“养兵千日,用兵一时”。

设计思路

EMC在业务连续性服务方面有着一套完整的实施方法论,称做业务连续性服务集成方法论(Business Continuity Solution Integration,简称BCSI)。它是EMC通过对多年实施业务连续性和容灾服务所积累的经验进行总结和提炼,开发出来的业务连续性实施方法论模型,该实施方法在全球众多相关项目中广为使用并得到验证。

根据客户的容灾地点的选择考虑范围,EMC针对生产站点和容灾站点之间的距离推荐三种技术方案。第一个是北京、成都,距离在1000公里以上,EMC推荐使用SRDF SAR单跳数据复制方案,该方案对于链路的带宽没有具体要求,可以满足任何链路带宽和RPO需求。第二个是南京、杭州、苏州等地,距离在3个小时车程以内,EMC推荐使用SRDF异步数据复制方案,如果链路带宽允许的话,可以考虑对最关键的业务数据实施同步复制保护; 如果链路带宽比较低,也可以考虑SRDF SAR单跳数据复制模式。第三个是同城(外高桥、张江、漕河径)容灾,EMC推荐使用SRDF同步数据复制方案,根据灾备地点和目前生产中心之间的物理距离,建议在同城的模式下,可以采用SRDF同步方式,对核心业务数据采用同步保护模式。

三种方案

同城同步方案如图所示。而城域容灾方案中,根据灾备地点和目前生产中心之间的物理距离,建议在城域的模式下,对核心业务数据采用同步/异步保护模式。如果站点距离在100公里之内,而且链路仍然采用光纤链路的话,考虑光纤信号的时延问题,可以对部分核心业务数据采用同步数据模式,其他数据采用异步模式。如果采用基于IP的数据链路,则最好采用异步方式。

在异地容灾方案中,由于考虑到异地之间的距离比较长,用户租用高带宽的链路成本很高,建议采用EMC特有的Single HOP(单跳)的方式,可以满足用户在超常距离和有限带宽条件下的RPO和RTO指标。

wps_clip_image-4333
同域同步容灾系统架构图

HDS三数据中心容灾解决方案

中国国际电子商务中心(简称CIECC)从2005年初开始酝酿建设一套安全可靠以及高效的容灾系统:以北京亦庄的数据中心为主生产中心,在同城的东单建立同城容灾系统,并在广州建立异地容灾系统,以此构成三数据中心容灾备份系统来实现最高级别的灾难恢复能力和业务连续性。

wps_clip_image-25531
系统架构图

经过对多家主流厂商容灾方案进行谨慎和严格的评估,CIECC最终于2006年底选择了由日立数据系统公司(HDS)提供的采用了Delta Resync技术的三数据中心容灾解决方案。

三地数据中心容灾模式

三数据中心容灾其实并非一个全新的概念,自2005年起在全球范围内就已经有应用,但是根据所采用技术的不同,它又包括三种实现方式: 级联方式是最基本的也是最早出现的方式; 还有Multi-target并发方式的三数据中心解决方案;第三种是多采用Delta Resync技术的三数据中心解决方案。

CIECC最终采用的就是第三种容灾方式。HDS公司于一年前推出该技术。在这种容灾方式下,任意两个站点之间都可以互为容灾备份,不会有数据丢失,因而实现了真正意义上的三数据中心容灾,也是当前较高级别的容灾方案。

CIECC决定采用HDS三数据中心Delta Resync容灾解决方案经历了一个严谨的论证过程,是在详细分析和论证的基础上做出的慎重决定。CIECC构建了北京亦庄、东单和广州三个数据中心存储平台,其中对亦庄至东单的同城容灾系统的RPO要求近似为零,而亦庄至广州以及东单至广州的异地容灾系统RPO也要求不超过两小时。如果采用落后的容灾方案,那么当东单灾备中心出现故障时就会影响亦庄生产系统的正常运行,而且还需要多出一份复制卷以确保数据一致性,从而导致未来系统扩展时增加成本。通过采用三数据中心Delta Resync容灾方案,当东单灾备中心出现故障时完全不会影响到亦庄的生产系统,而且由于不需要付出多余容量来确保数据一致性,因此大大降低了用户的维护成本。

为了确保安全可靠和高效的容灾系统,同时也基于CIECC当前及未来业务发展的需要,HDS为该容灾项目中的三个数据中心各提供了一台TagmaStore Universal Storage Platform(USP)为核心存储系统,并为每台USP配置了30TB的容量。配合以HDS异步复制软件Hitachi Universal Replicator(日立通用复制软件,HUR)、系统内复制软件Hitachi ShadowImage以及TrueCopy 同步复制软件等,实现了对CIECC现有异构存储环境的先进的数据复制和灾难保护机制。

NetApp容灾方案… 阅读全文



快乐成长 每天进步一点点