当前位置：文档库 › 本地Blast2GO安装,及其数据库更新和导入数据中断的解决方案

本地Blast2GO安装,及其数据库更新和导入数据中断的解决方案

本地Blast2GO安装，及其数据库更新和导入数据中断的解决方案

2013年08月21日? Bioinformatics ? 暂无评论? 被围观141 views+ 本文提供改进的本地化Blast2GO自动化安装脚本，以及指导如何更新数据库，并提供导入数据中断的解决方案。对无root权限的用户同样有效，同时指导如何成功运行b2g4pipe和本地Blast2GO图形界面。

由于Blast2GO官方网站提供的Blast2GO数据库安装教程需要用户具有root权限，而其官网上另一自动化安装脚本已过时，会出错，故文本将二者结合，并根据自身经验重新整理。

软件环境

■操作系统：Linux（Centos, Ubuntu, Fedora等），最好有root权限，配置mysql。

■数据库：Mysql（或者Mysql的分支MariaDB），要有能创建数据库权限的用户，如果弄不到，可以参照我另一篇日志在没有Root权限的情况下安装Mysql。

■Java运行环境：一定要Oracle JDK (6、7都行)，不要用OpenJDK！可参照我另一篇日志《Linux安装JDK》（内含没root权限时安装方法）。

■Local NCBI-Blast。

注：请一定参照网上的方法把Mysql的数据库目录配置到有足够空间的目录下面！安装oracle jdk，不用卸载openjdk，并切换java到oracle jdk。

查看源代码打印帮助

1 sudo /usr/sbin/alternatives --config java

手动准备数据

1) 避免不稳定的网络环境使下载中断，自己用迅雷或者FTP客户端（wget也支持断点续传）下载以下4个文件（一共5.1G）：

■godatabase: https://www.wendangku.net/doc/df14283820.html,/latest-full/ 目录下对应的go_XXXX-assocdb-data.gz

■gene_info.gz: ftp://https://www.wendangku.net/doc/df14283820.html,/gene/DATA/gene_info.gz

■gene2accession.gz: ftp://https://www.wendangku.net/doc/df14283820.html,/gene/DATA/gene2accession.gz

■idmapping.tb.gz: ftp://https://www.wendangku.net/doc/df14283820.html,/databases/idmapping/idmapping.tb.gz

2) 解压文件。提示：gzip -d解压文件后会删除原来的压缩文件。

查看源代码打印帮助

1 gzip -d *.gz

3）下载local_b2g_db.zip文件，并解压。内含创建数据库的b2gdb.sql文件和导入idmapping 文件的java程序ImportIdMapping.class及其依赖的库mysql-connector-java-5.0.8-bin.jar。

为了方便，上述文件都放到同一目录下。解压后文件清单如下：

查看源代码打印帮助

1 ./: 31.48 GB

2 2.97 KB ImportIdMapping.class

3 2.33 KB b2gdb.sql

4 1.83 KB download_and_install.sh

5 3.27 GB gene2accession

6 1.32 GB gene_info

7 22.37 GB go_201307-assocdb-data

8 4.51 GB idmapping.tb

9 528.18 KB mysql-connector-java-5.0.8-bin.jar

导入数据库

1) 配置download_and_install.sh文件：

查看源代码打印帮助

01 #!/bin/sh

03 # 配置以下7行

04 godbname=go_201307-assocdb-data # 根据https://www.wendangku.net/doc/df14283820.html,/latest-full/下assocdb-data.gz文件更改

05 dbname=b2gdb # 数据库名称，不用改

06 dbuser=root # 数据库用户名

07 dbpass=passwordofroot # 数据库用户密码

08 dbhost=localhost # 数据库所在ip

09 dbport=3306 # 数据库端口，3306是默认的，如果是无root权限安装的MySQL，一定要改为设置的端口，比如我的33060

10 path=/home/shenwei/Public/Data/local_b2g # 数据文件目录，注意路径末尾不要有“/”

12 # 如果已经下载数据文件，下列部分保持注释

13 ### Download the GO database the NCBI mapping files and the PIR mapping

14 # wget https://www.wendangku.net/doc/df14283820.html,/latest-full/$godbname.gz

15 # wget ftp://https://www.wendangku.net/doc/df14283820.html,/gene/DATA/gene_info.gz

16 # wget ftp://https://www.wendangku.net/doc/df14283820.html,/gene/DATA/gene2accession.gz

17 # wget ftp://https://www.wendangku.net/doc/df14283820.html,/databases/idmapping/idmapping.tb.gz

19 # 如果已经下载并解压数据文件，下列部分保持注释

20 ###unzip files

21 # gzip -dv $godbname.gz

22 # gzip -dv gene_info.gz

23 # gzip -dv gene2accession.gz

24 # gzip -dv idmapping.tb.gz

26 echo 1. Create the DB Tables and user

27 mysql -h$dbhost -P$dbport -u$dbuser -p$dbpass < b2gdb.sql

29 ### Import data to the GO Database

30 echo 2. Import $godbname

31 mysql -h$dbhost -P$dbport -u$dbuser -p$dbpass $dbname < $godbname

33 echo 3. Import gene2accession

34 mysql -h$dbhost -P$dbport -u$dbuser -p$dbpass $dbname -e"LOAD DATA LOCAL INFILE '$path"/gene2accession"' INTO TABLE gene2accession FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n';"

36 echo 4. Import gene_info

37 mysql -h$dbhost -P$dbport -u$dbuser -p$dbpass $dbname -e"LOAD DATA LOCAL INFILE '$path"/gene_info"' INTO TABLE gene_info FIELDS TERMINATED BY '\t' LINES TERMINATED BY '\n';"

39 echo 5. Import idmapping.tb

40 java -cp .:mysql-connector-java-5.0.8-bin.jar: ImportIdMapping $path/idmapping.tb $dbhost:$dbport $dbname blast2go blast4it

41 echo All data imported.

注意：如果是无root权限安装的MySQL，一定要设置数据库端口为为自己设置的端口，比如我的33060，否则无法导入idmapping.tb。

如果导入数据出现中断，切勿简单地重新运行download_and_install，请参照后面的章节进行操作。

2) 运行download_and_install.sh

查看源代码打印帮助

1 sh ./download_and_install.sh

由于非常费时，强烈推荐以下命令将任务转到后台

查看源代码打印帮助

1 nohup sh ./download_and_install.sh &

关闭ssh客户端后，任务仍然可以正常运行，通过查看nohup的默认日志文件nohup.out来观察数据导入的进度。

运行时间：

我的笔记本（Intel(R) Core(TM) i5-3320M CPU @ 2.60GHz双核四线程，硬盘7200 rpm）工作硬盘4921 RPM，CPU温度73.0°C 。%>_<%

go_201307-assocdb-data（约5小时）和idmapping.tb（约1.5小时）比较费事。

总共导入数据需要约7小时。

数据库各文件大小：

查看源代码打印帮助

001 b2gdb/: 74.91 GB

002 17.59 GB association.MYI

003 14.82 GB evidence.MYI

004 6.43 GB evidence_dbxref.MYI

005 5.91 GB evidence.MYD

006 3.90 GB association.MYD

007 3.63 GB dbxref.MYI

008 3.31 GB gene_product.MYI

009 2.68 GB gene2accession.MYD

010 2.37 GB gene_product_count.MYI 011 2.01 GB gi2uniprot.MYI

012 1.95 GB gene_product_synonym.MYI 013 1.67 GB evidence_dbxref.MYD

014 1.42 GB gene_product.MYD

015 1.40 GB gene2accession.MYI

016 1.28 GB gene_info.MYD

017 1.10 GB gene_product_synonym.MYD 018 1.10 GB gene_product_count.MYD 019 894.13 MB gi2uniprot.MYD

020 636.91 MB dbxref.MYD

021 349.73 MB gene_info.MYI

022 224.40 MB species.MYI

023 156.21 MB graph_path.MYI

024 55.88 MB species.MYD

025 23.98 MB graph_path.MYD

026 16.19 MB term_synonym.MYI

027 10.71 MB term.MYI

028 9.58 MB term_dbxref.MYI

029 7.27 MB term_definition.MYD

030 5.63 MB term2term.MYI

031 5.16 MB term_synonym.MYD

032 3.10 MB term.MYD

033 2.32 MB term_dbxref.MYD

034 1.53 MB term2term.MYD

035 1.08 MB term_definition.MYI

036 735.00 KB association_qualifier.MYI 037 419.75 KB association_qualifier.MYD 038 343.00 KB term_subset.MYI

039 196.00 KB gene_product_homolset.MYI 040 111.00 KB term2term_metadata.MYI 041 87.12 KB term_subset.MYD

042 82.42 KB gene_product_homolset.MYD

043 49.76 KB db.MYD

044 38.00 KB db.MYI

045 37.67 KB term2term_metadata.MYD

046 36.00 KB homolset.MYI

047 35.00 KB association_species_qualifier.MYI 048 16.73 KB species.frm

049 14.35 KB homolset.MYD

050 12.63 KB db.frm

051 12.60 KB association.frm

052 12.58 KB graph_path.frm

053 12.57 KB term.frm

054 12.56 KB term_synonym.frm

055 12.54 KB gene_product.frm

056 12.52 KB dbxref.frm

057 12.51 KB evidence.frm

058 11.69 KB association_species_qualifier.MYD 059 9.06 KB gene_info.frm

060 8.96 KB gene2accession.frm

061 8.67 KB relation_properties.frm

062 8.64 KB source_audit.frm

063 8.62 KB seq.frm

064 8.61 KB homolset.frm

065 8.56 KB gene_product_ancestor.frm 066 8.54 KB term_definition.frm

067 8.53 KB instance_data.frm

068 8.53 KB gene_product_count.frm

069 8.53 KB term2term.frm

070 8.51 KB relation_composition.frm

071 8.50 KB association_property.frm

072 8.50 KB gene_product_homology.frm 073 8.49 KB intersection_of.frm

074 8.49 KB term2term_metadata.frm

075 8.49 KB phylotree_property.frm

076 8.48 KB assoc_rel.frm

077 8.48 KB seq_property.frm

078 8.47 KB association_qualifier.frm

079 8.47 KB gene_product_property.frm 080 8.46 KB gene_product_seq.frm

081 8.46 KB term_dbxref.frm

082 8.46 KB term_property.frm

083 8.45 KB gene_product_phylotree.frm 084 8.45 KB gene_product_homolset.frm 085 8.45 KB association_species_qualifier.frm 086 8.44 KB graph_path2term.frm

087 8.43 KB gene_product_synonym.frm 088 8.43 KB association_isoform.frm 089 8.42 KB phylotree.frm

090 8.42 KB gene_product_subset.frm 091 8.42 KB gene_product_dbxref.frm 092 8.41 KB evidence_dbxref.frm

093 8.41 KB term_audit.frm

094 8.40 KB term_subset.frm

095 8.40 KB seq_dbxref.frm

096 8.39 KB gi2uniprot.frm

097 7.00 KB relation_composition.MYI 098 4.00 KB source_audit.MYI

099 4.00 KB instance_data.MYI

100 3.00 KB relation_properties.MYI 101 2.00 KB seq_property.MYI

102 2.00 KB gene_product_property.MYI 103 1.00 KB term_property.MYI

104 1.00 KB intersection_of.MYI

105 1.00 KB phylotree.MYI

106 1.00 KB phylotree_property.MYI 107 1.00 KB graph_path2term.MYI

108 1.00 KB seq.MYI

109 1.00 KB seq_dbxref.MYI

110 1.00 KB gene_product_homology.MYI 111 1.00 KB gene_product_subset.MYI 112 1.00 KB gene_product_seq.MYI

113 1.00 KB gene_product_phylotree.MYI 114 1.00 KB gene_product_dbxref.MYI 115 1.00 KB term_audit.MYI

116 1.00 KB gene_product_ancestor.MYI 117 1.00 KB association_property.MYI 118 1.00 KB association_isoform.MYI 119 1.00 KB assoc_rel.MYI

120 289.00 B relation_composition.MYD 121 196.00 B source_audit.MYD

122 145.00 B relation_properties.MYD 123 65.00 B db.opt

124 24.00 B instance_data.MYD

125 0.00 B gene_product_dbxref.MYD 126 0.00 B seq_property.MYD

127 0.00 B intersection_of.MYD

128 0.00 B gene_product_ancestor.MYD 129 0.00 B assoc_rel.MYD

130 0.00 B association_isoform.MYD

131 0.00 B term_audit.MYD

132 0.00 B seq_dbxref.MYD

133 0.00 B term_property.MYD

134 0.00 B seq.MYD

135 0.00 B phylotree.MYD

136 0.00 B gene_product_seq.MYD

137 0.00 B graph_path2term.MYD

138 0.00 B gene_product_property.MYD

139 0.00 B association_property.MYD

140 0.00 B gene_product_phylotree.MYD

141 0.00 B gene_product_subset.MYD

142 0.00 B gene_product_homology.MYD

143 0.00 B phylotree_property.MYD

运行官方的例子b2g4pipe

下载https://https://www.wendangku.net/doc/df14283820.html,/data/blast2go/b2g4pipe_v2.5.zip并解压。配置b2gPipe.properties 文件中b2gdb信息：

查看源代码打印帮助

1 // GO and B2G Data Access Basic

2 Dbacces.dbname=b2gdb

3 Dbacces.dbhost=localhost:3306

4 Dbacces.dbuser=blast2go

5 Dbacces.dbpasswd=blast4it

注意：如果是无root权限安装的MySQL，一定要设置数据库端口为为自己设置的端口。

运行自带例子：

查看源代码打印帮助

1 sh ./runPipeExample.sh

不到一分钟运行结束。

运行图形界面

直接运行命令java -cp *:ext/*: es.blast2go.Blast2GO或者，将其写入文件：

查看源代码打印帮助

1 #!/bin/bash

3 # -Xmx1024M 指定java最大可使用内存，根据情况更改

4 java -Xmx1024M -cp *:ext/*: es.blast2go.Blast2GO

运行脚本:

查看源代码打印帮助

1 sh ./runPipeExample.sh

进入图形界面后，配置数据库：菜单栏点击“Tools”，最后一个“DB configuration"，更改Host为localhost，DB name为b2gdb，然后点击播放按钮生效，下次启动程序仍然有效。注意：如果是无root权限安装的MySQL，Host需要加上自定义的mysql端口，比如localhost:33060。

运行例子：菜单栏File->Import->Import Blast Results->One XML File，导入10_BlastResults_2011.xml，菜单栏Mapping->Run Go Mapping Step即可。运行一分钟左右完成。

数据库更新，导入数据中断的解决方案：

1）assocdb-data数据的更新：

下载解压新的assocdb-data文件后，注释download_and_install.sh中其它导入数据的命令，只保留第二步：

查看源代码打印帮助

1 ### Import data to the GO Database

2 echo 2. Import $godbname

3 mysql -h$dbhost -u$dbuser -p$dbpass $dbname < $godbname

并运行download_and_install.sh。不用担心与旧的数据冲突，它们会被自动删除然后更新。

2）gene2accession、gene_info、idmapping.tb的更新：

由于它们是以导入数据文件的方式导入数据库，需要登陆到数据库中，手动清空对应的原来数据表中的数据：

查看源代码打印帮助

01 $ mysql -u root -p

02 Enter password:

04 mysql> use b2gdb;

05 Database changed

07 mysql> truncate table gene2accession;

08 Query OK, 0 rows affected (16.67 sec)

10 mysql> truncate table gene_info;

11 Query OK, 0 rows affected (2 min 2.49 sec)

13 mysql> truncate table gi2uniprot;

14 Query OK, 0 rows affected (0.00 sec)

16 mysql> quit

17 Bye

注意，上面truncate table gi2uniprot花费0.00 sec是因为当时我还没有导入idmapping.tb，即gi2uniprot中还没有数据，所以速度很快。

3）用download_and_install导入数据时，如果出现中断，请参照上面“数据库各文件大小”

核对数据文件大小，确认已导入和未导入的数据库，按照“数据库更新”的操作恢复导入过程，切勿简单地重新运行download_and_install。

参考

1.Blast2GO安装https://www.wendangku.net/doc/df14283820.html,/blog-402211-629228.html

2.Blast2GO Documentation https://www.wendangku.net/doc/df14283820.html,/b2glaunch/resources

3.Local Blast2GO Database Installation https://www.wendangku.net/doc/df14283820.html,/b2glaunch/resources/35-localb2gdb

4.其它无数Google出来的页面

-EOF-

本文转自爪爪

《本地Blast2GO安装，及其数据库更新和导入数据中断的解决方案》http://blog.shenwei.me/local-blast2go-installation/

如果您还有其他问题，请到生物信息问答社区https://www.wendangku.net/doc/df14283820.html,来问问吧，这里有来自中科院、国内外高校、公司的生物科研人员以及技术人员，大家一起在线交流。

数据库安全审计解决实施方案

数据库安全审计解决方案

————————————————————————————————作者：————————————————————————————————日期： 2

一、数据库安全审计需求概述数据库系统是一个复杂而又关键的系统，数据库存在各种管理和技术上的风险，如果这些风险变为事实，那么企业数据将遭受严重的经济损失和法律风险。而面对数据库的安全问题，企业常常要面对一下问题： ?数据库被恶意访问、攻击甚至数据偷窃，而企业无法及时发现、追踪并阻截这些恶意的行为。 ?数据库遭受恶意访问、攻击后，不能追踪到足够的证据。 ?不了解数据使用者对数据库访问的细节，从而无法保证数据安全，特别是敏感数据的管理。 ?来自内部的威胁：特权用户随意修改配置、改变或盗取数据，没有明确职责分工。 ?针对数据库、应用系统日志的审计只能做事后分析，周期长，且无法进行持续性审计。 ?审计缺乏规范性，无法有效成为公司的安全管理规范且满足外部审计需求。 ?人工审计面对海量数据，无法满足100%可见性，造成审计不完整。?DBA权责未完全区分开，导致审计效果问题。二、Guardium企业数据管理综合解决方案 InfoSphere Guardium提供的一组集成模块，使用一个统一的控制台和后端数据存储，管理整个数据库的安全与合规周期。通过Guardium，IBM 现在提供一种直接解决数据库安全性和遵从性问题的自动、有效且高效的方法。可扩展企业安全平台既能实时保护数据库，又能自动化所有合规审计流程。这套方案不仅在解决问题方面表现卓越，而且在避免消极影响方面同样表现出色。它对数据库性能的影响几乎为零，无需对数据库作任何变更，甚至不依赖本地数据库日志或审计工具。三、通过Guardium管理数据安全 ?发现、分类并且自动寻找、分类和保护敏感信息使用数据库自动搜寻和信息分类功能来识别机密数据的存储位置，然后使用定制的分类标签来自动执行适用于特定级别的敏感信息的安全策

关于XX业务系统数据同步方案简介

修订记录

目录 1. 概述 (4) 2. 数据分析现状 (5) 3. 数据同步方案 (6) 3.1. 理论分析 (7) 3.1.1. 理论值分析 (7) 3.1.2. 必要条件 (9) 3.1.3. 差集计算 (9) 3.2. 数据处理方案 (11) 3.2.1. 历史数据处理 (11) 3.2.2. 过渡性数据处理 (12) 3.2.3. 常规数据处理 (12) 3.3. 数据时效性 (12) 4. 未知性说明 (14)

1.概述 XX业务系统技术支持人员大部分时间均在进行数据统计分析，且基本是在正式环境中进行数据分析处理，而此举在实际操作中除会给生产系统带来诸多压力之外，还可能因为操作人员新建大量临时表时操作失误而出现删表或者删数据的情况。针对上述情况并结合可视化分析系统的现有使用情况，做本建设性思考方案，旨在针对实际问题提出理论上的建设性方案。

2. 数据分析现状 XX 业务系统数据分析一直因为数据时效性而无法很好的使用Spark 集群，且目前已建设的可视化分析环境因为历史数据存在被修改的可能性而导致用之甚少。且当前XX 业务系统集群可视化分析环境采用按月(月中)更新、人工拷贝而后转由集群导入的方式，如下图1所示。备份库集群库正式库人工拷贝系统同步图1 – XX 业务系统数据同步示意图该方式在实际操作中非常消耗人力、物力，且集群数据利用率极低(XX 业务系统版集群可视化环境几乎没人使用)。

3.数据同步方案近期，在处理HBase数据同步至HDFS方案时，构思如下数据更新方案，如图2所示：近期数据差集全量数据 Override Append 图2 – HBase数据迁移理论方案示意图同理，将HBase替换成XX业务系统生产数据库，则会得到下图3所示方案示意图：近期数据差集全量数据 Override Append Oracle 图3– XX业务系统数据迁移理论方案示意图该方案是采用蚂蚁搬家的思路，若在此方案思路使用至XX业务系统数据同步中将会使数据从一个月的更新周期调整为一天，从而使集群数据更接近实时数据，从而为XX业务系统日常统计使用Spark集群提供了可能性。

城市公共基础数据库建设参考方案

城市基础数据库系统建设方案

没有统一的数据交换管理平台。因此各部门对加快解决数据资源分散管理、数据共享不足的问题需求十分迫切，需要建立城市基础数据库（以下简称智慧城市公共基础数据库）系统以解决以上问题。依托智慧城市公共基础数据库系统的建设，可以实现各委办局、各所辖地区的经济社会综合数据采集交换，为各部门提供更广泛的信息共享支持，一方面数据信息从各委办局、各所辖地区整合接入，另一方面也为政府和这些接入部门提供全面的共享服务。同时，以智慧城市公共基础数据库指标体系建立为基础，整合来自各委办局和各所辖地区的、经过审核转换处理的数据资源，可实现对经济社会信息的统一和集中存储，确保数据的唯一性和准确性，为今后政府工作提供一致的基础数据支持。数据整合共享只是手段，数据分析服务才是目的。依托智慧城市公共基础数据库系统建设，可有效整合各政府部门所掌握的全市经济社会信息资源，满足政府业务对统一数据资源共享需要，进而提升形势分析预测水平，对政府在发展规划、投资布局、资源环境、管理创新、科学决策等业务提供强有力支持，提高了政府部门掌控全市经济社会发展态势能力。 2.建设目标 1）建立科学合理的智慧城市公共基础数据库指标体系，力求全面反映地区经济和社会发展的总体情况： 2）有组织、有计划、持续地对政府统计部门、政府各部门以及国民经济行业管理部门负责统计的关系到地区经济与社会发展的信息资源进行收集、整合，建立全地区城市信息资源共建、共享的统一管理机制； 3）依托地区电子政务基础设施，充分利用现代信息技术，以科学的地区宏观经济和社会发展指标体系为基础，建设支持政府宏观经济管理和社会和谐发展的基础数据库系统，提高信息资源的建设、管理和共建共享能力； 4）为地区经济建设和社会和谐发展提供一致的城市基础数据，为各类应用系统建设提供基础数据支持，满足政府管理决策、部门信息共享和社会公共服务“三个层次”的需求。

MySQL数据双向同步解决方案

1.mysql数据同步实现原理即读写操作在两台服务器上进行，每台服务器即主也是从。当其中的任何一台服务器收到操作请求时，其进行相应的数据变化，并把变化的数据复制到另一台服务器中。 2.配置服务器master 初始服务器通过mysql工具连接服务器master后，新建两个数据库audit，idm。导入初始化数据库文件，完成数据库的初始化给用户授权从开始菜单中打开mysql5的命令行，输入正确的密码，进入mysql控制台命令行模式后，输入如下命令： #授权来自192.168.0.189的backup用户拥有对所有库的复制数据的权限，该用户的密码设为123456 GRANT REPLICATION SLAVE ON *.* TO 'backup'@'192.168.0.189' IDENTIFIED BY '123456'; #刷新权限设置 FLUSH PRIVILEGES ; 修改配置文件修改主目录中的my.inf文件，在mysqld下面加入如下内容 server-id = 1 log-bin=mysql-bin binlog-do-db = audit binlog-do-db = idm binlog-ignore-db = information_schema binlog-ignore-db = mysql binlog-ignore-db = test master-host = 192.168.0.189 master-user = backup master-password = 123456 master-port = 3306

replicate-do-db = audit replicate-do-db = idm master-connect-retry = 60 3.配置服务器slave 初始服务器通过mysql工具连接服务器ha002后，新建两个数据库audit，idm。导入初始化数据库文件，完成数据库的初始化给用户授权从开始菜单中打开mysql5的命令行，输入正确的密码，进入mysql控制台命令行模式后，输入如下命令： #授权来自192.168.0.188的backup用户拥有对所有库的复制数据的权限，该用户的密码设为123456 GRANT REPLICATION SLAVE ON *.* TO 'backup'@'192.168.0.188' IDENTIFIED BY '123456'; #刷新权限设置 FLUSH PRIVILEGES ; 修改配置文件修改主目录中的my.inf文件，在mysqld下面加入如下内容 server-id = 2 master-host = 192.168.0.188 master-user = backup master-password = 123456 master-port = 3306 relicate-do-db = audit replicate-do-db = idm master-connect-retry = 60 log-bin=mysql-bin binlog-do-db = audit binlog-do-db = idm binlog-ignore-db = information_schema

数据处理平台解决方案设计.pdf

数据处理平台解决方案设计数据采集、处理及信息结构化相关技术全面的互联网信息采集：支持静态页面和动态页面的抓取，可以设置抓取网页深度，抓取文件类型，以及页面的特征分析和区块抓取。支持增量更新、数据源定位、采集过滤、格式转换、排重、多路并发等策略。 -实现企业内外部信息源的自动采集和处理，包括像网站、论坛、博客、文件系统、数据库等信息源 -海量抓取：根据信息不同来源，有效的进行海量不间断抓取，而且不干扰原有业务系统的正常运行 -更新及时：信息采集之后，对于相应的信息更新，要具备灵活的机制，保证内容的质量与完善； -结合权限：结合具体项目的流程，相应的文件都有不同的权限，抓取的时候，能够获得相关权限，以此在前台提供知识服务的同时，满足对权限的控制； -支持录入多种格式的知识素材，包括文本、表格、图形、图像、音频、视频等。 -支持批量上传多种格式的文档，包括txt、html、rtf、word、pdf、MP3、MPEG等。 -支持采集文档里面的内嵌文档抓取（如word文件里面嵌入visio的图片文件，word的图文框等）； -支持对各种压缩文件、嵌套压缩文件的采集； -支持导入Excel、XML、Txt等多种数据源，导入后可自动解析数据源中的知识条目。 -配置好之后可以完全自动化的运行，无需人工干预； -用户可指定抓取网站列表，可进行自定义、删除、更改等操作； -用户可自定义开始时间，循环次数，传送数据库等参数； -自动检测网页链接，可自动下载更新页面，自动删除无效链接； -可设置基于URL、网页内容、网页头、目录等的信息过滤； -支持Proxy模块，支持认证的网站内容抓取；

人口基础数据库建设方案【智慧城市应用】

智慧城市应用之人口基础数据库转型期的中国是人口发展的关键时期，经济发展和社会建设面临的重大问题无不与人口密切相关，人口问题的聚集与凸显是当前政府面临的重要问题。如何运用信息化的手段进行人口数据的科学有效管理，建立人口基础数据库（简称“人口库”），从而切实提高社会管理与民生服务水平就显得相当重要和紧迫。人口库建设的意义和重要性人口基础信息是国家重要的基础信息之一，现行人口管理模式和信息应用模式是一种“条块分割”式的管理，各个相关部门只是从本部门的角度出发对人口信息进行管理，相互间不能很好地协调起来。随着市场经济体制的建立和完善，这种“条块分割”式的、孤立的人口信息管理和应用模式的弊病已显端倪：一方面是造成了许多不必要的重复劳动，另一方面各部门间信息不能共享，不能更好地服务百姓。 1、建立人口基础数据库平台是有效实施人口战略的重要依据，是提高政府决策科学化的支撑。人口信息是社会的基础信息，是政府进行科学决策和公共行政管理的重要依据。长期以来，我国人口管理建立在户籍制度基础上，随着社会主义市场经济体制改革的深入发展，人口流动性越来越大，旧的管理模式已经不适应社会的发展需要。公安局、劳保局、建交委、社发局、工商局等部门都在实施对部分人口的专门管理，其要求是对实际居住地人口的管理，取得一定成效。由于各部门对人口管理和发展存在差异，统计口径也不一致，造成人口管理、统计的基础和基数始终不能统一，致使不能得到准确的人口及其分布状况信息。因此，迫切需要建立一个以公安人口信息为基础，以公民身份号码（境外人口为护照号）为唯一代码，以其他部门为补充和核准的，具有权威性、基础性和战略性的人口基础数据

XXX基础数据库系统建设可行性研究报告 (1)

XX城市基础数据库系统建设可行性方案

1.系统概述长期以来，政府各部门内部拥有着大量城市基础数据资源，但由于管理分散，制度规范不健全，造成重复采集、口径多乱、数出多门；各部门的指标数据自成体系，标准不一，共享程度较差。随着政府向“经济调节、市场监管、社会管理和公共服务”管理职能的转变，就要求必须能够全面、准确掌握全地区经济社会发展态势，强化政府部门掌控决策信息资源的能力，政府部门间信息资源整合与共享需求越来越紧密，但当前部门间信息共享多是点对点方式，没有统一的数据交换管理平台。因此各部门对加快解决数据资源分散管理、数据共享不足的问题需求十分迫切，需要建立城市基础数据库（以下简称智慧城市公共基础数据库）系统以解决以上问题。依托智慧城市公共基础数据库系统的建设，可以实现各委办局、各所辖地区的经济社会综合数据采集交换，为各部门提供更广泛的信息共享支持，一方面数据信息从各委办局、各所辖地区整合接入，另一方面也为政府和这些接入部门提供全面的共享服务。同时，以智慧城市公共基础数据库指标体系建立为基础，整合来自各委办局和各所辖地区的、经过审核转换处理的数据资源，可实现对经济社会信息的统一和集中存储，确保数据的唯一性和准确性，为今后政府工作提供一致的基础数据支持。数据整合共享只是手段，数据分析服务才是目的。依托智慧城市公共基础数据库系统建设，可有效整合各政府部门所掌握的全市经济社会信息资源，满足政府业务对统一数据资源共享需要，进而提升形势分析预测水平，对政府在发展规划、投资布局、资源环境、管理创新、科学决策等业务提供强有力支持，提高了政府部门掌控全市经济社会发展态势能力。 2.建设目标 1）建立科学合理的智慧城市公共基础数据库指标体系，力求全面反映地区经济和

数据中心同步平台建设方案

数据中心同步平台建设方案 Hessen was revised in January 2021

数据中心同步平台建设方案第一章概述平台建设背景当前政府、企业的信息化的状况是，各政府和企业一般都设计和建设了属于机构、业务本身的应用、流程以及数据的信息处理系统，独立、异构、涵盖各自业务内容的信息处理系统，系统设计建设的时期不同、业务模式不同，信息化建设缺乏有效的总体规划，重复建设；缺乏统一的设计标准，大多数系统都是由不同的厂商在不同的平台上，使用不同的语言进行开发的，信息交互共享困难，存在大量的信息孤岛和流程孤岛。为了有效整合分散异构的信息资源，消除“信息孤岛”现象，提高政府和企业的信息化水平。宇思公司要开发的数据共享交换平台，主要目的是有效整合分散异构系统的信息资源，消除“信息孤岛”现象，提高政府和企业的信息化水平，灵活实现不同系统间的信息交换、信息共享与业务协同，加强信息资源管理，开展数据和应用整合，进一步发挥信息资源和应用系统的效能，提升信息化建设对业务和管理的支撑作用。要求新构建的数据共享交换平台要遵循标准的、面向服务架构（SOA）的方式，基于先进的企业服务总线ESB技术，遵循先进技术标准和规范，为跨地域、跨部门、跨平台不同应用系统、不同数据库之间的互连互通提供包含提取、转换、传输和加密等操作的数据交换服务，实现扩展性良好的“松耦合”结构的应用和数据集成；同时要求数据共享交换平台，能够通过分布式部署和集中式管理架构，可以有效解决各节点之间数据的及时、高效地上传下达，在安

全、方便、快捷、顺畅的进行信息交换的同时精准的保证数据的一致性和准确性，实现数据的一次数据共享交换平台-设计方案采集、多系统共享；要求数据交换平台节点服务器适配器的可视化配置功能，可以有效解决数据交换平台的“最后一公里”问题，快速实现不同机构、不同应用系统、不同数据库之间基于不同传输协议的数据交换与信息共享，为各种应用和决策支持提供良好的数据环境。要求数据共享交换平台能够把各种纷繁复杂的数据系统集成在一起完成特定业务，提供同构数据、异构数据之间的数据抽取、格式转换、内容过滤、内容转换、同异步传输、动态部署、可视化管理监控等方面功能，支持的数据包括各主流数据库（如Oracle、SQL Server、MySQL等）、地理空间数据（如卫星影像、矢量数据）、常规文件（word、excel、pdf）等各种格式，并可以根据用户需求定制开发特定业务服务。应用场景场景一：中国科学院电子学研究所的信息交换需求实现各个数据中心间的数据库层面的数据共享交换，各中心之间是双向的、实时的数据交换，各数据节点的数据库是同构的数据库系统（即Oracle），数据的类型是基于数据库表格的规则数据，字段类型包含BLOB字段类型。目前各数据节点的数据结构（表）是相同的，主要是一表对一表的数据交换，数据抽取和过滤需求比较简单。目前数据共享交换是通过Oracle GoldenGate数据库同步工具来实现的。用户具体需求包括：

mysql数据库主主同步方案

Mysql 数据库主主（master-master）同步方案一、MySQL同步概述 1.MySQL数据的复制的基本介绍目前MySQL数据库已经占去数据库市场上很大的份额，其一是由于MySQL数据的开源性和高性能，当然还有重要的一条就是免费~不过不知道还能免费多久，不容乐观的未来，但是我们还是要能熟练掌握MySQL数据的架构和安全备份等功能，毕竟现在它还算是开源界的老大吧！ MySQL数据库支持同步复制、单向、异步复制，在复制的过程中一个服务器充当主服务，而一个或多个服务器充当从服务器。主服务器将更新写入二进制日志文件，并维护文件的一个索引以跟踪日志循环。这些日志可以记录发送到从服务器的更新。当一个从服务器连接主服务器时，它通知主服务器从服务器在日志中读取的最后一次成功更新的位置。从服务器接收从那时起发生的任何更新，然后封锁并等待主服务器通知新的更新。请注意当你进行复制时，所有对复制中的表的更新必须在主服务器上进行。否则，你必须要小心，以避免用户对主服务器上的表进行的更新与对从服务器上的表所进行的更新之间的冲突。单向复制有利于健壮性、速度和系统管理：健壮性：主服务器/从服务器设置增加了健壮性。主服务器出现问题时，你可以切换到从服务器作为备份。

速度快：通过在主服务器和从服务器之间切分处理客户查询的负荷，可以得到更好的客户响应时间。SELECT查询可以发送到从服务器以降低主服务器的查询处理负荷。但修改数据的语句仍然应发送到主服务器，以便主服务器和从服务器保持同步。如果非更新查询为主，该负载均衡策略很有效，但一般是更新查询。系统管理：使用复制的另一个好处是可以使用一个从服务器执行备份，而不会干扰主服务器。在备份过程中主服务器可以继续处理更新。 2.MySQL数据复制的原理 MySQL复制基于主服务器在二进制日志中跟踪所有对数据库的更改(更新、删除等等)。因此，要进行复制，必须在主服务器上启用二进制日志。每个从服务器从主服务器接收主服务器已经记录到其二进制日志的保存的更新，以便从服务器可以对其数据拷贝执行相同的更新。认识到二进制日志只是一个从启用二进制日志的固定时间点开始的记录非常重要。任何设置的从服务器需要主服务器上的在主服务器上启用二进制日志时的数据库拷贝。如果启动从服务器时，其数据库与主服务器上的启动二进制日志时的状态不相同，从服务器很可能失败。将主服务器的数据拷贝到从服务器的一个途径是使用LOAD DATA FROM MASTER语句。请注意LOAD DATA FROM MASTER目前只在

城市公共基础数据库建设方案.

城市基础数据库系统建设方案

数据库负载均衡解决方案

双节点数据库负载均衡解决方案问题的提出？在SQL Server数据库平台上，企业的数据库系统存在的形式主要有单机模式和集群模式（为了保证数据库的可用性或实现备份）如：失败转移集群（MSCS）、镜像（Mirror）、第三方的高可用（HA）集群或备份软件等。伴随着企业的发展，企业的数据量和访问量也会迅猛增加，此时数据库就会面临很大的负载和压力，意味着数据库会成为整个信息系统的瓶颈。这些“集群”技术能解决这类问题吗？SQL Server数据库上传统的集群技术 Microsoft Cluster Server(MSCS) 相对于单点来说Microsoft Cluster Server(MSCS)是一个可以提升可用性的技术，属于高可用集群，Microsoft称之为失败转移集群。 MSCS 从硬件连接上看，很像Oracle的RAC，两个节点，通过网络连接，共享磁盘；事实上SQL Server 数据库只运行在一个节点上，当出现故障时，另一个节点只是作为这个节点的备份；因为始终只有一个节点在运行，在性能上也得不到提升,系统也就不具备扩展的能力。当现有的服务器不能满足应用的负载时只能更换更高配置的服务器。 Mirror 镜像是SQL Server 2005中的一个主要特点，目的是为了提高可用性，和MSCS相比，用户实现数据库的高可用更容易了，不需要共享磁盘柜，也不受地域的限制。共设了三个服务器，第一是工作数据库（Principal Datebase），第二个是镜像数据库（Mirror），第三个是监视服务器（Witness Server，在可用性方面有了一些保证，但仍然是单服务器工作；在扩展和性能的提升上依旧没有什么帮助。

数据库实时同步技术解决方案

数据库实时同步技术解决方案一、前言随着企业的不断发展，企业信息化的不断深入，企业内部存在着各种各样的异构软、硬件平台，形成了分布式异构数据源。当企业各应用系统间需要进行数据交流时，其效率及准确性、及时性必然受到影响。为了便于信息资源的统一管理及综合利用，保障各业务部门的业务需求及协调工作，常常涉及到相关数据库数据实时同步处理。基于数据库的各类应用系统层出不穷，可能涉及到包括ACCESS、SQLSERVER、ORACLE、DB2、MYSQL等数据库。目前国内外几家大型的数据库厂商提出的异构数据库复制方案主要有：Oracle的透明网关技术，IBM的CCD表（一致变化数据表）方案，微软公司的出版者/订阅等方案。但由于上述系统致力于解决异构数据库间复杂的交互操作，过于大而全而且费用较高，并不符合一些中小企业的实际需求。本文结合企业的实际应用实践经验，根据不同的应用类型，给出了相应的数据库实时同步应用的具体解决方案，主要包括： (1) SQLSERVER 到SQLSERVER 同步方案 (2) ORACLE 到SQLSERVER 同步方案 (3) ACCESS 到SQLSERVER/ORACLE 同步方案

二、异构数据库异构数据库系统是相关的多个数据库系统的集合，可以实现数据的共享和透明访问，每个数据库系统在加入异构数据库系统之前本身就已经存在，拥有自己的DMBS。异构数据库的各个组成部分具有自身的自治性，实现数据共享的同时，每个数据库系统仍保有自己的应用特性、完整性控制和安全性控制。异构数据库的异构性主要体现在以下几个方面： 1、计算机体系结构的异构各数据库可以分别运行在大型机、小型机、工作站、PC嵌入式系统中。 2、基础操作系统的异构各个数据库系统的基础操作系统可以是Unix、Windows NT、Linux等。 3、DMBS本身的异构可以是同为关系型数据库系统的Oracle、SQL Server等，也可以是不同数据模型的数据库，如关系、模式、层次、网络、面向对象，函数型数据库共同组成一个异构数据库系统。三、数据库同步技术

【精品】海量数据处理分析

海量数据处理分析北京迈思奇科技有限公司戴子良笔者在实际工作中，有幸接触到海量的数据处理问题，对其进行处理是一项艰巨而复杂的任务。原因有以下几个方面：一、数据量过大，数据中什么情况都可能存在。如果说有10条数据，那么大不了每条去逐一检查，人为处理，如果有上百条数据，也可以考虑，如果数据上到千万级别，甚至过亿，那不是手工能解决的了，必须通过工具或者程序进行处理，尤其海量的数据中，什么情况都可能存在，例如，数据中某处格式出了问题，尤其在程序处理时，前面还能正常处理，突然到了某个地方问题出现了，程序终止了。二、软硬件要求高，系统资源占用率高。对海量的数据进行处理，除了好的方法，最重要的就是合理使用工具，合理分配系统资源。一般情况，如果处理的数据过TB级，小型机是要考虑的，普通的机子如果有好的方法可以考虑，不过也必须加大CPU和内存，就象面对着千军万马，光有勇气没有一兵一卒是很难取胜的。三、要求很高的处理方法和技巧。这也是本文的写作目的所在，好的处理方法是一位工程师长期工作经验的积累，也是个人的经验的总结。没有通用的处理方法，但有通用的原理和规则。那么处理海量数据有哪些经验和技巧呢，我把我所知道的罗列一下，以供大家参考：一、选用优秀的数据库工具现在的数据库工具厂家比较多，对海量数据的处理对所使用的数据库工具要求比较高，一般使用Oracle或者DB2，微软公司最近发布的SQL Server 2005性能也不错。另外在BI领域：数据库，数据仓库，多维数据库，数据挖掘等相关工具也要进行选择，象好的ETL工具和好的OLAP工具都十分必要，例如Informatic，Eassbase等。笔者在实际数据分析项目中，对每天6000万条的日志数据进行处理，使用SQL Server 2000需要花费6小时，而使用SQL Server 2005则只需要花费3小时。二、编写优良的程序代码处理数据离不开优秀的程序代码，尤其在进行复杂数据处理时，必须使用程序。好的程序代码对数据的处理至关重要，这不仅仅是数据处理准确度的问题，更是数据处理效率的问题。良好的程序代码应该包含好的算法，包含好的处理流程，包含好的效率，包含好的异常处理机制等。三、对海量数据进行分区操作对海量数据进行分区操作十分必要，例如针对按年份存取的数据，我们可以按年进行分区，不同的数据库有不同的分区方式，不过处理机制大体相同。例如SQL Server的数据库分区是将不同的数据存于不同的文件组下，而不同的文件组存于不同的磁盘分区下，这样将数据分散开，减小磁盘I/O，减小了系统负荷，而且还可以将日志，索引等放于不同的分区下。四、建立广泛的索引对海量的数据处理，对大表建立索引是必行的，建立索引要考虑到具体情况，例如针对大表的分组、排序等字段，都要建立相应索引，一般还可以建立复合索引，对经常插入的表则建立索引时要小心，笔者在处理数据时，曾经在一个ETL流程中，当插入表时，首先删除索引，然后插入完毕，建立索引，并实施聚合操作，聚合完成后，再次插入前还是删除索引，所以索引要用到好的时机，索引的填充因子和聚集、非聚集索引都要考虑。

MSSQL数据库高可用性方案

高可用MS SQL Server数据库解决方案建设目标减少硬件或软件故障造成的影响，保持业务连续性，从而将用户可以察觉到的停机时间减至最小，确保数据库服务7*24小时（RTO为99.9%）运转，建设一套完整的高可用性MS SQL Server数据库系统。需求分析服务器宕机造成的影响服务器宕机时间使得丢失客户收益并降低员工生产效率，为了避免对业务造成影响，从两个方面采取预防措施：一、计划宕机时的可用性： ●补丁或补丁包安装 ●软硬件升级 ●更改系统配置 ●数据库维护 ●应用程序升级二、防止非计划性宕机： ●人为错误导致的失败 ●站点灾难 ●硬件故障

●数据损毁 ●软件故障现有状况 ●服务器存在单点故障； ●数据库未做高可用性配置； ●数据库版本为MS SQL Server2008； ●服务器配置为CPU E7540 2.0，24G存； ●数据库容量约800G 技术解决方案解决思路考虑到本项目的需求和最佳性能，为了达到最佳可用性，方案采用两台数据库服务器做故障转移集群，连接同一台存储做数据库的共享存储，实现故障自动转移。同时，将旧服务器作为镜像数据库，采用SQL Server 2012的alwayson 功能来再次完成自动故障转移，并可以分担查询的负载。

架构拓扑新数据库：承担数据库主体计算功能，用于生产数据，采用双机集群，实现自动故障转移。旧数据库：通过镜像功能，存储数据库副本，用于发生故障时的转移。也可配置为只读，承担备份的负载。存储：存储采用双控制器，双FC连接两台服务器，避免单点故障。主/辅域控制器：采用双机模式，SQL Server 2012 实现高可用的必备基础设施。高可靠性技术方案 SQL Server的企业版支持所有的高可用性功能，这些功能包括：

浅谈Oracle 数据库之间数据同步方案

随着信息技术的飞速发展，企业信息化建设的不断深入，使得企业业务系统数量不断增加。这时，各业务系统之间数据交互，各子业务系统与核心业务系统之间数据交互，诸如此类场景的应用需求不断出现。因此，IT部门应对此类需求的压力越来越大。比较突出的问题，主要有实时性与性能的冲突，数据交互方案的安全性与健壮性等。下面浅谈下Oracle数据库之间数据同步方案，不涉及方案的好坏选择，可供参考。 Oracle 提供的数据同步方案： 1，比较原始的，触发器/Job + DBLINK的方式，可同步和定时刷新。 2，物化视图刷新的方式，有增量刷新和完全刷新两种模式，定时刷新。 3，高级复制，分为多主复制和物化视图复制两种模式。其中多主复制能进行双向同步复制和异步复制，物化视图用于单向复制，定时刷新，与2类似。 4，流复制，可实时和非实时同步。 5，GoldenGate复制，Oracle新买的复制产品，后面应该会取代流复制。它不仅能提供Oracle数据库之间的数据复制支持，还支持在不同种数据库之间的数据同步，也可设置实时和非实时同步。 6，DataGurd,此技术主要用于灾备方案，不过在最新11gR2版本中加入了备库实时应用日志，同时能open 提供read only访问的功能。因此，可以作为读写分离，或者作为report数据库，降低系统负载的一个好的方案。其中上面1，2，3，是采用Oracle数据库内部的机制来实现，而4，5，6是采用挖掘数据库日志的方式实现的。因此，后面3中方式在性能上会更好些。第三方提供的数据同步方案：主要根据实现机制分为两大类： 1，采用挖掘数据库日志的方式实现市场上用的比较多的，如Quest SharePlex, DSG RealSync 。此类软件与Oracle 新收购的GoldenGate 工具类似。 2，采用相关软件在存储级进行复制 IBM,EMC等存储厂商可以实现，使用第三方存储管理软件，如Veritas Replication也可实现。此类方式应用场景与上面6类似。

SqlServer数据库同步方案详解

SqlServer数据库同步是项目中常用到的环节，若一个项目中的数据同时存在于不同的数据库服务器中，而这些数据库需要被多个不同的网域调用时，配置SqlServer数据库同步是个比较好的解决方案。SqlServer数据库同步的配置比较烦锁，下面对其配置详细步骤进行介绍：一、数据复制前提条件 1. 数据库故障还原模型必需为完全还原模型。 2. 所有被同步的数据表都必须要用主键。 3. 发布服务器、分发服务器和订阅服务器必须使用计算机名称来进行SQLSERVER服务器的注册。 4. SQLSERVER必需启动代理服务，且代理服务必需以本地计算机的帐号运行。二、解决前提条件实施步骤 1. 将数据库故障还原模型调整为完全还原模型。具体步骤如下: 打开SQLSERVER企业管理器à选择对应的数据库à单击右键选择属性à选择”选项”à 故障还原模型选择完全还原模型。 2. 所有被同步的数据表都必须要用主键。（主要指事务复制）如果没有主键的数据表，增加一个字段名称为id,类型为int 型，标识为自增1的字段。 3. 发布服务器、分发服务器和订阅服务器必须使用计算机名称来进行SQLSERVER服务器的注册。在企业管理器里面注册的服务器，如果需要用作发布服务器、分发服务器和订阅服务器，都必需以服务器名称进行注册。不得使用IP地址以及别名进行注册，比如LOCAL, “.”以及LOCALHOST等。

如果非同一网段或者远程服务器，需要将其对应关系加到本地系统网络配置文件中。文件的具体位置在%systemroot%\system32\drivers\etc\hosts 配置方式: 用记事本打开hosts文件，在文件的最下方添加IP地址和主机名的对应关系。如图: SQLSERVER必需启动代理服务，且代理服务必需以本地计算机的帐号运行。启动SQLSERVER代理的方法：我的电脑à单击右键”管理”à服务à SQLSERVERAGENT 将其设为自动启动。如图:

数据库大型应用解决方案

随着互联网应用的广泛普及，海量数据的存储和访问成为了系统设计的瓶颈问题。对于一个大型的互联网应用，每天百万级甚至上亿的PV无疑对数据库造成了相当高的负载。对于系统的稳定性和扩展性造成了极大的问题。 [@more@] 一、负载均衡技术负载均衡集群是由一组相互独立的计算机系统构成，通过常规网络或专用网络进行连接，由路由器衔接在一起，各节点相互协作、共同负载、均衡压力，对客户端来说，整个群集可以视为一台具有超高性能的独立服务器。 1、实现原理实现数据库的负载均衡技术，首先要有一个可以控制连接数据库的控制端。在这里，它截断了数据库和程序的直接连接，由所有的程序来访问这个中间层，然后再由中间层来访问数据库。这样，我们就可以具体控制访问某个数据库了，然后还可以根据数据库的当前负载采取有效的均衡策略，来调整每次连接到哪个数据库。 2、实现多据库数据同步对于负载均衡，最重要的就是所有服务器的数据都是实时同步的。这是一个集群所必需的，因为，如果数不据实时、不同步，那么用户从一台服务器读出的数据，就有别于从另一台服务器读出的数据，这是不能允许的。所以必须实现数据库的数据同步。这样，在查询的时候就可以有多个资源，实现均衡。比较常用的方法是 Moebius for SQL Server集群，Moebius for SQL Server集群采用将核心程序驻留在每个机器的数据库中的办法，这个核心程序称为Moebius for SQL Server 中间件，主要作用是监测数据库内数据的变化并将变化的数据同步到其他数据库中。数据同步完成后客户端才会得到响应，同步过程是并发完成的，所以同步到多个数据库和同步到一个数据库的时间基本相等；另外同步的过程是在事务的环境下完成的，保证了多份数据在任何时刻数据的一致性。正因为Moebius 中间件宿主在数据库中的创新，让中间件不但能知道数据的变化，而且知道引起数据变化的SQL语句，根据SQL语句的类型智能的采取不同的数据同步的策略以保证数据同步成本的最小化。

城市地质数据库系统解决方案

城市地质数据库系统解决方案发布时间：2012-10-26 15:40:01来源：原创【打印本页】 1. 设计目标以城市地质调查成果为基础，初步建立城市三维可视化城市地质信息服务和管理系统，实现地质资料收集全面化、整理标准化、录入格式化、管理常态化；充分挖掘地质资料的潜在价值，实现地质资料信息服务多元化，提升地质资料信息服务化水平，提高地质资料的利用率。通过三维地质建模，实现重点区域地质模块的三维可视化、分析、提取、信息生成等功能，为政府宏观决策、重大工程建设项目实施等提供科学依据，降低社会投资风险，构建城市地质资料信息服务经济社会发展的新体制和动态运行保障机制，全面提升地质工作对经济社会发展的服务水平和综合服务能力。 2. 总体框架设计面向城市地质和三维地质建模数据库建设、成果集成、信息共享和可视化的总体需求，基于GIS、地质、三维可视化和Virtual Globes技术，建立了三维环境下的海量、多尺度、三维立体地质信息的建模、集成、共享和可视化的总体技术框架（下图）。

三维地质建模成果集成、信息共享和可视化的总体技术框架 3. 系统结构与功能设计根据项目建设目标和需求分析，城市地质信息服务和管理系统的系统结构如下图所示，系统从纵向上可以划分为5个层次：（1）数据采集层，（2）数据库层，（3）数据服务层，（4）专题数据及应用层；（5）业务层。

系统结构及功能模块划分示意图 3.1. 数据采集层数据采集层满足各类地质资料数据在数据录入、数据编辑、数据更新、数据转入等方面的需求，包含数据辅助整理入库和辅助建库软件编制工具，实现海量数据库建立和后续数据更新，以及数据访问权限控制。数据采集层实现了基于已有空间数据的建库和三维建模。 3.2. 数据库及其管理层数据管理模块主要是用来管理所有地质专题数据和三维模型数据，实现地质专题数据的导入导出和加载可视化显示。三维模型目前基于标准obj及vrml交换格式存储，以大字段方式存储于数据库。Ctech、discover3D和MapGIS K9等三维建模工具建好的模型导出为中间格式后进行入库，然后统一由数据管理模块进行管理。数据库层存储了来自数据采集系统采集的各类空间和属性数据，按数据类型分包括空间数据库（基础地理空间数据库、专题图形数据库、基础地质数据库），专业属性数据库、三维地质模型数据库等数据库。数据库在Oracle支持下实现空间数据与非空间数据一体化存储与管理，具有下述特征：

两台SQL Server服务器数据同步方案

两台SQL Server服务器数据同步方案时间:2009-08-27 20:57来源:80后学习网作者:小牛点击:165次如何让多台SQL Server服务器实现数据同步呢，本章我会就这个问题来详细讲解的：两台SQL Server服务器数据同步解决方案复制是将一组数据从一个数据源拷贝到多个数据源的技术，是将一份数据发布到多个存储站点上的有效方式。使用复制技术，用户可以将一份数据发布到多台服务器上，从而使不同的服务器用户都可以在权限的许可的范围内共享这份数据。复制技术可以确保分布在不同地点的数据自动同步更新，从而保证数据的一致性。 SQL复制的基本元素包括出版服务器、订阅服务器、分发服务器、出版物、文章 SQL复制的工作原理 SQL SERVER 主要采用出版物、订阅的方式来处理复制。源数据所在的服务器是出版服务器，负责发表数据。出版服务器把要发表的数据的所有改变情况的拷贝复制到分发服务器，分发服务器包含有一个分发数据库，可接收数据的所有改变，并保存这些改变，再把这些改变分发给订阅服务器 SQL SERVER复制技术类型 SQL SERVER提供了三种复制技术，分别是： 1、快照复制(呆会我们就使用这个) 2、事务复制 3、合并复制只要把上面这些概念弄清楚了那么对复制也就有了一定的理解。接下来我们就一步一步来实现复制的步骤。第一先来配置出版服务器 (1)选中指定[服务器]节点 (2)从[工具]下拉菜单的[复制]子菜单中选择[发布、订阅服务器和分发]命令 (3)系统弹出一个对话框点[下一步]然后看着提示一直操作到完成。 (4)当完成了出版服务器的设置以后系统会为该服务器的树形结构中添加一个复制监视器。同时也生成一个分发数据库(distribution) 第二创建出版物 (1)选中指定的服务器 (2)从[工具]菜单的[复制]子菜单中选择[创建和管理发布]命令。此时系统会弹出一个对话框 (3)选择要创建出版物的数据库，然后单击[创建发布] (4)在[创建发布向导]的提示对话框中单击[下一步]系统就会弹出一个对话框。对话框上的内容是复制的三个类型。我们现在选第一个也就是默认的快照发布(其他两个大家可以去看看帮助)

大量数据海量数据处理办法

大数据量的问题是很多面试笔试中经常出现的问题，比如baidu google 腾讯这样的一些涉及到海量数据的公司经常会问到。下面的方法是我对海量数据的处理方法进行了一个一般性的总结，当然这些方法可能并不能完全覆盖所有的问题，但是这样的一些方法也基本可以处理绝大多数遇到的问题。下面的一些问题基本直接来源于公司的面试笔试题目，方法不一定最优，如果你有更好的处理方法，欢迎与我讨论。 1.Bloom filter 适用范围：可以用来实现数据字典，进行数据的判重，或者集合求交集基本原理及要点：对于原理来说很简单，位数组+k个独立hash函数。将hash函数对应的值的位数组置1，查找时如果发现所有hash函数对应位都是1说明存在，很明显这个过程并不保证查找的结果是100%正确的。同时也不支持删除一个已经插入的关键字，因为该关键字对应的位会牵动到其他的关键字。所以一个简单的改进就是counting Bloom filter，用一个counter数组代替位数组，就可以支持删除了。还有一个比较重要的问题，如何根据输入元素个数n，确定位数组m的大小及hash函数个数。当hash函数个数k=(ln2)*(m/n)时错误率最小。在错误率不大于E的情况下，m至少要等于n*lg(1/E)才能表示任意n个元素的集合。但m还应该更大些，因为还要保证bit数组里至少一半为0，则m应该> =nlg(1/E)*lge 大概就是nlg(1/E)1.44倍(lg表示以2为底的对数)。举个例子我们假设错误率为0.01，则此时m应大概是n的13倍。这样k大概是8个。注意这里m与n的单位不同，m是bit为单位，而n则是以元素个数为单位(准确的说是不同元素的个数)。通常单个元素的长度都是有很多bit的。所以使用bloom filter内存上通常都是节省的。