java分表查询

⑴ 数据库分表后，怎样方便查询 比如表a中间的字段id,title,content.数据量很大，8百万条记录

我们在工作中的表都上亿的数据，所以考虑的效率问题要根据区域分表；比如西城是01，东城是02，朝阳区是03；你要根据id查某个表的content ,数据分表是依据程序来的，建议建一个配置表 A ,
value_id Tablename
01 table01
02 table02
03 talble03
.
.
table01
id,title,content
1 xx dfd
2 yy ddf
3 zz dfdf
.
.
table02
id,title,content
12 xx1 dfdxx
13 yy1 ddfxx
14 zz1 dfdfxx

如果再数据库中执行查询

create or replace procere Prc_Get_Record( v_id in varchar2,v_tableid in varchar2,v_content out varchar )
is
v_table varchar2(20);
v_sql varchar2(4000);
BEGIN

select Tablename into v_table from A where value_id ='v_tableid' ;

v_sql:='select content from '||v_table||' t where t.id='''|| v_id ||'''';

execute immediate v_sql into v_content;

end if;

END Prc_Get_Record;

存储过程调用输入参数

Prc_Get_Record('1','01',content ); content 为你所想想要分的a的 “dfd”
Prc_Get_Record('14,'02',content ); content 为你所想想要分的a的 “dfdfxx”

如果是java代码，要得到数据，可以建立一个函数

public String getTablename( String tableid){

//暂用hibernate的base
String sql ="select Tablename from A where value_id ="+v_tableid ;

return baseDao.getString(sql);

}
//分表查询的结果

String id = request.getParameter("id");
String table_name = getRTableName("01");

String sql = "select content from "+table_name+" d where d.id='" + id + "' ";
return baseDao.getString(sql);
}

其他的 ibatIS，hibernate ；xml的sql查询 同样是如此，在form里获取，表名变量，get，set 将配置表的表名作为sql字符的一个变量执行。

sql里
/~table_name : {tablename}~/

⑵ Java怎么分区分表

当Java程序创建一个类的实例或者数组时，都在堆中为新的对象分配内存。虚拟机中只有一个堆，所有的线程都共享他。Java中所有的对象都存放在堆中，包括class对象和异常对象。
那么这些对象中有存放些什么呢？实例数据是肯定的，还有就是当通过对象访问类信息时就必须有一个指针将对象和方法区中的类信息关联起来，关联的方法有多种。一个可能的堆的设计是将堆分为两个部分：引用池和对象池。一个对象的引用就是指向引用池的本地指针。

⑶ java里当数据库里的数据量很大的时候、要一次性查询出来、并且展示出来、应该怎样查询、效率更高

sql语句要快1.不必要的列就不用查出来;2作为查询的条件列设索引;3.如果查询的表数据大于500万条数据,表创建之初就应该建立表分区,依据分表去查;
最最重要的是传输给前台页面的数据量尽量简化减少传输量,比如时间数据最好不传,自己规定个顺序,依据顺序前台生成对应的时间;非要传可转为毫秒数去掉最后四个零(依据实际情况而定,因为时间只要求精确到分),用[]不用{}(key就不用传了,根据商量好的下标对应提取)

⑷ 一个JAVA单体项目中的数据库有必要分库分表吗

分库分表要看数据量有多大
一般一个表数据超过几个G就应该进行分表操作，非常大的话可以进行分库操作

⑸ hibernate 分表解决方案。一个JAVA类，一个HBM.XML，对应多个结构相同的表。该怎么处理

用注解你看怎么样 就是 不用hbm.xml 用@Entity（里面加个变量，这个变量来更换表明，看你的意思不是其他结构都相同吗，你用过注解吧，没用过可以看下资料，基本的配置不难按规定配置就是了，把你的model写个构造器，里面传表名），Hibernater.cfg.xml<mapping class="model的路径带类名的"/>里面我就是这么一想，仅供参考

⑹ java如何实现一千万条数据的计算而内存不会溢出

这跟大数据查询优化的方法差不多，毕竟数据量在那里，不可能单靠一种方式就能解决。
1）、硬件要求不用说了，表空间，内存等分配最大；
2）、如果大表已经做过分表最好，其次就是常用查询用的字段加索引(有时候效果很明显)；
3）、SQL语句方面，用exist代替in，查询大表前小表后，过滤条件方最后，大条件方最后，
尽量用表关联查询减少子查询，避免在索引上试用计算；
4）、程序方面；尽量减少在同一循环内做复杂计算，多条件计算等。
5）、采用缓存技术，避免大数据的重复查询。

⑺ 分库的数据用java怎么并行查询

如果使用java多线程查询，必须使用CyclicBarrier，等待所有结果都查询完成合并结果集，或者使用dblink，然后HINT方式使用并行Parallell，利用数据的并行技术进行查询

⑻ mysql分库分表后如何统计

数据库分库分表是缓解数据库服务器压力和增加并发量的途径之一，但是随着分库分表之后，也不可避免的带来了一些问题，很显而易见的问题就是如何解决分库后的查询统计。分库之后没有SQL可以用了，简单的过滤后再合并还可以做，但分组都会很麻烦，必须把分库分组汇总结集再分组汇总。这对很多java应用程序员来讲是个挑战。但是，数据量太大大，不分库也不行，进退两难。

这时候，采用集算器来做后一步的汇总计算就很容易，比如刚才说的分组汇总问题，写出来只要这么几行：

这里实现分组的代码还考虑了让分库并行执行SQL。

利用集算器实现分库汇总里包含几个典型例子来说明分库汇总的用法，跨库数据表的运算 是有关分库后统计查询的更详细解释，还有讲解视频分库后的统计查询梳理要点和难点。集算器还很容易嵌入到Java应用程序中，Java 如何调用 SPL 脚本 有使用和获得它的方法。关于集算器安装使用、获得免费授权和相关技术资料，可以参见 集算器如何使用 。

⑼ java数据库分库分表怎么路由

可以按照时间划分库，或者按照账户数量等，在一张表里面存储账户对应的库名，然后每次操作库的时候从内存中通过账户id获取库名，表名应该是统一的，只是对应的表明前缀不一样而已（前缀是根据账户id或者一定规则开头，后半部分应该都一样的）

⑽ 如何用java 建立一个分布式系统

分布式架构的演进

系统架构演化历程-初始阶段架构

初始阶段 的小型系统 应用程序、数据库、文件等所有的资源都在一台服务器上通俗称为LAMP

特征：
应用程序、数据库、文件等所有的资源都在一台服务器上。

描述：
通常服务器操作系统使用Linux，应用程序使用PHP开发，然后部署在Apache上，数据库使用MySQL，汇集各种免费开源软件以及一台廉价服务器就可以开始系统的发展之路了。

系统架构演化历程-应用服务和数据服务分离

好景不长，发现随着系统访问量的再度增加，webserver机器的压力在高峰期会上升到比较高，这个时候开始考虑增加一台webserver

特征：
应用程序、数据库、文件分别部署在独立的资源上。

描述：
数据量增加，单台服务器性能及存储空间不足，需要将应用和数据分离，并发处理能力和数据存储空间得到了很大改善。

系统架构演化历程-使用缓存改善性能

特征：
数据库中访问较集中的一小部分数据存储在缓存服务器中，减少数据库的访问次数，降低数据库的访问压力。

描述：
系统访问特点遵循二八定律，即80%的业务访问集中在20%的数据上。
缓存分为本地缓存和远程分布式缓存，本地缓存访问速度更快但缓存数据量有限，同时存在与应用程序争用内存的情况。

系统架构演化历程-使用应用服务器集群

在做完分库分表这些工作后，数据库上的压力已经降到比较低了，又开始过着每天看着访问量暴增的幸福生活了，突然有一天，发现系统的访问又开始有变慢的趋势了，这个时候首先查看数据库，压力一切正常，之后查看webserver，发现apache阻塞了很多的请求，而应用服务器对每个请求也是比较快的，看来 是请求数太高导致需要排队等待，响应速度变慢

特征：
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，提升系统的并发处理能力，使得服务器的负载压力不再成为整个系统的瓶颈。
系统架构演化历程-数据库读写分离

享受了一段时间的系统访问量高速增长的幸福后，发现系统又开始变慢了，这次又是什么状况呢，经过查找，发现数据库写入、更新的这些操作的部分数据库连接的资源竞争非常激烈，导致了系统变慢

特征：
多台服务器通过负载均衡同时向外部提供服务，解决单台服务器处理能力和存储空间上限的问题。

描述：
使用集群是系统解决高并发、海量数据问题的常用手段。通过向集群中追加资源，使得服务器的负载压力不在成为整个系统的瓶颈。
系统架构演化历程-反向代理和CDN加速

特征：
采用CDN和反向代理加快系统的 访问速度。

描述：
为了应付复杂的网络环境和不同地区用户的访问，通过CDN和反向代理加快用户访问的速度，同时减轻后端服务器的负载压力。CDN与反向代理的基本原理都是缓存。
系统架构演化历程-分布式文件系统和分布式数据库

随着系统的不断运行，数据量开始大幅度增长，这个时候发现分库后查询仍然会有些慢，于是按照分库的思想开始做分表的工作

特征：
数据库采用分布式数据库，文件系统采用分布式文件系统。

描述：
任何强大的单一服务器都满足不了大型系统持续增长的业务需求，数据库读写分离随着业务的发展最终也将无法满足需求，需要使用分布式数据库及分布式文件系统来支撑。
分布式数据库是系统数据库拆分的最后方法，只有在单表数据规模非常庞大的时候才使用，更常用的数据库拆分手段是业务分库，将不同的业务数据库部署在不同的物理服务器上。
系统架构演化历程-使用NoSQL和搜索引擎

特征：
系统引入NoSQL数据库及搜索引擎。

描述：
随着业务越来越复杂，对数据存储和检索的需求也越来越复杂，系统需要采用一些非关系型数据库如NoSQL和分数据库查询技术如搜索引擎。应用服务器通过统一数据访问模块访问各种数据，减轻应用程序管理诸多数据源的麻烦。
系统架构演化历程-业务拆分

特征：
系统上按照业务进行拆分改造，应用服务器按照业务区分进行分别部署。

描述：
为了应对日益复杂的业务场景，通常使用分而治之的手段将整个系统业务分成不同的产品线，应用之间通过超链接建立关系，也可以通过消息队列进行数据分发，当然更多的还是通过访问同一个数据存储系统来构成一个关联的完整系统。

纵向拆分：
将一个大应用拆分为多个小应用，如果新业务较为独立，那么就直接将其设计部署为一个独立的Web应用系统

纵向拆分相对较为简单，通过梳理业务，将较少相关的业务剥离即可。

横向拆分：将复用的业务拆分出来，独立部署为分布式服务，新增业务只需要调用这些分布式服务

横向拆分需要识别可复用的业务，设计服务接口，规范服务依赖关系。

系统架构演化历程-分布式服务

特征：
公共的应用模块被提取出来，部署在分布式服务器上供应用服务器调用。

描述：
随着业务越拆越小，应用系统整体复杂程度呈指数级上升，由于所有应用要和所有数据库系统连接，最终导致数据库连接资源不足，拒绝服务。

Q：分布式服务应用会面临哪些问题？

A：
(1) 当服务越来越多时，服务URL配置管理变得非常困难，F5硬件负载均衡器的单点压力也越来越大。
(2) 当进一步发展，服务间依赖关系变得错踪复杂，甚至分不清哪个应用要在哪个应用之前启动，架构师都不能完整的描述应用的架构关系。
(3) 接着，服务的调用量越来越大，服务的容量问题就暴露出来，这个服务需要多少机器支撑？什么时候该加机器？
(4) 服务多了，沟通成本也开始上升，调某个服务失败该找谁？服务的参数都有什么约定？
(5) 一个服务有多个业务消费者，如何确保服务质量？
(6) 随着服务的不停升级，总有些意想不到的事发生，比如cache写错了导致内存溢出，故障不可避免，每次核心服务一挂，影响一大片，人心慌慌，如何控制故障的影响面？服务是否可以功能降级？或者资源劣化？

Java分布式应用技术基础

分布式服务下的关键技术：消息队列架构

消息对列通过消息对象分解系统耦合性，不同子系统处理同一个消息
分布式服务下的关键技术：消息队列原理

分布式服务下的关键技术：服务框架架构

服务框架通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务框架是一个点对点模型
服务框架面向同构系统
适合：移动应用、互联网应用、外部系统

分布式服务下的关键技术：服务框架原理

分布式服务下的关键技术：服务总线架构

服务总线同服务框架一样，均是通过接口分解系统耦合性，不同子系统通过相同的接口描述进行服务启用
服务总线是一个总线式的模型
服务总线面向同构、异构系统
适合：内部系统

分布式服务下的关键技术：服务总线原理

分布式架构下系统间交互的5种通信模式

request/response模式（同步模式）：客户端发起请求一直阻塞到服务端返回请求为止。

Callback（异步模式）：客户端发送一个RPC请求给服务器，服务端处理后再发送一个消息给消息发送端提供的callback端点，此类情况非常合适以下场景：A组件发送RPC请求给B，B处理完成后，需要通知A组件做后续处理。

Future模式：客户端发送完请求后，继续做自己的事情，返回一个包含消息结果的Future对象。客户端需要使用返回结果时，使用Future对象的.get(),如果此时没有结果返回的话，会一直阻塞到有结果返回为止。

Oneway模式：客户端调用完继续执行，不管接收端是否成功。

Reliable模式：为保证通信可靠，将借助于消息中心来实现消息的可靠送达，请求将做持久化存储，在接收方在线时做送达，并由消息中心保证异常重试。
五种通信模式的实现方式-同步点对点服务模式

五种通信模式的实现方式-异步点对点消息模式1

五种通信模式的实现方式-异步点对点消息模式2

五种通信模式的实现方式-异步广播消息模式

分布式架构下的服务治理

服务治理是服务框架/服务总线的核心功能。所谓服务治理，是指服务的提供方和消费方达成一致的约定，保证服务的高质量。服务治理功能可以解决将某些特定流量引入某一批机器，以及限制某些非法消费者的恶意访问，并在提供者处理量达到一定程度是，拒绝接受新的访问。

基于服务框架Dubbo的服务治理-服务管理

可以知道你的系统，对外提供了多少服务，可以对服务进行升级、降级、停用、权重调整等操作
可以知道你提供的服务，谁在使用，因业务需求，可以对该消费者实施屏蔽、停用等操作

基于服务框架Dubbo的服务治理-服务监控
可以统计服务的每秒请求数、平均响应时间、调用量、峰值时间等，作为服务集群规划、性能调优的参考指标。

基于服务框架Dubbo的服务治理-服务路由

基于服务框架Dubbo的服务治理-服务保护

基于服务总线OSB的服务治理-功能介绍

基于服务总线OSB的服务治理

Q：Dubbo到底是神马？
A：
淘宝开源的高性能和透明化的RPC远程调用服务框架
SOA服务治理方案
Q：Dubbo原理是？
A：

-结束-