大数据四大阵营

Posted 2021-12-17 ML李嘉图

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了大数据四大阵营相关的知识，希望对你有一定的参考价值。

OLTP
- NoSQL
- NewSQL数据库
OLAP
- Hadoop
- MPP
流数据

任何高性能系统，都是相对的，找到自己合适的就是对的！

依据不同的实现理念、方式以及应对不同的业务及应用场景，可以把大数据解决方案划分为四大类!

OLTP（在线事务、交易处理）：RDBMS( Relational Database Management System)、NoSQL、NewSQL
OLAP（在线分析处理）：MapReduce、Hadoop、Spark等
MPP（大规模并行处理）：Greenplum、Teradata Aster等
流数据管理：CEP/Esper、Storm、Spark Stream、Flume等

OLTP

OLTP阵营可以分为：

传统的关系型数据库

NoSQL

NewSQL

NoSQL

NoSQL类系统普遍存在下面一些共同特征：

· 不需要预定义数据模式（No-Upfront-Schema）或表结构：数据中的每条记录都可能有不同的属性和格式。当插入数据时，并不需要预先定义它们的模式。

· 无共享（Shared Nothing）架构：NoSQL通常把数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输（如NAS/SAN）来读取数据的性能，从而提高了系统的性能，当然，代价是多份数据拷贝及数据一致性保证。

无共享架构（Shared Nothing Architecture (SNA) ）是一种分布式计算架构，由多个不共享资源的独立节点组成。节点是独立和自给自足的，因为它们有自己的磁盘空间和内存。

· 分区：NoSQL需要对数据集进行分区，将记录分散在多个节点上面。并在分区的同时进行复制。这样既提高了并行性能，又能保证没有单点失效的问题。

· 弹性可扩展：可以在系统运行的时候，动态添加或者删除节点。不需要停机维护，数据可以自动迁移。

· 异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据。

· 符合BASE模型：BASE提供的是最终一致性和软事务（相对于事务严格的ACID模型，下文中的NewSQL在NoSQL基础上实现了对ACID模型的支持）。

以下再对颇具代表性的MongoDB（文档型）、Cassandra（宽表型）、Redis（键值型）和Ultipa Graph（图数据库）解决方案进行介绍。

一种通过牺牲高一致性来获得可用性或可靠性的模型。主要包括基本可用性、软状态（柔事务性）和最终一致性。

文档型NoSQL—MongoDB

作为文档型NoSQL数据库的代表，MongoDB采用了一种与RDBMS反其道而行之的设计理念，不需要预先定义数据结构，使用了与JSON（JavaScript Object Notation）兼容的BSON（Binary JSON）的轻量级数据传输与存储结构（相对于笨重、复杂的XML而言，XML一直以其解析复杂而被广大Web开发人员所诟病），也不需要对存储的数据结构像关系型数据库一样进行正则化（Normalization，目的是减少重复数据）。

例如构建一个数字图书馆，如果用传统的RDBMS则至少需要对书名、作者等相关信息使用多个正则化的表结构来存储，

在进行数据检索与分析的时候则需要频繁的（且昂贵的）表JOIN操作，

而MongoDB中则只需要通过对JSON（在MongoDB中称作BSON，Binary JSON）描述的简单文档型数据结构进行一次读操作即可完成。

对于提高性能以及在商用硬件上扩展而言MongoDB的优势不言而喻，同时MongoDB也兼顾关系型数据库操作习惯，例如它保留了left-outer JOIN操作……

宽表型NoSQL—Cassandra

Cassandra是目前最流行的宽表数据库（Wide Column），最早由Facebook开发并开源。相信Facebook是受到了谷歌的高性能存储系统BigTable（基于GFS等技术，服务于MapReduce等任务）的启发而来的。它的最大特点是：

①无特殊节点（如主、备服务器），因此无单点故障；
②服务器集群可跨多个物理数据中心，无需主服务器的异步同步功能支持。

Cassandra系统中有几个关键概念：

数据分区（Data Partitioning）与一致性哈希（Consistent Hashing）：鉴于Cassandra的核心设计理念是一个逻辑数据库中的数据由所有集群中的节点分散保存，也就是所谓分区。数据的分布式会带来两个潜在的问题：

①如何判断指定的数据存储在哪个节点之上？
②在增加或删除节点时如何尽量减少数据的跨节点移动？解决方案就是通过持续的一致性哈希运算（即实现对Cassandra分区索引）。

数据复制（Data Replication）：所有无共享（Shared-Nothing）架构避免单点故障都是通过对数据进行多份复制（类似于拷贝）来实现的。
一致性级别（Consistency Level）：在Cassandra系统中可以定制一致性级别，也就是说需要多少节点返回读写操作的确认。

业界对于Cassandra的使用相当广泛，大部分用它来做数据分析服务，甚至是实时数据分析及流数据处理，还有些公司试图用Cassandra全面取代MySQL。

例如Twitter，不过貌似这一尝试并未获得成功，而始作俑者Facebook本来最早用Cassandra来做邮箱搜索（Inbox Search），后来因为最终一致性的问题而换成了HBase，不过这丝毫不影响业界对它趋之若鹜。

Cassandra一直宣称是NoSQL数据库中线性可扩展（Linear Scalability）做得最好的，目前已知全球最大的商用Cassandra部署恐怕是苹果公司，有超过十万个节点和数以十PB计的数据对其地图、iTunes、iCloud及iAd服务进行管理与分析。

键值型NoSQL—Redis

参考链接：https://www.cnblogs.com/zwtblog/tag/Redis/

Redis是由早期的键值（Key-Value Pair）数据库发展而来的。

因此，即便今天它已经支持了更为丰富的数据结构类型（如列表、集合、哈希、比特数组、字符串、HyperLogLogs等），它依然被大家看作一款基于内存（高速）的键值（Key-Value）型NoSQL数据库。

Redis区别于RDBMS的关键在于不需要数据库索引（Indexing），而通过主键检索（Key）来实现数据结构与算法，而且主键可以是任何binary-safe（二进制安全）数据类型（如子串、数字、图片、音乐甚至一段视频）。

因此Redis适用于快速查询、检索类操作（特别是以读操作为主的应用）。和所有NoSQL数据库一样，Redis也具有高度水平可扩展性（Scale-Out）。下图展示的是在2个数据中心中构建一个Redis集群，每个数据中心可以就近满足客户应用（App Server）的SLA访问时间需求（如相应时间≤200ms），这样的设计对于以读操作为主的应用类型特别适合。