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和Cass
andra本来的特性。一切就又恢复到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.这个问题给云中的软件开发带来一些麻烦事。