读数据掩护：工作负载的可规复性12数据库模型

1.       数据库中的数据

1.1.         大多数组织的重要信息都存放在某种数据库里

• 1.1.1.           有些组织虽然会把这些信息保存在应用程序中，但这款应用程序还是会将它的数据保存在数据库里
  

1.2.         最为困难的备份与规复问题根本上都跟数据库有关

• 1.2.1.           数据库的种类很多，而且每个数据库的备份方式也不一样
  

1.3.         不要由于过于寻求完美而放弃那些有所妥协的良好方案
1.4.         方案无论如何都比根本不做备份要强
2.       数据库的交付模型

2.1.         数据库也从实体服务器逐渐转移到了虚拟服务器乃至云计算平台之中
2.2.         数据库里的数据是以一种较为特别的方式存在的，以是不太容易通过常规的本领来备份

• 2.2.1.           你要备份的数据文件，其内容在持续地变革
  
  
  
  • 2.2.1.1.            用数据文件(data
    
  
  

file)的形式存放的，你可以在该数据库所在的服务器或虚拟机的文件系统里看到这种文件

• 2.2.1.2.            只要数据库中的数据有所更新，这些文件的内容就会变革，这意味着你不能像备份其他文件那样备份这种文件
  
• 2.2.1.3.            对于这种内容持续变革的文件来说，按照备份平凡文件的方式来备份是没有意义的
  
• 2.2.1.4.            不能像备份平凡的文件那样备份
  
• 2.2.2.           可以把数据库规复到制作备份的那个时间点
  
  
  
  • 2.2.2.1.            即便你可以大概通过某种方式将数据库精确地备份下来，在出现故障之后，你只能把它规复到制作备份的那个时间点，而未必可以大概规复到发生故障之前的那一刻
    
  
  
• 2.2.3.           可以从某个时间点向前（或向后）滚动
  
  
  
  • 2.2.3.1.            许多数据库都有变乱日记，你把数据库规复到某个时间点之后，可以重放这个日记，让数据库的状态可以大概逐渐变革到你所指定的另一个时间点，那个时间点通常是一个离现在更近的时间点
    
  • 2.2.3.2.            先把数据库规复到某个时间点，然后通过日记，让数据库向前滚动到间隔故障点只有几分钟的那一刻，以便减少数据损失
    
  • 2.2.3.3.            这种日记还可以大概向后滚动，如果数据库由于某个操作发生崩溃而陷入不协调或不一致的状态，那么你可以让它向后滚动到尚未实行该操作的那一刻
    
  
  
• 2.2.4.           某些数据库的数据文件可能是块设备，因此根本就不是以文件形式存在的，就算数据库不停在变，这些充当数据文件的东西也未必会随之改变
  

2.3.         数据库的交付模型是一种将某个数据库与其他数据库区别开的方式
2.4.         传统形式与PaaS形式之间的区别，就好比手动换挡与自动换挡之间的区别

• 2.4.1.           手动换挡让司性可以大概更为精准地控制车辆
  
• 2.4.2.           自动换挡的车开起来则比力容易，尤其是在一样平常交通的过程
  

2.5.         以传统软件的方式来交付的数据库

• 2.5.1.           数据库软件的交付模型还跟其他软件的交付模型没什么区别
  
• 2.5.2.           先购买某个数据库产品的使用许可，然后下载数据库软件，接着把它安装到你选定的服务器或虚拟机上
  
• 2.5.3.           所有的事变都必须由你切身负责，包括服务器的安保与管理、存储系统、数据库程序本身，最后（当然）还有数据库的备份工作
  
• 2.5.4.           如果数据库运行在你所管理的服务器或虚拟机上，那么给这种数据库做备份，自然有许多种方式可供选择
  
• 2.5.5.           你所管理的服务器或虚拟机
  
  
  
  • 2.5.5.1.            企业内部的服务器或虚拟机
    
  • 2.5.5.2.            运行在云平台，乃至运行在主机托管中内心的服务器或虚拟机
    
  
  
• 2.5.6.           只要你拥有这个服务器的只要你拥有这个服务器的root权限或管理员权限，你所接纳的就是传统的数据库交付模型，你所接纳的就是传统的数据库交付模型
  

2.6.         以PaaS方式交付的数据库

• 2.6.1.           接纳PaaS（Platform-as-a-Service，平台即服务）模型交付
  
• 2.6.2.           你只能看到数据库应用程序，你对该程序背后的基础设施仅有相当少的访问权，甚至根本就没有访问权
  
• 2.6.3.           你不用担心详细应该如何给数据库分配存储空间或如何为其配置服务器，你只必要指出自己想要告竣的分配结果
  
• 2.6.4.           Amazon RDS(Amazon Relational Database Service)就是一款PaaS式的产品
  
  
  
  • 2.6.4.1.            可以配置该服务，令其支持Oracle、MySQL、PostgreSQL、MariaDB以及Aurora等数据库
    
  
  
• 2.6.5.           Azure虽然没有宣称自己支持所有的PaaS数据库，但它在按照PaaS形式使用的时间，也能支持SQL Server、MySQL、PostgreSQL以及其他一些数据库
  
• 2.6.6.           每种PaaS产品都提供一套支持备份的机制
  
  
  
  • 2.6.6.1.            只必要根据文档来操作，就能把备份流程做好
    
  
  
• 2.6.7.           PaaS数据库不必要你自己去划分并配置相关的资源，你只必要指定自己想要的配置结果
  
  
  
  • 2.6.7.1.            一般来说，这意味着你只需指出数据库应该有多少个replica与partition，以及应该拥有多大的存储容量
    
  
  

2.7.         serverless数据库

• 2.7.1.           serverless数据库（无服务器数据库）比PaaS理念更进一步，它不要求用户做出管理，因而比PaaS式的数据库更容易使用
  
• 2.7.2.           你只必要往里面放数据
  
  
  
  • 2.7.2.1.            相关的计算与存储资源，以及数据库的分区问题，都会由serverless数据库自动为你决定并予以划分
    
  
  
• 2.7.3.           你唯一可以大概肯定的就是自己确实给数据库里添加了记录
  
• 2.7.4.           在使用serverless数据库的时间，你连完备的管理权限都没有
  
• 2.7.5.           你只能看到你所控制的这部分数据库里有什么内容，而且还必须通过数据库所提供的管理界面与API来查看
  
  
  
  • 2.7.5.1.            不能随意选用自己想要的方式去查看
    
  
  
• 2.7.6.           数据库的备份方式也是由提供该数据库的厂商决定的
  
• 2.7.7.           AWS(Amazon Web Service)的DynamoDB就是一个serverless数据库
  
• 2.7.8.           AWS的Aurora也可以大概以serverless方式运作，它会随着数据的规模而伸缩
  

2.8.         备份数据库的方式重要取决于数据库的交付模型
2.9.         PaaS式数据库或serverless数据库的备份与规复工作，则会受各种原因而显得比传统数据库轻松得多
3.       数据库模型

3.1.         差别的数据库在查询信息时所用的办法也各不一样

• 3.1.1.           区别可以归结为数据库模型(database model)之间的区别
  
• 3.1.2.           最为熟悉的一种就是RDBMS（Relational
  

DataBase Management System，关系型数据库管理系统）​，但这只是众多数据库模型里的一个
3.2.         至少有13种数据库模型或数据库设计方式

• 3.2.1.           关系型数据库管理系统
  
• 3.2.2.           RDF存储
  
• 3.2.3.           面向对象的数据库管理系统
  
• 3.2.4.           原生XML数据库管理系统
  
• 3.2.5.           多值数据库管理系统
  
• 3.2.6.           键值存储
  
• 3.2.7.           图数据库管理系统
  
• 3.2.8.           文档存储
  
• 3.2.9.           宽列存储
  
• 3.2.10.      时间序列数据库管理系统
  
• 3.2.11.      搜索引擎
  

3.3.         关系型数据库管理系统

• 3.3.1.           关系型数据库管理系统(RDBMS)是最根本的一种数据库
  
• 3.3.2.           最为流行的一种数据库模型
  
• 3.3.3.           由一系列数据表(table)构成，每张数据表都界说有schema（模式/纲要）​，这个schema决定了表格的布局(layout)
  
• 3.3.4.           数据表由记录(record)构成，一条记录相当于表中的一行(row)
  
• 3.3.5.           每条记录都包含一个或多个属性(attribute)，这些属性也称为值(value)
  
• 3.3.6.           两张数据表之间通过预先界说的（且与这两张表都有关系的）值来建立接洽
  
• 3.3.7.           Oracle、SQL Server、DB2、MySQL以及PostgreSQL都属于关系型数据库
  
• 3.3.8.           用结构化查询语言(Structured Query Language, SQL)来查询
  

3.4.         键值存储（键值数据库）

• 3.4.1.           schema比力简单，只有键与值两个概念，你可以根据键(key)查询对应的值(value)
  
• 3.4.2.           Redis与DynamoDB是比力常见的键值数据库
  

3.5.         时间序列数据库

• 3.5.1.           专门用来处理时间数据的一种NoSQL数据库
  
• 3.5.2.           由于其中的时间数据都有时间戳(time stamp)，可以大概体现出先后次序
  
• 3.5.3.           对涉及时间序列的一些用法在结构与查询方面做了特别设计，因而更适适用来处理这些数据
  
• 3.5.4.           Prometheus是一个比力流行的时间序列数据库，它在Kubernetes实现方案里常常用到
  

3.6.         文档存储（文档数据库）

• 3.6.1.           专门用来存储文档的NoSQL数据库
  
• 3.6.2.           数据库的记录不必要遵照某种统一的标准，因此各种类型的数据都可以存储到里面
  
• 3.6.3.           通常接纳JSON格式存储文档
  
• 3.6.4.           最流行的一款产品是MongoDB
  

3.7.         图数据库

• 3.7.1.           不使用传统的数据表与数据行的概念，而是通过图(graph)结构来查询
  
• 3.7.2.           最常见的是Neo4j
  
• 3.7.3.           Amazon Neptune
  

3.8.         搜索引擎

• 3.8.1.           专门为了搜索而优化的NoSQL数据库
  
• 3.8.2.           支持复杂的索引与搜索机制，让你可以大概像在搜索网站里查询信息时那样查询数据库中的数据
  
• 3.8.3.           Elasticsearch与Splunk是两种较为流行的搜索引擎数据库
  

3.9.         宽列数据库

• 3.9.1.           无schema的NoSQL数据库管理系统
  
• 3.9.2.           不必要预先设定schema，就可以大概存储那种包含很多个列的数据
  
• 3.9.3.           列名与键可以针对整个数据库（而不但是针对单张数据表）来界说
  
• 3.9.4.           Cassandra是此类数据库里最着名的一个
  

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