数据存储的演进路线以及原因

最新推荐文章于 2024-01-29 23:03:53 发布

原创最新推荐文章于 2024-01-29 23:03:53 发布 · 516 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#大数据 #数据库 #运维

本文探讨了RDBMS和NoSQL数据库的区别，包括它们的扩展方式、数据一致性、查询语言等方面。介绍了RDBMS的横向扩展方法如主从复制和分片，以及NoSQL数据库的特点和CAP理论。

摘要生成于 C知道，由 DeepSeek-R1 满血版支持，前往体验 >

作者：邵兵
链接：https://www.zhihu.com/question/21677041/answer/22393192
来源：知乎
著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

1. RDBMS
让数据集保持在一台单一的机器上是RDBMS提供ACID特性和丰富查询模型的最好方式。但数据集变大时，垂直扩展（scaling up）带来诸多限制。企业慢慢发现，通过增加多节点的服务器进行横向扩展（scaling out）是一种更经济和更可行的方式。DBA们对RDBMS采用的横向扩展的方法主要有主从复制（Master-slave）、分片（Sharding）。

横向扩展RDBMS – Master/Slave

利用数据库的复制或镜像功能，同时在多台数据库上保存相同的数据，并且将读操作和写操作分开，写操作集中在一台主数据库上，读操作集中在多台从数据库上。复制过程的速度与系统中的从节点数量成反比。
关键的读取可能不正确，因为写可能没有来得及被向下传播；
大数据集可能会造成问题，因为主节点需要将数据复制到从节点；

横向扩展RDBMS - Sharding

通常来说，在满足ACID特性的数据库中进行扩展是非常难的。基于这个原因，对数据进行扩展，这个数据库本身就必须拥有简单的模型，将数据分割为N片，然后在单独的片中执行查询。数据分割的单元被称为“shard”。将N片数据分配个M个DBMS进行操作。DBMS并不会去管理数据片，这需由服务开发者自行完成。
不同的分片方法有：

- 垂直分区（Vertical Partitioning）：将不需要进行联合查询的数据表分散到不同的数据库服务器上。
- 水平分区(sharding/分表) 将同一个表的记录拆分到不同的表甚至是服务器上，这往往需要一个稳定的算法来保证读取时能正确从不同的服务器上取得数据。比如，将ZIP codes小于50000的客户存储在CustomersEast，将ZIP codes大于或等于50000的客户存储在CustomersWest。CustomersEast和CustomersWest就成为两个分区表。方法有 Range-Based Partitioning, Key or Hash-Based partitioning等。

优点与不足

- 对读取和写入都有很好的扩展
- 不透明，应用需要做到可识别分区
- 不再有跨分区的关系/joins
- 跨片参照完整性损失

其他RDBMS扩展方法

Multi-Master replication：所有成员都响应客户端数据查询。多主复制系统负责将任意成员做出的数据更新传播给组内其他成员，并解决不同成员间并发修改可能带来的冲突。
INSERT only, not UPDATES/DELETES：数据进行版本化处理。
No JOINs, thereby reducing query time：Join的开销很大,而且频繁访问会使开销随着时间逐渐增加。非规范化（Denormalization）可以降低数据仓库的复杂性，以提高效率和改善性能。
In-memory databases：磁盘数据库解决的是大容量存储和数据分析问题，内存数据库解决的是实时处理和高并发问题。主流常规的RDBMS更多的是磁盘密集型，而不是内存密集型。

2. NoSQL
NoSQL现在被理解为 Not Only SQL 的缩写，是对非关系型的数据库管理系统的统称（正因为此，人们通常理解 NoSQL 是 anti-RDBMS）。

NoSQL 与 RDBMS 存在许多不同点，
- 最重要的是NoSQL不使用SQL作为查询语言。
- NoSQL 不需要固定的表模式(table schema)，也经常会避免使用SQL的JOIN操作，一般有可水平扩展的特征。
- NoSQL产品会放宽一个或多个 ACID 属性（CAP定理）

CAP 理论
CAP理论是数据系统设计的基本理论，目前几乎所有的数据系统的设计都遵循了这个理论。CAP理论指出，分布式系统只能满足以下三项中的两项而不可能满足全部三项，

一致性（Consistency)（所有节点在同一时间具有相同的数据）
可用性（Availability）（保证每个请求不管成功或者失败都有响应）
分区容忍性（Partition tolerance）（系统中任意信息的丢失或失败不会影响系统的继续运作）

一致性有两种类型：
- strong consistency – ACID(Atomicity Consistency Isolation Durability)：对于关系型数据库，要求更新过的数据能被后续所有的访问都看到，这是强一致性。
- weak consistency – BASE(Basically Available Soft-state Eventual consistency )
-- Basically Available - system seems to work all the time (基本可用)
-- Soft State - it doesn't have to be consistent all the time （不要求所有时间都一致）
-- Eventually Consistent - becomes consistent at some later time （最终一致性）

对于分布式数据系统(scale out)，分区容忍性是基本要求，否则就失去了价值。因此只能在一致性和可用性上做取舍，如何处理这种取舍正是目前NoSQL数据库的核心焦点。几乎所有的情况都是牺牲一致性而换取高可用性。当然，牺牲一致性，只是不再要求关系数据库中的强一致性，而是只要系统能达到最终一致性即可。考虑到客户体验，这个最终一致的时间窗口，要尽可能的对用户透明，也就是需要保障“用户感知到的一致性”。通常是通过数据的多份异步复制来实现系统的高可用和数据的最终一致性的。

3. HBase
HBase is an open-source, distributed, column-oriented database built on top of HDFS (or KFS) based on BigTable!

按照CAP理论，HBase属于C+P类型的系统。HBase是强一致性的（仅支持单行事务）。每一行由单个区域服务器（region server）host，行锁（row locks）和多版本并发控制(multiversion concurrency control)的组合被用来保证行的一致性。

There are three types of lookups:

Fast lookup using row key and optional timestamp.
Range scan from region start to end.
Full table scan (全表扫描)

Access or manipulate
- Programmatic access via Java, REST, or Thrift APIs.
- Scripting via JRuby.

HBase benefits than RDBMS
- No real indexes
- Automatic partitioning
- Scale linearly and automatically with new nodes
- Commodity hardware
- Fault tolerance
- Batch processing

4. Hive
- Provide higher-level language (HQL, like SQL) to facilitate large-data processing
- Higher-level language “compiles down” to Hadoop Map/Reduce jobs

5. Hive + HBase
Reasons to use Hive on HBase:

A lot of data sitting in HBase due to its usage in a real-time environment, but never used for analysis
Give access to data in HBase usually only queried through MapReduce to people that don’t code (business analysts)
When needing a more flexible storage solution, so that rows can be updated live by either a Hive job or an application and can be seen immediately to the other