最早的商业列式数据库是在1995年发布的Sybase IQ，但是一直到1999年左右才慢慢稳定到能够投入生产环境。现在的大多数分析型数据库都是在年从Postgresql分支出来的。这篇文章解释介绍列式数据库的几大特点。
1.高效的储存空间利用率
传统的行式数据库由于每个列的长度不一，为了预防更新的时候不至于出现一行数据跳到另一个block上去，所以往往会预留一些空间。而面向列的数据库由于一开始就完全为分析而存在，不需要考虑少量的更新问题，所以数据完全是密集储存的。
行式数据库为了表明行的id 往往会有一个伪列rowid 的存在。列式数据库一般不会保存rowid。
列式数据库由于其针对不同列的数据特征而发明的不同算法使其往往有比行式数据库高的多的压缩率，普通的行式数据库一般压缩率在3：1 到5：1 左右，而列式数据库的压缩率一般在8：1到30：1 左右。（InfoBright在特别应用可以达到40:1，Vertica在特别应用可以达到60:1 ，一般是这么高的压缩率都是网络流量相关的）
列式数据库由于其特殊的IO模型所以其数据执行引擎一般不需要索引来完成大量的数据过滤任务（Sybase IQ 除外）。这又额外的减少了数据储存的空间消耗。
列式数据库不需要物化视图，行式数据库为了减少IO 一般会有两种物化视图，常用列的不聚合物化视图和聚合的物化视图。列式数据库本身列是分散储存所以不需要第一种，而由于其他特性使其极为适合做普通聚合操作。（另外一种物化视图是不能实时刷新的，比如排名函数，不规则连接connect by 等等，这部分列数据库不包括。）
2.不可见索引
列式数据库由于其数据的每一列都按照选择性进行排序，所以并不需要行式数据库里面的索引来减少IO和更快的查找值的分布情况。如下图所示: 当数据库执行引擎进行where条件过滤的时候。只要它发现任何一列的数据不满足特定条件，整个block 的数据就都被丢弃。最后初步的过滤只会扫描可能满足条件的数据块。
（from InfoBright : Blazing Queries Using an Open Source Columnar Database for High Performance Analytics and Reporting ）
另外在已经读取了可能的数据块之后，对于类似age&65或job=‘Axx’的，列式数据库并不需要扫描完整个block，因为数据已经排序了。如果读到第一个age=66 或者 Job = ‘Bxx’ 的时候就会停止扫描了。这相当与行式数据库索引里的范围扫描。
3.数据迭代 （Tuple Iteration）
现在的多核CPU 提供的L2缓存在短时间执行同一个函数很多次的时候能更好的利用CPU的二级缓存和多核并发的特性。而行式数据库由于其数据混在一起没法对一个数组进行同一个简单函数的调用，所以其执行效率没有列式数据库高。
4.压缩算法
列式数据库由于其每一列都是分开储存的。所以很容易针对每一列的特征运用不同的压缩算法。常见的列式数据库压缩算法有Run Length Encoding ， Data Dictionary ， Delta Compression ， BitMap Index ， LZO ， Null Compression 等等。根据不同的特征进行的压缩效率从10W:1 到10:1 不等。而且数据越大其压缩效率的提升越为明显。
5.延迟物化
列式数据库由于其特殊的执行引擎，在数据中间过程运算的时候一般不需要解压数据而是以指针代替运算，直到最后需要输出完整的数据时。
（from McKnight : Columnar Database : Data Does the Twist and Analytics Shout）
传统的行式数据库运算，在运算的一开始就解压缩所有数据，然后执行后面的过滤，投影，连接，聚合操作而列式数据库的执行计划却是这样的。
（from McKnight : Columnar Database : Data Does the Twist and Analytics Shout）
在整个计算过程中，无论过滤，投影，连接，聚合操作，列式数据库都不解压数据直到最后数据才还原原始数据值。这样做的好处有减少CPU 消耗，减少内存消耗，减少网络传输消耗，减少最后储存的需要。
列式数据库优缺点
列式数据库从一开始就是面向大数据环境下数据仓库的数据分析而产生，它跟行式数据库相比当然也有一些前提条件和优缺点。
列式数据库优点：
极高的装载速度（最高可以等于所有硬盘IO的总和，基本是极限了）适合大量的数据而不是小数据实时加载数据仅限于增加（删除和更新需要解压缩Block 然后计算然后重新压缩储存）高效的压缩率，不仅节省储存空间也节省计算内存和CPU。非常适合做聚合操作。列式数据库缺点：
不适合扫描小量数据不适合随机的更新批量更新情况各异，有的优化的比较好的列式数据库（比如Vertica）表现比较好，有些没有针对更新的数据库表现比较差。不适合做含有删除和更新的实时操作。常见误区
一个常见的误区认为如果每次扫描较多行或者全列全表扫描的时候，行式数据库比列式数据库更有优势。事实上这只是行式数据库认识上的一个误区，即认为列式数据库的主要优势在于其列分开储存，而忽略了列式数据库上面提到的其他几大特征，这个才是列式数据库高性能的核心。
Hbase与Oracle比较（列式数据库与行式数据库）
关系型和非关系型数据库的区别?
一分钟搞懂列式与行式数据库
数据库优化性能解析
数据库面试题目(mysql、nosql)
没有更多推荐了，如何看待yandex开源clickhouse这个列式文档数据库?
我的图书馆
如何看待yandex开源clickhouse这个列式文档数据库?
【欧阳辰的回答(26票)】:
作者：欧阳辰
链接：的分析-ClickHouse - 互联居 - 知乎专栏
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。
俄罗斯的‘百度’叫做Yandex，覆盖了俄语搜索超过68%的市场，有俄语的地方就有Yandex；有中文的地方，就有百度么？好像不一定 :) 。
Yandex在日开源了一个的数据库，名字叫做ClickHouse，这对保守俄罗斯人来说是个特大事。更让人惊讶的是，这个列式存储数据库的跑分要超过很多流行的商业MPP数据库软件，例如Vertica。如果你没有听过Vertica，那你一定听过 Michael Stonebraker，2014年图灵奖的获得者，PostgreSQL和Ingres发明者（Sybase和SQL Server都是继承 Ingres而来的）, Paradigm4和SciDB的创办者。Michael Stonebraker于2005年创办Vertica公司，后来该公司被HP收购，HP Vertica成为MPP列式存储商业数据库的高性能代表，Facebook就购买了Vertica数据用于用户行为分析。
简单的说，ClickHouse作为分析型数据库，有三大特点：一是跑分快， 二是功能多 ，三是文艺范
1. 跑分快： ClickHouse跑分是Vertica的5倍快：
ClickHouse性能超过了市面上大部分的列式存储数据库，相比传统的数据ClickHouse要快100-1000X，ClickHouse还是有非常大的优势：
100Million 数据集:
ClickHouse比Vertica约快5倍，比Hive快279倍，比My SQL快801倍
1Billion 数据集:
ClickHouse比Vertica约快5倍，MySQL和Hive已经无法完成任务了
2. 功能多：ClickHouse支持数据统计分析各种场景
- 支持类SQL查询，
- 支持繁多库函数（例如IP转化，URL分析等，预估计算/HyperLoglog等）
- 支持数组(Array)和嵌套数据结构(Nested Data Structure)
- 支持数据库异地复制部署
3.文艺范：目前ClickHouse的限制很多，生来就是为小资服务的
- 目前只支持Ubuntu系统
- 不提供设计和架构文档，设计很神秘的样子，只有开源的C++源码
- 不理睬Hadoop生态，走自己的路
谁在用ClickHouse?
由于项目今年6月才开源，因此外部商业应用并不多件，但是开发社区的讨论还是保持热度(主要用俄语）
Yandex有十几个项目在用使用ClickHouse，它们包括：Yandex数据分析，电子邮件，广告数据分析，用户行为分析等等
2012年，欧洲核子研究中心使用ClickHouse保存粒子对撞机产生的大量实验数据，每年的数据存储量都是PB级别，并支持统计分析查询
ClickHouse最大应用：
最大的应用来自于Yandex的统计分析服务Yandex.Metrica，类似于谷歌Analytics(GA)，或友盟统计，小米统计，帮助网站或移动应用进行数据分析和精细化运营工具，据称Yandex.Metrica为世界上第二大的网站分析平台。ClickHouse在这个应用中，部署了近四百台机器，每天支持200亿的事件和历史总记录超过13万亿条记录，这些记录都存有原始数据（非聚合数据），随时可以使用SQL查询和分析，生成用户报告。
ClickHouse就是快：比Veritca快约5倍
下面是100M数据集的跑分结果：ClickHouse 比Vertia快约5倍，比Hive快279倍，比My SQL 快801倍；虽然对不同的SQL查询，结果不完全一样，但是基本趋势是一致的。ClickHouse跑分有多块？ 举个例子：ClickHouse 1秒，Vertica 5.42秒，Hive 279秒；
ClickHouse是什么，适合什么场景？
到底什么是ClickHouse数据库，场景应用是什么，参考下面说明：
ClickHouse的不完美：
不支持Transaction：想快就别想Transaction
聚合结果必须小于一台机器的内存大小：不是大问题
缺少完整的Update/Delete操作
支持有限操作系统
开源社区刚刚启动，主要是俄语为主
ClickHouse和一些技术的比较
1.商业OLAP数据库
例如：HP Vertica, Actian the Vector,
区别：ClickHouse是开源而且免费的
2.云解决方案
例如：亚马逊RedShift和谷歌的BigQuery
区别：ClickHouse可以使用自己机器部署，无需为云付费
3.Hadoop生态软件
例如：Cloudera Impala, Spark SQL, Facebook Presto , Apache Drill
-ClickHouse支持实时的高并发系统
-ClckHouse不依赖于Hadoop生态软件和基础
-ClickHouse支持机房的部署
4.开源OLAP数据库
例如：InfiniDB, MonetDB, LucidDB
区别：这些项目的应用的规模较小，并没有应用在大型的互联网服务当中，相比之下，ClickHouse的成熟度和稳定性远远超过这些软件。
5.开源分析，非关系型数据库
例如：Druid , Apache Kylin
区别：ClickHouse可以支持从原始数据的直接查询，ClickHouse支持类SQL语言，提供了传统关系型数据的便利。
第二章，死而后生
ClickHouse设计之初就是为Yandex.Metrika而生，先一起看看Yandex.Metrika数据分析系统的演化过程吧，ClickHouse是第四代的解决方案，经过三次死亡后的产物，涅槃重生的巨兽！
第一阶段：MyISAM (LSM-Tree) ()
Yandex.Metrika产品成立于2008年，最开始使用了MyISAM作为存储引擎。熟悉MySQL的同学都知道，这是MySQL的重要存储引擎之一（另外一个是InnoDB)。MyISAM中的实现也是使用LSM-Tree的设计，基本思路就是将对数据的更改hold在内存中，达到指定的threadhold后将该批更改批量写入到磁盘，在批量写入的过程中跟已经存在的数据做rolling merge。
使用MyISAM的方法，刚开始数据量不大，访问请求也不大的时候，这个方法非常有效，特别是对于一些固定的报告生成，效率非常高，系统能够保持很好的系统写能力。
数据格式也是传统的索引结构：一个数据文件+一个索引结构； 索引结构是一个B-Tree结构，叶子节点保持着数据文件的OffS 通过Index文件找到数据范围，然后进行数据文件读取；早期的实现是将Index文件装在内存中，数据文件在磁盘当中，或则SSD等。当时7200RPM的硬盘，每秒进行100-200次随机读；SSD硬盘可以支持30000次随机读/每秒。
除了考察MyISAM之外，InnoDB也被考察过。MyISAM的索引和数据是分开的，并且索引是有压缩的，这种方式可以提高内存的使用率。加载更多索引到内存中，而Innodb是索引和数据是紧密捆绑的，没有使用压缩的情况下，InnoDb的大小会比MyISAM体积大很多。当然，InnoDB支持的Transaction也是非常诱人的。
阶段二: Metrage (从2010-现在)
为了解决MyISAM的一些问题，Yandex决定开发Metrage，核心想法来源于统计分析数据的一些特点，统计分析数据的每行数据量都不大，因此可以将多行数据聚合在一起作为处理单位，加快操作速度和系统的吞吐能力。
它有几个特点：
数据通过小批量Batch存储
支持高强度的写操作（数千行写入/每秒）
读数据量非常小
读数据操作中Primary Key 的数量有限（&1百万）
每一行的数据量很小
整个结构类似于MyISAM的索引，但是数据块中也聚合了一些小粒度的数据，索引放在内存中，数据被整理成块放在磁盘中，并且进行压缩。
该数据结构的优点：
- 数据被压缩成块。 由于存储有序，压缩足够强大，其中使用了快速压缩算法（在2010年使用QuickLZ ，自2011年使用LZ4 ）。
- 采用稀疏索引： 稀疏索引 - 主键值排序后放置于若干个组中，可以节省大量索引空间。 这个索引始终放在内存中。
Metrage在数据量最大的时候，39*2台服务器中存储了大约3万亿行数据，每天机器处理大约为1千亿的数据。
这个系统有个缺点，数据查询只能进行基于固定的查询模式（否则性能将受到很大影响），因此在设计数据Schema的时候，需要考虑数据查询的性能问题，缺少足够的灵活型。因此这个项目使用了5年后，统计分析的数据都开始迁移到其他的平台系统中了（那时候LevelDB，还没有出现，否则可以使用LevelDB作为Mertage的核心模块）。
阶段三 OLAPServer ()
随着Yandex.Metrike的数据量越来越大，数据查询的速度越来越慢，查询相应事件长，系统的CPU和IO资源占用大，因此公司内部尝试了不同的解决方案，其中一个原型方案是OLAPServer。 设计思路就是根据“星型结构”设计一些维度和事实列，通过预先部分聚合数据加快访问的速度，这一套技术用于支持各种报告的生成。
基本的场景如下：
支持一个Fact表，包括维度列(Dimension)和指标列（Metrics)，维度有上百个
读取大量行的数据，但是一次查询往往只关注某些列
写多读少的场景，报表查询请求量并不大
大部分简单查询不超过50毫秒响应时间
列的值数据量非常小，通常为整数或者不超过60字节的URL
它需要高带宽，同时处理单个请求（高达十亿每秒的行的单个服务器上）
查询结果的数据量非常小，通常是数据聚合的结果
无需支持事务，数据更新极少，通知只有添加操作
这些场景下，使用列式数据库是非常有效的，从两个方面可以理解
1. 磁盘I/O的优化
- 作为列式存储，查询只需要访问所关心的列数据
- 列数据放在一起，数据格式类似，非常容易压缩，因此减少I/O数据量
- 输入输出的减少，内存可以腾出更多地方作为Cache
由于数量行数特别大，数据的解压缩和计算将耗费非常多的CPU资源，为了提高CPU的效率，行业中通常是将数据转换成Vector的计算。例如行业比较流行的VectorWise方法。
下面是VectorWise的高层架构示意图，其基本想法就是将压缩的列数据整理成现代CPU容易处理的Vector模式，利用现代CPU的多线程，SIMD(Single Instruction,Multiple Data)，每次处理都是一批Vector数据，极大的提高了处理效率。
市场有非常多的的列式分析型数据库，例如HP Vertica, ParAccel Actian the Matrix, Google PowerDrill , Amazon的RedShift , MetaMarkets Druid等等，这些产品有很多不同的优化实践，有些是专于数据压缩，有些是专于数据聚合，有些是专于扩展性等。
OLAPServer在具体实现过程中，实际上采用的是比较保守的方法，实现的功能也比较有限，但是完全满足当时分析报表的支持。例如，OLAPServer数据类型只支持1-8字节的数据类型，查询只支持固定的模式：
Select keys ,aggregate(columns) from table where condition1 and condition2 .... Group by keys order by columns 。
尽管功能有限，OLAPServer还是满足了当时的分析报表功能，并且性能非常出色。由于设计之处的限制比较多，因此后期的改进过程中成本非常高，例如为了增加更长URL的数据类型，系统改动非常大。在2013年，OLAPServer存储了7280亿行数据，目前这些数据都迁移到ClickHouse了。
第四阶段 ClickHouse（2011-现在）
使用OLAPServer，我们能够可以实时看到一些预先聚合的数据，但是对于一些聚合前的详细数据是无法查询的，随着业务的深入发展，精细化运营对于统计服务提出了更高的要求，后期有大量需求是关于直接查询聚合前的数据。
总体来说，虽然数据聚合带来一些好处，但是也存在以下一些问题。
对于基数大的列，聚合的意义不大，例如URL等
过多的维度组合会导致组合爆炸
用户常常只关心聚合后的数据中的非常一一小部分数据，因此大量聚合预计算是得不偿失的。
聚合后的数据，数据修改会非常困难，很难保证存储的逻辑完整性
如果不预先聚合数据，如何保证响应时间是一个大挑战。这意味着，数据库需要支持秒级处理数十亿的行。
近年来，市面上也出现很多列式存储的开源DBMS，包括Cloudera Impala, Spark SQL, Presto, Apache Drill，这些系统虽然都能完成查询的功能，但是速度却无法满足数据统计分析的需求，即使聚合后的性能能够满足，但也缺少灵活度。
因此，Yandex开发了自己的列式分析数据库 ClickHouse，初期主要是满足Yandex.Metrike的统计分析需求，主角要上场了。
ClickHouse实际上来源于内部的几个项目的整合，项目起源起源于2011年左，
到2013年的时候，ClickHouse的性能就和Vertica大致相同；2015年12月，ClickHouse的数量已经达到11万亿行，数据表有200多列，主集群的服务器数量也从初期的60台到394台；
整个系统的部署是支持水平扩展的，并且支持多机房部署和备份。虽然它是能够在大型集群操作，它可以被安装在同一服务器上，甚至在虚拟机上。
在最新的性能评测中，ClickHouse比Vertica快约5倍。现在Yandex公司内部有十几个应用系统在使用ClickHouse，场景包括数据存储，查询分析，报表制作等。
ClickHouse的蓝图
关于ClickHouse的下一步发展，公司并没有给出太多规划，因为多数信息还是属于不公开状态，但是从一些公开的信息，我们可以了解到，ClickHouse会向两个方向发展。
1 云计算数据库：
Yandex希望通过ClickHouse促进公司云计算数据库的发展，包括用户可以通过云服务的方式，使用ClickHouse，开源是走向市场的第一步。
2. 加强SQL兼容性。
为了支持更多的企业用户，目前的查询虽然采用非常近似的SQL语言，但是还有很多地方需要改进，包括和一些商业软件（例如Tableau,Pentaho）的集成无缝使用。
第三部分：遥指杏花村
这一部分包括了一些ClickHouse的一些基本信息，帮助大家进入ClickHouse的世界。为了深度了解ClickHouse社区，不仅仅需要翻墙，也需要谷歌或者必应的翻译器，俄文翻译的效果不错。
３参考文章：
Yandex.Metrike的架构演化：
（俄文）很棒的文章
MPP数据库基础架构：
４关于Yandex的
Yandex的（纳斯达克股票代码：YNDX）是互联网公司在俄罗斯主导，经营该国最流行的搜索引擎和访问量最大的网站。Yandex的还经营在乌克兰，哈萨克斯坦，白俄罗斯和土耳其。Yandex的的使命是回答任何互联网用户的任何问题（Answer any question Internet users may have)。
最近在学习一些ClickHouse的源代码，还没有理清楚头绪，下次搞清楚逻辑后再和大家介绍一下，这里先纸上谈兵，点到为止了。
---------------------完------------------------------
【yyywww的回答(0票)】:
is actually a kind of "view" to local tables of ClickHouse cluster.
还不支持transaction。。。。
你要知道用可写view就马上能搭建起来类似的，还支持transaction。。。。。
列式存储也不是新鲜东西，甚至连sql2016都支持了
喜欢该文的人也喜欢大数据学习资源最全版本（收藏）
大数据学习资源最全版本（收藏）
资源列表：
关系数据库管理系统（RDBMS）
分布式编程
分布式文件系统
文件数据模型
Key -Map 数据模型
键-值数据模型
图形数据模型
NewSQL数据库
列式数据库
资源列表：
关系数据库管理系统（RDBMS）
分布式编程
分布式文件系统
文件数据模型
Key -Map 数据模型
键-值数据模型
图形数据模型
NewSQL数据库
列式数据库
时间序列数据库
搜索引擎与框架
MySQL的分支和演化
PostgreSQL的分支和演化
Memcached的分支和演化
嵌入式数据库
数据可视化
物联网和传感器
有一句话叫做三人行必有我师，其实做为一个开发者，有一个学习的氛围
跟一个交流圈子特别重要这是一个我的大数据交流学习群
不管你是小白还是大牛欢迎入驻，正在求职的也可以加入
，大家一起交流学习，话糙理不糙，互相学习，共同进步，一起加油吧。
关系数据库管理系统（RDBMS）
：世界最流行的开源数据库；
：世界最先进的开源数据库；
：对象-关系型数据库管理系统。
：分布式处理架构，结合了 MapReduce（并行处理）、YARN（作业调度）和HDFS（分布式文件系统）；
：高吞吐量实时流处理框架。
分布式编程
：最初在AddThis上开发的分布式数据处理和存储系统；
：用在Hadoop MapReduce v1上运行Spark；
：为统一的模型以及一套用于定义和执行数据处理工作流的特定SDK语言；
：一个简单的Java API，用于执行在普通的MapReduce实现时比较单调的连接、数据聚合等任务；
：由LinkedIn开发的针对Hadoop and 和Pig的用户定义的函数集合；
：具有高性能的执行时间和自动程序优化；
：内存中的数据模型和持久性框架；
：BSP（整体同步并行）计算框架；
：在集群上使用并行、分布式算法处理大数据集的编程模型；
：Hadoop中，用于处理数据分析程序的高级查询语言；
：用来简化和统一低层大数据系统的保留性评估执行框架；
：S4中流处理与实现的框架；
：内存集群计算框架；
：流处理框架，同时是Spark的一部分；
：Twitter流处理框架，也可用于YARN；
：基于Kafka和YARN的流处理框架；
：基于YARN，用于执行任务中的复杂DAG（有向无环图）；
：基于YARN的抽象概念，用于减少开发分布式应用程序的复杂度；
：数据处理和查询库；
：在MapReduce之上的高性能、自定义数据仓库；
：在Hadoop上的数据管理/分析框架；
：用于Clojure的MapReduce库；
：可选择的MapReduce范例；
：为实时引擎，用于以尽可能畅通的方式、最小的开支和对性能最小的影响，实现分布式、异步、实时的内存大数据计算；
：为Hadoop做优化处理，从而消除单点故障；
：MapReduce框架；
：分布式内存数据存储；
：创建数据管道，以帮助其分析框架；
：为MapReduce，用于编译成Apache Pig；
：由Nokia开发的MapReduc获取、转换和分析数据；
：MapReduce框架；
：容错流处理框架；
：用于处理结构化、半结构化和非结构化数据工作的声明性编程语言；
：为一组库、工具、实例和文档集，用于使在Hadoop的生态系统上建立系统更加容易；
：用于大数据集的实时e框架；
：分布式云计算；
：异步任务执行系统；
：用于Hadoop的Python MapReduce和HDFS API；
：多租户分布式测度处理系统；
：通用集群计算框架；
：用于计算基于不同时间窗口的事件流的活动，并找到最活跃的一个；
：易于使用的用于分批处理和流计算的平台，通过Scala、 Akka和Play所建；
：基于Cascading，用于Map Reduce工作的Scala库；
：在Twitter上使用Scalding和Storm串流MapReduce；
：Twitter上的时间序列聚合器。
分布式文件系统
：在多台机器上存储大型文件的方式；
：以前是FhGFS，并行分布式文件系统；
：设计的软件存储平台；
：分布式文件系统；
：对象存储系统；
：分布式文件系统(GFS2)；
：分布式文件系统；
：可扩展的、高度可用的存储；
：兼容GGFS、Hadoop内存的文件系统；
：高性能分布式文件系统；
：开源分布式文件系统；
：向外扩展的附网存储（Network-attached Storage）文件系统；
：简单的、高度可扩展的分布式文件系统；
：以可靠的存储速率在跨集群框架上文件共享；
：分布式云存储系统；
文件数据模型
：商用的面向对象数据库管理系统；
：是一个开源的大规模可扩展的数据存储，需要零管理模式；
：Facebook的Paxos算法，类似于NoSQL数据库；
：基于Hadoop的面向文档的数据存储；
：可横向扩展的面向文档的NoSQL数据存储；
：模式不可知的企业版NoSQL数据库技术；
：面向文档的数据库系统；
：一个事务性的，开源文档数据库；
：支持连接查询和群组依据等查询的文档型数据库。
Key Map 数据模型
注意：业内存在一些术语混乱，有两个不同的东西都叫做“列式数据库”。这里列出的有一些是围绕“key-map”数据模型而建的分布式、持续型数据库，其中所有的数据都有（可能综合了）键，并与映射中的键-值对相关联。在一些系统中，多个这样的值映射可以与键相关联，并且这些映射被称为“列族”（具有映射值的键被称为“列”）。
另一组也可称为“列式数据库”的技术因其存储数据的方式而有别于前一组，它在磁盘上或在存储器中——而不是以传统方式，即所有既定键的键值都相邻着、逐行存储。这些系统也彼此相邻来存储所有列值，但是要得到给定列的所有值却不需要以前那么繁复的工作。
前一组在这里被称为“key map数据模型”，这两者和之间的界限是相当模糊的。后者对数据模型有更多的存储格式，可在中列出。若想了解更多关于这两种模型的区分，可阅读Daniel Abadi的博客：。
：内置在Hadoop上的分布式键/值存储；
：由BigTable授权，面向列的分布式数据存储；
：由BigTable授权，面向列的分布式数据存储；
：Facebook所开发的HBase的衍化品；
：面向列的分布式数据存储；
：为完全管理型的无模式数据库，用于存储在BigTable上非关系型数据；
：由BigTable授权，面向列的分布式数据存储；
：通过MySQL的接口访问，并使用大规模并行处理进行并行查询；
：用于HBase处理；
：Twitter的实时、多租户分布式数据库。
键-值数据模型
：支持NoSQL的闪存优化，数据存储在内存。开源，“’C’（不是Java或Erlang）中的服务器代码可精确地调整从而避免上下文切换和内存拷贝”。
：分布式键/值存储，Dynamo论文的实现；
：为替代Redis的协议兼容的服务器；
：专门研究Hadoop中数据导出的分布式数据库；
：分布式时间序列数据库；
：适用于存储在时间序列中的传感器数据；
：简单的持久性数据存储，拥有低延迟和高吞吐量；
：分布式键/值存储系统；
：Oracle公司开发的分布式键值数据库；
：内存中的键值数据存储；
：分散式数据存储；
：Twitter开发的异步键值存储的库；
：一个高效的NoSQL数据库和Lua应用服务器；
：由Google Spanner和HBase授权，Rust提供技术支持的分布式键值数据库；
：可复制、共享的键-值存储，能提供多行原子写入。
图形数据模型
：基于Hadoop的Pregel实现；
：可实现Pregel，为Spark的一部分；
：多层模型分布式数据库；
：一个可扩展的、分布式、低时延、高吞吐量的图形数据库，旨在为Google生产水平规模和吞吐量提供足够的低延迟，用于TB级的结构化数据的实时用户查询；
：TAO是facebook广泛用来存储和服务于社交图形的分布式数据存储；
：GCHQ中的Gaffer是一个易于存储大规模图形的框架，其中节点和边缘都有统计数据；
：开源图形数据库；
：图形处理框架；
：核心C ++ GraphLab API和建立在GraphLab API之上的高性能机器学习和数据挖掘工具包的集合；
：Spark中的弹性分布式图形系统；
：图形追踪语言；
：以RDF为中心的Map / Reduce框架；
：在Hadoop上构建大规模图形的工具；
：用于在GPU上大规模并行图形处理；
：完全用Java写入的图形数据库；
：文档和图形数据库；
：大型图形处理框架；
：建于Cassandra的分布式图形数据库；
：分布式图形数据库。
NewSQL数据库
：由商业支持，开源的SQL关系数据库管理系统；
：基于PostgreSQL的数据仓库服务；
：面向统计数值的SQL数据库；
：通过分区和复制横向扩展PostgreSQL；
：可扩展、地址可复制、交易型的数据库；
：旨在产生可扩展、灵活的智能应用的分布式数据库；
：由F1授意的分布式数据库；
：建立在Spanner上的分布式SQL数据库；
：全球性的分布式半关系型数据库；
：是一个实验性主存并行数据库管理系统，用于联机事务处理（OLTP）应用的优化；
：基于Percolator，HBase的线性可扩展多行多表交易库；
：MySQL/MariaDB的NoSQL插件；
：无限可扩展的RDBMS；
：内存中的SQL数据库，其中有优化的闪存列存储；
：SQL / ACID兼容的分布式数据库；
：内存中具有持久性和可恢复性的关系型数据库管理系统；
：内存中低延时的分布式SQL数据存储，可为内存列表数据提供SQL接口，在HDFS中较持久化；
：是在内存中面向列的关系型数据库管理系统；
：分布式实时半结构化的数据库；
：用于行为数据的灵活、高性能分析的数据库；
：用于文件和数据库同步的开源软件；
：为GPU内存数据库，也为大数据分析和可视化平台；
：TiDB是分布式SQL数据库，基于谷歌F1的设计灵感；
：自称为最快的内存数据库。
列式数据库
注意：请在阅读相关注释。
：解释什么是列存储以及何时会需要用到它；
：面向列的分析型数据库；
：面向列的DBMS；
：列存储数据库；
：Hadoop的列存储格式；
：专门设计的、专用的分析数据仓库，类似于传统的基于行的工具，提供了一个列式工具；
：用来管理大规模、快速增长的大量数据，当用于数据仓库时，能够提供非常快的查询性能；
：谷歌的云产品，由其在Dremel的创始工作提供支持；
：亚马逊的云产品，它也是基于柱状数据存储后端。
时间序列数据库
：使用MongoDB来存储时间序列数据；
：在HBase之上的分布式时间序列数据库，它包括内置的Rule Engine、数据预测和可视化；
：基于Cassandra和Elasticsearch的可扩展的时间序列数据库；
：分布式时间序列数据库；
：类似于OpenTSDB但会考虑到Cassandra；
：在HBase上的分布式时间序列数据库；
：一种时间序列数据库和服务监测系统；
：一种基于Apache Cassandra的时间序列数据库。
：高性能交互式的SQL，可访问所有的Hadoop数据；
：由Dremel授意的交互式分析框架；
：Hadoop的表格和存储管理层；
：Hadoop的类SQL数据仓库系统；
：一种框架，可允许高效的查询翻译，其中包括异构性及联合性数据的查询；
：Apache Phoenix 是 HBase 的 SQL 驱动；
：由Dremel授意的交互式分析框架；
：Cascading中的类SQL查询语言；
：用于大数据集的完整的SQL查询工具；
：分布式SQL查询工具；
：交互式分析框架，Dremel的实现；
：Hadoop的类SQL的数据仓库系统；
：用于存储大规模PB级结构化和半结构化数据的数据库；
：用于Spark和Shark的查询优化框架；
：使用Spark操作结构化数据；
：一个全功能的Hadoop上的SQL RDBMS，并带有ACID事务；
：用于Hive的交互式查询；
：Hadoop的分布式数据仓库系统；
：为企业级的SQL-on-HBase针对大数据的事务或业务工作负载的解决方案。
：大规模数据流的实时处理；
：数据采集系统；
：管理大量日志数据的服务；
：分布式发布-订阅消息系统；
：在Hadoop和结构化的数据存储区之间传送数据的工具；
：帮助 Solr、HBase和HDFS完成ETL的框架；
：流日志数据聚合器；
：采集事件和日志的工具；
：实时连接多个数据流的分布式计算机系统，具有高可扩展性和低延迟性；
：开源流处理软件系统；
：用Hadoop连接不同数据源的框架；
：分布式消息队列系统；
：对数据库更改捕获的事件流；
：压缩已分类整型数组的程序包；
：日志聚合器和仪表板；
：用于管理事件和日志的工具；
：像基于Chukwa 的Storm和Samza一样的日志聚合器；
：是实现Kafka日志持久性的服务；
：LinkedIn的通用数据摄取框架；
：是一种数据存储略图，使用概率性数据结构来处理计数、略图等相关的问题；
：连续大数据采集的基础设施，可简单地使用IDE。
：JVM中分布性、容错事件驱动应用程序的运行时间；
：数据序列化系统；
：Apache ZooKeeper的Java库；
：在任何OSGi框架之上运行的OSGi运行时间；
：构建二进制协议的框架；
：流程管理集中式服务；
：一种松耦合分布式系统锁服务；
：集群管理器；
：消息传递框架；
：服务发现和协调的分散化解决方案；
：一种构建批处理作业的复杂管道的Python包，它能够处理依赖性解析、工作流管理、可视化、故障处理、命令行一体化等等问题；
：数据摄取、实时分析、批量处理和数据导出的分布式、可扩展系统；
：LZO压缩数据的工作库；
：JVM的异步网络堆栈。
：在Apache Mesos之上运行的服务调度程序；
：数据管理框架；
：工作流作业调度程序；
：分布式容错调度；
：批处理工作流作业调度；
：Hadoop作业敏捷调度的Scala DSL；
：调度平台；
：一个以编程方式编写、调度和监控工作流的平台。
：Hadoop的机器学习库；
：JavaScript中的神经网络；
：实时大规模机器学习；
：Cascading的机器学习库；
：Javascript中的机器学习，在浏览器中训练卷积神经网络（或普通网络）；
：Ruby中灵活、可扩展的机器学习；
：支持多种先进算法的机器学习框架，同时支持类的标准化和处理数据；
：机器学习文本分类；
：Scalding中可扩展的机器学习；
：Google中的大规模机器学习系统；
：Python的机器学习平台，包括ML工具包、数据工程和部署工具的广泛集合；
：Hadoop统计性的机器学习和数学运行时间；
：用于BDAS堆栈的分布式机器学习库；
：针对iOS和Mac OS X的快速多层感知神经网络库；
：使文本挖掘更为容易，从文本中提取分类数据；
：智能计算的Numenta平台，它是一个启发大脑的机器智力平台，基于皮质学习算法的精准的生物神经网络；
：建于Hadoop、Mahout和Cascading上的机器学习服务器；
：分布式流媒体机器学习框架；
：scikit-learn为Python中的机器学习；
：Spark中一些常用的机器学习（ML）功能的实现；
：微软和雅虎发起的学习系统；
：机器学习软件套件；
：CPU和加速GPU的机器学习库。
：测试Hadoop性能的微基准；
：现实大数据工作负载基准测试；
：Hadoop基准测试套件；
：MapReduce应用的基准测试套件；
：雅虎工程师团队的Hadoop集群基准测试。
：Hadoop集群安全访问的单点；
：存储在Hadoop的数据安全模块。
：Hadoop管理的运作框架；
：Hadoop生态系统的部署框架；
：集群管理框架；
：集群管理器；
：一种YARN应用，用来部署YARN中现有的分布式应用程序；
：运行云服务的库集；
：集群管理器；
：用于简化应用程序部署和管理的库；
：基于Groovy语言，和Apache BigTop类似；
：和Hadoop进行交互的Web应用程序；
：多数据中心复制系统；
：作业调度和监控系统；
：作业调度和监控系统；
：可在YARN上部署HBase集群的应用；
：用于长期运行服务的Mesos框架。
：使用Scala、Spark和Parquet处理的下一代web分析；
：基于HBase，实时采集和分析数据的框架；
：开源网络爬虫；
：用于NASA科学档案中数据的捕获、处理和共享；
：内容分析工具包；
：时间序列监测和报警平台；
：基于Node.js和MongoDB，开源的手机和网络分析平台；
：运行、规划、共享和部署模型——没有任何基础设施；
：基于Eclipse的报告系统；
：开源的事件分析平台；
：建于Kafka上的异步消息代理；
：在Hadoop’s MapReduce上执行图像处理任务的API；
：Hadoop的Splunk分析；
：大规模分析平台；
：RDBMS的用于数据分析的数据处理库；
：来自eBay的开源分布式分析工具；
：Pivotal HD / HAWQ和PostgreSQL中的R；
：为自动缩放Hadoop集群，内置的数据连接器；
：用于数据科学和大数据分析的云平台；
：用于实时运营分析的分布式内存数据存储，提供建立在Spark单一集成集群中的数据流分析、OLTP（联机事务处理）和OLAP（联机分析处理）；
：企业级网络和事件分析，由Hadoop、Kinesis、Redshift 和Postgres提供技术支持；
：Spark的R前端；
：用于机器生成的数据的分析；
：基于云的分析仪，用于分析机器生成的数据；
：用于YARN、Hadoop、HBASE、Hive、HCatalog和Pig的统一开源环境；
：利用大数据（OS X app）的实例查询工具。
搜索引擎与框架
：搜索引擎库；
：用于Apache Lucene的搜索平台；
：基于Apache Lucene的搜索和分析引擎；
：为免费增值的健壮性web应用，用于探索、筛选、分析、搜索和导出来自网络的大规模数据集；
：社交图形搜索平台；
：连续索引系统；
：连续索引系统；
：大型搜索索引；
：为Percolator的实现，HBase的一部分；
：快速、轻松地搜索存储在HBase的任何内容；
：完全由Java编写的分面搜索的实现，为Apache Lucene的延伸；
：为一个一个灵活的软件库，使得局部、无序、实时预输入的搜索实现了快速发展；
：LinkedIn搜索架构；
：是用Java编写的实时搜索/索引系统；
：全文搜索引擎
MySQL的分支和演化
：亚马逊云的MySQL数据库；
：MySQL的6.0的演化；
：谷歌云的MySQL数据库；
：MySQL的增强版嵌入式替代品；
：使用NDB集群存储引擎的MySQL实现；
：MySQL的增强版嵌入式替代品；
：MySQL的高性能代理；
：用于MySQL和 MariaDB的存储引擎；
：运行MySQL时面临类似挑战的几家公司，它们的工程师之间的合作。
PostgreSQL的分支和演化
– multi-peta-byte database / MPP derived by PostgreSQL.
：MapReduce和DBMS的混合体；
：高性能数据仓库设备；
：基于PostgreSQL，可扩展的开源数据库集群；
：完全建立在PostgreSQL内部的开源推荐引擎；
：开源MPP数据库系统，只针对数据仓库和数据集市的应用程序；
：PostgreSQL可以推导多字节P比特数据库/MPP。
Memcached的分支和演化
：闪存的键/值缓存；
：Memcache的分支；
：Memcached和Redis的快速、轻型代理；
：闪存的键/值缓存；
：Memcache的分支。
嵌入式数据库
：Pervasive Software公司开发的ACID兼容的DBMS，在应用程序中嵌入了优化；
：为键/值数据提供一个高性能的嵌入式数据库的一个软件库；
：Erlang LSM BTree存储；
：谷歌写的一个快速键-值存储库，它提供了从字符串键到字符串值的有序映射；
：Symas开发的超快、超紧凑的键-值嵌入的式数据存储；
：基于性LevelDB，用于快速存储的嵌入式持续性键-值存储。
：商业智能云平台；
：精益业务智能平台，用于可视化和探索数据；
：基于云的自助服务商业智能工具；
：功能强大的商业智能套件；
：定制的商业智能平台；
：商业智能软件和平台；
：商业智能、移动智能和网络应用软件平台；
：商业智能平台；
：商业智能和分析平台；
：开源的分析平台；
：开源商业智能平台；
：商业智能平台；
：大数据分析；
：交互式大数据分析。
数据可视化
：用于PrestoDB的网页UI；
：利用网络工作者和jQuery的图形可视化库；
：对存储在Kibana中Solr. Port的日志和时戳数据进行可视化；
：一个功能强大的Python交互式可视化库，它针对要展示的现代web浏览器，旨在为D3.js风格的新奇的图形提供优雅简洁的设计，同时在大规模数据或流数据集中，通过高性能交互性来表达这种能力；
：基于D3可重复使用的图表库；
：开源或免费增值的虚拟主机，用于带有强大的前端编辑功能和API的地理空间数据库；
：只带Img标签的反应灵敏、兼容Retina的图表；
：开源的HTML5图表可视化效果；
：另一个开源HTML5图表可视化效果；
：JavaScript库，用于在浏览器中探索多元大数据集，用Dc.js和D3.js.效果很好；
：用于时间序列可视化的JavaScript库；
：用于可视化复杂网络的JavaScript库；
：维度图表，和Crossfilter一起使用，通过D3.js呈现出来，它比较擅长连接图表/附加的元数据，从而徘徊在D3的事件附近；
：操作文件的JavaScript库；
：从可重复使用的图表和组件构成复杂的、数据驱动的可视化；
：一组相当强大的可重用的图表，还有D3.js的样式；
：百度企业场景图表；
：动态HTML5可视化；
：写SQL查询，返回SVG图表，而不是表；
：针对IOT和其他Web混搭的开源实时仪表盘构建；
：屡获殊荣的开源平台，可视化和操纵大型图形和网络连接，有点像Photoshop，但是针对于图表，适用于Windows和Mac OS X；
：简单的图表API；
：石墨仪表板前端、编辑器和图形组合器；
：可扩展的实时图表；
：简单而灵活的图表API；
：为交互式计算提供丰富的架构；
：可视化日志和时间标记数据；
：Python绘图；
：建立在D3之上的库，针对时间序列数据进行最优化；
：d3.js的图表组件；
：渐进式SVG条形图，折线和饼图；
：易于使用的Web服务，它允许快速创建从热图到直方图等复杂的图表，使用图表Plotly的在线电子表格上传数据进行创建和设计；
：支持plotly的开源JavaScript图形库；
：简单但功能强大的库，纯粹利用JavaScript和HTML构建数据应用；
：查询和可视化数据的开源平台；
：针对R的Web应用程序框架；
：JavaScript库，专门用于图形绘制；
：一个可视化语法；
：一个笔记本式的协作数据分析；
：用于大数据的JavaScript图表库。
物联网和传感器
：基于云的传感器分析；
：物联网平台；
：数据流网络；
：ThingWorx 是让企业快速创建和运行互联应用程序平台；
：IFTTT 是一个被称为 “网络自动化神器” 的创新型互联网服务，它的全称是 If this then that，意思是“如果这样，那么就那样”；
：Evrythng则是一款真正意义上的大众物联网平台，使得身边的很多产品变得智能化。
（较）- Cassandra vs MongoDB vs CouchDB vs Redis vs Riak vs HBase vs Couchbase vs Neo4j vs Hypertable vs ElasticSearch vs Accumulo vs VoltDB vs Scalaris comparison；
（）- Redshift, Hive, Shark, Impala and Stiger/Tez的基准；
（） – 电子表格的继承者应该是大数据。
2015 – 2016
–Facebook– One Trillion Edges: Graph Processing at Facebook-Scale.（一兆边：Facebook规模的图像处理）
2013 – 2014
–Stanford - Mining of Massive Datasets.（海量数据集挖掘）
–AMPLab– Presto: Distributed Machine Learning and Graph Processing with Sparse Matrices. （Presto： 稀疏矩阵的分布式机器学习和图像处理）
–AMPLab– MLbase: A Distributed Machine-learning System. （MLbase：分布式机器学习系统）
–AMPLab - Shark: SQL and Rich Analytics at Scale. （Shark: 大规模的SQL 和丰富的分析）
- AMPLab -
GraphX: A Resilient Distributed Graph System on Spark. （GraphX:基于Spark的弹性分布式图计算系统）
- Google– HyperLogLog in Practice: Algorithmic Engineering of a State of The Art Cardinality Estimation Algorithm. （HyperLogLog实践:一个艺术形态的基数估算算法）
–Microsoft - Scalable Progressive Analytics on Big Data in the Cloud.（云端大数据的可扩展性渐进分析）
- Metamarkets - Druid: A Real-time Analytical Data Store. （Druid：实时分析数据存储）
–Google– Online, Asynchronous Schema Change in F1.（F1中在线、异步模式的转变）
- Google - F1: A Distributed SQL Database That Scales. （F1: 分布式SQL数据库）
–Google– MillWheel: Fault-Tolerant Stream Processing at Internet Scale.（MillWheel: 互联网规模下的容错流处理）
–Facebook - Scuba: Diving into Data at Facebook. （Scuba: 深入Facebook的数据世界）
–Facebook– Unicorn: A System for Searching the Social Graph. （Unicorn: 一种搜索社交图的系统）
- Facebook - Scaling Memcache at Facebook. （Facebook 对 Memcache 伸缩性的增强）
2011 – 2012
–Twitter– The Unified Logging Infrastructure for Data Analytics at Twitter. （Twitter数据分析的统一日志基础结构）
–AMPLab–Blink and It’s Done: Interactive Queries on Very Large Data. （Blink及其完成：超大规模数据的交互式查询）
–AMPLab–Fast and Interactive Analytics over Hadoop Data with Spark. （Spark上 Hadoop数据的快速交互式分析）
–AMPLab–Shark: Fast Data Analysis Using Coarse-grained Distributed Memory. （Shark：使用粗粒度的分布式内存快速数据分析）
–Microsoft–Paxos Replicated State Machines as the Basis of a High-Performance Data Store. （Paxos的复制状态机——高性能数据存储的基础）
–Microsoft–Paxos Made Parallel. （Paxos算法实现并行）
–AMPLab– BlinkDB：BlinkDB: Queries with Bounded Errors and Bounded Response Times on Very Large Data.（超大规模数据中有限误差与有界响应时间的查询）
–Google–Processing a trillion cells per mouse click.（每次点击处理一兆个单元格）
–Google–Spanner: Google’s Globally-Distributed Database.（Spanner：谷歌的全球分布式数据库）
–AMPLab–Scarlett: Coping with Skewed Popularity Content in MapReduce Clusters.（Scarlett：应对MapReduce集群中的偏向性内容）
–AMPLab–Mesos: A Platform for Fine-Grained Resource Sharing in the Data Center.（Mesos：数据中心中细粒度资源共享的平台）
–Google–Megastore: Providing Scalable, Highly Available Storage for Interactive Services.（Megastore：为交互式服务提供可扩展，高度可用的存储）
2001 – 2010
–Facebook - Finding a needle in Haystack: Facebook’s photo storage.（探究Haystack中的细微之处： Facebook图片存储）
–AMPLab -Spark: Cluster Computing with Working Sets.（Spark:工作组上的集群计算）
–Google– Storage Architecture and Challenges.（存储架构与挑战）
–Google - Pregel: A System for Large-Scale Graph Processing.（Pregel: 一种大型图形处理系统）
–Google - Large-scale Incremental Processing Using Distributed Transactions and Notifications base of Percolator and Caffeine.（使用基于Percolator 和 Caffeine平台分布式事务和通知的大规模增量处理）
–Google– Dremel: Interactive Analysis of Web-Scale Datasets.（Dremel: Web规模数据集的交互分析）
–Yahoo -S4: Distributed Stream Computing Platform.（S4:分布式流计算平台）
– HadoopDB：An Architectural Hybrid of MapReduce and DBMS Technologies for Analytical Workloads.（混合MapReduce和DBMS技术用于分析工作负载的的架构）
–AMPLab– Chukwa: A large-scale monitoring system.（Chukwa: 大型监控系统）
–Amazon - Dynamo: Amazon’s Highly Available Key-value Store.（Dynamo: 亚马逊的高可用的关键价值存储）
–Google– The Chubby lock service for loosely-coupled distributed systems.（面向松散耦合的分布式系统的锁服务）
–Google– Bigtable: A Distributed Storage System for Structured Data.（Bigtable: 结构化数据的分布式存储系统）
–Google - MapReduce: Simplied Data Processing on Large Clusters.（MapReduce: 大型集群上简化数据处理）
- Google - The Google File System.（谷歌文件系统）
数据可视化
数据可视化之美
的数据可视化设计
冰桶挑战的数据可视化
用云栖社区APP，舒服~
【云栖快讯】Apache旗下顶级开源盛会 HBasecon Asia 2018将于8月17日在京举行，现场仅600席，免费赠票领取入口&&
快速、完全托管的TB/PB级数据仓库解决方案，向用户提供了完善的数据导入方案以及多种经典的分...
一种稳定、可靠、容量和服务能力可弹性伸缩的分布式关系型数据库服务。
提供海量、安全和高可靠的云存储服务。RESTful API的平台无关性，容量和处理能力的弹性...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效...
阿里云总监课正式启航