He3DB如何区分冷热数据
-
静态指定：例如创新表时，可以指定整个表是热数据，或者指定满足特定条件的表是热数据（例如订单表，指定订单生成时间<一周的记录都是热数据）；部分系统表或者索引数据会被自动标识为热数据
-
动态变化：数据会按照时间梯度（例如数据生成时间，最新使用时间，甚至可以指定不同的时间区间数据冷热属性），使用频率（例如1个小时内使用次数），数据属性（例如索引表）等维度，定义数据温度属性。通过温度标识数据，支持-100度到100度，为了方便存储分层，数据基于温度分成三个区间 冷（-100-30度），温（30-60度），高（60-100度）。不同等级的数据会被保存在不同的存储层
冷热数据标识粒度是多少（支持列，行，数据页，还是表）？
He3DB支持表粒度，以及行数据粒度，例如一些系统表我们会以表粒度定义整个表都是热数据。一些大表定义不同的数据行范围为不同的温度，例如 订单时间>三个月的就是冷数据，小于三个月的就是热数据He3DB计划支持多种粒度，主要因为这样方便用户基于他们的业务场景，可以灵活配置数据冷热属性。例如 一些小的，高频使用的表可以考虑整表作为热表。一些大表可以指定部分区间的数据作为热数据
冷热数据如何转换？
冷热转换时机？
-
支持在线修改，例如改变冷热数据规则，触发后，异步进行数据分层
-
基于业务访问动态变化，例如部分数据被频繁访问，自动转换为热数据
-
基于统计信息，数据冷热时间区间定义（例如6-8点是热数据，10-12点是冷数据），提前 实施热转化，保证性能
冷热数据转换涉及的过程？
-
热转化冷：是一个异步递进的过程，存储层会被划分为多层，热数据会递进的转移到下一层
-
冷转换热：直接最热层，递过向下分层。部分转变是同步过程，保证效率
-
HE3DB 实例包含那些数据，每一种数据如何区分冷热：**
-
用户表数据： 基于冷热数据规则，区分冷热，保存在不同的存储层
-
WAL日志数据：He3DB基于数据页+WAL日志提供多版本数据页读取功能，所以WAL日志的 缓存伴随数据页缓存
-
PG 管理数据，例如CLOG数据，用于事务管理，PG_CONTROL数据，数据量比较小，建议作为热数据或者温数据管理
-
系统表数据：热数据或者温数据
-
日志数据：冷数据
上面一些问题，只是给大家一些启发，现在很多数据库都标称自已支持冷热分层，但是做的很浅，不够彻底，例如 数据分层粒度只支持到表，并且通过分区表实现存储层的实现更简单，冷存储对应HDD盘，热存储对应SSD，也不支持冷热属性在线变化。所以对用户使用非常受限。
He3DB对成本的极致追求，以及对性能的不委协。因此对冷热分层技术要求更高。我们认为的理想状态的冷热分层效果:对用户完全透明,实现数据在冷热层自由轮转，用户访问的数据永远在热存储中，保持性能。冷数据保存在冷存储层，这样达到性能和成本的完美平衡。冷数据被使用前，能够提前转存到高性能存储区，数据变冷以后，能够快速转存到冷存储区。
HE3DB存储分层
下面我将基于新架构，详细描述HE3DB存储分层，每层缓存什么数据（数据按层数逐渐转冷）
第1层：计算引擎内存（databuffer），
第2层：He3FS client
第3层：计算引擎本地盘
第4层：高性能存储层(数据对应状态机中的内存区域)
第5层：低成本持久层S3（未来可以基于AZ或者Region进一步拆分S3存储层）
第1层 计算引擎内存
对应数据库实例data buffer内存，数据库实例提供读服务时，首先读取 data buffer内存中的数据，如果命中，直接返回。所以对数据库服务来说，这层效率最高，对应最热数据，为了把这部分内存串联起来，变成一个大的内存池，HE3DB 重新设计data buffer的缓存算法，使每一个备节点能够缓存不同的表数据，具体每个备节点缓存那些表数据，可以由创建表的时候指定。目的就是变成一个大的内存池，尽量把所有的最热的数据尽量都缓存在内存中，从而提高性能。（这是我们HE3DB实现高性能非常核心的一个设计）
之所以能够实现备机缓存不同的表数据，并且提供一致性读，得益于HE3DB其它几个设计：
1. 备机接收到日志实现deplay replay,如果备机内存有对应页,实施回放；如果没有，直接扔掉WAL日志。如果是单机处理日志的方式，备节点需要回放所有的日志，那么会污染内存中的数据页，导致我们缓存算法效率不高
2. 智能中间件：中间件接收到用户读请求后，选择一个节点提供读服务，基于两个判断：一是读取的数据缓存在那个备节点缓存中，二是备节点能够提供最新数据。用户通过中间件访问数据库，具体访问那个节点对用户完全透明，用户只要知道，我们选择了最佳节点并保证数据一致性
3. 通过DELAY回放，主备同步由磁盘IO优化为内存IO；通过备节点新的缓存算法，进一步降低内存中要回放的WAL日志，最终保证主备delay极致小，为备机提供读服务提供方便
第2层：HE3FS CLIENT 内存
这一层主要缓存数据页的链表关系，HE3DB支持一主多备，主备存在非常低的DELAY，也就是主备实现是的最终一致性。因为HE3DB是共享存储，所以底层存储通过多版本数据页提供读服务
所谓数据页的多版本，通过基础页+WAL日志链表维护，一个日志对应一个版本，串行回放。所H3FS CLIETN 内存主要用于维护链表关系:
-
链表关系更新：备机从底层存储层读取WAL日志后，首先检察是否在HE3FS CLIENT内存中的链表是否缓存对应的数据页，如果缓存，进一步检察对应数据页是否在DATA BUFFER中，如果在，直接更新date buffer数据页，并更新h3fs client中的链表关系。如果链表找到数据页,但是data buffer没有命中，则只更新he3fs client 链表关系。这一步主要通过链表关系，快速检察计算引擎是否缓存对应数据页
-
读取数据页时，如果链表中有对应数据页，读取数据页以及对应链表中所有的WAL日志，由he3fs client回放成对应版本数据页
第3层：计算引擎本地盘
因为内存的大小始终有限，并且内存价格比较高,所以内存空间不会太大。所以我们并不能把所 有的热数据都保留到内存中，当内存无法缓存所有热数据时，部分数据会被替换到计算引擎本地盘中
本地盘缓存的数据包含: 基础数据页，WAL的链表关系，链表中的WAL日志
当计算引擎读取一个表的数据页时，如果data buffer没有命中，会底层读取本地盘数据，如果本地盘缓存了这个数据页,读取这个页并且基于链表关系读取相关WAL 日志，回放成对应版本的数据页，然后加载到data buffer中（整个过程，由he3fs client完成）
