索引

什么情况下使用全局索引和本地索引

2013年12月10日 08:56:20 zhaoyangjian724 阅读数：937

我举个 global 索引的例子

查询 条件 不走 分区键这个值

但是 我走另外一个where条件

而且选择性很高

 

假设索引高度为3

不跨越分区 扫描3个block +1个 data block

跨越分区 扫描 1000个 分区 *3 +1个data block

 

扫描要跨越 多个 分区你就建立 global

条件里不带上了分区键对应的列,对应的列就用GLOBAL

oracle会对主键自动创建全局索引

 

我 有一个查询
查询 条件 不走 分区键这个值
但是 我走另外一个where条件

总结就是
扫描要跨越 多个 分区
你就建立 global

global 索引是为了解决 跨越 分区扫描的用的

 

总结:

全局索引：
优点：通过索引检索，没有限定分区的谓词、或跨分区时，性能好点，
缺点：分区维护的时候麻烦，drop分区等维护会失效，dml的时候索引维护成本高，数据大了rebuild也难

local 索引：
优点：通过索引检索，有限定分区的谓词、不跨分区时，性能好，分区维护容易，dml的索引维护底，rebuild也方便。
缺点：通过索引检索，又没有限定分区的谓词、或跨分区时，性能不如全局索引

 

 

有分区裁剪的,那么其他列就建立分区索引

就是where 条件里带上了分区键,对应的列 就用LOCAL

没有分区裁剪的,那么列就建立global 索引

==================================================================================================================================================================================

DQL、DML、DDL、DCL的概念与区别

SQL(Structure Query Language)语言是数据库的核心语言。

SQL的发展是从1974年开始的，其发展过程如下：
1974年-----由Boyce和Chamberlin提出，当时称SEQUEL。
1976年-----IBM公司的Sanjase研究所在研制RDBMS SYSTEM R
时改为SQL。
1979年-----ORACLE公司发表第一个基于SQL的商业化RDBMS产品。
1982年-----IBM公司出版第一个RDBMS语言SQL/DS。
1985年-----IBM公司出版第一个RDBMS语言DB2。
1986年-----美国国家标准化组织ANSI宣布SQL作为数据库工业标准。
SQL是一个标准的数据库语言，是面向集合的描述性非过程化语言。
它功能强，效率高，简单易学易维护（迄今为止，我还没见过比它还好
学的语言）。然而SQL语言由于以上优点，同时也出现了这样一个问题：
它是非过程性语言，即大多数语句都是独立执行的，与上下文无关，而
绝大部分应用都是一个完整的过程，显然用SQL完全实现这些功能是很困
难的。所以大多数数据库公司为了解决此问题，作了如下两方面的工作：
(1)扩充SQL，在SQL中引入过程性结构；(2)把SQL嵌入到高级语言中，
以便一起完成一个完整的应用。

二. SQL语言的分类

SQL语言共分为四大类：数据查询语言DQL，数据操纵语言DML，数据定义语言DDL，数据控制语言DCL。

1. 数据查询语言DQL
数据查询语言DQL基本结构是由SELECT子句，FROM子句，WHERE
子句组成的查询块：
SELECT <字段名表>
FROM <表或视图名>
WHERE <查询条件>

2 .数据操纵语言DML
数据操纵语言DML主要有三种形式：
1) 插入：INSERT
2) 更新：UPDATE
3) 删除：DELETE

3. 数据定义语言DDL
数据定义语言DDL用来创建数据库中的各种对象-----表、视图、
索引、同义词、聚簇等如：
CREATE TABLE/VIEW/INDEX/SYN/CLUSTER
| | | | |
表 视图 索引 同义词 簇

DDL操作是隐性提交的！不能rollback 

4. 数据控制语言DCL
数据控制语言DCL用来授予或回收访问数据库的某种特权，并控制
数据库操纵事务发生的时间及效果，对数据库实行监视等。如：
1) GRANT：授权。

2) ROLLBACK [WORK] TO [SAVEPOINT]：回退到某一点。
回滚---ROLLBACK
回滚命令使数据库状态回到上次最后提交的状态。其格式为：
SQL>ROLLBACK;

3) COMMIT [WORK]：提交。

    在数据库的插入、删除和修改操作时，只有当事务在提交到数据
库时才算完成。在事务提交前，只有操作数据库的这个人才能有权看
到所做的事情，别人只有在最后提交完成后才可以看到。
提交数据有三种类型：显式提交、隐式提交及自动提交。下面分
别说明这三种类型。

(1) 显式提交
用COMMIT命令直接完成的提交为显式提交。其格式为：
SQL>COMMIT；

(2) 隐式提交
用SQL命令间接完成的提交为隐式提交。这些命令是：
ALTER，AUDIT，COMMENT，CONNECT，CREATE，DISCONNECT，DROP，
EXIT，GRANT，NOAUDIT，QUIT，REVOKE，RENAME。

(3) 自动提交
若把AUTOCOMMIT设置为ON，则在插入、修改、删除语句执行后，
系统将自动进行提交，这就是自动提交。其格式为：
SQL>SET AUTOCOMMIT ON；

===========================================================================================================================================================================================================================================================================

1，列存：

实现列裁剪和过滤下压

2，索引技术：

全局多维索引，文件索引，Min/Max ， 倒排索引等多种索引技术

从表级，文件级，列级等多个层级逐级快速定位数据，避免SQL-on-Hadoop引擎常见的“暴力扫描“，从而大幅提升性能，实现十年数据秒级响应， 三百维字段任意组合查询。

3，字典编码：

=============================================================================================================================================================================================================================================================================================================================================================================================================================================================

华为开源数据格式CarbonData项目

明翼

0.2 2018.04.17 21:56 字数 4383 阅读 1498评论 1喜欢 5

这篇文章整理自：http://www.infoq.com/cn/news/2016/07/huwei-CarbonData-data-second-res
里面的思想很有意义，不排除今年尝试下，对我们的项目也许比solr更适用。

简介

Apache® CarbonData™是由华为开源贡献的大数据高效存储格式解决方案。针对当前大数据领域分析场景需求各异而导致的存储冗余问题，CarbonData提供了一种新的融合数据存储方案，以一份数据同时支持“交互式分析、详单查询、任意维度组合的过滤查询等”多种大数据应用场景，并通过丰富的索引技术、字典编码、列存等特性提升了IO扫描和计算性能，实现百亿数据级秒级响应，与大数据生态Apache Hadoop、Apache Spark等无缝集成。
数据统一存储：为了节约成本，企业希望一份数据支持多种使用场景；减少数据孤岛和冗余，通过数据共享产生更大价值。

现在企业数据要求：
高效：数据分析要求越来越高效、实时。
易集成：提供标准接口，新的大数据方案与企业已采购的工具和IT系统要能无缝集成，支撑老业务快速迁移。
大集群：区别于以往的单机系统，企业客户希望新的大数据平台能应对日益增多的数据，随时可以通过增加资源的方式横向扩展，无极扩容。
开放生态：通过开源开放，让更多的客户和合作伙伴的数据连接在一起，发挥更大的价值。

CarbonData 特点

列式存储：高效的列式数据组织，区别于行存，可以实现列裁剪和过滤下压，使OLAP查询性能更高。同时，CarbonData针对明细数据查询实现了深度优化，在需要返回所有列的场景下性能优于其他列存方案。

丰富的索引支持：支持全局多维索引、文件索引、Min/Max、倒排索引等多种索引技术，从表级，文件级，列级等多个层级逐级快速定位数据，避免SQL-on-Hadoop引擎常见的“暴力扫描“，从而大幅提升性能，实现十年数据秒级响应， 三百维字段任意组合查询。

全局字典编码：除了常见的Delta、RLE、BitPacking等编码外，CarbonData应用了全局字典编码来实现免解码的计算，计算框架可以直接使用经过编码的数据来做聚合，排序等计算，这对需要做跨节点数据交换的业务来说性能提升非常明显。

自适应类型转换：CarbonData针对分析型应用中大量使用的数值类型（Double/Decimal/Numeric/BigInt）实现存储内数据类型转换，配合列式数据压缩，使得压缩非常高效，数据压缩率基于应用场景不同一般压缩比在2到8之间。

标准SQL和API：在SparkSQL基础上，支持标准SQL99/2003；支持数据批量更新、删除，适用于OLAP场景下数据的周期性刷新，例如拉链表更新、维表数据同步。提供JDBC/ODBC连接，支持与BI工具无缝对接；兼容Spark DataFrame/DataSet，支持复杂分析应用。

数据生态集成：支持与Hadoop、Spark等大数据生态系统集成，支持和商业BI工具无缝对接。既满足传统数仓、数据集市、BI应用要求，也提供大数据生态丰富多样的API支持，覆盖从GB级到EB级应用。

开源开放： CarbonData于2016年6月全票通过进入Apache孵化器，不到一年时间，毕业成为Apache顶级项目，这标志着CarbonData项目完成依照Apache way开源方式运作，社区多样化，贡献来自华为、Intel、Talend、eBay、Inmobi、Knoldus、Habib Bank、上汽、携程、丁香园、阿里、美团、乐视、滴滴等公司资深架构师和开发人员。

产品解决痛点

第一，在部署上， 区别于以往的单机系统，企业客户希望有一套分布式方案来应对日益增多的数据，随时可以通过增加通用服务器的方式scale out横向扩展。

第二，在业务功能上，很多企业的业务都处在从传统数据库逐渐转移到大数据平台的迁移过程中，这就要求大数据平台要有较高兼容老业务的能力，这里面主要包含的是对完整的标准SQL支持，以及多种分析场景的支持。同时为了节约成本，企业希望“一份数据支持多种使用场景”，例如大规模扫描和计算的批处理场景，OLAP多维交互式分析场景，明细数据即席查询，主键低时延点查，以及对实时数据的实时查询等场景，都希望平台能给予支持，且达到秒级查询响应。

第三，在易用性上， 企业客户以往使用BI工具，业务分析的OLAP模型是需要在BI工具中建立的，这就会导致有的场景下数据模型的灵活性和分析手段受到限制，而在大数据时代，大数据开源领域已经形成了一个生态系统，社区随时都在进步，经常会冒出一些新型的分析工具，所以企业客户都希望能跟随社区不断改进自己的系统，在自己的数据里快速用上新型的分析工具，得到更大的商业价值。

要同时达到上诉要求，无疑对大数据平台是一个很大的挑战。为了满足这些要求，我们开始不断在实际项目中积累经验，也尝试了很多不同的解决方案，但都没有发现能用一套方案解决所有问题。

大家首先会想到的是，在涉及到低时延查询的分布式存储中，一般常用的是KV型NoSQL数据库（如HBase，Cassandra），可以解决主键低时延查询的问题，但如果业务的查询模式稍作改变，例如对多维度灵活组合的查询，就会使点查变为全表扫描，使性能急剧下降。 有的场景下，这时可以通过加入二级索引来缓解该问题，但这又带来了二级索引的维护和同步等管理问题，所以KV型存储并不是解决企业问题的通用方案。

那么，如果要解决通用的多维查询问题，有时我们会想到用多维时序数据库的方案（如Linkedin Pinot），他们的特点是数据都以时间序列的方式进入系统并经过数据预聚合和建立索引，因为是预计算，所以应对多维查询时非常快，数据也非常及时，同时具备多维分析和实时处理的优点，在性能监控、实时指标分析的场景里应用较多。但它在支持的查询类型上也有一定限制，因为做了数据预计算，所以这种架构一般无法应对明细数据查询，以及不支持Join多表关联分析，这无疑给企业使用场景带来了一定的限制。

另外一类是搜索系统（如Apache Solr，ElasticSearch），搜索系统可以做多维汇总也可以查询明细数据，它也具备基于倒排索引的快速布尔查询，并发也较高，似乎正是我们希望寻找的方案。但在实际应用中我们发现两个问题：一是由于搜索系统一般是针对非结构化数据而设计的，系统的数据膨胀率一般都比较高，在企业关系型数据模型下数据存储不够紧凑，造成数据量较大， 二是搜索系统的数据组织方式和计算引擎密切相关，这就导致了数据入库后只能用相应的搜索引擎处理，这又一定程度打破了企业客户希望应用多种社区分析工具的初衷，所以搜索系统也有他自己的适用场景。

最后一类系统，就是目前社区里大量涌现的SQL on Hadoop方案，以Hive, SparkSQL, Flink为代表，这类系统的特点是计算和存储相分离，针对存储在HDFS上的文件提供标准SQL功能，他们在部署性和易用性上可以满足企业客户需求，业务场景上也能覆盖扫描，汇聚，详单等各类场景，可见可以将他们视为一类通用的解决方案。为了提高性能，Spark，Flink等开源项目通过不断优化自身架构提升计算性能，但提升重点都放在计算引擎和SQL优化器的增强上，在存储和数据组织上改进并不是重点。

所以，可以看出当前的很多大数据系统虽然都能支持各类查询场景，但他们都是偏向某一类场景设计的，在不是其目标场景的情况下要么不支持要么退化为全表扫描，所以导致企业为了应对批处理，多维分析，明细数据查询等场景，客户常常需要通过复制多份数据，每种场景要维护一套数据。

CarbonData的设计初衷正是为了打破这种限制，做到只保存一份数据，最优化地支撑多种使用场景。

技术架构和优势

CarbonData：整个大数据时代的开启，可以说是源自于Google的MapReduce论文，他引发了Hadoop开源项目以及后续一系列的生态发展。他的“伟大”之处在于计算和存储解耦的架构，使企业的部分业务（主要是批处理）从传统的垂直方案中解放出来，计算和存储可以按需扩展极大提升了业务发展的敏捷性，让众多企业普及了这一计算模式，从中受益。

虽然MapReduce开启了大数据时代，但它是通过纯粹的暴力扫描+分布式计算来提升批处理性能，所以并不能解决客户对所有查询场景的低时延查询要求。

在目前的生态中，最接近于客户要求的其实是搜索引擎类方案。通过良好的数据组织和索引，搜索引擎能提供多种快速的查询功能，但偏偏搜索引擎的存储层又和计算引擎是紧耦合的，并不符合企业对”一份数据，多种场景”的期望。

这给了我们启发，我们何不为通用计算引擎打造更一个高效的数据组织来满足客户需求呢，做到既利用计算和存储解耦架构又能提供高性能查询。抱着这个想法，我们启动了CarbonData项目。针对更多的业务，使计算和存储相分离，这也成了CarbonData的架构设计理念。

确立了这个理念后，我们很自然地选择了基于HDFS+通用计算引擎的架构，因为这个架构可以很好地提供Scale out能力。下一步我们问自己这个架构里还缺什么？这个架构中，HDFS提供文件的复制和读写能力，计算引擎负责读取文件和分布式计算，分工很明确，可以说他们分别定位于解决存储管理和计算的问题。但不难看出，为了适应更多场景，HDFS做了很大的“牺牲”，它牺牲了对文件内容的理解，正是由于放弃了对文件内容的理解，导致计算只能通过全扫描的方式来进行，可以说最终导致的是存储和计算都无法很好的利用数据特征来做优化。

所以针对这个问题，我们把CarbonData的发力重点放在对数据组织的优化上，通过数据组织最终是要提升IO性能和计算性能。为此，CarbonData做了如下工作。

CarbonData基础特性

1、多维数据聚集： 在入库时对数据按多个维度进行重新组织，使数据在“多维空间上更内聚”，在存储上获得更好的压缩率，在计算上获得更好的数据过滤效率。
2、带索引的列存文件结构：首先，CarbonData为多类场景设计了多个级别的索引，并融入了一些搜索的特性，有跨文件的多维索引，文件内的多维索引，每列的minmax索引，以及列内的倒排索引等。其次，为了适应HDFS的存储特点，CarbonData的索引和数据文件存放在一起，一部分索引本身就是数据，另一部分索引存放在文件的元数据结构中，他们都能随HDFS提供本地化的访问能力。
3、列组： 整体上，CarbonData是一种列存结构，但相对于行存来说，列存结构在应对明细数据查询时会有数据还原代价高的问题，所以为了提升明显数据查询性能，CarbonData支持列组的存储方式，用户可以把某些不常作为过滤条件但又需要作为结果集返回的字段作为列组来存储，经过CarbonData编码后会将这些字段使用行存的方式来存储以提升查询性能。
4、数据类型： 目前CarbonData支持所有数据库的常用基本类型，以及Array，Struct复杂嵌套类型。同时社区也有人提出支持Map数据类型，我们计划未来添加Map数据类型。
5、压缩：目前CarbonData支持Snappy压缩，压缩是针对每列分别进行的，因为列存的特点使得压缩非常高效。数据压缩率基于应用场景不同一般在2到8之间。
6、Hadoop集成： 通过支持InputFormat/OutputFormat接口，CarbonData可以利用Hadoop的分布式优点，也能在所有以Hadoop为基础的生态系统中使用。

CarbonData高级特性

1、可计算的编码方式： 除了常见的Delta，RLE，Dictionary，BitPacking等编码方式外，CarbonData还支持将多列进行联合编码，以及应用了全局字典编码来实现免解码的计算，计算框架可以直接使用经过编码的数据来做聚合，排序等计算，这对需要大量shuffle的查询来说性能提升非常明显。
2、与计算引擎联合优化：为了高效利用CarbonData经过优化后的数据组织，CarbonData提供了有针对性的优化策略，目前CarbonData社区首先做了和Spark的深度集成，其中基于SparkSQL框架增强了过滤下压，延迟物化，增量入库等特性，同时支持所有DataFrame API。相信未来通过社区的努力，会有更多的计算框架与CarbonData集成，发挥数据组织的价值。
目前这些特性都已经合入Apache CarbonData主干，欢迎大家使用。

适应性和性能场合

CarbonData：推荐场景：希望一份存储同时满足快速扫描，多维分析，明细数据查询的场景。在华为的客户使用案例中，对比业界已有的列存方案，CarbonData可以带来5~30倍性能提升。

性能测试数据及应用案例等更多信息，请关注微信公众号eCarbonData，及社区]https://github.com/apache/incubator-carbondata