StanfordDB class自学笔记 (11) Indexes and Transactions

Indexes 

• 提高数据库性能的原始机制
• 持续的数据结构，存在数据中
• 有很多有趣的实现问题

下面说的主要是注重在用户、应用层

用处

具体的来说，用户访问的不是index，使用的是query索引机制

通过查询语句返回的是index索引 

潜在的数据结构有两种，平衡树或者哈希表 其中哈希表的使用情况比较单一，而平衡树的使用情况适合更多情况，如上图！

许多DBMS自动构建索引 PRIMARY KEY（有时是UNIQUE）属性

Index的缺点

• 需要额外的空间（需要支持的数据结构）-小影响
• 创造index需要花费时间 -中影响
• 保持index 特别是指需要经常修改的数据库-大影响  

Benefit of an index depends on:

• Size of table (and possibly layout)
•  Data distributions
•  Query vs. update load

Physical design Advisor

physical design 是指在数据库中使用什么index

输入是database的数据以及workload（query和update语句）

输出是推荐的index

physical design 的运作成功非常依赖数据库系统中已有的一个东西 ：Query Optimizer，工作原理如下图所示。

Transaction简介

由两个独立的需要而产生

• 并发数据访问(Concurrent database access)
• 防止抵御系统错误(Resilience to System Failures)

并发数据库访问(Concurrent database access)

并发访问可能会引起 Attribute-level Inconsistency、Tuple-level Inconsistency、Table-level Inconsistency、Multi-statement inconsistency等一些问题。

并发问题的一个简单解决方式就是单独分开执行不同的sql语言

但是有时候我们想要使得并发，并且不会发生问题，我们就有很多解决措施。比如多处理器、多线程、系统提供异步I/O。甚至有五个客户端在访问处理数据库，但是每个客户端处理数据库的不同部分，这样也可以实现并发。

抵制系统错误(Resilience to System Failures)

系统错误是指比如我们在传输数据进入数据库系统的时候，由于软件、硬件甚至电源问题，导致传输数据到一半时失败。

我们想要实现 Guarantee all-or-nothing execution, regardless of failures！即成功的时候实现所有的操作，失败了不做任何操作！

上面讲的两种情况可以用Transcation技术解决！

简单的说，可以一个Transaction想象成很多的SQL操作，组成了一个uint！可以利用“commit”进行标识。

 

Transactions Property(ACID)

Isolation 性质

每个操作可以是相互间隔的，但是每次执行必须是按照一定的序列化transaction执行，比如按照T1、T2、T9、T10、T3这样的顺序执行

Durability性质

下图中，s1s2s3commit后 ，系统crash了，不影响他们已经对数据库造成的改变。原理是logging原理，但是这节课不会介绍到实现原理。

Atomicity性质

下图中 在s1s2执行后 commit前crash，那么整个T2不对数据库造成影响，实现的原理也是基于logging。

在之前我们提到的atomicity性质，在这个过程中取消已经进行的部分操作称为Transaction Rollback (= Abort)

Transaction Rollback 可以是由系统引起的，也可以由我们的客户端引起，由客户端引起的见下图

但是要注意的是，rollback操作只对数据库中的系统进行操作，假如在rollback中有一些修改数据库的操作，那么rollback不会undo这些操作

 

Consistency

consistency讲的是Transaction如何与integrity constraints 作用。。这里我没太搞明白是什么意思。

网上有篇文章说：事务必须是使数据库从一个一致性状态变到另一个一致性状态，一致性与原子性是密切相关的。比如A向B转账，不可能A扣了钱，B却没收到（这就是非一致性）

Isolation Level

有三种isolation level，并且每个Transaction可能有不同的level，互不影响。

Dirty Read

“Dirty” data item: written by an uncommitted transaction

一个transaction与其他未commit transaction中的操作产生并发问题。

Read Uncommitted

此时transaction可能会有dirty read，此时采用read uncommitted是因为也许我们并不在意此时产生的并发问题，我们只在乎更多的效率、性能。

Read Uncommitted

此时一个trasaction可能不会有dirty read（我的天，这和上面的也没区别啊！） 

此时我们：Still does not guarantee global serializability

此时也是不太在意并发问题，只关注性能。

Repeatable Read

此时的trasaction可能不会有dirty read，并且一个多次访问的item不会改变value，不过这样还是不能保证global serializability。

此时的一个relation可以change。

我们在数据库中读取的某个值的时候会被lock，但是插入的时候不会lock，删除的时候value会被lock。

 

总结