ITPub博客

paxos 说multi-paxos之前先简要说一下paxospaxos是在多个成员之间对某个值(提议)达成一致的一致性协议。这个值可以是任何东西。比如多个成员之间进行选主，那么这个值就是主的身份。在把multi-paxos协议应用在日志同步中时，这个值就是一条日志。网上讲paxo…

Spanner要满足的external consistency是指：后开始的事务一定可以看到先提交的事务的修改。所有事务的读写都加锁可以解决这个问题，缺点是性能较差。特别是对于一些workload中只读事务占比较大的系统来说不可接受。为了让只读事务不加任何锁，需要引入多版…

这篇文章是对知乎上如何自己实现一个关系型数据库的一个尝试性回答，后续会不断更新。对外数据模型为关系型数据库，内部的实现主要分成两大类，一类是disk-based，比如mysql，postgres，一类是memorybased，后者包括MemSQL，SAPHAHA，OceanBase。这里说一个dis

physicalclock机器上的物理时钟，不同的机器在同一个时间点取到的physicalclock不一样，之间会存在一定的误差，NTP可以用来控制这个误差，机器之间的时钟误差可以控制在几十ms以内。两个事件a和b，a在机器M1上physicalclock为12点5分0秒6ms发生，b在机器M2上p

HBase对外暴露出来的是一个表格数据模型，如下图所示rowkey应用程序可以自己设计。每一个Cell可以保存多个版本的数据，由timestamp标示版本。应用程序可以自己指定timestamp，如果不指定HBase会设置为当前时间。RegionServer是HBase对外提供数据存取的server

今天谈谈分布式事务的时序问题。在说这个问题之前首先说说这为什么是个问题。单机场景对于数据库来说，读到已经commit的数据是最基本的要求。一般来说，为了性能，读写不互相阻塞，现在的数据库系统(Oracle，MySQL，OceanBase，Spanner，CockRoachDB,HBase)几乎无一例

F1是Google开发的分布式关系型数据库，主要服务于Google的广告系统。Google的广告系统以前使用MySQL，广告系统的用户经常需要使用复杂的query和join操作，这就需要设计shard规则时格外注意，尽量将相关数据shard到同一台MySQL上。扩容时对数据reshard时也需要尽量

HDFSAppend时packet的格式以及DataNode对block/checksum文件的处理HDFS的Block一般比较大，默认64MB/128MB，客户端给DataNode发数据实际上是以Packet的形式发送的，Packet一般只有64KB左右。Packet内部由分为一个个chunk，每

HDFS-RAID是Facebook基于hadoop-20-append分支(第一代Hadoop)开发的raid方案，对HDFS的修改极少，主要包括为NameNode增加了根据block信息找到block所属文件的接口。RAID的基本知识和目前社区的方案对比见这，本文重点分析HDFS-RAID的原理

Facebook在OSDI2014上发表论文f4:Facebook’sWarmBLOBStorageSystem，这个系统主要目的就是降低存储成本，在容忍磁盘，主机，机架，数据中心的同时提供2.1倍的存储因子(用户存储的1bit数据实际上占用磁盘2.1bit空间)。本文只讨论f4系统的核心Erasu

最近迁移数据时需要执行大Scan，HBase集群经常碰到以下日志:Exceptioninthread"main"org.apache.hadoop.hbase.DoNotRetryIOException:FailedafterretryofOutOfOrderScannerNextException

存储选型Blob(binarylargeobject)存储系统主要用来存储二进制的大对象，比如图片，视频。这样的数据不太适合存储在类LSM系统例如HBase中，原因在于这种数据尺寸相对较大，写入RegionServer的memstore后很快会触发region的flush，在磁盘上形成大量的数据文件

HDFS目前存储文件的方案是将一个文件切分成多个Block进行存储，通常一个Block64MB或者128MB，每个Block有多个副本(replica)，每个副本作为一个整体存储在一个DataNode上，这种方法在增加可用性的同时也增加了存储成本。ErasureCode通过将M个数据block进行编

这篇分析一下LeaseRecovery和BlockRecoveryhdfs支持hflush后，需要保证hflush的数据被读到，datanode重启不能简单的丢弃文件的最后一个block，而是需要保留下hflush的数据。同时为了支持append，需要将已经finalized的block重新打开追加

这篇分析一下namenode写editlog的过程。关于namenode日志,集群做了如下配置<property><name>dfs.nameservices</name><value>sync</value><description

HDFS的hflush,hsync和close有啥区别，分别做了什么hflush:语义是保证flush的数据被新的reader读到，但是不保证数据被datanode持久化.hsync:与hflush几乎一样，不同的是hsync保证数据被datanode持久化。close:关闭文件.除了做到以上2点，

上一篇说了datanode端如何处理pipeline写请求的，这里主要看DFSClient。这里以append为例,write差不多。创建一个pipeline用于append操作的流程:FileSystem.get(configuration)返回一个已经初始化完成的DistributedFileS

站在DataNode的视角，看看pipeline写的流程，本文不分析客户端部分，从客户端写数据之前拿到了3个可写的block位置说起。每个datanode会创建一个线程DataXceiverServer，接收上游过来的TCP连接，对于每个新建的TCP连接,都会创建一个叫做DataXceiver的线程

HBaseCompaction策略RegionServer这种类LSM存储引擎需要不断的进行Compaction来减少磁盘上数据文件的个数和删除无用的数据从而保证读性能。RegionServer后台有一组负责flushregion的线程(MemStoreFlusher)，每次从flushQueue中

分裂策略不同的分裂策略的实现需要继承RegionSplitPolicy，主要实现两个方法：shouldSplit()表示是否需要分裂getSplitPoint()得到分裂点rowkey从HBase0.94之后，默认的分裂策略是IncreasingToUpperBoundRegionSplitPoli