分布式实时处理系统:原理、架构与实现
上QQ阅读APP看书,第一时间看更新

1.5.1 分布式存储概念

分布式存储系统通常指的是有多个用于存储信息的节点的计算机网络,而且对于绝大多数分布式存储系统来说,它们都会原生支持节点之间的数据复制和同步。一般来说,如果用户的数据是存储在多个节点或对等网络节点中,其中对等网络节点指的是在网络拓扑结构中,各个节点地位相同,没有主从关系,则把这类系统称为分布式存储系统。

考虑到分布式存储系统的多节点存储特性,就不得不思考如何才能高效地访问大批量节点的数据。因此,绝大多数分布式存储系统都是非关系型数据库。当然,凡事都有例外,像Oracle Clusterware、MySQL的Sharding集群方案,也能解决一定程度上的分布式存储需求。

提示 Oracle Clusterware是一款能让多个服务器协同工作(作为一套系统)的可移植的集群软件。该软件首次由Oracle 10g Release 1提供,其初衷是实现一套Oracle多点数据库的集群技术,基于Oracle的Real Application Clusters(RAC)技术。

MySQL Sharding与普通的集群负载均衡方案不同。完整的集群方案中,分布式系统会自动帮助用户完成负载均衡等工作,帮助用户建立分布式索引与缓存等。但是早期的MySQL并不支持这种高级特性,MySQL中,用户需要手动将自己的关系数据根据表格切分到不同的数据库或者主机中,比起完整的集群解决方案,这种方式是较为复杂的。

对于分布式存储系统来说,最重要的问题是如何确保在众多节点中保持数据的一致性、容错性、数据可恢复能力和负载均衡。一般来说,为了确保每个节点访问的负载保持在一个水平上,我们还要考虑数据的分布问题,采用什么方法确保数据分布的均匀性,除了数据均匀,我们还要考虑数据访问的频率等因素,这样才能确保节点负载和访问频率保持相对均衡,例如,在Apache Cassandra中,就使用Partition Key作为数据分布存储的依据之一对数据进行存储。另外,对于数据写入的事务性也是需要确保的,这是传统关系型数据库系统必备的功能之一,但在分布式系统中的实现方法会很不一样。事务性不仅仅是分布式存储系统所需的特性之一,对于分布式实时处理系统来说,操作的事务性同样重要,在后续章节中将会介绍实时数据处理的事务功能。

提示 Cassandra是一套开源分布式NoSQL数据库系统。它最初由Facebook开发,用于存储收件箱等简单格式数据,集Google BigTable的数据模型与Amazon Dynamo的完全分布式的架构于一身。Facebook于2008将Cassandra开源,此后,由于Cassandra良好的可扩展性,被Digg、Twitter等知名Web 2.0网站所采纳,成为了一种流行的分布式结构化数据存储方案。

Cassandra是一个混合型的非关系的数据库,类似于Google的BigTable。其主要功能比Dynamo(分布式的Key-Value存储系统)更丰富,但支持度却不如文档存储MongoDB(介于关系数据库和非关系数据库之间的开源产品,是非关系数据库中功能最丰富、最像关系数据库的。支持的数据结构非常松散,是类似JSON的BJSON格式,因此可以存储比较复杂的数据类型)。

更多内容请读者参阅项目官网:https://cassandra.apache.org/

和传统的关系型数据库(Oracle 11g)相比,这些NoSQL数据都各有优缺点。

1)模式相对自由,适合存储非结构化数据:NoSQL数据库往往没有严格的数据模式限定,因此我们可以在业务需求变更时方便地修改数据库模式而不会引起原来数据的变化。这个特性的优点在于可以快速适应业务变化,缺点在于没有模式来帮助我们维护数据的合法性。

2)数据一致性和事务性较弱:NoSQL往往为了提升速度而舍弃了许多数据一致性的保证。在NoSQL中,数据一致性完全需要用户在上层逻辑中维护。此外,NoSQL大部分都不支持事务或者事务功能较弱,基本都是基于性能而舍弃这些特性。

3)查询与关联功能有限:由于NoSQL没有像关系型数据库那样,数据之间有那么多关联,因此难以建立很完善的查询与关联功能,即使有(如Cassandara),也会在功能上有诸多限制。一般关联需要用户在上层解决。

4)读写性能问题:部分NoSQL的读写性能并不是非常好,如Cassandra,在写入时非常快,但是读取时则较慢。而MongoDB这种文档型数据库进行简单的检索时很快,但是当检索条件复杂时(无法充分利用索引时),速度就会很慢。一般NoSQL由于不需要维护数据一致性,因此都具有很高的写入性能。