cstore_fdw的安装使用以及源码分析

一、cstore_fdw的简介

  https://github.com/citusdata/cstore_fdw,此外部表扩展是由citusdata公司开发,使用orc_file格式对数据进行列式存储。

  

  优点1:因为有压缩,所以在disk上的存储大大减少,压缩比能达到2-4倍

  优点2:数据内部分块存储,对于块数据进行了max以及min值的记录,在查询时能够进行跳块查询

  优点3:在进行查询时,并不是将所有的磁盘数据都load到内存,而是选择列根据记录的skiplist中的offset来load所需要的数据,减少IO

二、安装使用

  [[email protected] ~]# git clone https://github.com/citusdata/cstore_fdw.git

  下载好后修改Makefile文件中的pgconfig指定到安装目录下 例如:/usr/local/postgres/bin/pgconfig

  [[email protected] ~]# make && make install

  配置postgres.conf文件末尾添加:

  shared_preload_libraries = ‘cstore_fdw‘

  启动数据库:

  [[email protected] ~]$ pg_ctl -D db1 -l logfile start -m fast

  [[email protected] ~]$ psql

  

postgres=# create extension cstore_fdw;
CREATE EXTENSION
postgres=# create server cstore_server foreign data wrapper cstore_fdw ;
CREATE SERVER
postgres=# CREATE FOREIGN TABLE customer_reviews
postgres-# (
postgres(#     customer_id TEXT,
postgres(#     review_date DATE,
postgres(#     review_rating INTEGER,
postgres(#     review_votes INTEGER,
postgres(#     review_helpful_votes INTEGER,
postgres(#     product_id CHAR(10),
postgres(#     product_title TEXT,
postgres(#     product_sales_rank BIGINT,
postgres(#     product_group TEXT,
postgres(#     product_category TEXT,
postgres(#     product_subcategory TEXT
postgres(# )
postgres-# SERVER cstore_server
postgres-# OPTIONS(compression ‘pglz‘);

  PG原生表占用磁盘大小:

postgres=# insert into customer_reviews select * from customer;
INSERT 0 176774
postgres=# select pg_relation_size(‘customer‘);
 pg_relation_size
------------------
        145489920
(1 row)

  经过cstore_fdw外部扩展压缩后占用的磁盘大小:

[[email protected] 13056]$ ll /home/postgres/db1/cstore_fdw/13056

-rw------- 1 postgres postgres 6236569 Dec 5 10:07 278237
-rw------- 1 postgres postgres 56 Dec 5 10:07 278237.footer

  对比后磁盘使用减少了很多!!

三、源码分析

postgres中外部表的实现相当于一个引擎,通过挂接C语言的函数指针实现

Datum
cstore_fdw_handler(PG_FUNCTION_ARGS)
{
	FdwRoutine *fdwRoutine = makeNode(FdwRoutine);

	fdwRoutine->GetForeignRelSize = CStoreGetForeignRelSize;
	fdwRoutine->GetForeignPaths = CStoreGetForeignPaths;
	fdwRoutine->GetForeignPlan = CStoreGetForeignPlan;
	fdwRoutine->ExplainForeignScan = CStoreExplainForeignScan;
	fdwRoutine->BeginForeignScan = CStoreBeginForeignScan;//1
	fdwRoutine->IterateForeignScan = CStoreIterateForeignScan;//2
	fdwRoutine->ReScanForeignScan = CStoreReScanForeignScan;//3
	fdwRoutine->EndForeignScan = CStoreEndForeignScan;//4
	fdwRoutine->AnalyzeForeignTable = CStoreAnalyzeForeignTable;
	fdwRoutine->PlanForeignModify = CStorePlanForeignModify;//5
	fdwRoutine->BeginForeignModify = CStoreBeginForeignModify;//6
	fdwRoutine->ExecForeignInsert = CStoreExecForeignInsert;//7
	fdwRoutine->EndForeignModify = CStoreEndForeignModify;//8

	PG_RETURN_POINTER(fdwRoutine);
}

  1、2、3、4构成了查询操作 例如: select * from customer_reviews;

  5、6、7、8构成了插入操作 例如:insert into customer_reviews select * from customer;

  特别注意的是在插入的时候,由于CStorePlanForeignModify这个函数中判断了tableEntry->rtekind == RTE_SUBQUERY,

  因此 insert into xx values xxx 这种插入是不支持的。

  从源码中观察到在CStoreEndForeignModify中会进行flushstripe操作,就是不管插入一条数据还是批量插入数据,都会进行flushstripe操作

  如果插入一条数据,则此条数据占用了一个条带的磁盘空间

  如果是批量插入,则按照默认的条带大小,块大小来进行分割,满足stripe了就刷磁盘,接着剩余不满足stripe的作为另外一个条带,如果按照一条数据一个条带的话,查询load数据就会相当缓慢。

  最后得出结论:对于总是进行单条插入或者交易型数据库,这种压缩效率就不是很明显了,如果对于批量插入的话,压缩比例还是很可观的,而且查询也会较快。

  RCFile格式对比orc格式:

  还有就是对于RCfile这种格式,字符串类型的压缩并没有很明显的处理,不像orc格式,orc带有字典压缩处理,而RCFile并没有

  https://github.com/gokhankici/orc_fdw

  这个外部表扩展仅仅对orc格式的文件进行读操作,并没有写操作,写文件的操作是使用java语言开发的。

时间: 2024-10-13 02:23:24

cstore_fdw的安装使用以及源码分析的相关文章

memcached源码分析-----安装、调试以及如何阅读memcached源码

        转载请注明出处:http://blog.csdn.net/luotuo44/article/details/42639131 安装: 安装memcached之前要先安装Libevent.现在假定Libevent安装在/usr/local/libevent目录了. 因为memcached安装后不像Libevent那样,有一堆头文件和库文件.安装后的memcached不是用来编程而直接用来运行的.所以不需要在/usr/local目录下专门为memcached建立一个目录.直接把mem

[python] 词云:wordcloud包的安装、使用、原理(源码分析)、中文词云生成、代码重写

词云,又称文字云.标签云,是对文本数据中出现频率较高的“关键词”在视觉上的突出呈现,形成关键词的渲染形成类似云一样的彩色图片,从而一眼就可以领略文本数据的主要表达意思.常见于博客.微博.文章分析等. 除了网上现成的Wordle.Tagxedo.Tagul.Tagcrowd等词云制作工具,在python中也可以用wordcloud包比较轻松地实现(官网.github项目): from wordcloud import WordCloud import matplotlib.pyplot as pl

Android的软件包管理服务PackageManagerService源码分析

Android系统下的apk程序都是通过名为PackageManagerService的包管理服务来管理的.PacketManagerService是安卓系统的一个重要服务,由SystemServer启动,主要实现apk程序包的解析,安装,更新,移动,卸载等服务.不管是系统apk(/system/app),还是我们手工安装上去的,系统所有的apk都是由其管理的. 以android 4.0.4的源码为例,android4.0.4/frameworks/base/services/java/com/

Android逆向之旅---反编译利器Apktool和Jadx源码分析以及错误纠正

一.前言 在之前的破解过程中可以看到我们唯一离不开的一个神器那就是apktool了,这个工具多强大就不多说了,但是如果没有他我们没法涉及到后面的破解工作了,这个工具是开源的,也是使用Java语言开发的,代码相对简单,我们今天就来分析一下他的大体逻辑,注意是大体逻辑哦,因为如果要一行一行代码分析,首先觉得没必要,其次浪费时间,有了源码,谁看不懂呢.至于为什么要分析这个工具其实原因只有一个,就是我们在之前的反编译过程中会发现,总是有那么几个apk应用不让我们那么容易的反编译,他们就利用apktool

Linux内核源码分析--内核启动之(6)Image内核启动(do_basic_setup函数)(Linux-3.0 ARMv7)【转】

原文地址:Linux内核源码分析--内核启动之(6)Image内核启动(do_basic_setup函数)(Linux-3.0 ARMv7) 作者:tekkamanninja 转自:http://blog.chinaunix.net/uid-25909619-id-4938396.html 在基本分析完内核启动流程的之后,还有一个比较重要的初始化函数没有分析,那就是do_basic_setup.在内核init线程中调用了do_basic_setup,这个函数也做了很多内核和驱动的初始化工作,详解

Android应用setContentView与LayoutInflater加载解析机制源码分析

[工匠若水 http://blog.csdn.net/yanbober 转载烦请注明出处,尊重分享成果] 1 背景 其实之所以要说这个话题有几个原因: 理解xml等控件是咋被显示的原理,通常大家写代码都是直接在onCreate里setContentView就完事,没怎么关注其实现原理. 前面分析<Android触摸屏事件派发机制详解与源码分析三(Activity篇)>时提到了一些关于布局嵌套的问题,当时没有深入解释. 所以接下来主要分析的就是View或者ViewGroup对象是如何添加至应用程

keystone源码分析(一)——Paste Deploy的应用

本keystone源码分析系列基于Juno版Keystone,于2014年10月16日随Juno版OpenStack发布. Keystone作为OpenStack中的身份管理与授权模块,主要实现系统用户的身份认证.基于角色的授权管理.其他OpenStack服务的地址发现和安全策略管理等功能.Keystone作为开源云系统OpenStack中至关重要的组成部分,与OpenStack中几乎所有的其他服务(如Nova, Glance, Neutron等)都有着密切的联系.同时,Keystone作为开源

Solr4.8.0源码分析(4)之Eclipse Solr调试环境搭建

Solr4.8.0源码分析(4)之Eclipse Solr调试环境搭建 由于公司里的Solr调试都是用远程jpda进行的,但是家里只有一台电脑所以不能jpda进行调试,这是因为jpda的端口冲突.所以只能在Eclipse 搭建Solr的环境,折腾了一小时终于完成了. 1. JDPA远程调试 搭建换完成Solr环境后,对${TOMCAT_HOME}/bin/startup.sh 最后一行进行修改,如下所示: 1 set JPDA_ADDRESS=7070 2 exec "$PRGDIR"

TOMCAT源码分析(启动框架)

建议: 毕竟TOMCAT的框架还是比较复杂的, 单是从文字上理解, 是不那么容易掌握TOMCAT的框架的. 所以得实践.实践.再实践. 建议下载一份TOMCAT的源码, 调试通过, 然后单步跟踪其启动过程. 如果有不明白的地方, 再来查阅本文, 看是否能得到帮助. 我相信这样效果以及学习速度都会好很多! 1. Tomcat的整体框架结构 Tomcat的基本框架, 分为4个层次. Top Level Elements: Server Service Connector HTTP AJP Conta