51Testing软件测试论坛

 找回密码
 (注-册)加入51Testing

QQ登录

只需一步,快速开始

微信登录,快人一步

手机号码,快捷登录

查看: 670|回复: 0
打印 上一主题 下一主题

从SQL到NoSQL,数据库还要向何处演进?

[复制链接]
  • TA的每日心情
    无聊
    3 天前
  • 签到天数: 1050 天

    连续签到: 1 天

    [LV.10]测试总司令

    跳转到指定楼层
    1#
    发表于 2022-7-8 10:22:54 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式
     在开发一个应用程序时,不可避免要选择使用SQL还是NoSQL数据库来存储数据。传统的数据库,即使用SQL(结构化查询语言)进行查询的关系型数据库,是经过几十年来技术发展、良好实践和现实世界压力测试的产物。它们是为可靠的事务和临时查询而设计的,是业务线应用的主力军。但它们也有一些限制,如严格的模式,使它们不太适合于其他类型的应用。
      NoSQL数据库是针对这些限制而产生的。NoSQL系统存储和管理数据的方式,允许高操作速度,并让开发人员有巨大灵活性。许多数据库是由谷歌、亚马逊、雅虎和Facebook等公司开发的,它们寻求更好的方式来存储内容或处理大型网站的数据。与SQL数据库不同,许多NoSQL数据库可以在数百或数千台服务器上进行横向扩展。
      不过,NoSQL的优势并不是没有代价的。NoSQL系统倾向于速度和可扩展性,而不是SQL数据库所承诺的可靠事务背后的ACID属性。与围绕SQL建立的数十年的机构知识相比,在NoSQL系统中用于处理数据的隐喻也是相对较新的。
      SQL和NoSQL数据库提供了不同的权衡。虽然它们在特定项目的背景下可能会有竞争,例如,为不同应用会面临二选一的情况,但它们在更大范围内是互补的,每一种都适合于不同的使用情况。是选择SQL还是NoSQL并不是绝对的,要根据场景需求选合适的。
      NoSQL与SQL
      SQL和NoSQL之间的根本区别并不那么复杂。对于如何存储和检索数据,两者都有不同的理念。
      对于SQL数据库,所有数据都有一个固有的结构。像Microsoft SQL Server、MySQL、PostgreSQL或Oracle数据库这样的传统数据库使用一个模式--对插入数据库的数据如何组成的正式定义。例如,一个表中的某一列可能被限制为只能是整数。因此,记录在该列中的数据将有很高的规范化程度。SQL数据库的严格模式也使得对数据进行聚合变得相对容易,例如,使用SQL JOIN命令将两个表的数据合并。
      在NoSQL中,数据可以以无模式或自由的方式存储。任何数据都可以存储在任何记录中。在NoSQL数据库中,你会发现四种常见的数据存储模式,这导致了四种常见的NoSQL系统类型。
      ·文档数据库(如MongoDB)。插入的数据以无模式的JSON结构或“文档”的形式存储,其中的数据可以是任何东西,从整数到字符串再到自由格式的文本。没有必要指定JSON文档将包含哪些字段(如果有的话)。
      · 键值存储(如Redis)。自由格式的值,从简单的整数或字符串到复杂的JSON文档,都可以通过键(比如字符串)在数据库中访问。
      · 宽列存储(如 Cassandra)。数据被存储在列中,而不是像传统SQL系统存储在行。任何数量的列(以及许多不同类型的数据)都可以根据查询或数据视图的需要进行分组或聚合。
      · 图数据库(如Neo4j)。数据被表示为实体及其关系的网络或图形,其中图中的每个节点是一个自由形式的数据块。
      无模式的数据存储在以下情况下是有用的。
      · 你想快速访问数据,你更关心访问的速度和简单性,而不是可靠的事务或一致性。
      · 你正在存储大量的数据,你不想把自己锁定在一个模式中,因为以后改变模式可能是缓慢和痛苦的。
      · 你正在从一个或多个来源接收非结构化数据,你想保持数据的原始格式以获得最大的灵活性。
      · 你想把数据存储在一个分层结构中,但你希望这些分层结构由数据本身来描述,而不是外部模式。NoSQL允许数据随意地自我引用,该方式对于SQL数据库来说更为复杂,难以模仿。
      查询NoSQL数据库
      关系型数据库使用的结构化查询语言提供了一种统一的方式,在存储和检索数据时与服务器通信。SQL语法是高度标准化的,所以尽管各个数据库可能会以不同的方式处理某些操作(例如,窗口函数),但基本原理仍然是相同的。
      相比之下,每个NoSQL数据库往往都有自己的语法来查询和管理数据。例如,CouchDB使用JSON形式的请求,通过HTTP发送,以创建或检索其数据库中的文档。MongoDB通过二进制协议,以命令行接口或语言库的方式发送JSON对象。
      一些NoSQL产品可以使用类似SQL的语法来处理数据,但只是在有限的范围内。例如,Apache Cassandra,一个广泛的列存储,有自己的类似SQL的语言,Cassandra查询语言(CQL)。CQL的一些语法是直接来自于SQL的手册,比如SELECT或INSERT关键字。但在Cassandra中没有执行JOIN或子查询的本地方法,因此相关的关键字在CQL中并不存在。
      无共享shared-nothing架构
      NoSQL系统常见的一个设计选择是“shared-nothing”架构。在一个无共享的设计中,集群中的每个服务器节点都独立于其他节点运行。系统不需要从其他节点获得共识来返回数据给客户端。查询速度很快,因为它们可以从最近的或最方便的节点返回。
      无共享系统的另一个优点是弹性和向外扩展。向外扩展集群非常容易,只需旋转集群中的新节点并等待它们与其他节点同步即可。如果一个NoSQL节点宕机,集群中的其他服务器将继续运行。即使服务请求的节点减少,所有数据仍然可用。
      请注意,无共享的设计并不是NoSQL数据库所独有的。许多传统的SQL系统可以以无共享的方式设置,如MySQL,尽管这通常涉及到牺牲整个集群的一致性以获得性能。
      NoSQL的局限性
      如果NoSQL提供了如此多的自由和灵活性,为什么不完全放弃SQL?答案很简单,许多应用仍然需要SQL数据库所提供的各种约束、一致性和保障措施。在这些情况下,NoSQL的一些“优势”可能会变成劣势。其他的限制来自于NoSQL系统缺乏某些在SQL领域中本应有的功能。
      (1) 无模式(No schema)
      即使你接收的是自由格式的数据,你也几乎总是需要对数据施加约束,以使其有用。对于NoSQL,施加约束涉及到将责任从数据库转移到应用开发者身上。例如,开发者可以通过一个对象关系映射系统(或称ORM)强加结构。但如果你想让模式与数据本身共存,NoSQL通常不支持这种做法。
      一些NoSQL解决方案为数据提供了可选的数据类型和验证机制。例如,Apache Cassandra有一系列的本地数据类型,让人想起传统SQL中的那些数据类型。
      (2) 最终一致性
      NoSQL系统提供了强一致性或即时一致性的选择,以获得更好的可用性和性能。传统的数据库确保操作是原子的(事务的所有部分都成功,或者没有一个成功)、一致的(所有用户都有相同的数据视图)、隔离的(事务不竞争)和持久的(一旦完成,它们将不受服务器故障的影响)。
      这四个属性,统称为ACID,在NoSQL系统中可以用不同的方式处理。你可以选择最终一致性,而不是要求整个集群的强一致性,这必然会延迟对请求的响应,允许服务请求,而无需等待最新的写入复制到集群的其它节点。插入集群的数据最终在各处都是可用的,但不能保证任何时候可用。
      对于一些NoSQL系统,你可以在一致性和速度之间选择一个折中方案,不同的产品有不同的方案。例如,[url=]微软[/url]的Azure Cosmos DB可以让你选择每个请求的一致性级别,所以你可以选择适合你的。事务语义,在SQL系统中保证事务中的所有步骤(例如执行销售和减少库存)要么完成,要么回滚,在一些NoSQL系统中也有,例如MongoDB。
      (3) NoSQL的锁定
      大多数NoSQL系统在概念上是相似的,但实现方式不同。每个系统都有自己的隐喻和机制,用于数据的查询和管理。
      这样做的一个副作用是应用逻辑和数据库之间可能存在高度的耦合。如果你选择一个NoSQL系统并坚持使用它,这种耦合性并没有什么坏处,但如果你在未来更换系统,它就会成为一个绊脚石。
      如果你从MongoDB迁移到CouchDB(或者相反),你需要做的不仅仅是迁移数据。还必须驾驭数据访问和编程隐喻之间的差异。换句话说,你必须重写应用程序中访问数据库的部分。
      (4) NoSQL技能
      NoSQL的另一个缺点是相对缺乏专业知识。传统SQL人才的市场相当大,而NoSQL技能的市场却刚刚起步。
      作为参考,Indeed.com报告称,截至2022年,传统SQL数据库(MySQL、微软SQL Server、Oracle数据库等)的职位数量仍然高于MongoDB、Couchbase和Cassandra的职位数量。对NoSQL专业知识的需求仍然只是SQL技能市场的一小部分。
      合并SQL和NoSQL
      未来,随着时间的推移,SQL和NoSQL系统之间的一些差异会消失。现在已经有许多SQL数据库接受JSON文档作为原生数据类型,并可以对该数据进行查询。一些数据库甚至有对JSON数据施加约束的本地方法,因此其处理方式与传统的行和列数据一样严格。
      另一方面,NoSQL数据库不仅增加了类似SQL的查询语言,还增加了传统SQL数据库的其他功能,比如MongoDB的ACID属性。
      一个可能的路径是,未来几代数据库以及当前数据库系统的未来版本将跨越这些范式,同时提供SQL和NoSQL功能,有助于使数据库世界不再支离破碎。例如,微软的Azure Cosmos DB在底层使用了一套基元,可以互换地再现两种系统的行为。谷歌云Spanner将SQL的强一致性与NoSQL系统的水平可扩展性相结合。
      不过,纯SQL和纯NoSQL系统仍将在未来很多年占有一席之地。在设计灵活性、水平扩展性和高可用性比强读一致性和其他SQL数据库常见的保障措施更重要的情况下,可以考虑使用NoSQL。对于许多应用来说,这些保障措施很可能值得用来交换NoSQL所提供的东西。
      对于许多应用程序来说,以NoSQL的特有优势来那些换保障措施是值得。

    分享到:  QQ好友和群QQ好友和群 QQ空间QQ空间 腾讯微博腾讯微博 腾讯朋友腾讯朋友
    收藏收藏
    回复

    使用道具 举报

    本版积分规则

    关闭

    站长推荐上一条 /1 下一条

    小黑屋|手机版|Archiver|51Testing软件测试网 ( 沪ICP备05003035号 关于我们

    GMT+8, 2024-11-24 20:50 , Processed in 0.063605 second(s), 23 queries .

    Powered by Discuz! X3.2

    © 2001-2024 Comsenz Inc.

    快速回复 返回顶部 返回列表