1.1. 列式数据库(Column-oriented Database)能压缩冗余数据，通常用于商务智能(BI)的应用

1.2. 权衡

1.2.1. 需要对很多行进行聚合计算时，面向列的存储组织方式会更加高效

1.2.1.1. 这只适用于处理少数列的情况，因为读取少数列比读取所有列的数据更快

1.2.2. 当一次向所有行更新某个列时，面向列的存储组织更加高效，因为可以不必访问行里的其他列就有效地写入数据，替换旧的列数据

1.2.3. 当同时需要获取一行中的许多列，并且行的体量相对较小，单次磁盘访问就能将整行数据检索时，面向行的存储组织更加高效

1.2.4. 如果写入一条新纪录时同时要提供所有的行数据，那么面向行的组织效率更高

1.2.4.1. 整个行的数据可以用单次磁盘操作写入

1.2.5. 面向行的存储布局非常适合于在线事务处理(OLTP)类的工作负载，此类负载的重点是交互式事务

1.2.6. 面向列的存储布局非常适合于在线分析处理(OLAP)类的工作负载

2.1. 空间数据库(Spatial Database)被优化用于存储和查询表示几何空间中定义的对象数据

2.2. 支持基本类型（简单的几何图形，如方框、矩形、立方体、圆柱体等）和由点、线和形状组合成的几何图形

2.3. 空间数据库使用索引进行快速查找

2.3.1. 空间数据库使用空间索引加快数据库操作

2.4. 空间评估(Spatial Measurements)

2.4.1. 计算线条长度、多边形面积、几何图形之间的距离等

2.5. 空间功能(Spatial Functions)

2.5.1. 修改现有特征以创建新特征

2.6. 空间预测(Spatial Predicate)

2.6.1. 允许对几何图形之间的空间关系进行真假查询

2.7. 几何构造(Geometry Constructors)

2.7.1. 通常通过描述所定义形状的顶点（点或节点）来创建新的几何图形

2.8. 观测功能(Observer Functions)

2.8.1. 查询并返回某个特征的特定信息

3.1. 多媒体数据库(Multi-media Database)包括一个分层存储管理系统，用于高效管理磁介质和光存储介质

3.2. 包括表示系统基础对象的集合

4.1. 平面文件数据库(Flat File Database)描述了将数据集编码为单个文件的各种方法

4.2. 平面文件不仅用作数据库管理系统的数据存储工具，还用作数据传送工具

4.3. Hadoop数据库使用平面文件做数据存储

5.1. 键值对数据库(Key-Value Pair Database)的数据项包含两个部分：键的标识符和值

5.2. 文档数据库(Document Databases)

5.2.1. 面向文档的数据库包含由结构和数据组成的文件集合

5.2.2. 每个文档都分配了一个键

5.2.3. 更高级的面向文档的数据库还可以存储文档内容的属性，如日期或标记

5.3. 图数据库(Graph Databases)

5.3.1. 图数据库存储关键值对，关注的重点是组成图的节点关系，而不是节点本身

6.1. 由主语、谓语和宾语组成的数据实体称为三元组存储(Triplestore)

6.2. 在资源描述框架(Resource Description Framework, RDF)术语中，三元组存储由表示资源的主语、表示资源和对象之间关系的谓语以及对象本身组成

6.3. 三元组存储是一个专门构建的数据库，用于以主-谓-宾表达式的形式存储和检索三元组

6.4. 最适合分类和同义词管理、链接数据集成和知识门户

6.5. 原生三元组存储(Native Triplestores)

6.5.1. 那些从零开始实现并利用RDF数据模型来高效地存储和访问RDF数据的三元组存储

6.6. RDBMS支持的三元组存储(RDBMS-backed Triplestores)

6.6.1. 在现有的RDBMS之上添加RDF描述层构建的三元组存储

6.7. NoSQL三元组存储(NoSQL Triplestores)

6.7.1. 正在被研究将来可能的RDF存储管理器

7.1. 专用数据库即使它们构建在传统关系数据库之上，它们的模式也是专有的，并且大部分情况下是隐藏的

7.2. 计算机辅助设计和制造(CAD/CAM)

7.2.1. 其程序和大多数嵌入式的实时应用程序一样，需要一个对象数据库

7.3. 地理信息系统(GIS)

7.3.1. 每年保持更新参考数据的地理空间信息专用数据库

7.3.2. 用于公用事业（电网、燃气等）、电信管理网或航海等领域

7.4. 购物车功能

7.4.1. 在大多数在线零售网站上都有采用，利用XML数据库暂时存储客户订购数据以及用于社交媒体数据库在其他网站上进行实时广告投放

8.1. 归档(Archiving)是将数据从可立即访问的存储介质迁移到查询性能较低的存储介质上的过程

8.2. 归档后的数据可以恢复到原系统，供短期使用

8.3. 不需要活跃地支持应用程序处理的数据，应迁移到价格较低的磁盘、磁带或CD/DVD光盘中进行归档

8.4. 从归档中恢复的过程简单来说是将归档文件中的数据复制回原系统

8.5. 归档过程必须与分区策略保持一致，以确保最佳的可用性和数据保留度

8.5.1. 创建一个辅助存储区域，优先建在辅助数据库服务器上

8.5.2. 将当前的数据库表分区成可以归档的单元

8.5.3. 将不经常使用的数据复制到单独的数据库

8.5.4. 创建磁带或磁盘备份

8.5.5. 创建数据库任务，定期清理不再使用的数据

8.6. 对归档进行定期恢复测试是明智做法，以确保在紧急事件发生时避免无法恢复的意外状况

8.7. 当归档数据不同步或不一致时

8.7.1. 确定是否保留历史归档或有多少历史归档需要保留

8.7.1.1. 不需要的历史归档可以清除

8.7.2. 对于重大技术调整，在调整前将归档恢复到原始系统、升级或迁移到新系统，并在新系统下重新归档数据

8.7.3. 对于源数据库结构发生更改的高价值归档数据，恢复归档，并对数据结构进行相应更改，用新结构重新归档

8.7.4. 对于相对低价值的低频访问归档，在源系统的技术或结构发生改变时，保持旧系统的小版本，供有限的数据访问，并根据需要用旧系统的数据格式从归档中抽取数据

8.8. 现有技术无法恢复的归档是糟糕的归档

8.8.1. 那些一定要用旧系统（老技术）来读取归档而其他方式无法读取归档，不管从效率或成本来看都是不合算的

9.1. 把数据库想象成一个盒子，把数据想象成水果，把管理成本（索引等）想象成包装材料

9.2. 确定盒子的容量是随着时间的推移保持不变，还是必须随着时间的推移而扩大，以便确定存放更多的水果

9.3. 增长预测(Growth Projection)

9.3.1. 如果盒子不能扩大，那么水果必须尽可能从盒子里快进快出，增长预测即为零

10.1. 变动数据捕获(Change Data Capture, CDC)是指检测到数据的变动并确保与变动相关的信息被适当记录的过程

10.2. CDC通常指的是基于日志的复制，是一种非侵入性方法，将数据更改复制到目标端而不影响源端

10.3. 数据版本控制-评估标识已改动过行的列

10.4. 通过读取日志(Logs)

10.4.1. 日志里记录了变化，并能将变化复制到辅助系统中

11.1. 如果所有数据都要永远保存在主要存储中，那么最终数据会填满所有的可用空间，从而使性能开始下降

11.1.1. 需要将数据存档、清除，或者两样都要做

11.1.2. 有些数据的价值会降低，不值得继续保留

11.2. 清除(Purging)是指从存储介质中彻底删除数据并让它无法恢复的过程

11.3. 数据管理的主要目标是维护数据的成本不应超过其对组织的价值

11.3.1. 清除数据可以降低成本和风险

11.4. 要清除的数据即使从监管的角度来看也是被认定是过时的和不必要的

11.4.1. 某些数据如果超过保存的必要时间，就会成为负担

11.4.2. 清除这些数据还可以降低它被滥用的风险

12.1. 数据复制(Replication)意味着多个存储设备上存放着相同的数据

12.2. 在某些情况下，拥有重复的数据库很有用

12.3. 主动复制(Active Replication)

12.3.1. 不存在主副本，可以在每个副本上主动创建和存储来自其他副本的相同数据

12.4. 被动复制(Passive Replication)

12.4.1. 首先在主副本上创建和存储数据，然后把更改的状态传送到其他副本上

12.5. 扩展方式

12.5.1. 水平数据扩展

12.5.1.1. 拥有更多的数据副本

12.5.2. 垂直数据扩展

12.5.2.1. 将数据副本放到距离更远的不同地理位置上

12.6. 复制方式

12.6.1. 镜像(Mirroring)

12.6.1.1. 作为两阶段提交过程的一个部分，在主库的更新会立即（相对而言）同步给辅助数据库

12.6.1.2. 镜像方式通常比日志传送方式成本更高

12.6.1.3. 镜像方式通常对一台辅助服务器是有效的，日志传送方式可以用来更新数据到更多的辅助服务器

12.6.2. 日志传送(Log Shipping)

12.6.2.1. 辅助数据库定时接收并应用从主数据库传来的事务日志副本

13.1. 数据库韧性(Resiliency)是衡量系统对错误条件容忍度的指标

13.2. 如果一个系统能够容忍高级别的处理错误，并且仍能像预期的那样工作，那么它就具有很强的韧性

13.3. 如果应用程序一碰到意外条件就崩溃，那么系统就没有韧性

13.4. 如果数据库可以检测异常，并提前终止或从通用的错误处理办法（如失控查询）中自动恢复，则认为它具有韧性

13.5. 恢复类型

13.5.1. 立即恢复(Immediate Recovery)

13.5.1.1. 有些问题有时需要通过设计来解决的

13.5.1.2. 可以通过预判并自动解决问题，切换到备用系统

13.5.2. 关键恢复(Critical Recovery)

13.5.2.1. 指尽快恢复以尽量减少业务延迟或业务中断的恢复计划

13.5.3. 非关键恢复(Non-critical Recovery)

13.5.3.1. 指该类业务可以延迟恢复，直到更关键的系统恢复完毕

13.6. 提高数据处理系统恢复能力的常见方法是：捕获并重新输入导致错误的数据，检测并忽略导致错误的数据

13.7. 对于非常关键的数据，DBA需要执行一种复制机制，把数据移动到远端服务器上的另一个数据库副本

14.1. 数据保留(Retention)是指数据保持可用的时间

14.2. 数据保留规划应该是物理数据库设计的一部分

14.2.1. 数据保留需求也会影响容量规划

15.1. 分片(Sharding)是一个把数据库中的一部分独立出来的过程

15.2. 因为分片的复制只是一个很小的文件，所以分片可以独立于其他分片进行更新