分类目录:存储系统

Google File System

写在前面 最近没什么论文好看,于是乎又翻阅起了分布式存储系统的老祖宗GFS。开始愈发理解之前的领导花总说的:常读常新。 之前也阅读过GFS的论文,但总是一带而过,很多问题没有想的特别清楚。于是,趁着这次阅读,将我对于GFS的理解总结下来,希望有所帮助。 再次阅读GFS,给我最大的感触是:许多的问题,只能这么做,而且最好就这么做,也充分体会到了简洁优雅的系统设计给我带来的冲击。

mongodb集群化部署(sharding + replication)

说明 Mongodb是一个非关系型的分布式数据库,它可以通过自身的群集技术组成mongodb群集,进而实现数据库的横向扩展和数据库的高可用功能。Mongodb数据库群集分为Replica Sets(复制集)和Sharding(分片)两个部分。其中Replica Sets实现了mongodb数据库的高可用功能,Sharding分片实现了数据库的横向分布式扩展。在生产环境中搭建mongodb群集时一般都采取了Replica Sets+Sharding的解决方案。

LevelDB详解: Compaction

说明 LevelDB是日志型KV存储系统,所有的更新操作(包括插入、更新、删除)都以(key, value)的形式追加至log文件的尾部,这样,系统中更新的访问模式就变成了顺序写,很适合更新频繁的应用场景。

Ceph科普

基本概念 Pool Pool是Object的逻辑组合,之所以划分成Pool,是因为在Ceph RADOS中,可以按照Pool来设置PG数量、副本策略等。 每个Pool下管辖多个PG,PG的数量可以通过更新Pool的属性来设定。 注意: Pool是RADOS层抽象的概念,至于映射成更上层的RBD、RGW什么概念,目前尚不清楚; Pool是逻辑概念,不同Pool可能的内容映射至底层相同的OSD; 实践中可以为每个pool在crushmap中定义rule,可以指定pool的一些个性化策略,比如可以为某个pool设置特定的存储介质ssd、设定pool的副本数等。

LMDB调研

事务管理 LMDB中所有的读写都是通过事务来执行,LMDB事务具备以下特点: 支持事务嵌套(??) 读写事务可以并发执行,但写写事务需要被串行化 因此,在lmdb实现中,为了保证写事务的串行化执行,事务执行之前首先要获取全局的写锁。

浅谈BoltDB的数据结构设计

前言 伟大的Linus曾说过下面的话: “烂程序员关心的是代码。好程序员关心的是数据结构和它们之间的关系。” 以前的我在阅读开源代码时,经常过于痴迷于复杂的业务逻辑,而不能自拔。每每将仔细陷入一种痛苦万分却又无可奈何的境地,苦不堪言却也收获甚微。

BoltDB之COW技术

说明 COW,Copy-On-Write技术,是在并发资源访问场景中的一种资源保护模式。当资源仅有读取访问而无更新时,资源仅存在单一副本,但当有对资源进行修改时,将资源复制一份,然后修改复制后的资源,这便是Copy On Write的核心含义。

BoltDB之Bucket(二)

前言 我们在前面的博客中详细描述了BoltDB的Bucket存储格式以及针对Bucket的一些关键动作。但在前讲我们关注的重点是Inline Bucket,也即Bucket内所有的KV记录都紧随Bucket的记录而存放,这样可以提高Bucket的搜寻效率。 但随着数据量的增长,一个Bucket无法永远保存Inline的特性,总会在某个点的时候,Inline Bucket终究还是要成为非Inline Bucket,在本篇博客中,我们就来关注一个Inline Bucket如何变成非Inline Bucket以及非Inline Bucket在BoltDB底层的存储形式。

BoltDB之Bucket(一)

概述 BoltDB中的Bucket类似于传统关系型数据库的”表”。BoltDB通过Bucket将一个庞大的数据库划分成诸多的命名空间。用户在每个命名空间内存储KV数据,通过此种办法可以提高数据的搜索效率。 例如,一个BoltDB中可: 创建User Bucket,用于记录用户信息(存储的K是用户名,而Value是用户详情) 创建Order Bucket,用户记录用户订单信息(存储的K是用户名,而Value则是订单详情) ……