不同的业务对数据库有不同的要求
常用的 SQL 数据库比如 Oracle、MySQL、PostgreSQL、SQLite
SQL 和 NoSQL 是一个互补的关系，应用在不同的场景中。
OLAP (On-Line Analytical Processing)
OLTP 通常用传统的关系数据库，如果数据量大要分表，对事务性、一致性、完整性等要求不高的话也可以用 NoSQL
OLAP 通常用 NoSQL，数据量不大的话也可以用传统的关系数据库
Oracle：甲骨文开发的商业数据库，不开源，支持所有主流平台，性能好，功能强，稳定性好，安全性好，支持大数据量，比较复杂，收费昂贵。
SQL Server：微软开发的商业数据库，只能在 Windows 运行。
MySQL：甲骨文拥有的开源数据库，支持多种操作系统，体积小，功能弱些，简单的操作性能好，复杂的操作性能差些。 ** PostgreSQL**：使用 BSD 协议的完全开源免费的项目，支持多种操作系统，功能更强大，可以和多种开源工具配合。
SQLite：开源、轻型、无服务器、零配置，一个数据库就只是一个文件，在应用程序内执行操作，占用资源小，可用于嵌入式或小型应用。
Oracle 多用于银行等高要求的领域，要求不高的比如互联网行业多用 MySQL 和 PostgreSQL，而 SQLite 用于嵌入式或作为应用程序内的数据库使用，SQL Server 用于 Window 服务器。
组件比较多，比较重，适用于已有的 Hadoop 平台，适用于海量宽表数据、需要增删改查、OLTP 的场景
用于强化 HBase，主要作为 OLTP，查询性能要求不高的话也可作为 OLAP，多用于 HDP (HDP 有集成 Phoenix)
主要用于 OLTP，要求不高的话也可以作为 OLAP 使用，和 HBase 比需要的组件比较少，维护比较容易
通常作为高性能内存数据库、缓存、消息中间件等使用
memcached 比较简单，作为纯粹的 Key-Value 缓存性能会比 Redis 好些，但功能没有 Redis 强大
之所以说是文档数据库，是因为它的数据是以 JSON 文档的形式存储
MongoDB 的概念和很多数据库不一样，它的 collection 相当于表，document 相当于行，field 相当于列，比如：
这是一条插入语句，这里的 db 是指当前数据库，user 就是 collection 相当于表，insert 语句里面的 JSON 就是 document 相当于其他数据库的行，name，age，street 这些就是 field 相当于列
相同的文档可以插入多次而不会被覆盖，实际上 mongodb 会自动创建 _id 字段作为 primary key，并分配不同的数值，所以不会重复，也可以 insert 的时候指定 _id，但如果 _id 已经存在则会报错
mongodb 更适用于高度非结构化，或者源数据就是 JSON，每条数据比较大，以 OLTP 为主的场景，不适合于事务要求比较高，或比较复杂的大数据量的查询的场景，另外由于 mongodb 的语法和其他数据库差异比较大，需要一定的学习成本
和 Impala、Presto 类似都是并行内存计算，但 Greenplum 性能可能稍差一点点，并且 Greenplum 还分开源版和商业版，有的功能只有商业版才支持
传统 OLAP 根据数据存储方式的不同分为 ROLAP（Relational OLAP）以及 MOLAP（Multi-Dimension OLAP），ROLAP 以关系模型的方式存储数据，优点在于体积小，查询方式灵活，缺点是每次查询都需要对数据进行聚合计算，而 Kylin 属于 MOLAP
Kylin 将数据按维度的不同组合，提前计算好结果，形成 Cube (立方体) 结构，这样查询速度快，缺点是数据量不容易控制，N 个维度可以有 2**N 种组合，可能会出现维度爆炸的问题，而且数据有改动的话需要重新计算
比如有 Phone 和 Country 两张维度表，以及 Sale 事实表 (明细表)，取手机品牌、国家、日期作为三个维度，有 (null)、(品牌)、(国家)、(日期)、(品牌、国家)、(品牌、日期)、(国家、日期)、(品牌、国家、日期) 共 8 种组合，可以提前计算好这 8 种 group by 组合的 sale 的各种汇总信息 (sum、count 等)，一个维度组合的一个汇总信息称为一个 cuboid，所有的 cuboid 合起来就被称为一个 Cube
Kylin 的数据源可以是 Hive 或 Kafka (Json 格式消息，key 就是列名)
Kylin 的预计算结果存到 HBase，RowKey 就是各种维度的组合，相应的明细汇总存在 Column 中，这样 SQL 就变成对 RowKey 的扫描，并进一步的对 Column 计算 (如果需要的话)，这样查询性能自然就提升了，可以支持亚秒级查询
Kylin 支持 ODBC，JDBC，RESTful API 等接口
Kylin 可以和 Tableau、PowerBI 等 BI 工具集成
build Cube，实际是通过 MapReduce/Spark 计算，任务完成后结果会写入 HBase
build 成功后即可直接用 SQL 查询了，实际是根据维度查 RowKey，然后把 Column 存的聚合结果取出，如果必要的话再做进一步计算
如果数据源有改动，需要重新 build Cube
可以看到 Kylin 是一个纯粹的 OLAP 工具，通过预计算提升查询性能，但无法及时反应出数据源的改变，预计算可能很耗时并且可能会占用大量空间，且需要和 Hadoop 集成
基于预计算的 OLAP 数据查询引擎还有 Druid
俄罗斯企业 Yandex 开发的 OLAP 数据库
不依赖 Hadoop、列存储、向量化、并行、多线程、多存储引擎
单表查询性能极好，比 Impala、Presto 之类的要好很多
多表查询性能差些，比 Impala、Presto 之类的要差
适合于以搜索为主的业务场景，最开始 ELK (Elasticsearch + Logstash + Kibana) 就是用于日志收集和搜索
数据库虽然强大，但如果遇到复杂的逻辑计算也是无能为力，这种情况，就需要有专门的计算工具
Spark 和 Flink 都是高性能的并行计算引擎，Flink 更偏向实时流业务，Spark 更偏向批处理业务，都可以用来高效地处理数据
数据通常要可视化，比较常用的 BI 工具有 Tableau (收费的) 和 PowerBI
K8S (容器部署) + SpringCloud (微服务) + Keycloak (认证) + Kafka (数据流) + Spark/Flink (数据处理) + ELK (日志收集) + PG/MySQL (基本数据) + NoSQL-OLTP (大数据量业务数据) + OLAP (分析业务) + BI (数据可视化)
推荐阅读
如有错误或其它问题，欢迎小伙伴留言评论、指正。如有帮助，欢迎点赞+转发分享。更多相关开源技术文章，请持续关注：民工哥知乎技术专栏
