|
我感觉,HANA里面的基本的数据库的概念,如log commit, roll back, roll forward, dirty data write,这些,没变化。HANA就一数据库。
所以断电对HANA不是一个问题,数据的一致性和持久性用数据文件+日志里面的记录回滚数据库保证呗,commit了的日志就往前滚,没有commit的就往后滚。
HANA肯定是有即使断电了也能记忆数据的介质来存储数据文件和日志文件的。应该还是磁盘吧,我不确信了。
另外呢,HANA“出身”大概这么一个八卦故事:
老早以前SAP AG.有个DB,叫SAP DB,从大学实验室买出来的;
后来呢SAP AG又给它改名叫MAX DB,市场要求吧,SAP要显得自己专心做应用平台,而不是DB;
再后来SAP AG为了自己数据库平台无关的厂商身份,把它卖给了北欧的一个公司叫MYSQL AB,对,那个开源的公司,好多网站都用MySql有没有?
最近SAP AG觉得不能继续搞DB无关平台无关了,要增长点,要跟O记场上角逐数据库市场,就又把MAXDB买回来,改改名,叫HANA了。
HANA跟Sybase的关系我就搞不清楚了。我觉得跟APO里面的liveCache有关系。理念太像了。
从SAP的APO说起,这个产品在乘用车的整车厂广泛使用,high volume planning,料实在太多,结构也太复杂,ERP的MRP吃不消了,运行一次或许几天,灵活性不够;而APO里面的heuristic跑一次只需要几个小时,为什么呢?因为有liveCache,一个SAP自产的内存计算的面向对象型数据库,有关planning的数据全都在内存里。涉及大量数据的参与运算的场景,内存是关键(假设运算复杂度不高,否则CPU是关键)
大致也就在这里,月结需要参与运算的数据量很大。一开始提到,对读的速度很快,写的速度提高不多,那就对了啊,因为HANA的写操作最终还是要发生在磁盘(数据文件和日志文件存储的位置)上的。
不过话说回来,如果有一天内存和硬盘没有区别了----存储速度,制造成本市场价格,那以上说的好多东西,就又不对了。
|
|