前言

Github：https://github.com/HealerJean

博客：http://blog.healerjean.com

一、数据库

1、关系型数据库

1）什么是（SQL）关系型数据库：

关系型数据库指的是使用关系模型（二维表格模型）来组织数据的数据库， 关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系（如主键和外键）进行连接。

常见的有：Oracle，MySql，Microsoft SQL Server，SQLite，PostgreSQL

2）优势

1、数据结构清晰，易于理解和维护。

2、 数据一致性和完整性高，通过 ACID 事务保证数据的一致性；

3、支持复杂查询，通过 SQL 语言可以方便地进行多表联合查询；

3）不足

随着互联网企业的不断发展，数据日益增多，因此关系型数据库面对海量的数据会存在很多的不足。

1、数据读写性能有限，特别是在处理大规模高并发数据时。。

2、扩展性相对较差，不易应对快速变化的数据模型。

3、 固定的数据结构可能导致灵活性不足，关系型数据库的数据模型定义严格，无法快速容纳新的数据类型（需要提前知道需要存储什么样类型的数据）

4）代表

Oracle：大型关系数据库管理系统，提供企业级的数据管理解决方案。

MySQL：开源的关系型数据库，广泛应用于各种Web应用中。

SQL Server：微软开发的关系数据库管理系统，提供丰富的功能和强大的性能。

2、非关系型数据库

1）什么是（NOSQL）非关系型数据库：

非关系型数据库（NoSQL）泛指非关系型的、分布式的、且一般不保证遵循 ACID 特性的数据存储系统。它不基于关系模型，而是基于键值对、文档、图形或列式存储等方式。

非关系型数据库又被称为 NoSQL（Not Only SQL )，意为不仅仅是 SQL。通常指数据以对象的形式存储在数据库中，而对象之间的关系通过每个对象自身的属性来决定，常用于存储非结构化的数据。

非关系型数据库存储数据的格式可以是 key- value 形式、文档形式、图片形式等。使用灵活，应用场景广泛，而关系型数据库则只支持基础类型。

2）优势

1、 高并发读写性能，适用于大规模数据处理。

2、 海量数据的维护和处理非常轻松，成本低。

3、数据结构灵活，无需预定义表结构。

4、水平扩展性好，易于构建分布式系统。

3）不足

1、不同的非关系型数据库之间差异较大，选择时需要考虑具体需求。

1、非关系数据库没有事务处理，无法保证数据的完整性和安全性。适合处理海量数据，但是不一定安全。

3、缺乏统一的查询语言，查询和处理的复杂度可能增加。

4）代表

1、键值数据库-Redis：内存数据结构存储，可以用作数据库、缓存和消息中间件

2、列族数据库-**HBase **基于列存储的分布式数据库，适用于大规模的结构化数据存储

3、文档数据库- MongoDB 基于文档的 NoSQL 数据库，支持动态模式，适用于快速变化的数据模型

4、 图形数据库：Neo4j、InfoGrid

二、OLTP、OLAP

OLTP·（联机事务处理）应用的场景，其存储的主要是与业务直接相关的数据，强调准确、低时延、高并发，如果没有特别强调，基本上数据库里只会去存储与业务相关的数据。

OLAP（联机分析处理）是数据仓库系统的主要应用，其支持的对象只要是面向分析场景的应用，提供结构化的、主题化的数据提供给运营，做业务反馈和辅助决策用，同时，有些场景下，也可以由数据仓库对业务进行支持。

	OLTP （联机事务处理）	OLAP（联机分析处理）
使用场景	在线业务服务	数据分析、挖掘、机器学习
涉及数据量	当前正在发生的业务数据	历史存档数据
事务和数据完整性	对事务和数据一致性要求高	对实物能力没有要求，数据不一致也可以重建
功能使用需求	简单增删改查，要求相应时间极短	复杂的聚合和多数据源关联，查询时间可到分钟，小时，天
并发要求	高并发	低并发
实现方案	事务、索引、存储计算耦合	大量 SCAN、列式存储，存储计算可以分离
可用性要求	非常高	不高
技术典范	MYSQL	Clickhouse
数据结构	关系数据库。	使用多维（多维数据集）或关系数据库。

1、理解篇

1）场景

场景：跟开发沟通需求时，可能会听到“这个（数据）数据库没存，取不到……”、“我这边没这张表，去找业务的人要……”、“这个（数据）在日志里，要的话提个需求给我……”、“我们两边存储的逻辑不一样，数据结果当然不一样啊”、如果你也碰到过这种情况，这节内容对你有用。这节内容将围绕数据从产生-入库-分析环节，数据库和数据仓库的区别和作用。

产品的使用者在前端做交互会产生各种行为数据，略作区分的话，可以分为行为数据，和业务数据。

⬤ 行为数据是指用户的点击、浏览等操作数据；

⬤ 业务数据本质上也是行为数据，能被叫作业务数据，是因为与产品的业务目标挂钩。如用户的注册行为、订单行为（也是需要与服务端做交互产生的数据）。

为了保证对业务的快速响应和支持，针对产品和业务功能有一个直接的数据库与之进行交互，OLTP是与功能、业务强相关的事务查询系统，要保证高并发场景下低时延的查询和处理效率，因此对 CPU 的性能要求较高。而直接存储与功能和业务直接相关的地方，就叫数据库，一般是服务端开发的同事来负责。

​

数据库主要为在线业务服务。如果是分析场景需要查询数据，涉及到从业务数据库取数据，就意味着会影响业务数据库对业务的支持。量小还好，量大或者查询比较复杂，服务端的同事就会担心影响到线上业务，或者把业务数据库查“崩”了影响线上业务，因此非常 nice地拒绝你的需求。

企业在经过初期的市场验证阶段后，会开始寻求从数据中找到下一步发展的方向，直接从业务数据库获取数据限制颇多，因此这时候就需要搭建数据仓库体系了。

​

数据仓库是独立于业务数据库之外的一套数据存储体系，OLAP 是数据仓库系统的主要应用，能够支持复杂的分析操作，与数据库需要直接直接线上业务不同，数据仓库侧重于分析决策，提供直观的数据查询结果。（当然数据仓库也是可以支持线上业务的，比如电商场景下常见的，根据用户行为做商品推荐。用户的行为数据存进数仓后，进行实时计算，然后将算法模型计算出的推荐结果发给业务端做展示。）。

在企业初期阶段，全部数据存储、业务应用支持和分析支持都是交给业务数据库来做。相比于对分析应用的支持，数据库肯定会先确保对前端业务的支持。因此在响应分析场景的需求时，速率和数据完整度往往不尽如人意。

2）过程

Q1、这个（数据）数据库没存，取不到……：

答:如果行为数据没有与业务直接关联，而且产品经理也没有要求记录，开发们大概率是不会做对应的数据采集的，所以有了上面回答。这时候要拿小本本记一下，告诉开发gg：“谢谢gg，下次我就提这个数据的采集需求！”

Q2. “我这边没这张表，去找业务的人要……”：

答：如果你们已经有了数据仓库，和 BI 应用的话，开发那边大概率会拆分一组叫【大数据】的人，他们主要负责数据仓库的建设和 B I数据产品的支持。但有的数据存在了业务数据库，没有同步到数据仓库时，你去问大数据同事要数据的时候，他们就会这样温柔地回应你。

Q3. “这个（数据）在日志里，要的话提个需求给我……”：

答：只要用户与服务端有交互（如发起了订单、注册成功等行为），业务数据库基本会将其全部记录下来，是一条条的明细数据。所以如果你提的需求恰好有，在日志里，他们需要从日志里“捞”出对应的数据，然后清洗计算之后，才能把数据拿出来，因此需要你提一个需求，要不然主管又要问他今天干啥了。

注：需注意，明细日志一般不会永久保留，过一段时间后，已经没有依赖这些数据的应用时，这些数据就会被删掉，保留时长不同公司不一样，所以上述场景发生在数据还在的前提下。

2、OLAP

OnLine Analytical Processing：联机分析处理

olap是传统的关系型数据库的主要应用，主要基本的、日常的事务处理，例如银行交易。目前市面上主流的开源 olap数据库引擎包含：Hive、Hawq、Presto、Kylin、Impala、Sparksql、Druid、Clickhouse、Greeplum等。

1）多维 OLAP ( Multi-dimensional OLAP )

多维 OLAP 基于直接支持多维数据和操作的本机逻辑模型。数据物理上存储在多维数组中, 并且使用定位技术来访问它们。。

这种方式可以快速地响应用户的多维分析请求，提供高效的查询和分析性能，MOLAP 一般会根据用户定义的数据维度、度量（也可以叫指标）在数据写入时生成预聚合数据；Query 查询到来时，实际上查询的是预聚合的数据而不是原始明细数据，在查询模式相对固定的场景中，这种优化提速很明显。

MOLAP 的优点和缺点都来自于其数据预处理 ( pre-processing ) 环节。数据预处理，将原始数据按照指定的计算规则预先做聚合计算，这样避免了查询过程中出现大量的即使计算，提升了查询性能。

但是这样的预聚合处理，需要预先定义维度，会限制后期数据查询的灵活性；

如果查询工作涉及新的指标，需要重新增加预处理流程，损失了灵活度，存储成本也很高。同时，这种方式不支持明细数据的查询，仅适用于聚合型查询（如：sum，avg，count）。

使用场景：多维 OLAP 主要适用于需要对数据进行多维分析的场景，如市场分析、销售分析等。在这些场景中，用户可以通过多维度的视角，深入剖析数据，挖掘潜在的业务价值。

优点： 多维 OLAP 的优点在于其查询和分析性能高，可以支持复杂的多维分析操作。

缺点：由于数据存储在多维数组中，可能会占用较多的存储空间。此外，对于非预定义的多维分析需求，可能需要重新构建多维数组，增加了操作的复杂性。

代表：主要有 Druid 和 Kylin 。这些系统都是基于直接支持多维数据和操作的本机逻辑模型，它们在数据写入时生成预聚合数据，从而在查询时提高查询速度，尤其在查询模式相对固定的场景中，这种优化提速效果尤为明显。

2）关系型 OLAP (Relational OLAP)

关系型 OLA P的实现通常依赖于关系型数据库管理系统（RDBMS）和相关的 OLAP 工具。这些工具可以提供从关系型数据到多维数据模型的转换功能，并支持多维分析查询。

关系型 OLAP 以关系型数据库为核心，通过关系型结构进行多维数据的表示和存储。它利用关系型数据库的查询优化和索引技术，来提高 OLAP查询的性能

使用场景：关系型 OLAP 主要适用于那些已经使用关系型数据库存储数据的场景。它可以将关系型数据库中的数据转化为多维数据模型，从而进行多维分析。适用于对查询模式不固定、查询灵活性要求高的场景。如数据分析师常用的数据分析类产品，他们往往会对数据做各种预先不能确定的分析，所以需要更高的查询灵活性

优点：关系型 OLAP 的优点在于可以利用现有的关系型数据库基础设施和查询优化技术，ROLAP 不需要进行数据预处理 ( pre-processing )，因此查询灵活，可扩展性好

缺点：由于其基于关系型数据库，可能不如多维 OLAP 那样高效地支持复杂的多维分析操作。关系型 OLAP 可能需要更多的转换和映射工作，以便将关系型数据转化为多维数据模型。当数据量较大或 query 较为复杂时，查询性能也无法像 MOLAP 那样稳定。所有计算都是即时触发 ( 没有预处理 )，因此会耗费更多的计算资源，带来潜在的重复计算

3）混合 OLAP (Hybrid OLAP)

混合 OLAP，是 MOLAP 和 ROLAP 的一种融合。它旨在平衡数据处理的灵活性和查询性能，以满足复杂的数据分析需求。当查询聚合性数据的时候，使用 MOLAP 技术；当查询明细数据时，使用 ROLA 技术。在给定使用场景的前提下，以达到查询性能的最优化。混合 OLAP的技术体系架构如下图：

使用场景：混合 OLAP适用于那些既需要高效的多维分析性能，又希望利用关系型数据库的优势的场景。它结合了多维 OLAP 和关系型OLAP 的特点，提供了更加灵活和高效的数据分析解决方案。

优点：

⬤ 性能与灵活性的平衡：混合 OLAP 结合了 ROLAP 和 MOLAP 的优势，既提供了较高的查询性能，又保持了数据的灵活性。

⬤ 适应性强：混合 OLAP 能够处理不同规模和复杂度的数据集，适应不同的分析需求。

⬤ 易于扩展：混合 OLAP 解决方案通常具有较好的扩展性，可以随着数据量的增长和分析需求的变化进行扩展。

缺点：混合 OLAP 的劣势恰恰在于其由于集成了 MOLAP 和 ROLAP，因此需要同时支持 MOLAP 和 ROLAP，并且本身的体系结构也非常复杂。。

三、全局概览

数据库	类型	优点	缺点	主键问题	使用场景	实现原理	是否关系型数据库	OLAP/OLTP
HBase	存储	高可靠性和高扩展性 - 适合海量数据存储和读写访问	不支持复杂查询 - 不适合需要事务支持的场景	HBase的行键是唯一的，可以用作主键。	适用于海量数据的实时读写访问	基于 HDFS，列式存储，支持水平扩展	否	OLAP
Elasticsearch	工具/存储	高性能全文搜索和分析功能 - 实时索引和搜索数据	不适合高事务性应用 - 对于大规模数据的聚合计算性能较差	Elasticsearch本身没有原生唯一主键的概念，但可以通过文档ID或文档内的某个字段来保证唯一性。	适用于全文搜索、日志分析、实时监控等场景	基于Apache Lucene的分布式搜索引擎	否	OLAP
ClickHouse	存储	高性能的列式存储和并行查询 - 良好的压缩率和吞吐量	不支持事务和复杂的更新操作 - 不适合实时数据写入	ClickHouse没有原生唯一主键的概念，通常通过表结构或应用层逻辑来确保数据的唯一性。	适用于大规模数据分析和OLAP场景。海量数据处理，复杂查询，实时分析	列式存储、MPP架构	否	OLAP
MySQL	存储	成熟稳定,支持事务处理 - 社区庞大,有丰富的工具和文档资源	读写性能不如一些新型数据库 - 不适合大规模数据分析	MySQL 支持唯一主键，可以通过创建唯一索引来确保字段值的唯一性。	适用于事务处理、关系型数据存储等场景	关系型数据库管理系统	是	OLTP
TiDB	存储	支持水平扩展,高可用性和一致性事务 - 兼容MySQL协议,易于迁移	相比传统数据库,性能仍有提升空间 - 较大规模部署需要更多资源	TiDB 也支持唯一主键，与 MySQL 类似。	适用于在线事务处理和实时分析	分布式NewSQL数据库	是	OLAP/OLTP
MongoDB	存储	高可扩展性和灵活的数据模型 - 适合文档型数据存储	不支持事务处理 - 对复杂查询支持不如关系型数据库好	MongoDB 没有原生唯一主键的概念，但可以通过创建唯一索引来确保文档内某个字段的唯一性。	适用于大规模文档存储、实时分析等场景	面向文档的NoSQL数据库	否	OLTP
Redis	存储	高速读写访问,支持丰富的数据结构操作	数据持久化方案相对简单 - 不适合大规模数据存储	Redis本身没有原生唯一主键的概念，其唯一性通常通过数据结构（如哈希、集合）或应用层逻辑来保证。	适用于缓存、会话管理、消息队列等场景	键值存储，内存数据库，持久化可选	否	OLTP
Druid	存储	高性能实时查询和快速聚合分析 - 支持复杂的多维度聚合查询	部署和维护相对复杂 - 不适合事务处理	Druid 也没有原生唯一主键的概念，通常需要在数据导入或处理阶段通过数据模型或应用层逻辑来保证数据的唯一性。	适用于实时OLAP 分析和数据探索	列式存储，分布式，实时分析	否	OLAP