RavenDB建模--ACID模式和BASE模式

本专题最后一节，我们将学习 RavenDB 中常用的两种模式：ACID和BASE模式。首先我先来简述一下什么是 ACID和BASE。

1. ACID 是数据库事务正确执行的四个基本要素的缩写。指 DBMS 在写入或更新资料的过程中，为保证事务是正确可靠的，所必须具备的四个特性：原子性（atomicity）、一致性（consistency）、隔离性（isolation）、持久性（durability）。
2. BASE 是为了解决解数据库强一致性引起的问题而引发的可用性降低而提出的解决方案。BA指的是基本可用（Basically Available）、S指的是软状态（Soft state）、E指的是最终一致性（Eventually consistent）。

这两种模式在 RavenDB 中都有用到，但是各有利弊。虽然完全一致的迷哦行使得数据建模和数据库易于构建和推理，但构建和维护的成本是非常高的。在分布式系统中，要确保原子性成本也是很高的，每进行一个操作都要和多台机器对话。 在 RavenDB 中，使用文档或附件 ID对文档或附件的所有操作（增、删、改）始终是一致的，并且它们是在事务中运行的。对文档集的批量操作则是由由多个单独的事务组成，而不是由一个庞大的事务去执行。默认情况下，当我们将文档保存到 RavenDB 中并且数据以持久的方式保存在一个节点上时，就确认文档已经保存成功。当然，为了提高数据的安全性，还可以要求文档在多个节点上持久时才确认文档已经保存。（这些内容我将在后续的专题中讲解） 数据库管理员必须做的一项权衡操作是选择数据库需要多少索引。 索引过多的话写入过程有可能会停止，没有足够的索引查询将进行全表扫描。之所以权衡需要多少索引，是因为事务必须在文档每次更改时更新所有相关索引。这也就说明索引的更新就位于更新数据的主要途径中，这就解释了为什么错误的索引能严重地降低性能。 RavenDB 中的索引是作为异步任务处理的，每当数据库有更新时都会在后台运行相关索引更新。我们不必在完成写入之前等待索引完成更新，这样我们就可以做一些优化，比如可以将不同事务中发生的多个更改汇总到同一索引批量更新。同样，这也使我们能够即时确定一些操作的优先级，如果现在 RavenDB 负载很大，那么我们可以减少编制索引所花费的时间以便为更多请求提供服务，这遵循一种思想，即我们总是希望能够尽快的从 RavenDB 中返回结果。RavenDB 中的索引的更新在某种程度上可能会落后于它们所反映的文档，但是一般来说文档更新和索引更新之间的时间差通常以微秒为单位进行度量。索引的性质使我们能够实现许多理想的属性，向系统添加索引不会阻止任何对内容的操作，并且可以并行更新索引定义，因此可以利用索引进行各种优化。当然，如果你需要在操作完文档后让 RavenDB 等待索引更新完成也是可以的，但是在实际开发中这个功能并不是优先选择的。

TIP：在这里需要注意查询、批量操作和对特定文档的操作之间的区别，这些操作作为事务发生，利用索引的性质可以降低查询和写入的成本，并根据具体情况有选择地应用决策。