首页 > 代码库 > 关于重新设计data accessing layer的思考(一)

关于重新设计data accessing layer的思考(一)

背景:项目中已运行10年的数据访问层,存在若干架构方面的问题,为了彻底解决并释放并行访问的能力,并提供一套完整的面向对象的API,决定重新设计。

思考问题:

1.如何保证兼容性:  

  1)使用新库的实现替代旧库中的实现,保证一次性全部修改并测试,不修改旧库的API,且提供用户新的API

  2)新库与旧库完全隔离,同时存在,但新库需要保证与旧库的数据同步。旧库不做任何修改。用户可以同时使用新库和旧库

2.如何保证多线程访问的效率:

  1)一直以来,内存和CPU总会出现冲突,在数据访问更是如此。当动态数据在内存中只有一个存储地址,必然在多线程访问中需要各种同步机制,或者异步访问而影响到效率。如果牺牲内存,提供内存的duplication,那么存在的问题,变为了内存的使用量double,并且需要merge这些修改,或者是duplication。实际上,数据库的设计中,对这个问题提供了多种的解决方式,比如snapshot。实际上这种思路在旧的Data Accessing Layer的设计中,也体现了一些,当时一开始数据存在内存中只有一份,但运行时发现在多线程或者多进程的条件下,使用锁的机制,无法完全发挥多线程的优势。后来只能采取通过数据的多个备份,来保证多线程的效率。当然每个备份就需要相互之间的数据同步,这也就造成了一个问题,就是当出现conflict怎么办的问题。最初,我认为,将数据放在share memory中大家一起共享,似乎是一个最方便且最有效率的方法,但越来越发现,如果想充分发挥多线程或者多进程的效率,应该考虑的是如何在内存使用量和CPU效率之间做一个权衡。

  2)减少数据的互斥性,特别是对于动态数据。修改数据库中Data Model,保证表中的数据均为运行期产生的动态数据(对于现有数据中,80%均为静态数据),将静态数据存入sharememory, 给所有进程共享,并且使用单独进程preload. 对于动态数据,特别是字符串数据,能够使用enum进行映射就应该从数据库中移出。

  3)每个线程当访问时,会创建一个独有的数据的snapshot,这样,当线程需要提交修改时,将自己决定如何处理conflict.

(待续)