NOSQL数据模型和CAP原理

本文涉及的产品
云原生数据库 PolarDB MySQL 版,通用型 2核4GB 50GB
云原生数据库 PolarDB PostgreSQL 版,标准版 2核4GB 50GB
简介:

http://blog.sina.com.cn/s/blog_7800d9210100t33v.html

我本来一直觉得NoSQL其实很容易理解的,我本身也已经对NoSQL有了非常深入的研究,但是在最近准备YunTable的Chart的时候,发现NoSQL不仅非常博大精深,而且我个人对NoSQL的理解也只是皮毛而已,但我还算是一个“知耻而后勇”的人,所以经过一段时间的学习之后,从本系列第六篇开始,就将和大家聊聊NoSQL,而本篇将主要给大家做一下NoSQL数据库的综述。

首先将和大家聊聊为什么NoSQL会在关系型数据库已经非常普及的情况下异军突起?

诞生的原因

随着互联网的不断发展,各种类型的应用层出不穷,所以导致在这个云计算的时代,对技术提出了更多的需求,主要体现在下面这四个方面:

1. 低延迟的读写速度:应用快速地反应能极大地提升用户的满意度;
2. 支撑海量的数据和流量:对于搜索这样大型应用而言,需要利用PB级别的数据和能应对百万级的流量;
3. 大规模集群的管理:系统管理员希望分布式应用能更简单的部署和管理;
4. 庞大运营成本的考量:IT经理们希望在硬件成本、软件成本和人力成本能够有大幅度地降低;

虽然关系型数据库已经在业界的数据存储方面占据不可动摇的地位,但是由于其天生的几个限制,使其很难满足上面这几个需求:

1. 扩展困难:由于存在类似Join这样多表查询机制,使得数据库在扩展方面很艰难;
2. 读写慢:这种情况主要发生在数据量达到一定规模时由于关系型数据库的系统逻辑非常复杂,使得其非常容易发生死锁等的并发问题,所以导致其读写速度下滑非常严重;
3. 成本高:企业级数据库的License价格很惊人,并且随着系统的规模,而不断上升;
4. 有限的支撑容量:现有关系型解决方案还无法支撑Google这样海量的数据存储;

业界为了解决上面提到的几个需求,推出了多款新类型的数据库,并且由于它们在设计上和传统的NoSQL数据库相比有很大的不同,所以被统称为 “NoSQL”系列数据库。总的来说,在设计上,它们非常关注对数据高并发地读写和对海量数据的存储等,与关系型数据库相比,它们在架构和数据模型方量面做了“减法”,而在扩展和并发等方面做了“加法”。现在主流的NoSQL数据库有BigTable、HBase、Cassandra、SimpleDB、 CouchDB、MongoDB和Redis等。接下来,将关注NoSQL数据库到底存在哪些优缺点。

优缺点

在优势方面,主要体现在下面这三点:

1. 简单的扩展:典型例子是Cassandra,由于其架构是类似于经典的P2P,所以能通过轻松地添加新的节点来扩展这个集群;

2. 快速的读写:主要例子有Redis,由于其逻辑简单,而且纯内存操作,使得其性能非常出色,单节点每秒可以处理超过10万次读写操作;
3. 低廉的成本:这是大多数分布式数据库共有的特点,因为主要都是开源软件,没有昂贵的License成本;

但瑕不掩瑜,NoSQL数据库还存在着很多的不足,常见主要有下面这几个:

1. 不提供对SQL的支持:如果不支持SQL这样的工业标准,将会对用户产生一定的学习和应用迁移成本;
2. 支持的特性不够丰富:现有产品所提供的功能都比较有限,大多数NoSQL数据库都不支持事务,也不像MS SQL Server和Oracle那样能提供各种附加功能,比如BI和报表等;
3. 现有产品的不够成熟:大多数产品都还处于初创期,和关系型数据库几十年的完善不可同日而语;

上面NoSQL产品的优缺点都是些比较共通的,在实际情况下,每个产品都会根据自己所遵从的数据模型和CAP理念而有所不同,接下来,将给大家介绍NoSQL两个最重要的概念:数据模型和CAP理念,并在本文最后,对主流的NoSQL数据库进行分类。

数据模型

传统的数据库在数据模型方面,主要是关系型,它的特色是对Join类操作和ACID事务的支持。在NoSQL领域,主要有三种主流的数据模型:

Column-oriented(列式)

列式也主要使用Table这样的模型,但是它并不支持类似Join这样多表的操作,它的主要特点是在存储数据时,主要围绕着“列(Column)”,而不是像传统的关系型数据库那样根据“行(Row)”进行存储,也就是说,属于同一列的数据会尽可能地存储在硬盘同一个页(Page)中,而不是将属于同一个行的数据存放在一起,这样做的好处是,对于很多类似数据仓库(Data Warehouse)的应用,虽然每次查询都会处理很多数据,但是每次所涉及的列并没有很多,这样如果使用列式数据库的话,将会节省大量I/O,并且大多数列式数据库都支持Column Family这个特性,通过这个特性能将多个Column并为一个小组,这样做好处是能将相似Column放在一起存储,这样能提高这些Column的存储和查询效率。总体而言,这种数据模型的优点是比较适合汇总(Aggregation)和数据仓库这类应用。.

Key-value

虽然Key-value这种模型和传统的关系型相比较简单,有点类似常见的HashTable,一个Key对应一个Value,但是其能提供非常快的查询速度、大的数据存放量和高并发操作,并非常适合通过主键对数据进行查询和修改等操作,虽然不支持复杂的操作,但是可以通过上层的开发来弥补这个缺陷。

Document(文档)
在结构上,Document和Key-value是非常相似的,也是一个Key对应一个Value,但是这个Value主要以JSON或者XML等格式的文档来进行存储,是有语义的,并且Document DB一般可以对Value来创建Secondary Index来方便上层的应用,而这点是普通Key-Value DB所无法支持的。

CAP理论

这个理论是由美国著名科学家,同时也是著名互联网企业Inktomi的创始人Eric Brewer在2000年PODC(Symposium on Principles of Distributed Computing)大会上提出的,后来Seth Gilbert 和 Nancy lynch两人也证明了CAP理论的正确性,虽然在后来近十年的时间很多人对CAP理论提出了很多异议,但是在NoSQL的世界中,它还是非常有参考价值的。它的意思是,一个分布式系统不能同时满足一致性,可用性和分区容错性这三个需求,最多只能同时满足两个。

1. 一致性(Consistency):任何一个读操作总是能读取到之前完成的写操作结果,也就是在分布式环境中,多点的数据是一致的;
2. 可用性(Availability):每一个操作总是能够在确定的时间内返回,也就是系统随时都是可用的。
3. 分区容忍性(Partition Tolerance): 在出现网络分区(比如断网)的情况下,分离的系统也能正常运行。

由于一致性、可用性和分区容忍性这三方面只能选择两个,所以大多数NoSQL系统都会根据自己的设计理念来进行相应的选择,但由于许多NoSQL数据库都以水平扩展著称,所以在CAP的选择上面,都倾向于坚持分区容忍性,而放弃一致性或者可用性,它们的做法主要是通过消减关系型和事务相关的功能。

具体分类

下面的具体分类是来自于Visual Guide to NoSQL Systems一文,虽然对于这块分类我个人觉得还存在一些牵强的地方,比如将能支持多种CAP配置的Dynamo和其衍生产品Cassandra归类为 AP,但是总体而言,这个分类还是相当不错,在现阶段非常具有参考价值,在每个相关的数据库后面还会介绍对应的数据模型。

具体分类和参考资料
▲图1. NoSQL产品分类图(参考1)

关注一致性和可用性的 (CA)

这些数据库对于分区容忍性方面比较不感冒,主要采用复制(Replication)这种方式来保证数据的安全性,常见的CA系统有:

1. 传统关系型数据库,比如Postgres和MySQL等(Relational) ;
2. Vertica (Column-oriented) ;
3. Aster Data (Relational) ;
4. Greenplum (Relational) ;

关注一致性和分区容忍性的(CP)

这种系统将数据分布在多个网络分区的节点上,并保证这些数据的一致性,但是对于可用性的支持方面有问题,比如当集群出现问题的话,节点有可能因无法确保数据是一致性的而拒绝提供服务,主要的CP系统有:
1. BigTable (Column-oriented) ;
2. Hypertable (Column-oriented);
3. HBase (Column-oriented) ;
4. MongoDB (Document) ;
5. Terrastore (Document) ;
6. Redis (Key-value) ;
7. Scalaris (Key-value) ;
8. MemcacheDB (Key-value) ;
9. Berkeley DB (Key-value) ;

关于可用性和分区容忍性的(AP)

这类系统主要以实现"最终一致性(Eventual Consistency)"来确保可用性和分区容忍性,AP的系统有:

1. Dynamo (Key-value);
2. Voldemort (Key-value) ;
3. Tokyo Cabinet (Key-value) ;
4. KAI (Key-value) ;
5. Cassandra (Column-oriented) ;
6. CouchDB (Document-oriented) ;
7. SimpleDB (Document-oriented) ;
8. Riak (Document-oriented) ;


参考资料

1. Visual Guide to NoSQL Systems
2. NoSQL数据库笔谈
3. NoSQL数据库探讨之一 - 为什么要用非关系数据库?
本文转自 你听海是不是在笑 博客园博客,原文链接: http://www.cnblogs.com/balaamwe/archive/2012/05/02/2479100.html   ,如需转载请自行联系原作者
相关实践学习
使用PolarDB和ECS搭建门户网站
本场景主要介绍基于PolarDB和ECS实现搭建门户网站。
阿里云数据库产品家族及特性
阿里云智能数据库产品团队一直致力于不断健全产品体系,提升产品性能,打磨产品功能,从而帮助客户实现更加极致的弹性能力、具备更强的扩展能力、并利用云设施进一步降低企业成本。以云原生+分布式为核心技术抓手,打造以自研的在线事务型(OLTP)数据库Polar DB和在线分析型(OLAP)数据库Analytic DB为代表的新一代企业级云原生数据库产品体系, 结合NoSQL数据库、数据库生态工具、云原生智能化数据库管控平台,为阿里巴巴经济体以及各个行业的企业客户和开发者提供从公共云到混合云再到私有云的完整解决方案,提供基于云基础设施进行数据从处理、到存储、再到计算与分析的一体化解决方案。本节课带你了解阿里云数据库产品家族及特性。
相关文章
|
5天前
|
SQL NoSQL Java
彻底革新你的数据库操作体验!Micronaut数据访问技巧让你瞬间爱上代码编写!
【9月更文挑战第10天】Java开发者们一直在寻找简化应用程序与数据库交互的方法。Micronaut作为一个现代框架,提供了多种工具和特性来提升数据访问效率。本文介绍如何使用Micronaut简化数据库操作,并提供具体示例代码。Micronaut支持JPA/Hibernate、SQL及NoSQL(如MongoDB),简化配置并无缝集成。通过定义带有`@Repository`注解的接口,可以实现Spring Data风格的命名查询。
19 6
|
15天前
|
SQL 存储 数据处理
"SQL触发器实战大揭秘:一键解锁数据自动化校验与更新魔法,让数据库管理从此告别繁琐,精准高效不再是梦!"
【8月更文挑战第31天】在数据库管理中,确保数据准确性和一致性至关重要。SQL触发器能自动执行数据校验与更新,显著提升工作效率。本文通过一个员工信息表的例子,详细介绍了如何利用触发器自动设定和校验薪资,确保其符合业务规则。提供的示例代码展示了在插入新记录时如何自动检查并调整薪资,以满足最低标准。这不仅减轻了数据库管理员的负担,还提高了数据处理的准确性和效率。触发器虽强大,但也需谨慎使用,以避免复杂性和性能问题。
25 1
|
15天前
|
安全 关系型数据库 数据库
FastAPI数据库操作秘籍:如何通过高效且安全的数据库访问策略,使你的Web应用飞速运转并保持数据完整性?
【8月更文挑战第31天】在构建现代Web应用时,数据库操作至关重要。FastAPI不仅简化了API创建,还提供了高效数据库交互的方法。本文探讨如何在FastAPI中实现快速、安全的数据处理。FastAPI支持多种数据库,如SQLite、PostgreSQL和MySQL;选择合适的数据库可显著提升性能。通过安装相应驱动并配置连接参数,结合ORM库(如Tortoise-ORM或SQLAlchemy),可以简化数据库操作。使用索引、批量操作及异步处理等最佳实践可进一步提高效率。同时,确保使用参数化查询防止SQL注入,并从环境变量中读取敏感信息以增强安全性。
29 1
|
1天前
|
SQL 存储 数据库
MSSQL遍历数据库根据列值查询数据
【9月更文挑战第12天】在 SQL Server 中,可以通过游标或临时表遍历数据库并根据列值查询数据。示例展示了如何创建临时表存储数据库名,并通过循环遍历这些名称来执行特定查询。需替换 `YourTableName`、`YourColumnName` 和 `YourValue` 为实际值。此方法要求有足够权限访问各数据库。若无跨库权限,需分别执行查询。
|
7天前
|
前端开发 数据库 开发者
数据模型(数据库表设计)生成代码
BizWorks ToolKit 插件集成 Mybatis-Plus 代码生成工具,支持从数据库表批量生成代码,简化开发流程。本文详细介绍配置方法及项目示例,包括配置文件格式、生成选项及具体操作步骤,帮助开发者快速实现代码同步更新。配置文件 `.mp.yaml` 支持自定义输出目录、生成组件等,适用于多种项目结构。
20 0
|
15天前
|
测试技术 Java
全面保障Struts 2应用质量:掌握单元测试与集成测试的关键策略
【8月更文挑战第31天】Struts 2 的测试策略结合了单元测试与集成测试。单元测试聚焦于单个组件(如 Action 类)的功能验证,常用 Mockito 模拟依赖项;集成测试则关注组件间的交互,利用 Cactus 等框架确保框架拦截器和 Action 映射等按预期工作。通过确保高测试覆盖率并定期更新测试用例,可以提升应用的整体稳定性和质量。
29 0
|
15天前
|
开发者 UED Java
Play Framework惊天秘密:如何让异常处理优雅得像芭蕾舞?
【8月更文挑战第31天】在Web应用开发中,异常处理至关重要,直接影响应用稳定性和用户体验。Play Framework作为轻量级Java Web框架,提供了基于Scala偏函数的灵活异常处理机制。通过实现`HttpErrorHandler`接口可定义全局异常逻辑,而在控制器中使用try-catch块则能捕获特定异常。定义自定义异常类也有助于表示特定错误情况。最佳实践包括保持处理一致性、提供有用错误信息、记录日志及分类处理异常。掌握这些技巧,能使Play应用更健壮可靠。
34 0
|
15天前
|
SQL 数据库 开发者
全面提速你的数据访问:Entity Framework Core性能优化指南,从预加载到批量操作的最佳实践揭秘,打造高性能数据库交互体验
【8月更文挑战第31天】本文详细介绍如何在Entity Framework Core(EF Core)中优化数据访问性能,涵盖从创建项目到定义领域模型、配置数据库上下文的最佳实践。文章通过具体代码示例讲解了预加载、惰性加载、显式加载、投影及批量操作等技术的应用,并介绍了如何使用SQL查询和调整查询性能来进一步提升效率。通过合理运用这些技术,开发者可以构建出高效且响应迅速的数据访问层,提升应用程序的整体性能和用户体验。
29 0
|
15天前
|
SQL 存储 NoSQL
从SQL到NoSQL:理解不同数据库类型的选择与应用——深入比较数据模型、扩展性、查询语言、一致性和适用场景,为数据存储提供全面决策指南
【8月更文挑战第31天】在信息技术飞速发展的今天,数据库的选择至关重要。传统的SQL数据库因其稳定的事务性和强大的查询能力被广泛应用,而NoSQL数据库则凭借其灵活性和水平扩展性受到关注。本文对比了两种数据库类型的特点,帮助开发者根据应用场景做出合理选择。SQL数据库遵循关系模型,适合处理结构化数据和复杂查询;NoSQL数据库支持多种数据模型,适用于非结构化或半结构化数据。SQL数据库在一致性方面表现优异,但扩展性较差;NoSQL数据库则设计之初便考虑了水平扩展性。SQL使用成熟的SQL语言,NoSQL的查询语言更为灵活。
26 0