工作总结数据库集群

最新推荐文章于 2022-05-23 14:37:59 发布

yibei8811

最新推荐文章于 2022-05-23 14:37:59 发布

阅读量471

点赞数

CC 4.0 BY-SA版权

分类专栏： postgres

本文链接：https://blog.youkuaiyun.com/yibei8811/article/details/48915885

postgres 专栏收录该内容

19 篇文章

订阅专栏

本文介绍了数据库集群在处理TB级和PB级数据时的作用，重点讨论了基于Postgres的集群解决方案，如postgres-xc、pl/proxy、greenplum和postgres-xl。作者分享了在使用postgres-xl时的搭建过程、操作示例及遇到的性能瓶颈，指出网络通讯和全局序列管理是性能的主要制约因素，并总结了搭建过程中遇到的问题及其解决方法。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

我使用数据库集群的时间并不算太长，我尽量将自己的一些感悟和心得总结下来。

首先数据库集群解决TB级的数据量就不得了，上了PB级，理论上还是nosql更好。基于postgres常用的集群解决方案有以下几种
postgres-xc，postgres-xl，pl/proxy,greenplum和postgres-x2
postgres-xc：浙江移动在用，貌似bug有不少，据传把postgres-xc的发起人从日本请过来帮忙解决问题。
pl/proxy：pl/proxy很多大型公司在用，包括斯凯(NASDAQ:MOBI)，它的可控性很强，但是它的开发量相对较大。pl/proxy我看过的资料比较多，它的本质就是一个架构于多台postgres数据库之上的水平拆分中间件。是由用户去定义函数，根据参数确定SQL语句交由指定的底层数据库处理，或并发的执行于多台底层数据库之上。其实正因为它的底层就是未作修改普通postgres数据库，所以它的风险系数较低。
greenplum：它早期被EMC收购，EMC就是提倡"去AOE"中"E"。它功能强大，售后服务也好，不过是基于postgres8.4版本的，所以新版本的数据库特性无法使用。它的商业版收取的维护费用价格不低。阿里巴巴，包括很多移动公司也在使用。可靠的消息，它目前已经确定正在进行做开源的准备。
postgres-x2：由李元佳和postgres-xc架构师铃木市一联合发起旨在融合Postgres-XC/XL一个项目。
						
========================================================================================================================
postgres-xl：它是基于postgres-xc演化而来，也是我的工作重点，下面尽可能回忆过往使用中遇到的问题，以及详细的描述一下解决方法。					
搭建过程：参考这篇blog可以搭建成功，http://blog.163.com/digoal@126/blog/static/163877040201441423449445/ ，我不再累述，早期blog曾有几处错误，不容易发现，如今blog中错误已经被作者修改。
				 
使用过程：				 
	给几个使用例子：
	create table tt(c1 serial8 primary key,c2 text) distribute by hash(c1) to group groupnode;
	创建表tt 字段c1，c2，分配规则根据c1的hash取值，对群组groupnode生效。
				 
	insert into tt(c2) values ('a');
	insert into tt(c2) values ('b');
	insert into tt(c2) values ('c');
	insert into tt(c2) values ('d');
	insert into tt(c2) values ('e');
	insert into tt(c2) values ('f');
	insert into tt(c2) values ('g');
	插入和普通插入没有区别
				 
	select * from tt
	查询和普通查询没有区别
				 
	EXECUTE DIRECT ON (data101) 'select * from tt'
	EXECUTE DIRECT ON (data102) 'select * from tt'
	分别查询data101号节点的数据和查询data102号节点的数据
				 
	drop table tt
	删除和和普通删除没有区别
				 
注意：查询的时候可以指定只查询某个节点，但是插入的时候不可以强制把数据插入某个节点，其实仔细想想就很容易明白。因为普通查询，他会根据字段的hash找到指定的节点，一旦强制插入某个节点，那么它的hash寻找到的节点很可能就是不正确的。
				 
性能瓶颈：				 
	我观察到的性能瓶颈有2个方面，其一，因为所有的数据需要通过gtm管理，之后分配到它自己所对应存在的节点上。节点与节点的网络通讯会造成很大的一部分性能开销。除非配置更好的网线网卡，否则是不可避免的。其二，就是插入的时候，集群的序列是全局共享的，所以gtm为了保证序列的唯一性也消耗了很多的性能作为代价。
				 
问题总结：				 
	搭建的过程最初出现过一些麻烦，主要就是防火墙之类，关闭后就好了，或者因为缺少依赖库，依赖包，找到对应的安装后，也没有问题。还有一个印象比较深的就是，我默认的配置是根据ip来寻找节点，但是后期架设hadoop的时候，因为修改了/etc/hosts文件，造成了我集群无法启动。虽然我配置了是根据ip访问节点，但是/etc/hosts如果存在内容，它还是优先选择hosts的域名作为通讯的目标。起初hadoop搭建了2个集群，/etc/hosts的配置有些缺陷，造成了某2台机器间，根据域名是不能互相拼通的，所以我的集群也无法起来，我通过降低日志的级别到debug级别，观察日志发现的，最后修改/etc/hosts文件解决了此问题。