1.1. 数据库管理系统
1.1.1. 用于存储和提供数据的数据库系统
1.1.2. 简称DBMS，它由存储引擎、查询优化器、灾难恢复和其他管理数据库系统的关键组件组成
1.1.2.1. 查询
1.1.2.2. 查询优化器
1.1.2.3. 扩展和分发
1.1.2.4. 模型
1.1.2.5. CRUD
1.1.2.6. 一致性
1.2. 关系数据库
1.2.1. 最常见的应用程序后端之一
1.2.2. 表通常由主键索引，主键是表中每一行的唯一字段
1.2.2.1. 主键的索引策略与表在磁盘上的布局密切相关
1.2.3. RDBMS系统通常是ACID兼容的
1.2.4. 将规范化模式、ACID兼容和对高事务率的支持相结合，使关系数据库系统成为有快速存储变化的应用程序的理想选择
1.3. NoSQL
1.3.1. 非关系数据库
1.3.1.1. NoSQL，代表不仅是SQL，还指全部放弃关系范式的数据库
1.3.1.2. 删除关系约束可以提高性能、可扩展性和模式的灵活性
1.3.1.3. NoSQL一词于1998年首次出现，但现代版本是由Eric Evans在21世纪00年代创造的
1.3.2. 键值存储
1.3.2.1. 键值数据库是一种非关系数据库，它使用唯一标识每条记录的键来检索记录
1.3.2.2. 类似于许多编程语言中提供的哈希映射或字典数据结构，但具有潜在的可扩展性
1.3.2.3. 内存中的键值数据库常用于Web和移动应用程序的缓存对话数据存储
1.3.2.4. 键值存储也可以服务于需要高持久化的应用
1.3.3. 文档存储
1.3.3.1. 文档存储是一种专门的键值存储
1.3.3.2. 文档是一个嵌套对象
1.3.3.3. 将每个文档视为一个JSON对象
1.3.3.3.1. 所有关系数据都可以存储在同一个文档中
1.3.3.4. 文档存储在集合中并通过键值检索
1.3.3.4.1. 集合大致相当于关系数据库中的表
1.3.3.5. 关系数据库和文档存储之间的一个主要区别是后者不支持连接
1.3.3.5.1. 意味着数据不能轻易规范化，即拆分到多个表中
1.3.3.6. 文档存储通常不符合ACID，这与关系数据库不同
1.3.3.7. 文档数据库通常包含JSON的所有灵活性，并且不强制要求模式或类型
1.3.3.7.1. 模式具有高度的灵活性和表现力，还可以随着应用程序的增加而发展
1.3.3.7.2. 文档数据库成为管理和查询的噩梦
1.3.3.8. 要对文档存储进行分析，工程师通常必须运行全面扫描以从集合中获取所有数据，或采用CDC策略将事件发送到目标流
1.3.3.8.1. 全扫描方法可能对性能和成本都有影响
1.3.3.8.2. 扫描通常会减慢数据库的运行速度，而且许多无服务器云产品对每次全面扫描都收取高额费用
1.3.4. 宽列数据库
1.3.4.1. 宽列数据库针对存储大量数据进行了优化，具有高事务率和极低的延迟
1.3.4.2. 宽列数据库可以支持PB级数据、每秒数百万次请求和低于10毫秒的延迟
1.3.4.3. 在电子商务、金融科技、广告技术、物联网和实时个性化应用程序中广受欢迎
1.3.4.4. 数据工程师必须了解他们所使用的宽列数据库的操作特征，以设置合适的配置、设计架构并选择合适的行键来优化性能并避免常见的操作问题
1.3.5. 图数据库
1.3.5.1. 图数据库以数学图形结构（作为节点和边的集合）来存储数据
1.3.5.2. Neo4j已经被证明是非常受欢迎的
1.3.5.3. 数据结构允许基于元素之间的连接性进行查询
1.3.5.4. 根据底层图数据库引擎，图数据库利用专门的查询语言
1.3.5.4.1. SPARQL、资源描述框架(Resource Description Framework，RDF)、图形查询语言(Graph Query Language，GQL)和Cypher
1.3.5.5. 图数据可以重新编码为关系数据库中的行，这可能是一个合适的解决方案，具体取决于分析用例
1.3.5.5.1. 交易型图数据库也是为分析而设计的，但大型查询可能会使生产系统过载
1.3.5.5.2. 当代基于云的图数据库支持对大量数据的重读和图形分析
1.3.5.6. 将源系统的图数据映射到现有的一个首选范式中去
1.3.5.7. 在源系统本身中分析图数据
1.3.5.8. 采用特定于图的分析工具
1.3.6. 搜索数据库
1.3.6.1. 搜索数据库是一个非关系数据库，用于探测你的数据的复杂度和直接的语义和结构特征
1.3.6.2. 搜索数据库有两个突出的用例：文本搜索和日志分析
1.3.6.3. 文本搜索包括在文本体中搜索关键词或短语，对精确、模糊或语义相似的进行匹配
1.3.6.3.1. 日志分析通常用于异常检测、实时监控、安全分析和运营分析
1.3.7. 时间序列
1.3.7.1. 一个时间序列是由时间组成的一系列数值
1.3.7.1.1. 股票价格可能随着一天中交易的进行而变化
1.3.7.1.2. 一个天气传感器每分钟都会测量大气温度
1.3.7.2. 任何定期或零星记录的事件都是时间序列数据
1.3.7.3. 时间序列数据库是为时间序列数据的检索和统计流程而优化的
1.3.7.4. 时间序列数据库解决了来自物联网、事件和应用程序日志、广告技术和金融科技以及其他许多用例的不断高速增长的数据量的需求
1.3.7.5. 时间序列数据库经常利用内存缓冲来支持快速写入和读取
1.3.7.6. 区分测量数据和基于事件的数据，它们在时间序列数据库中很常见
1.3.7.6.1. 测量数据是定期产生的，比如温度或空气质量传感器
1.3.7.6.2. 基于事件的数据是不规则的，每次事件发生时都会创建，例如，当运动传感器检测到运动时
1.3.7.7. 时间序列的模式通常包含一个时间戳和一组小字段
1.3.7.7.1. 数据是随时间变化的，所以数据是按时间戳排序的
1.3.7.7.2. 这使得时间序列数据库适用于操作分析，但不适合BI用例
2. API2.1. API现在是在云中、SaaS平台以及公司内部系统之间交换数据的一种标准且普遍的方式
2.2. 许多类型的API存在于网络中，但我们主要感兴趣的是围绕HTTP构建的接口，HTTP是网络和云中最流行的类型
2.3. API只是内部的一个简单包装，提供保护系统不受用户请求影响所需的最低功能
2.4. REST
2.4.1. 目前主流的API范式
2.4.2. REST是描述性状态迁移的意思
2.4.3. 构建HTTP网络的API实践和理念由Roy Fielding在2000年的博士论文中提出
2.4.4. REST是围绕HTTP动词建立的，比如GET和PUT
2.4.5. 主要观点之一是互动是无状态的
2.4.5.1. 每个REST调用都是独立的
2.4.5.2. REST调用可以改变系统的状态，但这些改变是全局的，适用于整个系统而不是当前的会话
2.4.6. 数据提供商经常提供各种语言的客户端库，特别是Python语言
2.4.7. 各种服务和开源库已经出现，以API互动并管理数据同步
2.5. GraphQL
2.5.1. GraphQL是在Facebook创建的，作为应用数据的查询语言，并代替通用REST API
2.5.2. GraphQL则提供了在单个请求中检索多个数据模型的可能性
2.6. Webhook
2.6.1. Webhook是一种简单的基于事件的数据传输模式
2.6.2. 数据源可以是一个应用程序的后端，一个网页，或一个移动应用程序
2.6.3. 当指定的事件在源系统中发生时，将触发对数据消费者托管的HTTP端点的调用
2.6.4. webhook经常被称为反向API
2.7. RPC和gRPC
2.7.1. 远程过程调用(Remote Procedure Call，RPC)通常用于分布式计算
2.7.1.1. 允许你在一个远程系统上调用一个程序
2.7.2. gRPC是2015年在谷歌内部开发的一个远程过程调用库，后来作为一个开放标准发布
2.7.2.1. gRPC是围绕协议缓冲区开放数据序列化标准建立的，也是由谷歌开发的
2.7.2.2. gRPC强调通过HTTP/2进行有效的双向数据交换
2.7.2.3. 效率指的是诸如CPU利用率、功耗、电池寿命和带宽等方面
2.7.2.4. gRPC规定了比REST更具体的技术标准
2.7.2.5. gRPC允许使用常见的客户端库，并允许工程师开发适用于各种gRPC交互代码的技能集
