1. 列式数据库
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. 空间数据库
2.1. 空间数据库(Spatial Database)被优化用于存储和查询表示多少空间中定义的对象数据
2.2. 支持根本范例（简单的多少图形，如方框、矩形、立方体、圆柱体等）和由点、线和形状组合成的多少图形
2.3. 空间数据库使用索引进行快速查找
- 2.3.1. 空间数据库使用空间索引加快数据库操作
2.4. 空间评估(Spatial Measurements)
- 2.4.1. 计算线条长度、多边形面积、多少图形之间的距离等
2.5. 空间功能(Spatial Functions)
2.6. 空间预测(Spatial Predicate)
- 2.6.1. 允许对多少图形之间的空间关系进行真假查询
2.7. 多少构造(Geometry Constructors)
- 2.7.1. 通常通过形貌所定义形状的顶点（点或节点）来创建新的多少图形
2.8. 观测功能(Observer Functions)
3. 对象/多媒体数据库
3.1. 多媒体数据库(Multi-media Database)包括一个分层存储管理系统，用于高效管理磁介质和光存储介质
3.2. 包括表示系统基础对象的集合
4. 平面文件数据库
4.1. 平面文件数据库(Flat File Database)形貌了将数据集编码为单个文件的各种方法
4.2. 平面文件不仅用作数据库管理系统的数据存储工具，还用作数据传送工具
4.3. Hadoop数据库使用平面文件做数据存储
5. 键值对数据库
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. 三元组存储
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. 专用数据库
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. 数据归档
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.2. 对于庞大技术调整，在调整前将归档恢复到原始系统、升级或迁移到新系统，并在新系统下重新归档数据
- 8.7.3. 对于源数据库结构发生更改的高代价归档数据，恢复归档，并对数据结构进行相应更改，用新结构重新归档
- 8.7.4. 对于相对低代价的低频访问归档，在源系统的技术或结构发生改变时，保持旧系统的小版本，供有限的数据访问，并根据需要用旧系统的数据格式从归档中抽取数据
8.8. 现有技术无法恢复的归档是糟糕的归档
- 8.8.1. 那些肯定要用旧系统（老技术）来读取归档而其他方式无法读取归档，不管从服从或成原来看都是不合算的
9. 容量和增长预测
9.1. 把数据库想象成一个盒子，把数据想象成水果，把管理成本（索引等）想象成包装材料
9.2. 确定盒子的容量是随着时间的推移保持不变，还是必须随着时间的推移而扩大，以便确定存放更多的水果
9.3. 增长预测(Growth Projection)
- 9.3.1. 如果盒子不能扩大，那么水果必须尽可能从盒子里快进快出，增长预测即为零
10. 变动数据捕获
10.1. 变动数据捕获(Change Data Capture, CDC)是指检测到数据的变动并确保与变动相关的信息被适当记载的过程
10.2. CDC通常指的是基于日志的复制，是一种非侵入性方法，将数据更改复制到目标端而不影响源端
10.3. 数据版本控制-评估标识已改动过行的列
10.4. 通过读取日志(Logs)
- 10.4.1. 日志里记载了变化，并能将变化复制到辅助系统中
11. 数据清除
11.1. 如果所有数据都要永远保存在主要存储中，那么终极数据会填满所有的可用空间，从而使性能开始下降
- 11.1.1. 需要将数据存档、清除，大概两样都要做
- 11.1.2. 有些数据的代价会降低，不值得继续保存
11.2. 清除(Purging)是指从存储介质中彻底删除数据并让它无法恢复的过程
11.3. 数据管理的主要目标是维护数据的成本不应凌驾其对组织的代价
11.4. 要清除的数据即使从监管的角度来看也是被认定是过时的和不必要的
- 11.4.1. 某些数据如果凌驾保存的必要时间，就会成为负担
- 11.4.2. 清除这些数据还可以降低它被滥用的风险
12. 数据复制
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.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. 韧性与恢复
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. 数据保存
14.1. 数据保存(Retention)是指数据保持可用的时间
14.2. 数据保存规划应该是物理数据库设计的一部分
15. 数据分片
15.1. 分片(Sharding)是一个把数据库中的一部分独立出来的过程
15.2. 因为分片的复制只是一个很小的文件，以是分片可以独立于其他分片进行更新
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。 |
