NOSQL Notes -- IT技术博客大学习 -- 共学习共进步！

• 持续可用与CAP理论 – 一个系统开发者的观点

在金融数据库中，由于强一致性是必选项，因此，要做到持续可用比较困难，但也并不是不可能，CAP和持续可用并不矛盾。成熟的商业数据库都是基于共享存储的，不过基于Paxos的持续可用方案开始越来越多地应用到核心场景，例如Google Spanner，Microsoft SQL Server云版本，Amazon DynamoDB，而Aliababa OceanBase也在金融核心场景得到了验证。同时，笔者认为，采用Paxos协议，虽然工程难度很高，但是，只要在实现上做到极致，在同城的情况下，可以容忍单个IDC故障，且性能损耗非常小；而在异地的场景，考虑到光速不可突破，往往由业务在一致性和可用性之间权衡。越来越多的云数据库将会采用Paxos来实现持续可用。

• AWS云平台系列介绍（一）：AWS平台与EC2介绍

AWS整体介绍 Amazon平台的产品分为几个部分：计算类：包含弹性计算云（EC2）和弹性MapReduce（Elastic MapReduce）这两个产品。EC2几乎可以认为是迄今为止云计算领域最为成功的产品，通俗地将，就是提供虚拟机。EC2的创新在于允许用户根据需求动态改变虚拟机实例的类型及数量，技术上支持容错并在收费模式上支持按使用量付费，而不是预付费。弹性MapReduce将Hadoop MapReduce搬到云环境中，大量EC2实例动态地成为执行大规模MapReduce计算任务的工作机。存储类：存储类产品较多，包括弹性块存储EBS，简单消息存储SQS，Blob对象存储S3，表格存储系统Simpledb和DynamoDB以及分布式数据库系统RDS。其中，EBS相当于一个分布式块设备，可以直接挂载在EC2实例上，用于替代EC2实例本地存储，从而增强EC2可靠性。

• GFS论文重读

Google文件系统（Google File System，GFS）是构建在廉价的服务器之上的大型分布式系统。它将服务器故障视为正常现象，通过软件的方式自动容错，在保证系统可靠性和可用性的同时，大大减少了系统的成本。 GFS是Google云存储的基石，其它存储系统，如Google Bigtable，Google Megastore，Google Percolator均直接或者间接地构建在GFS之上。另外，Google大规模批处理系统MapReduce也需要利用GFS作为海量数据的输入输出。系统架构 GF...

• 跨机房问题

跨机房问题一直都是一个老大难的问题，先看传统数据库的跨机房方案。 Master/Slave方案这是最常用的方案，适用于大多数需求。Master将操作日志实时地发送到Slave，Slave当成Master的一个Hot Backup。Master宕机时，服务切换到Slave，需要修改客户端逻辑使得Master失效时自动寻找新的Master。这个方案有一个问题就是数据库的Master和Slave一般不是强同步的，所以，切换到Slave后可能丢失宕机前的少量更新。如果将Master和Slave做...

• Google Megastore系统事务机制

最近CSDN头条有一篇介绍Google Megastore的文章，讲得挺好，本文主要针对Google Megastore的事务实现做一个更详细的探讨。Google Megastore的底层是GFS + Bigtable系统，GFS + Bigtable解决可扩展性问题，但提供的用户接口简单：读接口只提供Get随机读取和Scan连续扫描，写接口也只能够支持单行事务。Google Megastore构建在Bigtable系统之上，通过客户端封装复杂的特性，包括事务支持，基于Entity Group的数据模型，多机房同步等...

• 从Megastore看RDBMS和NOSQL系统结合

RDBMS的优势在于功能，包括事务，强一致性，同时支持随机读和顺序扫描，索引。NOSQL系统的优势在于扩展性和性能。Google的经验告诉我们，系统设计的关键点还是在于可扩展性，依赖于底层GFS+Bigtable提供的无与伦比的可扩展性，Megastore能够在上层不断完善功能，兼具RDBMS和NOSQL系统的优点。 1, 兼顾随机读和顺序扫描。Bigtable底层的存储引擎为MemTable + SSTable构成的Merge-Dump存储引擎，SSTable设计成8K ~ 64K的块，块之间有...

• GDB的两个技巧

分享两个GDB的小技巧： 1, GDB失效时手工得到stack； 2, GDB执行用户命令脚本；调试内存型服务程序的有时会遇到core dump或死锁问题，且gdb或者pstack都无法显示调用栈（call stack）。这是因为线程的调用栈被破坏了，而调用栈存放了函数的返回地址，gdb解析函数返回地址（根据地址查找符号表）失败，gdb也没有进行容错处理，只要有一处地址解析失败就无法展开调用栈。然而幸运的是，调用栈往往只是部分被破坏，RSP堆栈寄存器中保...

• 缓存设计的一些思考

互联网架构中缓存无处不在，某厂牛人曾经说过：”缓存就像清凉油，哪里不舒服，抹一下就好了”。高品质的存储容量小，价格高；低品质存储容量大，价格低，缓存的目的就在于”扩充”高品质存储的容量。本文探讨缓存相关的一些问题。 LRU替换算法缓存的技术点包括内存管理和替换算法。LRU是使用最多的替换算法，每次淘汰最久没有使用的元素。LRU缓存实现分为两个部分：Hash表和LRU链表，Hash表用于查找缓存中的...

• Microsoft Azure Storage架构分析

Microsoft云存储服务分为两个部分，SQL Azure和Azure Storage。云存储系统的可扩展性和功能不可兼得，必须牺牲一定的关系数据库功能换取可扩展性。Microsoft实现云存储的思路有两种： 1, 做减法。SQL Azure直接在原有的SQL Server上引入分布式的因素，在满足一定可扩展性的前提下尽可能不牺牲原有的关系型数据库功能。SQL Azure的可扩展性是有限的，单个SQL Azure实例不允许超过50GB，这是因为SQL Azure不支持子表动态分裂，单个SQ...

• Amazon S3 & Simpledb内部实现分析

Amazon S3申请了一篇专利，名称为”Keymap Service Architecture for A Distributed Storage System“，而Amazon Simpledb的实现细节暂时没有公开。本文根据Dynamo论文，S3专利以及S3&Simpledb的对外API尝试推测这两个系统的内部实现。

• Amazon分布式系统Dynamo

从09年第一次阅读Dynamo论文，到最近阅读Amazon S3的一篇专利，一路过来对论文的理解可以简单归结为两个字

• SQL到NOSQL的思维转变

NOSQL系统一般都会宣传一个特性，那就是性能好，然后为什么呢？关系型数据库发展了这么多年，各种优化工作已经做得很深了，NOSQL系统一般都是吸收关系型数据库的技术，然后，到底是什么因素束缚了关系型数据库的性能呢？我们从系统设计的角度看这个问题。

• 【分布式系统工程实践】随机访问KV存储引擎

Key-Value系统只需要支持简单的随机读(Get)，写(Put)和删除(Del)操作。由于磁盘是顺序存储介质，因此可以往数据文件追加Key-Value记录并在内存中存放记录所在的磁盘位置，即索引信息。由于对同一个Key的更新(Put)操作以最后一个为准，内存中的索引只需要记录最新的Key-Value对位置即可，而对于删除操作，也是往数据文件追加一个删除记录。由于内存的大小有限，需要尽可能减小索引记录的大小，比如只支持64位的整数Key（其它类型的K...

• 【分布式系统工程实现】Bigtable Merge-Dump存储引擎

单机存储引擎解决单机读写问题，Merge-Dump存储引擎设计成一种通用的存储引擎，同时支持数据写入，随机读取和顺序扫描功能。顺序扫描功能应用很广，比如MapReduce批处理，同一个广告主的所有关键词广告统计，用户浏览所有的收藏信息，淘宝卖家管理大量的商品等。简单的KV系统只需要支持随机读取，而类似Bigtable这样的通用表格系统需要考虑基于主键的顺序扫描功能。

• Facebook Haystack图片存储架构

OSDI 10中有一篇Facebook图片存储系统Haystack的论文，名称为”Finding a needle in Haystack: Facebook’s photo storage”。从这篇论文可以看出，数据量大的应用有时也并不复杂。我们先给Facebook图片存储系统算一笔账。Facebook目前存储了260 billion图片，总大小为20PB，通过计算可以得出每张图片的平均大小为20PB / 260GB，约为800KB。用户每周新增图片数为1 billion (总大小为60TB)，平均每秒钟新增的图片数...

• GLIBC内存分配机制引发的“内存泄露”

我们正在开发的类数据库系统有一个内存模块，出现了一个疑似”内存泄露”问题，现象如下：内存模块的内存释放以后没有归还操作系统，比如内存模块占用的内存为10GB，释放内存以后，通过TOP命令或者/proc/pid/status查看占用的内存有时仍然为10G，有时为5G，有时为3G, etc，内存释放的行为不确定。首先说一下内存模块的内存管理机制。我们的内存管理很简单，使用全局的定长内存池，每一个内存块为64KB，如果申请的内存小...

• 【分布式系统工程实现】如何检测一台机器是否宕机？

检测一台机器是否宕机的应用场景如下： 1, 工作机器宕机，总控节点需要能够检测到并且将原有服务迁移到集群中的其它节点。 2, 总控节点宕机，总控节点的备份节点（一般称为Slave）需要能够检测到并替换成主节点继续对外服务。检测一台机器是否宕机必须是可靠的。在大规模集群中，机器可能出现各种异常，比如停电，磁盘故障，过于繁忙导致假死等。对于机器假死，如果总控节点认为机器宕机并将服务迁移到其它节点，假死的机器又认为...

• GFS, HDFS, Blob File System架构对比

分布式文件系统很多，包括GFS，HDFS，淘宝开源的TFS，Tencent用于相册存储的TFS (Tencent FS，为了便于区别，后续称为QFS)，以及Facebook Haystack。其中，TFS，QFS以及Haystack需要解决的问题以及架构都很类似，这三个文件系统称为Blob FS (Blob File System)。本文从分布式架构的角度对三种典型的文件系统进行对比。我们先看GFS和HDFS。HDFS基本可以认为是GFS的一个简化版实现，二者因此有很多相似之处。

• Microsoft Azure存储架构设计

SQL Azure简介 SQL Azure是Azure存储平台的逻辑数据库，物理数据库仍然是SQL Server。一个物理的SQL Server被分成多个逻辑分片(partition)，每一个分片成为一个SQL Azure实例，在分布式系统中也经常被称作子表(tablet)。和大多数分布式存储系统一样，SQL Azure的数据存储三个副本，同一个时刻一个副本为Primary，提供读写服务，其它副本为Secondary，可以提供最终一致性的读服务。每一个SQL Azure实例的允许的最大数据量可以为1GB...

• 分布式系统的数据结构

常用的数据结构包括：数组，队列，堆栈，链表，树（平衡二叉树，B树，Trie树，堆），哈希表，图，后缀数组，等等。其中，堆，图结构，Trie树及后缀数组解决特定问题，其它数据结构解决通用的查找，更新，删除操作。查找，更新和删除操作一般是O(1)，O(logN)或者O(N)，通用的数据结果大致可分为如下三种： 1, 极端型；某些操作的算法复杂度为O(1)，另外一些算法复杂度为O(N)，比如有序链表查找复杂度为O(N)，更新和删除为O(1)； 2,...