列数据库 列式数据库的优缺点
本篇文章给大家谈谈列数据库，以及列式数据库的优缺点对应的知识点，文章可能有点长，但是希望大家可以阅读完，增长自己的知识，最重要的是希望对各位有所帮助，可以解决了您的问题，不要忘了收藏本站喔。
数据库中的“列”是什么意思
在数据库中大多数表的“列”称为“字段”。
一张数据表分为行和列，一行就是一跳记录，可能有很多个字段，就是各个属性。
比如一张Student表，里面有studentname，id等字段，是站一列的，他们合起来组成一跳记录。
扩展资料：
字段在数据库中的解释。
(field)
一个成员，它表示与对象或类关联的变量。
在数据库中，大多数时，表的“列”称为“字段”，每个字段包含某一专题的信息。就像“通讯录”数据库中，“姓名”、“联系电话”这些都是表中所有行共有的属性，所以把这些列称为“姓名”字段和“联系电话”字段。
但是有时候，字段也不是表中的列，比如用as将列的内容经计算，“存入”另一个字段。
字段在C++中的定义：
一个成员，它表示与对象或类关联的变量。
参考资料来源：百度百科-字段
参考资料来源：
列式数据库的优缺点
优点：
极高的装载速度
（最高可以等于所有硬盘IO
的总和，基本是极限了）
适合大量的数据而不是小数据
实时加载数据仅限于增加（删除和更新需要解压缩Block
然后计算然后重新压缩储存）
高效的压缩率，不仅节省储存空间也节省计算内存和CPU。
非常适合做聚合操作。
缺点：
不适合扫描小量数据
不适合随机的更新
批量更新情况各异，有的优化的比较好的列式数据库（比如Vertica）表现比较好，有些没有针对更新的数据库表现比较差。
不适合做含有删除和更新的实时操作。
MySQL 数据库如何添加列
传统情况
我们先回顾一下，在没有"立刻加列"功能时，加列操作是怎么完成的。我们也借此来熟悉一下本期的图例：
当进行加列操作时，所有的数据行都必须要增加一段数据（图中的列 4数据）
如上一期图解所讲，当改变数据行的长度，就需要重建表空间（图中灰蓝的部分为发生变更的部分）
数据字典中的列定义也会被更新
以上操作的问题在于每次加列操作都需要重建表空间，这就需要大量 IO以及大量的时间
立刻加列
"立刻加列"的过程如下图：
请点击输入图片描述
请点击输入图片描述
"立刻加列"时，只会变更数据字典中的内容，包括：
在列定义中增加新列的定义
增加新列的默认值
"立刻加列"后，当要读取表中的数据时：
由于"立刻加列"没有变更行数据，读取的行数据只有 3列
MySQL会将新增的第 4列的默认值，追加到读取的数据后
以上过程描述了如何读取在"立刻加列"之前写入的数据，其实质是：在读取数据的过程中，"伪造"了一个新列出来
那么如何读取在"立刻加列"之后写入的数据呢?过程如下图：
当读取行 4时：
请点击输入图片描述
请点击输入图片描述
通过判断数据行的头信息中的instant标志位，可以知道该行的格式是"新格式"：该行头信息后有一个新字段"列数"
通过读取数据行的"列数"字段，可以知道该行数据中多少列有"真实"的数据，从而按列数读取数据
通过上图可以看到：读取在"立刻加列"前/后写入的数据是不同的流程
通过以上的讨论，我们可以总结"立刻加列"之所以高效的原因是：
在执行"立刻加列"时，不变更数据行的结构
读取"旧"数据时，"伪造"新增的列，使结果正确
写入"新"数据时，使用了新的数据格式（增加了instant标志位和"列数"字段)，以区分新旧数据
读取"新"数据时，可以如实读取数据
那么我们是否能一直"伪造"下去?"伪造"何时会被拆穿?
考虑以下场景：
用"立刻加列"增加列 A
写入数据行 1
用"立刻加列"增加列B
写入数据行2
删除列B
我们推测一下"删除列 B"的最小代价：需要修改数据行中的instant标志位或"列数"字段，这至少会影响到"立刻加列"之后写入的数据行，成本类似于重建数据
从以上推测可知：当出现与"立刻加列"操作不兼容的 DDL操作时，数据表需要进行重建，如下图所示：
请点击输入图片描述
请点击输入图片描述
扩展思考题：是否能设计其他的数据格式，取代instant标志位和"列数"字段，使得加列/删列操作都能"立刻完成"?（提示：考虑加列-删列-再加列的情况）
使用限制
在了解原理之后，我们来看看"立刻加列"的使用限制，就很容易能理解其中的前两项：
"立刻加列"的加列位置只能在表的最后，而不能加在其他列之间
在元数据中，只记录了数据行应有多少列，而没有记录这些列应出现的位置。所以无法实现指定列的位置
"立刻加列"不能添加主键列
加列不能涉及聚簇索引的变更，否则就变成了"重建"操作，不是"立刻"完成了
"立刻加列"不支持压缩的表格式
按照 WL的说法："COMPRESSED is no need to supported"（没必要支持不怎么用的格式）
总结回顾
我们总结一下上面的讨论：
"立刻加列"之所以高效的原因是：
在执行"立刻加列"时，不变更数据行的结构
读取"旧"数据时，"伪造"新增的列，使结果正确
写入"新"数据时，使用了新的数据格式(增加了instant标志位和"列数"字段)，以区分新旧数据
读取"新"数据时，可以如实读取数据
"立刻加列"的"伪造"手法，不能一直维持下去。当发生与"立刻加列"操作不兼容的 DDL时，表数据就会发生重建
回到之前遗留的两个问题：
"立刻加列"是如何工作的?
我们已经解答了这个问题
所谓"立刻加列"是否完全不影响业务，是否是真正的"立刻"完成?
可以看到：就算是"立刻加列"，也需要变更数据字典，那么该上的锁还是逃不掉的。也就是说这里的"立刻"指的是"不变更数据行的结构"，而并非指"零成本地完成任务"
列式数据库的举例
下面以GBase 8a分析型数据库为例，描述列存储对数据存储与管理的作用。
面对海量数据分析的 I/O瓶颈，GBase 8a把表数据按列的方式存储，其优势体现在以下几个方面。
不读取无效数据：降低 I/O开销，同时提高每次 I/O的效率，从而大大提高查询性能。查询语句只从磁盘上读取所需要的列，其他列的数据是不需要读取的。例如，有两张表，每张表100GB且有100列，大多数查询只关注几个列，采用列存储，不需要像行存数据库一样，将整行数据取出，只取出需要的列。磁盘 I/0是行存储的 1/10或更少，查询响应时间提高 10倍以上。
高压缩比：压缩比可以达到 5~ 20倍以上，数据占有空间降低到传统数据库的1/10，节省了存储设备的开销。
当数据库的大小与数据库服务器内存大小之比达到或超过 2:1（典型的大型系统配置值）时，列存的 I/O优势就显得更加明显；
GBase 8a分析型数据库的独特列存储格式，对每列数据再细分为“数据包”。这样可以达到很高的可扩展性：无论一个表有多大，数据库只操作相关的数据包，性能不会随着数据量的增加而下降。通过以数据包为单位进行 I/O操作提升数据吞吐量，从而进一步提高I/O效率。
由于采用列存储技术，还可以实现高效的透明压缩。
由于数据按列包存储，每个数据包内都是同构数据，内容相关性很高，这使得GBase 8a更易于实现压缩，压缩比通常能够达到 1:10甚至更优。这使得能够同时在磁盘 I/O和 Cache I/O上都提升数据库的性能，使 GBase 8a在某些场景下的运算性能比传统数据库快 100倍以上。
GBase 8a允许用户根据需要设置配置文件，选择是否进行压缩。在启用压缩的情况下GBase 8a根据数据的不同特性以及不同的分布状况，自动采用相应的压缩算法，如：
行程编码（适用于大量连续重复的数据，特别是排序数据）；
基于数据的差值编码（适用于重复率低，但彼此差值较小的数据列）；
基于位置的差值编码（适用于重复率高，但分布比较随机的数据列）。
关于列数据库的内容到此结束，希望对大家有所帮助。