mysql分布式数据库适合做数据仓库么

1. mysql分布式数据库适合做数据仓库么

数据仓库就是数据库，只不过是按照业界不同的提法说法不同而已； 一般的数据仓库的说法是要建立一个高性能的可查询数据库，一般说来是提供高效的查询而不是交互。

从软件出发考虑：

MySQL现有的几种数据库从5.5后缺省的数据引擎是Innodb, 性能在查询上和MyISAM差不多，不过对事物的支持更加好。 如果需要建立一个有规模的数据仓库首先必须考虑查询和聚合运算的效率问题， 从MySQL内部的函数的使用效率出发选用innodb可以支持复杂的存储过程让运算集中在服务器上运行，可以高效的发挥服务器的运算性能和SQL集合运算的效率。

从平台考虑：
数据仓库的数据源可能来自不同的操作系统和数据库， 怎么把数据同步到本地可以参考通用的方法，作为数据仓库需要考虑的是数据的一致性，比如一个流程的不同环节的数据来自不同的数据库，这时就需要考虑怎么来定制来保证数据的时效和一致，比如不允许第一步的数据还未进行同步，第二步的数据就已经同步到本地，这样的话后台的应用在读取数据的时候就会非常的混乱

从硬件出发考虑：
数据仓库一般是从业务数据库导出到另外一个独立数据库作为计算分析， 这样的好处在于把计算分开，避免非业务的大规模运算对正常业务的影响。即使软硬件崩溃也不会对正常业务造成影响，而数据重建只需要按照原来的方法恢复即可。在往数据仓库上同步数据的过程要灵活考虑数据同步的方法，缺省可直接使用Mysql的主从备份。 如果不想对业务服务器造成太多影响，也可以采用自己定制的方法来进行增量备份和差异备份。

从SQL的使用出发考虑：
能够交由SQL完成的工作最好全部使用SQL来完成聚合，表和表进行联合的时候先进行添加约束，和外部的程序，比如统计分析的计算，尽量让SQL输出一个计算后的数据集给后台应用。

2. Mysql变成分布式数据库

　1、amoeba相当于一个SQL请求的路由器，目的是为负载均衡、读写分离、高可用性提供机制，而不是完全实现它们。用户需要结合使用MySQL的Replication等机制来实现副本同步等功能。amoeba对底层数据库连接管理和路由实现也采用了可插拨的机制，第三方可以开发更高级的策略类来替代作者的实现。这个程序总体上比较符合KISS的思想。
　　2、由上一条，建议使用MySQL的Replication机制建立Master-Slave来做副本。我一开始理解有误，使用了amoeba的virtual DB（负载均衡pool）做writePool，结果使得本应插入同一个表中的数据被拆分地写入了不同的物理数据库中。这样自然与副本的语义不符了。
　　3、amoeba已经实现了数据的垂直切分与水平切分。水平切分方面，粒度是行。使用SQLJEP语句可以设计出复杂的切分规则，个人认为是比较强大的。垂直切分的粒度是表，可以把针对不同表的请求发送到不同的节点上执行，但不能以列作为分片粒度。从作者的说法看，amoeba不做SQL解析和重写。在目前的机制下似乎是难以实现同一个表不同的列在不同节点上的分布。不过对开发人员来说，设计良好的表结构应该可以实现简单的基于关系属性的负载均衡的。

3. mysql分布式数据库问题

要数据同步就做双机热备，要仅仅为了异地访问，就在防火墙上把3306端口映射出来，然后给相应的用户开远程登录数据库的权限

4. mysql如何实现分布式数据库

应该是通过ndb的cluster来实现啊，你只需在网上找mysql cluster的资料就可以知道了。在mysql官方网站上可以下载到，如《mysql cluster维护手册.docx》等

5. 现在mysql的分布式数据访问层主流方案有哪些

（1）方案一（数据库保存所有服务器索引信息） 
全对称结构，没有中央服务器 
web方案： 
只从本地数据库检索符合条件的记录，给出结果 
每次检索都要从本地服务器的海量数据中进行 
数据库方案： 
数据库保存所有服务器的索引内容 
缓存命中率高的记录，减少检索时间 
服务器负载分析： 
服务器负载假设： 
一百个结点，每结点一百人同时使用，每个结点一万条记录 
web服务器：同时一百线程在本地数据库服务器检索 
数据库服务器：每次接收一百个查询请求；每个请求要从一百万条索引中检索（最坏的情况）；缓冲机制可以稍微减轻负担 
数据更新操作： 
同时更新所有数据库/只更新本地，服务器间相互同步 

方案二（数据库保存本地索引及少量缓冲） 
每高校作为一个结点 
所有结点全对称结构，网络中没有一个中央服务器 
web方案： 
接收到请求时同时多线程向其它服务器同时搜索（服务器压力问题？） 
数据库方案： 
数据库保存本地数据 
数据库保存一定量缓冲数据， 
服务器负载分析： 
服务器负载假设： 
一百个结点，每结点一百人同时使用 
则每个web服务器同时发起一万个线程向其它数据服务器搜索（oops!） 
每个数据库服务器会同时接收到一万个查询请求（oops！） 
采用学习过程只能少量减少查询请求和web服务器搜索线程 
数据更新操作： 
只更新本地 

方案三（中央服务器方案一） 
每高校一个结点 
每结点结构相同，连接到同一个中央服务器 
web方案 
每个查询向中央服务器进行，由中央服务器实行检索，中央服务器返回检索结果 
数据库方案 
中央数据库保存所有索引信息 
每结点可以只用小型数据库保存本地用户和其它信息即可 
服务器负载分析： 
服务器负载假设： 
一百个结点，每结点一百人同时使用，每结点资料记录一万条 
web服务器：同时发起一百个进程向中央数据库查询 
数据库服务器（中央）：同时接收一万条查询请求并返回大容量结果 
数据库服务器（结点）：少量工作 
数据更新操作： 
只更新中央服务器 

方案四（中央服务器方案二） 
每高校一个结点 
每结点结构相同，连接到同一中央服务器 
web方案： 
每个查询向中央服务器进行，由中央服务器根据查询内容进行转发到结点数据库，再由结点数据库返回结果 
数据库方案： 
中央服务器保存各结点分类信息，根据页面请求的分类转发查询到相应服务器 
服务器负载分析： 
服务器负载假设： 
一百个结点，每结点一百人同时使用，每结点资料记录一万条，每结点一百个类别 
web服务器：同时一百个进程向中央数据库查询 
数据库服务器（中央）：同时接收一万条请求并转发 
数据库服务器（结点）：从中央服务器接收查询请求，最坏情况下每结点接收到一万条查询请求 
数据更新操作： 
只更新本地服务器 
分类变化时更新中央服务器

6. 现在mysql的分布式数据访问层主流方案有哪些

跨库事务这块目前是没有一个完美的方案。
一般的做法也是维护一个消息队列异步去做这事，保证最终一致。
分布式join是分布式数据层工作量最大的地方。
在我看来是通过优化器，尽量的把条件下推给各个分库，在不同库上充分利用其性能。核心问题应该是减少结果合并的规模或者说本机的计算成本，也要尽量减少网络传输的成本 。

7. mysql 查当前有哪些分布式事务

查看 MySQL 客户端的事务提交方式命令：select @@autocommit;
修改 MySQL 客户端的事务提交方式为手动提交命令：set @@autocommit = 0;
（注：0 表示手动提交，即使用 MySQL 客户端执行 SQL 命令后必须使用commit命令执行事务，否则所执行的 SQL 命令无效，如果想撤销事务则使用 rollback 命令。1 表示自动提交，即在 MySQL 客户端不在需要手动执行 commit 命令。）
MySQL 在自动提交模式下，每个 SQL 语句都是一个独立的事务。
注意：
1、手动设置set @@autocommit = 0，即设定为非自动提交模式，只对当前的mysql命令行窗口有效，打开一个新的窗口后，默认还是自动提交；
2、对于非自动提交模式，比如在命令行中添加一条记录，退出命令行后在重新打开命令行，之前插入的记录是不在的。（用select * from + 表名 验证一下就可以了）

8. MySQL大型分布式集群具体怎么做

1、主要解决针对大型网站架构中持久化部分中，大量数据存储以及高并发访问所带来是数据读写问题。分布式是将一个业务拆分为多个子业务，部署在不同的服务器上。集群是同一个业务，部署在多个服务器上。
2、着重对数据切分做了细致丰富的讲解，从数据切分的原理出发，一步一步深入理解数据的切分，通过深入理解各种切分策略来设计和优化我们的系统。这部分中我们还用到了数据库中间件和客户端组件来进行数据的切分，让广大网友能够对数据的切分从理论到实战都会有一个质的飞跃。
通过分布式+集群的方式来提高io的吞吐量，以及数据库的主从复制，主主复制，负载均衡，高可用，分库分表以及数据库中间件的使用。