读数据保护：责任负载的可复原性13一致性模子

1. 一致性模子

1.1. 数据库与其他东西比较，还有一个很遑急的区别就在于，它们需要通过某种机制来确保数据一致，关于运行在多个节点上的数据库来说，这尤其遑急

1.1.1. 一致性模子(consistency model)

1.2. 立即一致性

1.2.1. 立即一致性(immediate consistency)也叫强一致性(strong consistency)，这种一致性模子能够确保扫数的用户都会在合并时刻看到相通的数据，不管他们身处何方，用何种步地来稽查数据，都不错保证这小数1.2.2. 要是数据库领受立即一致性模子，那么出现的bug与需要排解的问题，就会比领受最终一致性模子的数据库少一些1.2.3. 这种模子频频要比后者好，然而它会让数据库的性能受限，关于分散在多个节点上的数据库来说尤其如斯

1.3. 最终一致性

1.3.1. 最终一致性(eventual consistency)是，要是某实体于更新之后不再发生变化，那么对该实体的各式读取操作，最终都会看到更新之后的阿谁值1.3.2. DNS系统即是一种领受最终一致性模子的典型系统，它可能需要花几分钟乃至几个小时，身手把某条照旧修改的DNS记载传播到寰球上的扫数DNS职业器上1.3.2.1. 关于尚未收到更新的那些DNS职业器来说，查询操作复返的如素交记载1.3.2.2. 扫数的职业器最终都会收到更新，到当时，不管查询的是哪一台职业器，取得的都是更新之后的放置

1.4. 夹杂一致性

1.4.1. 夹杂一致性(hybrid consistency)模子频频用在一些NoSQL数据库里，这种数据库复旧以最终一致性的步地写入数据，同期又复旧在读取数据时通过API来指定你是按照立即一致性来读取，如故按照最终一致性来读取1.4.2. DynamoDB数据库就允许用户在读取数据时，领受强一致性（也即是立即一致性）的步地读取，这样数据库就老是会从leader（也即是最早发生写入的阿谁地点）运转读取，是以即便新值还莫得传播到扫数的地点，用户也老是能够看到这个值，而不会读取到尚未更新的旧值1.4.3. DynamoDB、MongoDB、Couchbase以过甚他几种数据库都复旧夹杂一致性模子1.4.4. 在备份这样的数据库时，不错指定我方需要按照立即一致性的步地读取最新的数据

1.5. 你必须凭证该模子遴选相应的办法，以保证你正在备份的（或者你以后复原出来的）数据是一致的

1.6. 参照完满性（referential integrity，也叫援用完满性）问题

1.7. 数据库所复旧的一致性模子会影响该数据库濒临各式故障的智商

1.7.1. 有些数据库能够交代某个存储设施发生故障的情况1.7.2. 有些数据库能够交代某个诡计节点发生故障的情况1.7.3. 有一些数据库则能够同期交代某个存储设施与某个诡计节点发生故障的情况

1.8. 某个数据库究竟能够交代什么样的故障，还取决于它是否会把数据复制到（或者说分享到）其他存储设施或诡计机上

1.9. 数据库交代某种故障的具体步地，则频频与它所领受的一致性模子商量

1.10. 位于本组织数据中心里的传统数据库

1.10.1. 要是数据库领受的是立即一致性模子，何况只慈祥我方能不行交代节点故障（而不慈祥是否能够交代存储故障）1.10.1.1. 频频的设想有盘算推算即是领受两个高度可用的（highly available，或者说，具备高可用性的）主机，让它们分享合并个存储阵列1.10.1.2. 能够濒临其中一个主机（也即是其中一个节点）出现故障的情况，但无法濒临扫数这个词存储阵列发生故障的情况1.10.2. 要是数据库领受的是立即一致性模子，但你思要的是一个全冗余系统(fully redundant system)，那么不错领受shared-nothing（无分享的）架构1.10.2.1. 这种架构不会让数据库节点共用任何东西（这也包括不让它们共用存储设施）1.10.2.2. 这种集群一般只须两个节点，因此这执行上意味着把数据复制给另外的阿谁节点1.10.2.3. 还不错作念出建树，让某个数据库事务必须比及这两个节点王人备更新结束之后，才会接到ACK信号，以默示写入的数据已更新到了扫数的节点上1.10.2.3.1. 会影响性能，然而不错尽量确保数据完满（或者说，尽量普及数据完满性水平）1.10.2.4. 有盘算推算能够濒临其中一个节点或其中一个存储设施发生故障的情况，因为不管何时出现故障，集群中的其他节点都有一份完满的数据库不错使用1.10.2.5. 最大弱点在于，它的彭胀智商有限1.10.3. 要是数据库领受的是最终一致性模子或夹杂一致性模子1.10.3.1. 数据库的数据表频频会分散到几十个乃至成百上千个节点中，它会领受与对象存储雷同的步地，将数据复制到这些节点1.10.3.2. 要是某个节点上的数据发生变化，那么该节点会坐窝记载此次更新，并凭证设想者的要求，把这个新的数据复制到一定数目的replica（副本节点）上1.10.3.3. 一般情况下，每札记载会复制到三个replica上1.10.3.3.1. replica不仅能够充任冗余机制，何况不错匡助咱们胜利实践备份与复原经过1.10.3.3.2. 在备份之前不错先把复制机制暂停，将内存中的数据王人备写入磁盘，并从每个节点里拿一个replica出来，然后针对拿出来这个的replica作念备份1.10.3.3.2.1. 备份责任不会影响主数据库的性能1.10.3.3.2.2. 备份下来的这个镜像，其内容是一致的，不会出现那种因为同期备份多个数据情景不一致的节点而产生的参照完满性问题

1.11. PaaS数据库与serverless数据库

1.11.1. PaaS与serverless数据库领受故障的智商，取决于你在购买这种数据库时所采纳的职业水平1.11.1.1. serverless数据库频频具备异常高的可用性，能够领受各式故障1.11.1.2. PaaS数据库是否领有这样强的故障领受智商，则要看你思达到什么样的冗余水平1.11.2. 不管是PaaS数据库，如故serverless数据库，它用来克服故障的这套手艺都集成在该产物之中，这个数据库产物的用户是看不到这套手艺的1.11.2.1. 用户只需要享受该手艺所带来的公正，而无须关注具体的已毕步地1.11.3. 其重心也仅在于交代硬件方面的故障1.11.3.1. 不管实践的是什么样的操作，它都会把该操作的后果尽快传播到系统中的扫数节点1.11.3.2. 数据库也必须像其他东西一样取得备份，以防受东谈主为原因影响而丢失数据

2. 传统数据库的术语

2.1. 实例

2.1.1. 实例(instance)是运行在一个或多个诡计机上的一组进度，但凡属于该实例的数据库都不错通过这组进度连结到分享内存并通讯2.1.2. 合并个实例里一般会有多个数据库2.1.3. 合并个数据库也不错分散在多个实例上2.1.3.1. 这些实例可能位于合并台诡计机里2.1.3.2. 可能分别处在某集群内的各台诡计机之中2.1.3.3. 实例频频会杰出多个职业器与节点

2.2. 数据库

2.2.1. 数据库(database)是由数据库对象(database object)所组成的集合

2.3. 表

2.3.1. 表(table)是数据库里的一组相互关联的信息2.3.2. 确认名字是relation（关系）2.3.3. 在给表中添加数据之前，必须先界说好schema（摘记/模式），何况表中的这些信息频频作念了安排，使得各表之间不会毫无必要塞出现重叠数据

2.4. 索引

2.4.1. 索引(index)是一种有稀少用途的对象，特意用来查找表格中的数据2.4.2. 能够更快地打听到数据，或是用一种与表格自身有所不同的步地来稽查数据2.4.3. 只针对表中的一部安分容（而不是整张表格）制作索引，这样的索引叫作疏淡索引(sparse index)2.4.4. 频频并不需要把索引一并复原出来，而是不错凭证照旧复原的表格内容来再行建立索引

2.5. 行

2.5.1. 行(row)是由相互关联的属性所组成的集合2.5.2. NoSQL数据库一般不使用“行”这个认识2.5.2.1. MongoDB、DynamoDB与Neo4j都莫得所谓的行2.5.2.2. 在DynamoDB里，这叫作一个条款(item)

2.6. 属性

2.6.1. 关于表中的数据来说，最基本的元素即是属性(attribute)2.6.2. 是单个的值

2.7. 数据文献

2.7.1. 数据文献(data file)是存放数据的地点2.7.2. 可能是一个（尚且莫得文献系统的）“生”开辟2.7.2.1. raw device，也即是所谓“生”文献，raw file2.7.2.2. Linux里的/dev/sd12.7.3. 可能是一个（照旧处于某个文献系统中的）旧例文献2.7.3.1. 所谓的“熟”文献，cooked file2.7.3.2. /oracle/data/dbs01.dbf2.7.3.3. c:\database\somefile.dbf2.7.4. 有可能位于腹地文献系统内部2.7.5. 有可能位于某个NAS filer的网罗驱动器中2.7.6. 某些数据库产物要求你必须使用“生”分区存放数据2.7.7. 其他一些产物则仅是建议你这样作念，而不提倡强制要求2.7.8. 本体区别仅在于一运转应该何如创建此文献，以及稍后应该何如备份文献2.7.8.1. 在数据库里并莫得什么不同

2.8. 表空间

2.8.1. 表空间(tablespace)是由一个或多个数据文献所组成的集合，数据表会添加到这个空间里2.8.2. 主要的表空间(main tablespace)

2.9. 分区

2.9.1. 数据库手艺的一项要紧进展即是能够把一张数据表分散到多个资源上2.9.1.1. 能够给某张数据表分区(partition)2.9.1.2. 把每个区分别存放在不同的资源中2.9.2. 给数据表分区，把它存放在多个表空间中2.9.3. 数据表不错横向分区，也不错纵向分区2.9.3.1. 要是沿着垂直主见分区，那么不错把其中某些属性放在一个表空间中，并将另外一些属性放在另一个表空间中2.9.3.2. 沿着水平时向分区，也即是按行来辞别，把某些行放在某个分区里，把另一些行放在另一个分区里2.9.4. 分片比分区更进一步，它会将数据表中的每块数据（也即是每一“片”数据）放在不同的节点上2.9.4.1. 关于大规模的数据库来说，这意味着该数据库会运行在好几十或好几百个节点上2.9.4.2. serverless数据库竟然都会对数据作念分片，并将其辞别到几十至几百个节点上2.9.4.2.1. 在使用serverless数据库时可能看不到这些分片，或者根柢就不必我方去斟酌分片问题

2.10. ⑩主文献

2.10.1. 很多传统数据库与PaaS数据库都会用某种步地来记载某个照旧装配好的数据库环境里的一起元素2.10.2. 要是你运行的是serverless数据库，那么好像无法不雅察到这份记载2.10.3. 一些数据库可能根柢就不领受集合管控式的架构，因而也就不需要保留这样一份记载2.10.4. 要是数据库领受集合管控式的架构，那么它会把扫数的存储元素都记载下来，以便惩办这些元素，这样的记载称为主文献(master file)2.10.4.1. 主文献可能是一个JSON文献2.10.4.2. 可能是一个文本文献2.10.4.3. 致使自身亦然一个数据库2.10.5. 内部记载着数据库系统的各式信息以及该系统的情景2.10.6. 要是数据库产物允许你在合并个环境里建树多个数据库系统，那么主文献会把每个数据库系统的信息王人备记载下来2.10.7. Oracle数据库将这个用来记载信息的主文献称为截止文献(control file)2.10.8. SQL Server会用主数据库(Master Database)来记载

2.11. ⑾事务

2.11.1. 任何一种发生在数据库里，且要修改其中一项或多项属性的举止，都不错称为事务(transaction)2.11.2. 浅易事务(simple transaction)2.11.2.1. 浅易事务只需用一溜语句即可已毕2.11.3. 复杂事务（complex transaction，又叫作复合事务）2.11.3.1. 复杂事务可能比较长，需要用多条语句来已毕，何况你必须把这些语句明确地放在一条肇端语句与一条收尾语句之间2.11.4. 要是在实践事务的过程中发生了问题（举例步调崩溃），那么不错取销扫数这个词事务，让数据库复原到实践该事务之前的情景，以确保其数据是一致的

2.12. ⑿事务日记

2.12.1. transaction log2.12.2. 扫数的关系型数据库惩办系统都有这样的日记，关联词NoSQL数据库则有时包含此机制2.12.3. 在从备份里复原数据库的时候，这样的日记也很有匡助2.12.3.1. 要是系统崩溃，导致咱们必须凭证最近制作的备份把数据库复原出来，那么在复原出来之后，必须设法将发生在备份点以后的事务重作念一遍，不然那些事务就会丢失2.12.3.2. 事务日记正巧不错匡助咱们已毕这样的重作念，因为它记载了用户在数据库上实践的每项事务，以及这些事务所修改的记载2.12.3.3. 要是数据库系统因为崩溃而必须再行录入某些事务，那么它就不错附近事务日记里的这些信息来录入那些事务，从而树立数据库2.12.3.4. 要是其中某个数据文献照旧损坏，何况无法通过事务日记来树立，那么你就必须我方从备份里复原阿谁数据文献了2.12.4. 把数据文献复原到当初制作备份时的情景之后，主数据库在稽查该数据文献时就会意志到：这个数据文献的情景处在早于刻下期间点的某个期间点上，因此，它可能是从备份里复原出来的（而不是蓝本就在那处）2.12.5. 究竟是先重作念如故先回滚，取决于具体的数据库产物，但不管何如，目的都是一致的，都是要令尚未提交的事务回滚，并凭证事务日记把需要重作念的事务重作念一遍，使得系统在崩溃或重启之后能够复原到稳健的情景