系统性能提升之道--内存镜像表
系统性能提升之道--内存镜像表
提出问题
对于一个系统，我们在设计开发时，不得不考虑系统的性能问题，硬件的提速可以缓减系统日益增长的消耗，但我们也不能肆无忌惮的扩展系统而不考虑性能的提高，我们应该重视资源的有限性。
为了说明问题，我先举个例子，有两个表如下：
Items物料表
|
字段名 |
数据类型 |
描述 |
|
ID |
Varchar(50) |
主键（PK） |
|
Name |
Varchar(50) |
物料名称 |
|
CatalogId |
Varchar(50) |
物料组ID(FK，关联Catalog表) |
|
…… |
…. |
….. |
Catalog物料组表
|
字段名 |
数据类型 |
描述 |
|
ID |
Varchar(50) |
主键（PK） |
|
Name |
Varchar(50) |
物料名称 |
物料表的CatalogId关联物料组表的主键
要求：我们在显示物料信息时，显示此物料的物料组名称
传统的非ORM模式下，我们一般可以采用
Select Items.*,Catalog.Name as “catalogName” from Items,Catalog where Items.CatalogId=Catalog.ID
的语句来读取，然后可以在Grid上直接绑定”catalogName”来显示物料组名。这种非ORM模式开发的系统，系统扩展性非常差、数据库移植性差、开发效率低下，所以大家也都开始使用ORM的开发模式。此文章不推荐、不讲述非ORM的开发。
ORM模式下，我们把这两个表映射为“ItemsEntity物料实体类”与“CatalogEntity物料组实体类”。然后我们在Retrieve到一个物料对象aItem后，在显示时要求显示物料组名的话，就需要CatalogEnity去Retrieveg一个物料组对象aCatalog，使用此aCatalog的Name属性才能显示出来。
我们也发现了，在ORM模式下，由于采用了OO的编程模式，对开发者来说带来了很多的方便，但在过程中，进行了两次数据库访问，我们试想一下，要是此Items物料表有十个类型的外键关联，那么一个Items的显示，将进行十一次数据访问，对于极其宝贵的数据库访问资料来说，性能大打折扣了。
NHibernate中的解决方案：
在NHibernate中，可以采用“Relation”的方式来解决，需要在XML中配置十个one-to-many的“Relation”，然后采用非Lazy的方式进行一次性读取，这种方式是把十一次的数据访问放在一起执行了，这看起来可以很方便的实现;但如果有N个人都要进行这样的操作，那么数据访问数还是非常大(N*11)。而且我非常不喜欢NH里的“Relation”，因为这“Relation”还存在一个问题，返回的是对象数组，在没有Grid控件绑定的Java中，这可能是不错的方式，可是在.NET中，我们更会选择Grid进行DataTable的数据绑定，因此这种“Relation”无法很方便的返回DataTable，所以从目前来看，这种“Relation”在.NET中非常不适用的。这也是我的SPL是没有添加“Relation”的原因之一。
缓存内存表的概念：
对于上面的这种情况，我们可以思考一下，采用另一种更好的方式解决。我们可以把这个物料组表的内容放到内存里，作为一个“内存镜像表”，此“内存镜像表”是数据库中实际表的一个镜像，实时保持与实际表的同步，我们在读取时：
if（内存镜像存在）
从内存直接读取;
else
{
从数据库读取;
建立内存镜像表，把数据库中的数据镜像到内存表中;
}
这样的方式可以减少很多的数据访问，就拿上面的例子中，在第一个人进行了十一次访问后，以后的N个人执行，只要执行N次数据访问了，速度将会有一个突破性的提高。
内存镜像表的可行性分析：
对于这种“内存镜像表”的可行性我们先从数据库数据来分析。
一个系统将包括很多的数据，但我们可以对这些数据进行分一下类：
“维护性数据”：
这是指那些在系统中的基本维护性数据，比如前面的物料组、客户类型、付款方式、结算方式、销售类型、货币种类等等，大家都可以举出很多很多这种类似的数据，这些数据存在的共同点是：
数据量小：这种数据一般在50条记录以内，都是一些类型，分类之类的数据
字段少：这种数据的字段都是很少的，主要是ID、名称、状态等
使用频繁高：这种数据的使用率非常频繁，因为在其他表中作为外键，经常会被使用
维护少：这种数据一般在系统启用前期进行维护，大部分情况下不维护
因此，具有这些特点的数据，我们就非常有理由放到内存中进行缓存起来。
“操作型数据”：
这种数据的特点是数据量比较大，字段也比较多，比如物料、客户等信息，不适合用到内存中。
“日志型数据”：
这种数据数据量就更多的，比如订单、订单明细、操作记录等，这就更不合适了。
因此我们主要是考虑“维护性数据”，大家想想在你的系统中，会有多少是这种“维护性数据”，对于结构相似的“维护性数据”都会采用“数据字典”的方式来对待。
内存镜像表的可操作性分析：
在可行性分析后，我们要考虑，在实际操作起来要注意哪些。
大家也很容易发现，唯一注意点就是“如何保持实时的镜像关系”，也就是要实时保持内存中镜像与实际的数据库表数据一致。
那么我们就要保证在进行更新（包括新增，更新，删除）时能同时更新内存表数据就可以了。
对于非ORM的开发模式来说，使用Sql语句进行数据访问的，要实现这种“实时同步”是很难的，幸好的是我们现在有了ORM的开发模式，在ORM上，我们的数据访问不是直接使用SQL的，而是通过中间的持久层(PersistenceLayer)来实现的，因此，这个持久层(PersistenceLayer)为实现这种同步提供了必不可少的条件。
在OR Mapping时，我们标识一个实体为“需保存到内存镜像”，那么持久层(PersistenceLayer)在进行此对象的Save()、Update()、Delete()时，自动进行“内存同步处理”即可，而且这是完全可实现的。
好了，我们回到前面的例子中，那样的一个物料Retrieve()操作，其实只要两次访问数据库，而且当有N个用户进行类似的操作时，由于“内存镜像表”在第一次就载入到内存了，因此访问数据库次数为N次了。
内存镜像表的弊端性：
从上面的操作性我们就可以看出了，效率的提高是建立在内存的牺牲上的，如果有过多的“维护型数据”使用“内存镜像”，那么，整个内存消耗将非常大，所以，在考虑使用多少“内存镜像表”时，是要考虑服务器的承受能力的。
但我想，增加内存，提高性能这是很多客户所在追求的。因此，我们只要能仔细分析，是可以得出一种好的“内存镜像表”量的。
内存镜像表的实现性：
这种“内存镜像表”在我的SPL(SmartPersistenceLayer)已经实现了，不知道NH等其他的持久层中是否也有类似的功能。
在SPL中的使用：
在ClassMap中定义实体类的IsSaveToMemory为true即可。例：
<class name="StudentEntity" table="Student" database="MyDB" IsSaveToMemory="true">
<attribute name="Id" column="Id" type="Integer" increment="true" key="primary" />
<attribute name="No" column="No" type="String" key="primary" />
<attribute name="Name" column="Name" type="String" />
<attribute name="Birthday" column="Birthday" type="Date" />
<attribute name="Grade" column="Grade" type="Integer" />
<attribute name="Score" column="Score" type="Decimal" />
</class>
SPL的实现细节：
在SPL中有个静态类，它的ArrayList里存放各种“内存镜像表”的“镜像DataTable”，在进行Retrieve()时，先判断此ArrarList中是否存在此实体的“镜像”，如果有的话，则直接从此“镜像DataTable”中Retrieve()出来，还有RetrieveCriteira(获取标准)时，会从此“镜像DataTable”中使用Select符合条件的，生成新的“镜像DataTable”返回出来。
SPL的实体在进行Save()、Delete()和UpdateCriteria(更新标准)以及DeleteCriteria(删除标准)时都是会进行“镜像DataTable”的同步更新。
但这种也不能完全意义上的保证“同步”，因为SPL支持Sql语句执行，所以不要使用Sql来更新“内存镜像”的表。要不然，就无法保证“内存同步”了。
听棠
浙公网安备 33010602011771号
评论
ASP.NET 2.0 中改进的缓存功能
也要注意休息啊﹗
有兴趣的话，可以MSN我发给你
cnlamar(at)hotmail.com
以前我也是使用楼主提的类似内存镜像表的结构，
在服务器内存中维护一个DataSet，将稳定型数据（多读少写）
置于DataSet中，然后用特定策略维护数据一致性。
但这种方式对内存的要求比较高，而且对服务器的稳定性有
不少影响。
之后，就采用了类型微软Application Block架构的缓存处理
（也是内存中维护数据，hashtable结构），
而缓存数据以记录为单元，第一次使用时才置入缓存中，然后用特定策略（完全避免脏数据）维护数据一致性。这种方式减少内存中的数据量。但也有缺点，对于返回DataTable记录集，该种方式有明显缺陷。
这两种方式各有其应用范围吧。
如何处理Scale out?
====================
lazy="true"
而且我非常不喜欢NH里的“Relation”，因为这“Relation”还存在一个问题，返回的是对象数组，在没有Grid控件绑定的Java中，这可能是不错的方式，可是在.NET中，我们更会选择Grid进行DataTable的数据绑定，因此这种“Relation”无法很方便的返回DataTable，所以从目前来看，这种“Relation”在.NET中非常不适用的。
====================
没Relation就不叫object-RELATIONAL mapping了.
Winform的Grid控件能绑定的条件是对象实现了IList, 可以用<bag>; Webform的要求更低, 实现IEnumerable就可以了(说白了, 是集合就能绑定), 可以用<bag>或<set>
哦，原来可以直接绑定啊。不过，竟然我对象的基类的IsPersistent属性也给带出来了。
象要是有十个关联的，要配置这么多关系，而且效率上也没有提高，我觉得这种利小于弊，增加这么多复杂度，就只为了那几个值。
我知道没有Relation就不是完整的ORM了，但我想理论归理论，有很多理论没有实际价值，那是美好的憧憬而已，ORM中还有些理论都没有实现的，就像共产主义就是理论，那是永远也到不了的理想社会，没有实际意义。我还是喜欢实践才是检验真理的唯一标准。
orm的精髓不在于自动处理curd, 而是能用面向对象的方式去操作数据.
Relation并不单指能customer.Orders这样通过关联访问"几个值", 而是在查询中能使用面向对象的关联, 例如
"From Order order = where order.Customer.Name = 'Tom'" 查询属于Tom的订单
"From Customer customer where count(customer.Orders) > 100" 查订单数量大于100的客户
另外多态性也是很常用, 假如在权限系统中, 用户User和用户组Group都可以作为一个被授权的实体, 可以用IActor接口来作为User和Group的抽象. "From IActor actor, Resorces res where res.Name = 'xx' and actor in elements(res.GrantedActors)"可以查出拥有名为"xx"的资源的访问权限的User或Group
要节省写sql的时间的话, 倒不如用DAAB或者用ide生成data adapter + typed dataset