-
3.4 复制
3.4 复制 3.4.1 复制的概述" level="4"> 3.4.1 复制的概述 3.4 复制 为了保证分布式存储系统的高可靠和高可用，数据在系统中一般存储多个副本。当某个副本所在的存储节点出现故障时，分布式存储系统能够自动将服务切换到其他的副本，从而实现自动容错。分布式存储系统通过复制协议将数据同步到多个存储节点，并确保多个副本之间的数据一致性... -
3.6.3 异构系统
3.6.3 异构系统 3.6.3 异构系统 传统数据库扩容与大规模存储系统的可扩展性有何区别呢？为了说明这一问题，我们首先定义同构系统，如图3-8所示。 图 3-8 同构系统 将存储节点分为若干组，每个组内的节点服务完全相同的数据，其中有一个节点为主节点，其他节点为备节点。由于同一个组内的节点服务相同的数据，这样的系统称为同构系统。同构... -
7.3.4 TrueTime
7.3.4 TrueTime 7.3.4 TrueTime 为了实现并发控制，数据库需要给每个事务分配全局唯一的事务id。然而，在分布式系统中，很难生成全局唯一id。一种方式是采用Google Percolator（Google Caffeine的底层存储系统）中的做法，即专门部署一套Oracle数据库用于生成全局唯一id。虽然Oracle逻辑上是一个... -
7.3.7 讨论
7.3.7 讨论 7.3.7 讨论 Google的分布式存储系统一步步地从Bigtable到Megastore，再到Spanner，这也印证了分布式技术和传统关系数据库技术融合的必然性，即底层通过分布式技术实现可扩展性，上层通过关系数据库的模型和接口将系统的功能暴露给用户。 阿里巴巴的OceanBase系统在设计之初就考虑到这两种技术融合的必然性，因... -
11.4.5 使用与运维
11.4.5 使用与运维 11.4.5 使用与运维 稳定性和性能并不是分布式存储系统的全部，一个好的系统还必须具备较好的可用性和可运维性。 1.吃自己的狗粮 开发人员和运维人员往往属于不同的团队，这就会使得运维人员的需求总是被开发人员排成较低的优先级甚至忽略。一种比较有效的方式是让开发人员轮流运维自己开发的系统，定期总结运维过程中的问题，这样，运维... -
第6章 分布式表格系统
第6章 分布式表格系统 6.1 Google Bigtable" level="3"> 6.1 Google Bigtable 6.1.1 架构" level="4"> 6.1.1 架构 第6章 分布式表格系统 分布式表格系统对外提供表格模型，每个表格由很多行组成，通过主键唯一标识，每一行包含很多列。整个表格在系统中全局有序，适用3.3.2节中讲的... -
3.3.2 顺序分布
3.3.2 顺序分布 3.3.2 顺序分布 哈希散列破坏了数据的有序性，只支持随机读取操作，不能够支持顺序扫描。某些系统可以在应用层做折衷，比如互联网应用经常按照用户来进行数据拆分，并通过哈希方法进行数据分布，同一个用户的数据分布到相同的存储节点，允许对同一个用户的数据执行顺序扫描，由应用层解决跨多个用户的操作问题。另外，这种方式可能出现某些用户的数据... -
3.5 容错
3.5 容错 3.5.1 常见故障" level="4"> 3.5.1 常见故障 3.5 容错 随着集群规模变得越来越大，故障发生的概率也越来越大，大规模集群每天都有故障发生。容错是分布式存储系统设计的重要目标，只有实现了自动化容错，才能减少人工运维成本，实现分布式存储的规模效应。 单台服务器故障的概率是不高的，然而，只要集群的规模足够大，每天都可... -
6.2.9 讨论
6.2.9 讨论 6.2.9 讨论 分布式存储系统有两个目标：一个是可扩展性，最终目标是线性可扩展；另外一个是功能，最终目标是支持全功能SQL。Megastore是一个介于传统的关系型数据库和分布式NoSQL系统之间的存储系统，融合了SQL和NoSQL两者的优势。 Megastore的主要创新点包括： ●提出实体组的数据模型。通过实体组划分数据，实... -
4.3 Facebook Haystack
4.3 Facebook Haystack 4.3.1 系统架构" level="4"> 4.3.1 系统架构 4.3 Facebook Haystack Facebook目前存储了2600亿张照片，总大小为20PB，通过计算可以得出每张照片的平均大小为20PB/260GB，约为80KB。用户每周新增照片数为10亿（总大小为60TB），平均每秒新增的...