NDBC2011会议总结~(1)

第一天是研究生论文指导...主要是论文中的数据最好尽量的使用真实数据..但是可以从真实数据中抽取或者sample出对自己算法有利的数据。但是算法必须解决为什么在这种数据集上就好，以及算法的局限性在什么地方。而不是提出一个算法和XX算法再比较一下就ok了..

第二天是大会开会..顺利的挤到前几排，照了一张露脸相.

有一个是讲LRU的算法改进的。传说改进算法是LIRS.LRU主要的缺陷在于使对于普遍的pattern而不是对于特殊的pattern适用。对于高频率访问数据和低频率访问数据并没有很好的区分度，很有可能因为低频率的数据使得中高频的数据被替换出缓存，从而导致缺页。

有一个是讲隐私保护的。主要的观点是将共有数据和想保护的数据直接的关联关系去掉。

下午EMC出了一个vplex的东东，这是一个存储平台。当然这东西早就出来了...其实是啥米呢？其实就是pool

1.然后去看demo,发现数据挖掘的东东还是不少的。可惜我的研究方向不是数据挖掘.要不还可以探讨的更加detail一些。不过大概很多也就是求sim(i,j)只是运用了各种图方法或者规则模型，或者统计模型,或者随时间的统计模型..再有新意的..还是没怎么看到。

2.看了下太极数据库(taiji DB)自从云计算大会时听说后，对这个东东很有期待..后来发现是对Hbase和Cassandra做了层sql解析，然后数据通过sql或者函数调用放入到两个类型的数据库中。Cassandra是一个支持Available 和Partition的东东， Hbase是支持最终Consistence 和 Partition的东东。另外Hbase的读很快，但是写不是很支持。Cassandra对于写操作的支持灰常好~Hbase有锁机制而Cassandra没有，Hbase在Hadoop之上，所以文件系统的管理对于Hbase来说几乎是透明的，Cassandra是自己管理自己的。Hbase是有主从结构的东东，而Cassandra是p2p的。其实这两个东西统一起来是相当困难的。当然在数据不需要恢复，不需要读取最新的数据时，这一切看起来很完美..但是一旦有异常发生..这东东就game over 了。因为这两个东东是不同的文件底层控制，也就是Hadoop根本就不知道Cassandra的情况。另外当数据更新时，网络产生分割，然后再由其他的客户端进行读取时，这整个系统的状态就不一致了。还有一点值得一提的是，Cassandra和Hbase都存在在一台机器中，本来就对原有的写效率和读效率造成损害。所以...现在的表面融合还能不能做成核心融合，还是很难说，即使做出来了，可能也要失去Hbase和Cassandra本来的特性。一切就又恢复到database的本来样貌......

3.代理对象数据库。这个demo中的数据存储模式的确在一定程度上解决了数据冗余问题，但是它有带来了极端的效率问题。怎么解释代理对象数据库呢？首先这东东和对象数据库有什么不同呢？对象数据库就是A表继承B表，那么A既有B中的所有属性，虽然这些属性可以控制是否可见，是否可以更改插入删除等。但是A中必须为这些所有属性消耗存储代价。当然这里要假设A表是按行存储。现在代理对象数据库解决的问题就是这个存储代价浪费。也就是A表中不再存储物理数据，而是引用B中的数据。将这个继承关系转换成了逻辑关系。但是这东东并没有解决菱形继承问题。另外我还不小心发现一个很严重的问题：假如对象继承层数增多，那么如果当B中某字段非空，但是此字段又非A中字段，那么要先要插入B表中一行，然后再插入到A表中一行。继承层数越多，那么需要插入的父表也就越多....时间消耗严重！！~~

总之，此次数据库发展方向正在向大内存占有率，混合数据库架构方向发展。当然用column based代替row based的数据库也有展现。从通用数据库向特定领域数据库转变。这样带来的好处在于这样的数据库操作更加方便，解决特定领域问题时效率会提高。但是这样的缺陷也很明显：不通用，开发维护代价高。所以应该有这样的公式：C_develop+C_maintain < V_dba+V_efficient 当然这里需要假设所有的硬件和软件环境是一致的。

云计算中强调auto tuning.但为什么数据库中不能auto tuning?另外云计算中调试不方便，许多过程不能repro.这个问题给云中的软件开发带来一些麻烦事。