Linux:
在bash里输入:dmidecode -s system-product-name
或者lshw -class system
或者dmesg | grep -i virtual
具体参考:http://unix.stackexchange.com/questions/89714/easy-way-to-determine-virtualization-technology
Linux:
在bash里输入:dmidecode -s system-product-name
或者lshw -class system
或者dmesg | grep -i virtual
具体参考:http://unix.stackexchange.com/questions/89714/easy-way-to-determine-virtualization-technology
数据的切分(Sharding)模式
一种是按照不同的表(或者Schema)来切分到不同的数据库(主机)之上,这种切可以称之为数据的垂直(纵向)切分;另外一种则是根据表中的数据的逻辑关系,将同一个表中的数据按照某种条件拆分到多台数据库(主机)上面,这种切分称之为数据的水平(横向)切分。
垂直切分:
一个架构设计较好的应用系统,其总体功能肯定是由很多个功能模块所组成的,而每一个功能模块所需要的数据对应到数据库中就是一个或者多个表。而在架构设计中,各个功能模块相互之间的交互点越统一越少,系统的耦合度就越低,系统各个模块的维护性以及扩展性也就越好。这样的系统,实现数据的垂直切分也就越容易。
一般来说,如果是一个负载相对不是很大的系统,而且表关联又非常的频繁,那可能数据库让步,将几个相关模块合并在一起减少应用程序的工作的方案可以减少较多的工作量,这是一个可行的方案。一个垂直拆分的例子:
1.用户模块表:user,user_profile,user_group,user_photo_album
2.群组讨论表:groups,group_message,group_message_content,top_message
3.相册相关表:photo,photo_album,photo_album_relation,photo_comment
4.事件信息表:event
垂直切分的优点
垂直切分的缺点
水平切分
将某个访问极其频繁的表再按照某个字段的某种规则来分散到多个表之中,每个表中包含一部分数据。
对于上面的例子:所有数据都是和用户关联的,那么我们就可以根据用户来进行水平拆分,将不同用户的数据切分到不同的数据库中。
现在互联网非常火爆的Web2.0类型的网站,基本上大部分数据都能够通过会员用户信息关联上,可能很多核心表都非常适合通过会员ID来进行数据的水平切分。而像论坛社区讨论系统,就更容易切分了,非常容易按照论坛编号来进行数据的水平切分。切分之后基本上不会出现各个库之间的交互。
水平切分的优点
水平切分的缺点
两种切分结合用:
一般来说,我们数据库中的所有表很难通过某一个(或少数几个)字段全部关联起来,所以很难简单的仅仅通过数据的水平切分来解决所有问题。而垂直切分也只能解决部分问题,对于那些负载非常高的系统,即使仅仅只是单个表都无法通过单台数据库主机来承担其负载。我们必须结合“垂直”和“水平”两种切分方式同时使用
每一个应用系统的负载都是一步一步增长上来的,在开始遇到性能瓶颈的时候,大多数架构师和DBA都会选择先进行数据的垂直拆分,因为这样的成本最先,最符合这个时期所追求的最大投入产出比。然而,随着业务的不断扩张,系统负载的持续增长,在系统稳定一段时期之后,经过了垂直拆分之后的数据库集群可能又再一次不堪重负,遇到了性能瓶颈。
如果我们再一次像最开始那样继续细分模块,进行数据的垂直切分,那我们可能在不久的将来,又会遇到现在所面对的同样的问题。而且随着模块的不断的细化,应用系统的架构也会越来越复杂,整个系统很可能会出现失控的局面。
这时候我们就必须要通过数据的水平切分的优势,来解决这里所遇到的问题。而且,我们完全不必要在使用数据水平切分的时候,推倒之前进行数据垂直切分的成果,而是在其基础上利用水平切分的优势来避开垂直切分的弊端,解决系统复杂性不断扩大的问题。而水平拆分的弊端(规则难以统一)也已经被之前的垂直切分解决掉了,让水平拆分可以进行的得心应手。
示例数据库:
假设在最开始,我们进行了数据的垂直切分,然而随着业务的不断增长,数据库系统遇到了瓶颈,我们选择重构数据库集群的架构。如何重构?考虑到之前已经做好了数据的垂直切分,而且模块结构清晰明确。而业务增长的势头越来越猛,即使现在进一步再次拆分模块,也坚持不了太久。
==>选择了在垂直切分的基础上再进行水平拆分。
==>在经历过垂直拆分后的各个数据库集群中的每一个都只有一个功能模块,而每个功能模块中的所有表基本上都会与某个字段进行关联。如用户模块全部都可以通过用户ID进行切分,群组讨论模块则都通过群组ID来切分,相册模块则根据相册ID来进切分,最后的事件通知信息表考虑到数据的时限性(仅仅只会访问最近某个事件段的信息),则考虑按时间来切分。
数据切分以及整合方案.
数据库中的数据在经过垂直和(或)水平切分被存放在不同的数据库主机之后,应用系统面临的最大问题就是如何来让这些数据源得到较好的整合,其中存在两种解决思路:
第二种方案,虽然短期内需要付出的成本可能会相对更大一些,但是对整个系统的扩展性来说,是非常有帮助的。针对第二种方案,可以选择的方法和思路有:
1.利用MySQLProxy 实现数据切分及整合.
可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它,目前具备的功能主要有连接路由,Query分析,Query过滤和修改,负载均衡,以及基本的HA机制等。MySQLProxy 本身并不具有上述所有的这些功能,而是提供了实现上述功能的基础。要实现这些功能,还需要通过我们自行编写LUA脚本来实现。
原理:MySQLProxy 实际上是在客户端请求与MySQLServer 之间建立了一个连接池。所有客户端请求都是发向MySQLProxy,然后经由MySQLProxy 进行相应的分析,判断出是读操作还是写操作,分发至对应的MySQLServer 上。对于多节点Slave集群,也可以起做到负载均衡的效果。
2.利用Amoeba实现数据切分及整合
Amoeba是一个基于Java开发的,专注于解决分布式数据库数据源整合Proxy程序的开源框架,Amoeba已经具有Query路由,Query过滤,读写分离,负载均衡以及HA机制等相关内容。Amoeba主要解决的以下几个问题:
AmoebaFor MySQL 主要是专门针对MySQL数据库的解决方案,前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说,AmoebaForMySQL 和一个MySQL数据库没有什么区别,任何使用MySQL协议的客户端请求,都可以被AmoebaFor MySQL 解析并进行相应的处理。
Proxy程序常用的功能如读写分离,负载均衡等配置都在amoeba.xml中进行。Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由,路由规则可以在rule.xml进行设置。
3.利用HiveDB实现数据切分及整合
HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架,只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题,同时支持数据的冗余及基本的HA机制。
HiveDB的实现机制与MySQLProxy 和Amoeba有一定的差异,他并不是借助MySQL的Replication功能来实现数据的冗余,而是自行实现了数据冗余机制,而其底层主要是基于HibernateShards 来实现的数据切分工作。数据切分与整合中可能存在的问题
引入分布式事务的问题?
一旦数据进行切分被分别存放在多个MySQLServer中之后,不管我们的切分规则设计的多么的完美(实际上并不存在完美的切分规则),都可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer 中了。
==>将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务,并通过应用程序来总控各个小事务。
跨节点Join的问题?
==>先从一个节点取出数据,然后根据这些数据,再到另一个表中取数据.
==>使用Federated存储引擎,问题是:乎如果远端的表结构发生了变更,本地的表定义信息是不会跟着发生相应变化的。
跨节点合并排序分页问题?
==>Join本身涉及到的多个表之间的数据读取一般都会存在一个顺序关系。但是排序分页就不太一样了,排序分页的数据源基本上可以说是一个表(或者一个结果集),本身并不存在一个顺序关系,所以在从多个数据源取数据的过程是完全可以并行的。这样,排序分页数据的取数效率我们可以做的比跨库Join更高,所以带来的性能损失相对的要更小。
垂直拆分
是指数据表列的拆分,把一张列比较多的表拆分为多张表
通常我们按以下原则进行垂直拆分:
垂直拆分更多时候就应该在数据表设计之初就执行的步骤,然后查询的时候用join关键起来即可;
水平拆分
是指数据表行的拆分,表的行数超过200万行时,就会变慢,这时可以把一张的表的数据拆成多张表来存放。
1. 拆分原则 通常情况下,我们使用取模的方式来进行表的拆分;比如一张有400W的用户表users
,为提高其查询效率我们把其分成4张表users1,users2,users3,users4
通过用ID取模的方法把数据分散到四张表内Id%4+1 = [1,2,3,4]
然后查询,更新,删除也是通过取模的方法来查询
$_GET['id'] = 17,
17%4 + 1 = 2,
$tableName = 'users'.'2'
Select * from users2 where id = 17;
在insert时还需要一张临时表uid_temp
来提供自增的ID,该表的唯一用处就是提供自增的ID;
insert into uid_temp values(null);
得到自增的ID后,又通过取模法进行分表插入;
注意,进行水平拆分后的表,字段的列和类型和原表应该是相同的,但是要记得去掉auto_increment自增长
另外
Create view users as select from users1 union select from users2 union.........
1.Shared Everthting:
一般是针对单个主机,完全透明共享CPU/MEMORY/IO,并行处理能力是最差的,典型的代表SQLServer
2.Shared Disk 架构,如Oracle的RAC集群
Shared Disk架构如图1所示,所有的节点共享一份数据,优点是只要有一个节点可用,就可以访问所有数据;缺点是内存融合(cache fusion)大大限制了它的水平扩展能力。简单地说:可用性高,但可扩展性弱,常见于24*7的高可用性核心业务。
3. Shared Nothing 架构,如Mysql的Cluster集群
Shared Nothing架构如图2所示,数据和节点具有对应关系,缺点是如果要访问所有数据,必须所有节点都可用;优点是每个节点交互少,很容易扩展。简单地说:可扩展性强,可用性低。多用于VLDB。
分步式数据,需要常解决的问题是统计翻页和事务
一主一从,一主多从这些主从架构是一种高可用性的解决方案,不属于分布式数据库的范畴。
查看容器IP:docker inspect {容器IDeas} |grep IPAddress
查看镜像:docker images
查看运行中的容器:docker ps
1.备份
先把运行中的容器提交为镜像:docker commit -p 70d5ee222609 container-mysql56-backup
再把该镜像tar保存到本地:docker save -o ~/container-mysql56-backup.tar container-mysql56-backup
2.恢复
如果是在同一台机子上做实验,先删除上一步提交的镜像:docker rmi 9ca852b519bd #最好是镜像的ID
先加载本地的tar文件到镜像列表:docker load -i ~/container-mysql56-backup.tar
再重新运行容器:docker run –name db002 -p 3308:3306 -d container-mysql56-backup #此处可以不用指定root密码,因为备份的容器中已经保存.
可以看出,恢复容器时,容器之内的原始镜像已经保存信息,但主机与容器之间的信息并未保存?
3.迁移
迁移其实就是把备份保存的tar文件迁移后再恢复的过程!
附:
删除镜像:docker rmi {ID}
删除容器:
先停止容器:docker kill {ID}
查看包括停止的所有容器:docker ps -a #查看运行的容器:docker ps,不带”-a”
删除容器:docker rm {ID}
使用docker应用,基本两个步骤.
1.有应用镜像,如mysql
2.docker容器
安装过程:
1.拉取镜像
先搜索:docker search mysql
再拉取:docker pull mysql:5.6
2.运行容器
先查看镜像是否存在:docker images
运行:docker run –name db001 -p 3307:3306 -e MYSQL_ROOT_PASSWORD=mytest -d mysql:5.6
db001容器名称,3307为本机端口映射,mytest为root密码,mysql:5.6为镜像
3.查看进程
docker ps
4.本机连接docker映像
mysql -h192.168.1.80:3307 -uroot -pmytest
服务端:
1.安装vnc服务端,需要配置,建议下面一种
2.或者已经安装桌面,system->preferencs->remote desktop,设置可以远程,并可选择客户端验证方式
window下客户端:
安装Ultravnc,输入服务端IP
字符串类型是String,首字母大写!!!