关于内存计算的不成熟的理解

说明

自己其实没有做过大数据内存计算方面的工作.
仅是对硬件知识有一些了解.
想着简单描述一下自己所理解的内存计算.
可能有多偏颇的地方.
简单记录一下. 后面学习了之后再来勘误.

内存计算的源头-存储的分级

CPU寄存器 ~0.4ns
一级缓存  ~1.0ns
二级缓存  ~4.0ns
三级缓存  ~16ns
主内存    ~60ns
NvmE      ~3us
sataSSD   ~10us
HDD       ~5ms

简单列了下不同存储的延迟情况.
越靠近CPU的延迟越低价格越高.
认为对速度的追求越来越高.随着内存价格的急剧降低
大家都想使用尽可能多的内存来进行相关的计算来提高速度.
内存比硬盘快3-5个数量级是内存计算能够提速的根本.
越来越低的存储器价格则是内存计算飞入寻常百姓家的基础.

内存计算的源头-大数据时代的到来

存储的分级与性能的优化仅是客观因素
大数据时代的到来才是推动内存计算的蓬勃发展的主要因素
OLTP 关系型数据库时代. 内存更多的是用来进行加速和缓存的
现如今的内存计算.基本上都是将内存作为主存储器来使用.
大数据库下的内存计算考虑的更多的是一个趋势. 而不是精确计算
这也就是很多AI计算要求半精度浮点运算(16位)而不是全精度

不管是第一代基于硬盘的hadoop的大数据
还有基于内存或者是流式计算的Spark和Storm很多计算结果并不要求完全精确
能够出现trend其实就可以了. 可以用来决策就可以了.

内存计算的流派

Google是大数据之父
他的Bigtable,GFS以及mapreduce 是大数据的基石.
他直接引领了世纪初的技术革新. 
Hadoop本质就是以Google的发布的论文为需求规格研发出来的一套山寨版
这一点与最近几年大火的K8S与Google自己的Borg的逻辑关系有的一拼. 
但是因为硬盘的速度较慢. 以及现在不管是社交还有流媒体对响应速度的要求越来越高
基于磁盘的Hadoop的玩法就无法跟上潮流. 于是就有了
基于批处理的Spark一基于流处理的Storm等内存计算框架(不严谨的分法)

内存计算的流派

hadoop与spark与storm 在大数据流处理上面大放异彩 相得益彰
但是处理的基本上还是非结构化数据,虽然有类似SQL的工具处理.但是与标准SQL
比如SQL92的差异性还比较大. 也不太支持关联等查询操作. 

ignite等内存计算框架则是实现了内存计算与标准SQL的一些融合. 
能够将数据集加载进内存. 然后通过自己的一套SQL解析引擎进行解析. 
实现类似于内存级别的OLTP数据库等功能.

可以作为ERP等基于RDBMS的重型数据库的内存缓存数据库来提高性能. 
与之对应的ignite的很多性能其实是受限制于三大方面
内存的带宽.
CPU的计算能力
以及与标准数据库的ETL速度.

关系型数据库的内存计算

Oracle数据库和SQLSERVER数据库作为RDBMS排名前两位的存在
十年前就开始布局内存计算的场景.
但是因为OLTP数据库要求100%不允许丢失数据. 关系型数据库进行内存计算
还是很多畏首畏尾的. 
比如Oracle可以将表空间放置于内存中. 但是依旧会经常写入磁盘保证数据不丢失.

HANA算是一个例外. SAP收购了曾经更微软一起开发SQLSERVER的sybase之后
将sybase在数据库上面的造诣一古脑的放置于HANA的内存数据库上面来.

其实HANA本质上就是一个内存计算的节点
只不过他的一致性是由他的硬件认证来托底. 并且有严格的日志和写盘规则以及大电容来保证安全.

内存计算与传统应用的碰撞

短时间来说 内存计算通过ETL抽取传统应用的RDBMS数据库内容.
然后进行计算分析. 进行企业智能分析.决策分析.制定财务和生产计划是最大和最可行的场景. 

其次. 基于大量数据的业务查询. 
但是认为这一块需要业务系统同步进行修改. 比如冷热数据拆分.
热数据通过OLTP类似于Oracle的内存数据库进行存放.
冷数据通过ETL等工具抽取到内存数据库进行查询和联查分析
区分数据的冷热程度进行不同程度的展示来降低OLTP的资源占用率.提高日常使用效率
又通过near-line的冷数据进入内存分析. 进行高速查询.可以提高产品的易用性

个人认为比较难的是一些比较大的计算场景.
如果需要从OLTP抓取数据计算完再写入. 此场景需要严格管控使用模式
避免抽取-计算-写入的时间段内有业务操作. 不然会导致计算不准确和数据丢失. 

内存计算的瓶颈

回到存储的分级. 因为OLTP数据库有着五十多年的积淀与发展
实际上高级的商用数据库已经可以将硬件压榨到了极致. 
虽然看起来内存的延迟和带宽比磁盘要好很多. 

但是因为内存计算的很多算法其实并没有很好的去跟CPU的cache-line以及寄存器等高速运算组件
进行很合时宜的融合. 

所以有时候内存计算的提升并不像是硬件宣传的那样数据集的提升
可能多付出三五倍的硬件设备只能获取2-3倍的性能提升. 还会被并不是非常专业的非原厂的ETL以及
数据清洗拖后腿. 

应用研发的核心其实是人才. 
开源的组件很多仅是覆盖一小块场景.
数据库这么多年的发展, 其实覆盖面远远高于最近几年才兴起的一些内存计算框架.
诚然因为OLTP的一些历史包袱.可能不如内存计算来的轻便.
但是这么多牛人.算法的结晶, 不是这么简单就可以被越来越廉价的内粗晶体管所打败的

决定性能的永远是最聪明的人. 哪个公司拥有最聪明的人, 哪个公司就有最优秀的产品, 最杰出的性能.