列存储和Greenplum压缩表

        这篇文章很好的介绍了行存储和列存储:https://blog.csdn.net/Xingxinxinxin/article/details/80939277

        一、Greenplum列存储的压缩表原理:

        create table testao(id int, name text) with (APPENDONLY=true, ORIENTATION=column, COMPRESSTYPE=zlib, COMPRESSLEVEL=5, BLOCKSIZE=1048576, OIDS=false)

        APPENDONLY=true, ORIENTATION=column这两个属性决定了这是列存压缩表。

        COMPRESSTYPE: 压缩方式,支持zlip,RTE等

        COMPRESSLEVEL: 压缩级别,0-9

        BLOCKSIZE: 块大小8kB-2MB

        优势

        1、节约成本,列存压缩表空间占用远小于普通的heap表空间

        2、对查询涉及的列很少时候,无需去读其他列的数据,减少IO

        3、追加写速度快

        二、MySQL的列存储引擎Infobright

        Infobright是一款基于独特的专利知识网格技术的列式数据库。Infobright是开源的MySQL数据仓库解决方案,引入了列存储方案,高强度的数据压缩,优化的统计计算(类似sum/avg/group by之类),infobright 是基于mysql的,但不装mysql亦可,因为它本身就自带了一个。mysql可以粗分为逻辑层和物理存储引擎,infobright主要实现的就是一个存储引擎,但因为它自身存储逻辑跟关系型数据库根本不同,所以,它不能像InnoDB那样直接作为插件挂接到mysql,它的逻辑层是mysql的逻辑层加上它自身的优化器。

        Infobright特征

        优点:

        大数据量查询性能强劲、稳定:百万、千万、亿级记录数条件下,同等的SELECT查询语句,速度比MyISAM、InnoDB等普通的MySQL存储引擎快5~60倍。高效查询主要依赖特殊设计的存储结构对查询的优化,但这里优化的效果还取决于数据库结构和查询语句的设计。

        存储数据量大:TB级数据大小,几十亿条记录。数据量存储主要依赖自己提供的高速数据加载工具(百G/小时)和高数据压缩比(>10:1)

        高数据压缩比:号称平均能够达到 10:1 以上的数据压缩率。甚至可以达到40:1,极大地节省了数据存储空间。高数据压缩比主要依赖列式存储和 patent-pending 的灵活压缩算法.

        基于列存储:无需建索引,无需分区。即使数据量十分巨大,查询速度也很快。用于数据仓库,处理海量数据没一套可不行。不需要建索引,就避免了维护索引及索引随着数据膨胀的问题。把每列数据分块压缩存放,每块有知识网格节点记录块内的统计信息,代替索引,加速搜 索。

        快速响应复杂的聚合类查询:适合复杂的分析性SQL查询,如SUM, COUNT, AVG, GROUP BY

        Infobright的价值

        节约设计开销。没有复杂的数据仓库模型设计要求(比如星状模型、雪花模型),无需要物化视图、数据分区、索引建立节省存储资源。高压缩比率通常是10:1,某些应用可能达到40:1集成利用广泛。和众多的BI套件相容,比如Pentaho、Cognos、Jaspersof降低运维成本。随着数据库的逐渐增大,查询和装载性能持续保持稳定,实施和管理简单,需要极少的管理商业保证。第一个商业支持的开源仓储分析数据库,是Oracle/MySQL 官方推荐的仓储集成架构

        Infobright的适用场景

        大数据量的分析应用。网页/在线分析、移动分析、客户行为分析、分析营销和广告日志/事件管理系统。电信详单分析和报告、系统/网络 安全认证记录数据集市。企事业单位特定数据仓库、为中小企业提供数据仓库嵌入式分析。为独立软件供应商/ SaaS供应商提供嵌入式分析应用

        限制:

        不支持数据更新:社区版Infobright只能使用“LOAD DATA INFILE”的方式导入数据,不支持INSERT、UPDATE、DELETE。这使对数据的修改变得很困难,这样就限制了它作为实时数据服务的数据仓库来使用。

        不支持高并发:只能支持10多个并发查询,虽然单库 10 多个并发对一般的应用来说也足够了,但较低的机器利用率对投资者来说总是一件不爽的事情,特别是在并发小请求较多的情况下。

        没有提供主从备份和横向扩展的功能。如果没有主从备份,想做备份的话,也可以主从同时加载数据,但只能校验最终的数据一致性,使得从机在数据加载时停服务的时间较长;横向扩展方面,它本身就不是分布式的存储系统。

        与MySQL对比

        infobright适用于数据仓库场合:即非事务、非实时、非多并发;分析为主;存放既定的事实,例如日志,或汇总的大量的数据。所以它并不适合于应对来自网站用户的请求。实际上它取一条记录比mysql要慢很多,但它取100W条记录会比mysql快。

        mysql的总数据文件占用空间通常会比实际数据多,因为它还有索引。infobright的压缩能力很强大,按列按不同类型的数据来压缩。

        服务形式与接口跟mysql一致,可以用类似mysql的方式启用infobright服务,然后原来连接mysql的应用程序都可以以类似的方式连接与查询infobright。这对熟练mysql者来说是个福音,学习成本基本为0。

        infobright有两个发布版:开源的ICE及闭源商用的IEE。ICE提供了足够用的功能,但不能 INSERT,DELETE,UPDATE,只能LOAD DATA INFILE。IEE除提供更充分的功能外,据说查询速度也要更快。

        社区ICE版,国内各大企业均有测试,投入生成系统的较少,主要有以下原因:

        对DML、alter语句限制

        需定时增量load导出导入

        自带的MyISAM难以支持高并发,若想充分利用服务器资源,需开启另外的MySQL实例

        对中文等多字节文字支持不好

        仅支持单核调度

        缺少原厂的支持

        ICE与IEE版本区别

        IEE包含针对大多数企业工作需求的附加特性,如:更好的查询性能、DML语句支持、分布式导入等。另外,IEE版本还包含了一定级别的Infobright原厂或代理商的支持救援服务、产品培训等。

        明显的查询性能差异。虽然IEE和ICE版本均具有明显超出例如Oracle、SQL Server、MySQL等行式数据库的查询性能,但IEE还要比ICE版本快50-500%。这个明显差距来自于IEE核心引擎中特有的——多线程调度模块(自IEE3.5引入).而在ICE中,一个独立的查询只能使用单个CPU核心,其他的查询进程只能使用其他核心。对于需要筛选和区分大量数据的复杂查询,使用IEE多线程调度模块可以显著地节约查询时间。

        支持DML语句。IEE支持标准的SQL 数据操作语言,使用insert、update、delete操控数据。而ICE只支持Load data infile进行数据导入,任何数据的变化都需要重新导入全部数据。DML语句的使用会降低数据查询性能,随次数递增。

        支持DDL语句。包括alter table rename,add column,drop column(但是列操作只能对最后列生效)

        支持Hadoop接口(通过DLP)

        高级复制和高可用。IEE版本包含主从功能,基于SQL statement

        更简易的导入和更快的导入速度。IEE支持分布式导入工具-DLP;且包含标准的MySQL原生loader,用于处理一些复杂数据的导入,另一方面也说明IBloader的容错性较差

        Load或DML同时的一致性查询

        支持临时表

        其他商业授权,售后支持等

你可能感兴趣的:(列存储和Greenplum压缩表)