IT评测·应用市场-qidao123.com

标题: 读DAMA数据管理知识体系指南14数据库情况 [打印本页]

---

作者: 祗疼妳一个    时间: 2025-3-9 09:16
标题: 读DAMA数据管理知识体系指南14数据库情况

1. ACID

1.1. 缩写词ACID是在20世纪80年代末期出现的一个合成词，含义是保证数据库事务可靠性不可或缺的束缚
1.2. 原子性(Atomicity)

• 1.2.1. 全部操纵要么都完成，要么一个也不完成
  
• 1.2.2. 如果事务中的某部分失败，那么整个事务就都会失败
  

1.3. 同等性(Consistency)

• 1.3.1. 事务必须时候完全符合系统定义的规则，未完成的事务必须回退
  

1.4. 隔离性(Isolation)

• 1.4.1. 每个事务都是独立的
  

1.5. 持久性(Durability)

• 1.5.1. 事务一旦完成，就不可撤销
  

2. BASE

2.1. 通常在大数据情况里会使用BASE类型的系统，如大型互联网公司和社交媒体公司

• 2.1.1. 它们的业务场景任何时候都不必要立即准确地拿到全部数据
  

2.2. 基本可用(Basically Available)

• 2.2.1. 即使节点发生故障，系统仍然能保证肯定级别数据的可用性
  
• 2.2.2. 数据可能过时，但系统仍然会给出响应
  

2.3. 软状态(Soft State)

• 2.3.1. 数据处于持续活动的状态，当给出响应时，数据不保证是最新的
  

2.4. 最终同等性(Eventual Consistency)

• 2.4.1. 数据在全部节点、全部数据库上最终状态是同等的，但并非每时每刻在每个事务里都是同等的
  

3. CAP

3.1. CAP定理（也称为“布鲁尔定理”​）是会合式系统在朝着分布式的系统方向发展过程中提出的理论

• 3.1.1. CAP定理指的是分布式系统不可能同时满意ACID的全部要求
  
• 3.1.2. 系统规模越大，满意的要求点越少
  

3.2. 同等性(Consistency)

• 3.2.1. 系统必须总是按照计划和预期的方式运行
  

3.3. 可用性(Availability)

• 3.3.1. 请求发生时系统时候都保持可用状态，并对请求作出响应
  

3.4. 分区容错(Partition Tolerance)

• 3.4.1. 偶尔发生数据丢失或者部分系统故障发生时，系统依然可以或许继续运行提供服务
  

3.5. 3项要求最多只可能同时满意此中两项
3.6. Lambda架构是通过两种路径方式来使用数据

• 3.6.1. 当可用性和分区容错更紧张时采用Speed路径（效率优先）​
  
• 3.6.2. 当同等性和可用性更紧张时采用Batch路径
  

4. 数据存储介质

4.1. 数据能存放到各种介质里

• 4.1.1. 最常见的用法是磁盘和存储区域网络(Storage Area Networks, SAN)、内存和列压缩办理方案、虚拟存储区域网络(Virtual SAN, VSAN)、基于云的存储办理方案、射频辨认技术(Radio Frequency Identification, RFID)、数字钱包、数据中央和私有云、公有云及混合云存储
  

4.2. 磁盘和存储区域网络(SAN)

• 4.2.1. 磁盘存储是一种非常稳固的存储永久数据的方法
  
• 4.2.2. 同一个系统里，可以用多种不同类型的磁盘
  
• 4.2.3. 可根据数据访问频率的不同，采用不同的存储介质
  
• 4.2.4. 访问频率较低的数据，得当存储在比高性能磁盘系统更廉价的慢速磁盘上
  
• 4.2.5. 磁盘阵列可以组成SAN
  
  
  
  • 4.2.5.1. SAN内的数据可以直接通过背板上的光口或电口移动，不必要通过网络
    
  
  

4.3. 内存

• 4.3.1. 每当系统启动时，内存数据库(In-Memory Database, IMDB)从永久存储中将数据加载到内存中，全部的数据处理都在内存中完成
  
• 4.3.2. 如果能将应用相关的大部分或者全部数据加载到内存中，那么使用内存数据库将会获得显著的性能提升
  
• 4.3.3. 相比磁盘存储系统，IMDB可以或许在更可期待的时间内获取数据，当然，这必要更大的资金投入
  

4.4. 列压缩方案

• 4.4.1. 列式数据库(Columnar-based Databases)是为处理那些数据值存在大量重复的数据集而计划的
  
• 4.4.2. 列式存储按列的方式存储数据并使用压缩技术，可以降低对I/O带宽的占用
  

4.5. 闪存

• 4.5.1. 内存存储(Flash Memory)技术的发展日新月异，闪存和SSD固态盘成为磁盘最有吸引力的替代品
  
• 4.5.2. 闪存具有集内存的访问速率和存储持久性于一体的特点
  

5. 数据库情况

5.1. DBA团队要实施QA情况的各种变更，并且还是对生产情况变更唯一负责的团队

• 5.1.1. 生产情况变更必须严格遵守标准流程和实施步骤
  
• 5.1.2. 专用硬件的类型包括数据库一体机，特殊为数据转换和数据分布而计划的服务器
  

5.2. 生产情况

• 5.2.1. 生产情况是指处理全部生产业务流程发生的技术情况
  
• 5.2.2. 生产情况非常关键，如果它制止运行，全部业务流程都会制止，最终导致业务丧失，同时会给那些无法访问服务的客户造成负面影响
  
• 5.2.3. 在告急情况下或者公共服务系统中，非计划的业务功能失效可能是灾难性的
  

5.3. 非生产情况

• 5.3.1. 系统的变更在真正部署到生产情况之前，必要在非生产情况下进行开发和测试
  
• 5.3.2. 在非生产情况下，变更引发的问题可以被提前检查和处理掉，不会影响到正常的业务流程
  
• 5.3.3. 为了尽可能检测出潜在的问题，非生产情况的配置要与生产情况非常靠近
  
• 5.3.4. 出于空间和成本的思量，通常不可能配置与生产情况完全同等的非生产情况
  
  
  
  • 5.3.4.1. 非生产情况越靠近生产情况，它的配置也就越必要尽可能赶上生产情况的配置
    
  • 5.3.4.2. 任何与生产情况配置的偏差，都可能会产生与变更无关的问题或错误，使问题的研究和处理变得复杂
    
  
  
• 5.3.5. 开发情况
  
  
  
  • 5.3.5.1. 开发用的情况通常是生产情况的精简配置版本，相对而言是更少量的磁盘空间、更少的CPU及内存等
    
  • 5.3.5.2. 大型企业可能会给个别开发人员独立的情况，通过恰当的权限进行开发管理
    
  • 5.3.5.3. 开发情况应该是任何补丁或更新进行测试的第一场所
    
  • 5.3.5.4. 应该与生产情况隔离开来，使用不同的物理硬件
    
  • 5.3.5.5. 如果没有确定清楚法律法规限定了些什么，不要从生产情况复制数据出来
    
  
  
• 5.3.6. 测试情况
  
  
  
  • 5.3.6.1. 测试情况通常用于执行质量保证和用户验收测试，有些情况下，也用于压力测试或性能测试
    
  • 5.3.6.2. 为了防止测试效果因为情况差异而失真，理想的测试情况应该与生产情况使用完全一样的软硬件配置，这一点对于性能测试来说尤为紧张
    
  • 5.3.6.3. 测试情况永远不要写数据到生产系统
    
  • 5.3.6.4. 质量保证测试(QA)
    

    5.3.6.4.1. 依据需求进行功能测试
    

    
    
  • 5.3.6.5. 集成测试
    

    5.3.6.5.1. 将独立开发或更新的多个模块作为一个团体系统进行测试
    

    
    
  • 5.3.6.6. 用户验收测试(UAT)
    

    5.3.6.6.1. 从用户视角进行系统功能测试
    

    5.3.6.6.2. 测试用例是最常见的测试输入
    

    
    
  • 5.3.6.7. 性能测试
    

    5.3.6.7.1. 任何时候都可思量进行的高复杂度或大容量的测试，而不必等到放工后，或者对生产系统的高峰时间产生倒霉的影响
    

    
    
  
  
• 5.3.7. 数据沙盒或实验情况
  
  
  
  • 5.3.7.1. 数据沙盒是答应以只读的方式访问和管理生产数据的另一个情况
    
  • 5.3.7.2. 数据沙盒用于实验开发或者验证相关假设的数据，或者将用户自己开发的数据或从外部获得的补充数据与生产数据进行合并
    
  • 5.3.7.3. 数据沙盒的价值如同进行一场概念验证(Proof-of Concept, POC)
    
  • 5.3.7.4. 沙盒情况可以是与生产处理隔离的生产系统的一个子集，也可以是一个完全独立的情况
    
  • 5.3.7.5. 数据沙盒的使用者经常在他们自己的空间中有CRUD权限，方便他们快速验证一些计划落实到生产系统上的想法
    
  • 5.3.7.6. DBA除了帮他们构建沙盒、赋予权限和监控使用情况之外，险些不消做什么
    
  • 5.3.7.7. 如果沙盒区域位于生产数据库系统内，为避免对生产系统产生负面影响，就必须对他们进行隔离，以杜绝这些情况的数据回写到生产系统
    
  
  

6. 数据库组织模型

6.1. 数据存储系统提供了一种将数据放入磁盘并管理和处理这些数据所需指令的封装方法
6.2. 3种形式进行组织：层次型、关系型和非关系型，这种归类并非是完全互斥的
6.3. 一些数据库系统可以同时读写以关系型和非关系型结构组织的数据
6.4. 层次型数据库

• 6.4.1. 层次型数据库可以映射成关系型表结构
  
• 6.4.2. 一些数据库系统可以同时读写以关系型和非关系型结构组织的数据
  
• 6.4.3. 层次型数据库(Hierarchical Database)是最古老的数据库类型，在早期的大型数据库管理系统中使用，它的结构要求最为严格
  
• 6.4.4. 在层次型数据库中，数据被组织成具有强制的父子关系的树型结构：每个父级可以有多个子级，但每个子级只有一个父级（也称为一对多关系）​
  
• 6.4.5. 目录树是层次数据库的一个示例
  
  
  
  • 6.4.5.1. XML使用的也是层次模型，尽管实际的结构是树的遍历路径，但可以表现成关系数据库
    
  
  

6.5. 关系型数据库

• 6.5.1. 关系型数据库(Relational Databases)基于集合理论和关系代数，此中数据元素或属性（列）与元组（行）相关
  
• 6.5.2. 表是指具有相同结构的关系集
  
• 6.5.3. 集合操纵（如Union、Intersect和Minus）以结构化查询语言(SQL)的形式从关系型数据库中组织或检索数据
  
• 6.5.4. 要写入数据，必须提前知道表的结构（模式）​，以是称之为“写入时进行处理的模式”​
  
• 6.5.5. 关系型数据库是面向行(Row)的
  
• 6.5.6. 多维数据库
  
  
  
  • 6.5.6.1. 多维数据库(Multidimensional Database)技术将数据存储在一种数据结构中，它答应同时对多个数据元素过滤器进行搜刮
    
  • 6.5.6.2. 常用于数据堆栈(DW)和商务智能(BI)
    
  • 6.5.6.3. 多维数据库对数据的访问使用的是SQL的一个变体多维表达式(Multidimensional eXpression, MDX)
    
  
  
• 6.5.7. 时态数据库
  
  
  
  • 6.5.7.1. 时态数据库(Temporal Database)是一种内置了支持处理涉及时间数据的关系型数据库
    
  • 6.5.7.2. 面向时间的特性通常包括有用时间和事务时间
    
  • 6.5.7.3. 有用时间
    

    6.5.7.3.1. 现实世界中一个真实事故或实体对象发生的时间范围
    

    
    
  • 6.5.7.4. 事务时间
    

    6.5.7.4.1. 存储在数据库中的究竟被认为是真实的时间段
    

    
    
  
  

6.6. 非关系型数据库

• 6.6.1. 非关系型数据库(Non-relational Database)可以将数据存储为简朴的字符串或者完整的文件
  
• 6.6.2. 简化计划、水平扩展性以及对可用性更好的控制
  
• 6.6.3. 非关系型数据库通常被称为NoSQL数据库（代表“Not Only SQL”​）
  
• 6.6.4. 重要区别是存储结构，数据结构不再绑定到表格关系中计划
  
  
  
  • 6.6.4.1. 可能是树、图、网络或键值对
    
  
  
• 6.6.5. 通常是高度优化的数据存储，用于简朴的检索和插入操纵
  
• 6.6.6. 目标是提高性能，特殊是在延迟和吞吐量方面比较明显
  
• 6.6.7. NoSQL数据库在大数据和及时Web应用程序中的应用越来越多
  

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。

---

欢迎光临 IT评测·应用市场-qidao123.com (https://dis.qidao123.com/)

Powered by Discuz! X3.4