创作不易,希望大家一键三连支持!!!♥♥♥
创作不易,希望大家一键三连支持!!!♥♥♥
创作不易,希望大家一键三连支持!!!♥♥♥
传统数据库系统将数据存储在磁盘(Disk)中,磁盘I/O次数多，效率低。
随着多核处理器的出现，现代数据库系统将数据存储在了内存(Memory)中,降低了磁盘I/O，但同时引入了处理器缓存的新问题。
现代化硬件上的理想数据库系统：
(1)内存式数据库，减少I/O.
(2)缓存优化的内存结构，连续访问数据临近存储.(CPU在未命中和等待状态下的优化)
(3)支持并行执行，利用多处理器的优势。
①企业资源计划系统(ERP)需要处理混合工作量
·OLAP:创建销售订单、进货出货凭证、发票等 →写优化
·OLTP:运营月度报告、可承诺量、库存量分析等 →读优化
②OLAP+OLTP系统因性能的顾虑而分离
·不便：
(1)OLAP数据并非最新数据，只是数据预先处理后的子集.
(2)需要ETL工具来同步两个系统，系统冗余，程序复杂.
③开发愿景
·使用现代硬件和数据库系统将OLTP和OLAP数据结合在一起，创建一个单一数据源，实现实时分析，并简化应用程序和数据库结构。
SAP HANA是一个包括了硬件、数据库和解决方案的结合体。
行式存储：每一行为一个基本存储单位。
列式存储：每一列为一个基本存储单位。
列式存储的优点：压缩
基于企业数据特点：
(1)列的使用相对集中
(2)列中的值基数不高；
列式存储的结构支持高效的数据压缩：
(1)节省空间
(2)提升速度：内存←传输→CPU缓存；字典编码，整数值比较快于字符值比较；加快扫描和聚合
(1)HANA基于原数据表对主键列进行排序并计算唯一值，由此提取出一个数据字典。
(2)对每一行的数据生成行ID与其对应值ID的对应表(验证了前述所说：数据库中真正存储的是数字、字典、对应关系)
(3)同时，HANA还会对原数据表的主键建立倒排索引，该索引是对(2)中对应表的一次再次索引，可以找到每个值ID所出现在的行数。
对查询语句使用倒排索引优化前后的对比:
在找到所有行号之后，基于流派字典(值ID和值的对应表)即找到所要查询的行记录。
常见问题：
1.HANA只是一个列式数据库么？
不是的，HANA中既有行存储，也有列存储。2.HANA中的列存储是否还可以使用索引？
是的，HANA的列式存储对所有主键自动建立索引(倒排索引)，对于经常访问到的非主键列也是可以建立索引的。
3.内存式数据库是否仍然依赖于硬盘？
是的，依旧需要硬盘支持备份与恢复。
(1)未加载: 数据仍在磁盘中
(2)部分加载:由于查询条件而载入内存
(3)全部加载:数据全部在内存中
注:可以通过对表的加载状态设置来控制哪些表置于内存中(全部加载)、哪些表置于磁盘中(未加载)
(1)数据并不直接修改而是插入新数据：并行化，减少锁，多版本控制
(2)主存储对值ID进一步压缩，对读取、计算性能优化
(3)增量存储不排序、不对值ID进一步压缩，占空间较大
(1)额外的CPU、内存消耗
(2)可选优化方案：内存内融合、分区
增量融合过程:
(1)融合前：
Read：主存储Main1、增量存储Delta1
Write：增量存储Delta1
(2)融合中：
拷贝出新的主存储，将主存储Main1中的数据解压缩并和增量存储Delta1中已经提交的事务来进行重新解压、排序、编码、压缩来生成新的主存储Main2，同时在增量融合过程中，所有Write操作会连同增量存储Delta1中未提交的事务一起融合到增量存储Delta2中.
Read：主存储Main1、增量存储Delta1、增量存储Delta2
Write：增量存储Delta2
(3)融合后：
增量融合后，原有的主存储Main1和增量存储Delta1会被舍弃，留下最新的主存储Main2和增量存储Delta2.
Read：主存储Main2、增量存储Delta2
Write：增量存储Delta2
HANA持久层和传统数据库持久层类似。
每5min写一个Savepoint，将更改后的数据和日志冲刷到磁盘中，并且对已提交的事务，HANA会通过SSD硬盘读写的方式在Log Volume记录Redo日志，一旦发生断电，系统就会自动读取最近的一个Savepoint，之后再通过Redo日志即可使断电恢复后系统回到一个稳定的状态.
因篇幅问题不能全部显示，请点此查看更多更全内容