qq_40448657的博客

Epoch-based Commit and Replication in Distributed OLTP Databases记录一篇之前读过的论文。。。整篇论文的核心在于Epoch，将传统数据库以事务为粒度提交和恢复变成了以Epoch为粒度来提交和恢复，这样做的好处就是可以减少2PC和同步复制的时间开销。并且提出两种OCC算法，对于Epoch机制来说很有好处。这篇文章理论介绍性居多，对于事务处理的流程做了很详细的解释，包括2PC的处理，容错的处理，及事务各生命周期的伪代码，如果各位有兴趣可以

Retrofitting High Availability Mechanismto Tame Hybrid Transaction/AnalyticalProcessing怎么说呢，HTAP也算是这几年比较热门的一个讨论方向，这篇论文胜在工作量吧，从OSDI 2018的DrTM+H基础上，加上了AP系统，论文对标MonetDB，整合成了现在的OLTP系统，VEGITO，并且TP性能和AP性能也没有明显的降低，有一个很好的扩展性，以及数据的Fre...

以下分享一下个人对于CRDB论文的些许浅见首先说一点，CRDB只支持Serializable隔离级别，是我目前见到最极端的数据库，只支持这种强隔离级别，可以预见的是，他数据库的吞吐量应该不会太高，但是事务abort率应该也不会高，因为事务执行机制导致事务只能Serializable的隔离级别执行。这种工业级的数据库，强隔离级别的应用场景我觉得可能银行，股票这些比较适合吧？适用场景或许不是很多？YugaByteDB和CRDB都是源于Google的Spanner，以后会看看YugaByteDB的论文看看

在上篇记录了如何初步使用CRDB，但是想要更多了解CRDB以及为了完成CRDB客户端没实现（可能我没找到）的某些功能，就需要自行阅读源码进行更改并进行编译，在更改源码过程中，因为怕影响CRDB性能，基本不会删除某些关键性代码，因为我需要的是查看CRDB测试时的abort率，以及事务的生命周期，以及每个阶段所消耗的时间，所以只对其做出了增加时间戳以及记录的代码，并不会影响数据库性能。下面，是我在编译过程中记录的语句。该说不说，CRDB的官方编译指南是真简洁，官方的指南1还有指南2仅作参考首先还是说初始..

这段时间老师需要我测试CRDB的性能，因而对CRDB做了些简单的了解，可以进行简单使用及测试编译，首先说明我使用的是阿里云服务器Ubuntu20.04，各位可以根据需要自行选择操作系统，centos和ubuntu，CRDB都支持,下面是我在配置三节点跨域集群过程中记录的执行语句安装CRDB下面的版本可以根据需要自行更改curl https://binaries.cockroachdb.com/cockroach-v21.2.4.linux-amd64.tgz | tar -xz &&a