上海交通大学高级数据库课件陆朝俊ed6ch26剖析.pptVIP

数字货币 信用卡支付不能提供匿名性 SET协议向卖主隐藏了买主身份 但即使在SET中, 通过信用卡公司的帮助也能追踪买主 类似于物理货币, 数字货币系统提供了匿名性 例如 DigiCash 基于加密技术使得不可能从银行查出购买数字货币的人 数字货币可由购买者拆零消费 很像是在匿名帐户上开支票 * 主存数据库 高性能事务系统 高性能硬件和并行化有助于改善事务处理速率, 但是仍不足以获得极低响应时间: 磁盘I/O 仍是瓶颈 — I/O 时间(10 毫秒) 没有随处理器速度的增加而以相当的比率减少. 并行事务可能试图读或写同一数据项, 导致数据冲突进而减少了有效的并行性 我们可以通过增加数据库缓冲区的大小来减少数据库系统对磁盘的依赖度. 主存数据库 实时控制之类的应用要求将数据存储在主存中才能满足性能需求. 今天的商用64位系统可支持数十GB的主存. Oracle TimesTen就是一个主存数据库系统. 但是仍然存在与磁盘有关的限制: 当事务率很高时,日志输出成为瓶颈. 用非易失性RAM作为日志缓存 利用组提交减少输出操作数目. (稍后研究) 如果修改了的缓冲块的更新率高, 磁盘数据传输率成为瓶颈. 提交事务的更新块应及时存盘以减少恢复时间 如果系统崩溃, 所有主存内容丢失.恢复时间长 主存数据库的优化 为减少空间开销, 主存数据库可使用跨多页的指针数据结构. 在磁盘数据库中, 跨越多页的I/O代价很高. 数据存取之前不需要钉住内存中的缓冲页, 因为缓冲页永远不会被替换. 设计查询处理技术以极小化空间开销 – 查询计值过程中避免超出主存限制. 改进操作的实现, 如封锁, 使之不成为瓶颈. 优化恢复算法, 因为页极少需要为了给别的页腾出空间而输出. 组提交 事务提交时要将有关日志记录输出到稳定存储器. 缓冲块经常不满 组提交技术: 为了输出比较满的缓冲块,不是一旦事务T准备提交就把日志记录输出到稳定存储器, 而是等到 多个事务已完成,或者 事务T在准备提交之后又等了足够长的时间 组提交技术导致每个提交事务平均执行较少输出操作, 从而对应地有较高吞吐量. 然而, 提交被延迟导致响应时间稍微增加. 上述延迟在高性能事务系统中是可接受的, 因为日志缓冲块会很快填满. * 实时事务系统 实时事务系统 有些应用要求在截止期限之前完成任务:工厂管理,交通控制,调度 实时系统: 执行的正确性涉及数据库一致性和最后期限的满足. 硬期限 – 在期限内若任务未完成可能发生严重问题 固期限 – 如果在期限之后完成任务则没有价值 软期限 - 如果在期限之后完成则任务价值减少,越晚价值越低. 实时系统的事务管理必须考虑期限 例如,并发控制让事务等待? 事务执行时间存在巨大差异:取决于要不要磁盘I/O 因此常用主存数据库 即使数据在主存中, 等待封锁, 事务中止, 竞争资源仍然是问题 实时系统的设计需要确保有足够的处理能力来满足期限, 而不过度要求硬件资源. * 长事务 长事务 事务概念产生于数据处理应用,事务多是非交互的,持续时间较短. 长(long-duration)事务:与人交互的事务.具有如下性质: 持续时间长 暴露未提交数据 子任务及部分回滚 可恢复性: 崩溃时恢复到故障前某个状态以减少用户工作的丢失.(即使对尚未提交的数据也应该能恢复) 性能: 好性能定义为响应时间快,而非传统的高吞吐率. 以上性质要求不同的事务处理技术 长事务(续) 表示为嵌套事务 较低级别上的原子数据库操作(读/写). 如果事务失败, 仅中止活跃的短事务. 一旦短事务已经恢复, 则活跃长事务即可继续. 有效管理长时间的等待和可能的中止. 需要等待与中止的替代方法; 替代技术必须确保正确性而不要求可串行化. 可串行化要求不适用长事务 对于长事务, 传统并发控制技术有负面作用. 2PL:等待长事务释放锁导致长时间等待,响应时间变长,增加死锁机会. 图协议:事务按数据间的序进行封锁,导致封锁不必要的数据,也可导致长时间等待. 时间戳协议:没有等待但常使事务中止.中止长事务会损失很多工作. 验证协议:和时间戳协议一样也是通过中止事务来确保可串行化的. 总之,确保可串行化导致长时间等待及长事务夭折. 另外,级联回滚也不利于长事务.而通过将X锁保持到事务提交来避免级联回滚,又会增加等待时间. 对长事务,冲突更新更可能发生,导致等待和中止. 并发控制 可串行化调度能保持数据库一致性,但保持数据库一致性的调度并非都是可串行化的. 例如:能保持A+B的非可串行化调度 并发控制 不要求可串行化的正确性: 正确性依赖于对数据库的一致性约束. 正确性依赖于每个事务执行的操作的性质. 对事务的低级操作做自动分析并检测其对数据库一致性约束的影响一般是不可能的. 但存在更简单的技术: 以数据库一致性约