建议先阅读前文HBase Snapshot基本原理。
HBase作为数据库，可以用于线上TP类需求，但如果直接基于HBase表运行AP类的离线分析型任务，则有2个问题：
所以HBase提供了工具，可以直接越过HBase层直接读存储在HDFS上的文件，常用的就是Scan Snapshot功能。好处是：
公司的HBase集群偶尔有个很奇怪的现象：内存占用会逐渐升高，超过堆内堆外内存限制，直到把操作系统内存占满被oom-killer杀死。在内存占用逐步升高的期间，响应延迟越来越高，最终服务宕机也会造成集群抖动，影响SLA。
内存增长过程非常缓慢，大概一两个月宕机一次。之前一直苦恼于没有现场，这次终于抓到了一个稳定复现的集群。
目前还没正式修复，修复验证也要几周时间，所以等我验证后再补充效果。
最近学习了MySQL的MVCC实现，然后看到了这篇博客详细介绍了PG MVCC的实现，以及这种实现有哪些问题。既能深入理解数据库MVCC实现基本原理，也能对比MySQL和PG的MVCC实现，理解为什么PG的MVCC深受吐槽，所以翻译了这篇文章。
现代数据库中，为提高并发行能，对于读写冲突，往往避免采用全程加锁的方案，而采用MVCC多版本并发控制。
本文简单介绍下HBase的MVCC的实现机制。
成熟的数据库都有备份与恢复的功能，在意外或故障时还能尽量恢复数据，同时还能实现数据迁移。接下来就是介绍HBase的备份与恢复功能——Snapshot。
出于学习目的，代码参考社区master分支，最接近的release版本应该是3.0.0-alpha-4，目前肯定是没有公司在线上使用的。也许实现细节上会有些区别，但核心逻辑基本一致。
HBase Snapshot具备以下能力：
在基于LSMT实现的数据库中，compaction是很重要的机制。compaction虽然有助于维持长期运行过程中的读低延迟，但在compaction过程中读延迟牺牲大。这篇论文中，深度分析了compaction相关的性能损耗，并提出了缓解的技术。我们将大的昂贵的compaction offload到了单独的compaction server，让datastore server更好地利用他自己的资源。此外，因为新compact的数据已经在compaction server的主内存里了，我们通过网络从compaction server把数据抓到datastore server的本地内存，避免读filesystem的性能损耗。事实上，在把workload切换到compaction server之前，预取 compact的数据已经可以消除缓存失效的影响，这时候compaction server只当是远程缓存。因此，我们实现了一个更智能的预热算法确保所有读请求都能被datastore server的本地缓存服务，即使它还在预热。我们已经集成进了hbase，使用YCSB和TPC-C的benchmark显示我们的方法显著消除了compaction相关的性能问题。也展示了compaction server可扩展性。
论文分享：Column-Stores vs. Row-Stores: How Different Are They Really?
面向列设计的数据库系统已经被证明，在一些 data warehouse 场景下，比传统的行存数据库的性能要高一个数量级。原因很简单：列存对只读查询的I/O效率更高，因为它们只从磁盘或内存中读所需的那些属性。
这种简单的认识导致了这样的假设，用行存也能获得列存的性能提升：通过垂直划分schema，或者通过索引每一列以便可以独立访问列。这篇论文就是为了证明这个假设是错的。
我们将各种不同配置下的商业行存与列存的性能进行了比较，结果表明，在数据仓库基准测试中，行存储的性能明显更慢。然后我们分析了两个系统的性能差异，结果显示在查询引擎层存在很大差异（除了存储层的明显差异）。我们分别梳理了这些不同，发现各种面向列的查询执行技术对性能的影响，包括向量化查询，压缩，和这篇论文中介绍的一种新的join算法。所以我们推断一个行存系统不可能获得列存的性能提升，要想充分获得列存的优势必须对存储层和查询引擎同时修改。
**单单是存储层的不同不足以构成如此大的性能差异，更重要的是查询引擎层的优化。**
最近AWS发布了DynamoDB新论文，不是涉及细节的学术论文，而是介绍了公有云在工业生产实践上的设计与实践。值得思考和学习。
这是在内部分享使用的，基本是论文翻译了。
Docusaurus允许创建独立页面，可以使用React或者Markdown来写。我刚好实现自己的导航页面。
写博客每次都要写一堆matter信息，贼麻烦，用hygen工具生成。