一 : Oracle跨数据库查询（database link方式）

通过创建database link实现Oracle跨数据库查询的方法

在Oracle本地数据库端执行赋权dbuser帐号

SQL> grant create database link to dbuser;

配置本地数据库服务器的tnsnames.ora文件
$ vi $ORACLE_HOME/network/admin/tnsnames.ora

增加需要远程连接服务器的连接配置，如：

ORCL_REMOTE =
(DESCRIPTION =
(ADDRESS = (PROTOCOL = TCP)(HOST = oradb )(PORT = 1521))
(CONNECT_DATA =
(SERVER = DEDICATED)
(SERVICE_NAME = orcl)
)
)

登录到本地数据库，创建database link

执行如下查询语句，其中ORCL_LINK为database link名（可自定义），ORCL_REMOTE为先前在tnsnames.ora中定义的连接名，
dbuser为用户名，password为密码

create database link ORCL_LINK connect to dbuser identified by password using 'ORCL_REMOTE';

查询创建database link的2中方式：
1)、执行SQL语句。
select * from user_db_links; --用户 DB Link
select * from dba_db_links; --dba DB Link
select * from v$dblink; --当前DB Link

2)、在PL/SQL中，在左边浏览器中点击database links就可以看到数据库链路了。

。www.61k.com。

使用链接的数据库

查询、删除和插入数据和操作本地的数据库是一样的，只不过表名需要写成“表名@database link名”，如
select * from table_name@ORCL_LINK

其它：

删除database link（本例中是ORCL_LINK）
SQL> Drop database link ORCL_LINK;

在CentOS6.4下安装Oracle 11gR2(x64)

Oracle 11gR2 在VMWare虚拟机中安装步骤

Debian 下 安装 Oracle 11g XE R2

更多Oracle相关信息见Oracle专题页面

二 : 解析Facebook的数据库查询引擎Presto在美团的应用

Facebook的数据仓库存储在少量大型Hadoop/HDFS集群。Hive是Facebook在几年前专为Hadoop打造的一款数据仓库工具。在以前，Facebook的科学家和分析师一直依靠Hive来做数据分析。但Hive使用MapReduce作为底层计算框架，是专为批处理设计的。但随着数据越来越多，使用Hive进行一个简单的数据查询可能要花费几分到几小时，显然不能满足交互式查询的需求。Facebook也调研了其他比Hive更快的工具，但它们要么在功能有所限制要么就太简单，以至于无法操作Facebook庞大的数据仓库。

2012年开始试用的一些外部项目都不合适，他们决定自己开发，这就是Presto。2012年秋季开始开发，目前该项目已经在超过 1000名Facebook雇员中使用，运行超过30000个查询，每日数据在1PB级别。Facebook称Presto的性能比Hive要好上10倍多。2013年Facebook正式宣布开源Presto。

本文首先介绍Presto从用户提交SQL到执行的这一个过程，然后尝试对Presto实现实时查询的原理进行分析和总结，最后介绍Presto在美团的使用情况。

Presto架构

Presto查询引擎是一个Master-Slave的架构，由一个Coordinator节点，一个Discovery Server节点，多个Worker节点组成，Discovery Server通常内嵌于Coordinator节点中。Coordinator负责解析SQL语句，生成执行计划，分发执行任务给Worker节点执行。Worker节点负责实际执行查询任务。Worker节点启动后向Discovery Server服务注册，Coordinator从Discovery Server获得可以正常工作的Worker节点。如果配置了Hive Connector，需要配置一个Hive MetaStore服务为Presto提供Hive元信息，Worker节点与HDFS交互读取数据。

Presto执行查询过程简介
既然Presto是一个交互式的查询引擎，我们最关心的就是Presto实现低延时查询的原理，我认为主要是下面几个关键点，当然还有一些传统的SQL优化原理，这里不介绍了。

完全基于内存的并行计算
流水线
本地化计算
动态编译执行计划
小心使用内存和数据结构
类BlinkDB的近似查询
GC控制
为了介绍上述几个要点，这里先介绍一下Presto执行查询的过程

提交查询
用户使用Presto Cli提交一个查询语句后，Cli使用HTTP协议与Coordinator通信，Coordinator收到查询请求后调用SqlParser解析SQL语句得到Statement对象，并将Statement封装成一个QueryStarter对象放入线程池中等待执行。

SQL编译过程
Presto与Hive一样，使用Antlr编写SQL语法，语法规则定义在Statement.g和StatementBuilder.g两个文件中。
如下图中所示从SQL编译为最终的物理执行计划大概分为5部，最终生成在每个Worker节点上运行的LocalExecutionPlan，这里不详细介绍SQL解析为逻辑执行计划的过程，通过一个SQL语句来理解查询计划生成之后的计算过程。

样例SQL：

select c1.rank, count(*) from dim.city c1 join dim.city c2 on c1.id = c2.id where c1.id > 10 group by c1.rank limit 10;

上面的SQL语句生成的逻辑执行计划Plan如上图所示。那么Presto是如何对上面的逻辑执行计划进行拆分以较高的并行度去执行完这个计划呢，我们来看看物理执行计划。

物理执行计划
逻辑执行计划图中的虚线就是Presto对逻辑执行计划的切分点，逻辑计划Plan生成的SubPlan分为四个部分，每一个SubPlan都会提交到一个或者多个Worker节点上执行。

SubPlan有几个重要的属性planDistribution、outputPartitioning、partitionBy属性。

PlanDistribution表示一个查询Stage的分发方式，逻辑执行计划图中的4个SubPlan共有3种不同的PlanDistribution方式：Source表示这个SubPlan是数据源，Source类型的任务会按照数据源大小确定分配多少个节点进行执行；Fixed表示这个SubPlan会分配固定的节点数进行执行（Config配置中的query.initial-hash-partitions参数配置，默认是8）；None表示这个SubPlan只分配到一个节点进行执行。在下面的执行计划中，SubPlan1和SubPlan0 PlanDistribution=Source，这两个SubPlan都是提供数据源的节点，SubPlan1所有节点的读取数据都会发向SubPlan0的每一个节点；SubPlan2分配8个节点执行最终的聚合操作；SubPlan3只负责输出最后计算完成的数据。
OutputPartitioning属性只有两个值HASH和NONE，表示这个SubPlan的输出是否按照partitionBy的key值对数据进行Shuffle。在下面的执行计划中只有SubPlan0的OutputPartitioning=HASH，所以SubPlan2接收到的数据是按照rank字段Partition后的数据。

完全基于内存的并行计算
查询的并行执行流程
Presto SQL的执行流程如下图所示

Cli通过HTTP协议提交SQL查询之后，查询请求封装成一个SqlQueryExecution对象交给Coordinator的SqlQueryManager#queryExecutor线程池去执行
每个SqlQueryExecution线程（图中Q-X线程）启动后对查询请求的SQL进行语法解析和优化并最终生成多个Stage的SqlStageExecution任务，每个SqlStageExecution任务仍然交给同样的线程池去执行
每个SqlStageExecution线程（图中S-X线程）启动后每个Stage的任务按PlanDistribution属性构造一个或者多个RemoteTask通过HTTP协议分配给远端的Worker节点执行
Worker节点接收到RemoteTask请求之后，启动一个SqlTaskExecution线程（图中T-X线程）将这个任务的每个Split包装成一个PrioritizedSplitRunner任务（图中SR-X）交给Worker节点的TaskExecutor#executor线程池去执行

上面的执行计划实际执行效果如下图所示。

Coordinator通过HTTP协议调用Worker节点的 /v1/task 接口将执行计划分配给所有Worker节点（图中蓝色箭头）
SubPlan1的每个节点读取一个Split的数据并过滤后将数据分发给每个SubPlan0节点进行Join操作和Partial Aggr操作
SubPlan1的每个节点计算完成后按GroupBy Key的Hash值将数据分发到不同的SubPlan2节点
所有SubPlan2节点计算完成后将数据分发到SubPlan3节点
SubPlan3节点计算完成后通知Coordinator结束查询，并将数据发送给Coordinator

源数据的并行读取
在上面的执行计划中SubPlan1和SubPlan0都是Source节点，其实它们读取HDFS文件数据的方式就是调用的HDFS InputSplit API，然后每个InputSplit分配一个Worker节点去执行，每个Worker节点分配的InputSplit数目上限是参数可配置的，Config中的query.max-pending-splits-per-node参数配置，默认是100。

分布式的Hash聚合
上面的执行计划在SubPlan0中会进行一次Partial的聚合计算，计算每个Worker节点读取的部分数据的部分聚合结果，然后SubPlan0的输出会按照group by字段的Hash值分配不同的计算节点，最后SubPlan3合并所有结果并输出

流水线
数据模型
Presto中处理的最小数据单元是一个Page对象，Page对象的数据结构如下图所示。一个Page对象包含多个Block对象，每个Block对象是一个字节数组，存储一个字段的若干行。多个Block横切的一行是真实的一行数据。一个Page最大1MB，最多16*1024行数据。

节点内部流水线计算
下图是一个Worker节点内部的计算流程图，左侧是任务的执行流程图。

Worker节点将最细粒度的任务封装成一个PrioritizedSplitRunner对象，放入pending split优先级队列中。每个

Worker节点启动一定数目的线程进行计算，线程数task.shard.max-threads=availableProcessors() * 4，在config中配置。

每个空闲的线程从队列中取出一个PrioritizedSplitRunner对象执行，如果执行完成一个周期，超过最大执行时间1秒钟，判断任务是否执行完成，如果完成，从allSplits队列中删除，如果没有，则放回pendingSplits队列中。

每个任务的执行流程如下图右侧，依次遍历所有Operator，尝试从上一个Operator取一个Page对象，如果取得的Page不为空，交给下一个Operator执行。

节点间流水线计算
下图是ExchangeOperator的执行流程图，ExchangeOperator为每一个Split启动一个HttpPageBufferClient对象，主动向上一个Stage的Worker节点拉数据，数据的最小单位也是一个Page对象，取到数据后放入Pages队列中

本地化计算
Presto在选择Source任务计算节点的时候，对于每一个Split，按下面的策略选择一些minCandidates

优先选择与Split同一个Host的Worker节点
如果节点不够优先选择与Split同一个Rack的Worker节点
如果节点还不够随机选择其他Rack的节点
对于所有Candidate节点，选择assignedSplits最少的节点。

动态编译执行计划
Presto会将执行计划中的ScanFilterAndProjectOperator和FilterAndProjectOperator动态编译为Byte Code，并交给JIT去编译为native代码。Presto也使用了Google Guava提供的LoadingCache缓存生成的Byte Code。

上面的两段代码片段中，第一段为没有动态编译前的代码，第二段代码为动态编译生成的Byte Code反编译之后还原的优化代
码，我们看到这里采用了循环展开的优化方法。

循环展开最常用来降低循环开销，为具有多个功能单元的处理器提供指令级并行。也有利于指令流水线的调度。

小心使用内存和数据结构
使用Slice进行内存操作，Slice使用Unsafe#copyMemory实现了高效的内存拷贝，Slice仓库参考：https://github.com/airlift/slice

Facebook工程师在另一篇介绍ORCFile优化的文章中也提到使用Slice将ORCFile的写性能提高了20%~30%，参考：https://code.facebook.com/posts/229861827208629/scaling-the-facebook-data-warehouse-to-300-pb/

类BlinkDB的近似查询
为了加快avg、count distinct、percentile等聚合函数的查询速度，Presto团队与BlinkDB作者之一Sameer Agarwal合作引入了一些近似查询函数approx_avg、approx_distinct、approx_percentile。approx_distinct使用HyperLogLog Counting算法实现。

GC控制
Presto团队在使用hotspot java7时发现了一个JIT的BUG，当代码缓存快要达到上限时，JIT可能会停止工作，从而无法将使用频率高的代码动态编译为native代码。

Presto团队使用了一个比较Hack的方法去解决这个问题，增加一个线程在代码缓存达到70%以上时进行显式GC，使得已经加载的Class从perm中移除，避免JIT无法正常工作的BUG。

美团如何使用Presto
选择presto的原因
2013年我们也用过一段时间的impala，当时impala不支持线上1.x的hadoop社区版，所以搭了一个CDH的小集群，每天将大集群的热点数据导入小集群。但是hadoop集群年前完成升级2.2之后，当时的impala还不支持2.2 hadoop版本。而Presto刚好开始支持2.x hadoop社区版，并且Presto在Facebook 300PB大数据量的环境下可以成功的得到大量使用，我们相信它在美团也可以很好的支撑我们实时分析的需求，于是决定先上线测试使用一段时间。

部署和使用形式
考虑到两个原因：1、由于Hadoop集群主要是夜间完成昨天的计算任务，白天除了日志写入外，集群的计算负载较低。2、Presto Worker节点与DataNode节点布置在一台机器上可以本地计算。因此我们将Presto部署到了所有的DataNode机器上，并且夜间停止Presto服务，避免占用集群资源，夜间基本也不会有用户查询数据。

Presto二次开发和BUG修复
年后才正式上线Presto查询引擎，0.60版本，使用的时间不长，但是也遇到了一些问题：

美团的Hadoop使用的是2.2版本，并且开启了Security模式，但是Presto不支持Kerberos认证，我们修改了Presto代码，增加了Kerberos认证的功能。
Presto还不支持SQL的隐式类型转换，而Hive支持，很多自助查询的用户习惯了Hive，导致使用Presto时都会出现表达式中左右变量类型不匹配的问题，我们增加了隐式类型转换的功能，大大减小了用户SQL出错的概率。
Presto不支持查询lzo压缩的数据，需要修改hadoop-lzo的代码。
解决了一个having子句中有distinct字段时查询失败的BUG，并反馈了Presto团队 https://github.com/facebook/presto/pull/1104
所有代码的修改可以参考我们在github上的仓库 https://github.com/MTDATA/presto/commits/mt-0.60

实际使用效果
这里给出一个公司内部开放给分析师、PM、工程师进行自助查询的查询中心的一个测试报告。这里选取了平时的5000个Hive查询，通过Presto查询的对比见下面的表格。

三 : Excel中保存Microsoft Query查询和数据库密码

　　Microsoft Query 查询定义可以保存在扩展名为qdy的文件中，打开qdy文件读取外部数据后，excel默认将查询定义和数据一道保存在excel文件中的。更新数据时只要刷新数据(点击“全部刷新”按钮)就行了。如果没有“全部刷新”按钮，点击菜单“工具”--“自定义”，勾选“外部数据”即可。 　　新的查询也可以复制当前建立好查询工作表后点击菜单“数据”—“导入外部数据”—“编辑查询”进入Microsoft Query编辑界面，修改SQL语句，产生一个新的查询。当向导无法建立的复杂查询也可以用这种方式产生。
　　建立查询或者打开一个查询读取外部数据时需要提供数据库的用户名和密码，输入密码获取数据后保存excel文件时系统默认将查询定义和数据一道保存在excel文件中，下次点击刷新虽然可以根据查询语句更新数据，但仍需要输入数据库密码，通过设置可以保存数据库密码以便简化操作，加快更新速度。方法是点击菜单“数据”—“导入外部数据”—“ 数据区域属性”，如下图：
　　勾选保存密码即可，如下图：

四 : 数据库查询的分页优化技巧

分页浏览功能是常见的Web应用功能，对于MySQL数据库来说可以很轻松的使用limit语句实现分页，而对于SQL Server数据库来说，常见的方法是使用数据集本身的游标实现分页，这种方法对于少量数据来说没什么问题，但是对于稍大一点的数据量，例如几十万条数据，则查询速度会降低很多，这里我介绍一种常用的技巧，只要简单的重新构造一下查询SQL语句，就能大幅提高查询性能的方法。

在分页算法中，影响查询速度的关键因素在于返回数据集的大小，我们先在数据表中设置一个名为id的主键，数值为自增量的整数，然后通过重构查询SQL语句，就可以实现SQL查询的优化，重构的SQL如下所示

以下为引用的内容： select top 页大小 * from table1 where id<=       (select min (id) from       (select top ((页码-1)*页大小) id from table1 order by id desc) as T        )    order by id desc

下面的JSP演示代码中，intPageSize为页大小，intPage为页码，id为主键，演示了操作一个t_Product表，并加入各类查询条件之后的重构SQL的主要语句，经过实际调试，经过这样简单优化后的SQL查询速度远远高于优化前的查询速度。

以下为引用的内容： String sql=" from t_Product where 1=1 and "; String ProductName = request.getParameter("ProductName"); if (ProductName!=null) sql=sql+"ProductName like '%" + ProductName + "%' and " ; sql=sql.substring(0,sql.length()-4);  // 去掉尾部的 and 字符串 sql="select top " + String.valueOf(intPageSize) + " *" +sql+" and id <=(select min(id) from (select top " +  String.valueOf(intPage*intPageSize) + " id " + sql + " order by id desc) as T) "; //通过子查询加快速度 sql=sql+" order by id desc ";

本文标题：hibernate查询数据库-Oracle跨数据库查询（database link方式）
本文地址： http://www.61k.com/1084278.html