先放个链接,万一有人关注呢
优质文章推荐
↓ ↓ ↓ ↓ ↓
CentOS再见!拥抱Rocky or Alma
Linux系统服务巡检脚本
Python脚本实现Zabbix自动微信告警
不会吧!Linux系统磁盘分区只会fdisk吗?
Linux系统不优化的后果有多严重?
伴随互联网的发展和新兴技术的不断涌现,大数据应用所带来的数据处理问题变得愈加突出。为了解决超大规模和高并发系统中多样化数据类型带来的挑战,NoSQL数据库应运而生。NoSQL数据库具备许多新特性,如良好的可扩展性、弱化的设计范式以及较弱的一致性要求。这些特性使其能够轻松应对高并发问题,并更加适应于海量数据的应用场景。
NoSQL概述
起源
NoSQL是“Not Only SQL”的缩写,含义为“不仅仅是SQL”,表示可以不使用SQL作为查询语言,也可以不使用固定的表格模式存储数据。NoSQL泛指非关系型数据库,NoSQL技术主要用于解决以互联网业务应用为主的大数据应用问题,其重点是数据处理的速度和海量数据的存储。NoSQL最初是在1998年开发的一个既轻量又开源的关系数据库,该数据库并不提供SQL功能。直到在2009年的一次关于分布式开源数据库的讨论中,再次说明了NoSQL概念,这时的NoSQL则是指非关系型、分布式、不提供数据库设计模式。同年,在亚特兰大举行的“no:sql(east)”讨论会,认定了对NoSQL的解释为“非关系型数据库”。伴随Web2.0网站的发展,传统的关系型数据库管理系统(Relational Database Management System,RDBMS)难以应付海量数据的纯动态网站,并且存在着很多难以克服的问题,例如:传统的关系型数据库IO瓶颈、性能瓶颈都难以有效突破,而NoSQL(非关系型)类的数据库的诞生则可以很好地解决这些问题。于是NoSQL技术在此之后得到了非常迅速的发展。SQL与NoSQL
SQL
关系型数据库指的是采用了关系模型来组织数据的数据库。关系型数据库采用了关系对应的表现形式,以行和列的形式存储数据,就像是一组二维表格。每一列代表着不同的选项,每一行代表着不同的数据。行与列组成的区域被称为表,数据库则由一组表组成。常见的关系型数据库产品有:Oracle数据库、SQL Server数据库、Access数据库等。NoSQL
非关系型数据库虽然被称为NoSQL数据库,但是NoSQL的产生并不是要彻底否定关系型数据库,而是作为传统数据库的一个有效补充。NoSQL的数据存储不需要固定的表结构,一般情况下也不存在对数据的连续操作。相比于关系型数据库,NoSQL在大数据存取上具备无法比拟的性能优势。常见的非关系型数据库产品有:Redis、MongoDB、HBASE、Memcached等。区别
关系型数据库基于行与列组成的表存储数据,一行代表一条记录,一列代表一个字段(即属性)。非关系型数据库以数据集的方式存储数据,比如按照数据本身键值对特点、文档特点、图结构特点或者纵向按列大块数据存储。关系型数据库按照数据表结构存储数据,而数据表需要提前定义和描述。经过预定义的数据表具有较高的稳定性和可靠性,但其数据模型的灵活性不高,当数据录入后,难以修改其数据类型。非关系型数据库使用动态结构,在面对大量非结构化的数据时,可以根据需求灵活变化。由于关系型数据库将数据存储在数据表中,数据操作的瓶颈也就出现在了多张数据表的操作中,而且数据表越多这个问题越严重。若要缓解这个问题,只能提高处理能力,也就是选择速度更快性能更高的计算机,这样的方法可以扩展存储空间,但这种纵向扩展的方式是有限的。非关系型数据库可使用部署存储集群进行分布式存储,通过添加数据库服务器来分担数据量,这种扩展数据库的方式属于横向扩展。关系型数据库采用结构化查询语言(Structured Query Language,简称SQL)对数据库进行查询,SQL语言直至今日已成为数据库行业的标准,它能够支持对数据的增加、查询、更新、删除操作,具备非常强大的功能,另外,它还可以采用类似索引的方法来加快查询操作。非关系型数据库没有固定的查询语言,不同类型的NoSQL数据库,提供的产品标准有所不同。关系型数据库强调ACID规则,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)、持久性(Durability),可以满足对事务性要求较高或者需要进行复杂数据查询的数据操作,而且可以充分满足数据库操作的高性能和稳定性的要求。并且关系型数据库十分强调数据的强一致性,对于事务操作有很好的支持。非关系型数据库遵循基本可用、软状态和最终一致性的BASE原则,虽然也可以支持事务管理,但不是NoSQL的主要特点。关系型数据库十分强调数据的一致性,并为此降低读写性能付出了巨大的代价,虽然关系型数据库存储数据和处理数据的可靠性很不错,但面对海量数据时,其效率就会大大降低,特别是遇到高并发读写时性能就会大幅下降。非关系型数据库大都是以键值对的存储格式,又利用内存存储、数据副本、负载均衡等机制提高大数据访问性能,因此可以很好地应对海量数据。关系型数据库把数据按照一定的规范化处理,分割成多个相关联的数据表。虽然这样管理起来更加有条理,但是在对一张数据表进行操作时往往“牵一发而动全身”,管理起来具有一定难度。非关系型数据库则没有严格的规范要求,往往将一个数据实体或数据集存储到一个单独的存储单元中,更加便于存储和管理大规模的数据。关系型类的数据库产品,除MySQL之外,几乎都是非开源、付费的,并且价格昂贵。非关系型类的数据库产品目前大多数是开源的,除了企业版需要收费外,相对来讲成本较低。如何选择
NoSQL并未完全取代关系型数据库,NoSQL主要被用于处理大量且多元数据的存储及运算问题。了解两者的差异后,这里提供4个要点作为判断选择合适的数据库的依据,帮助读者选择出最贴合实际需求的数据库。NoSQL适合模型关联性比较低的应用,RDB适合模型关联性比较高的应用。当需要多表关联时,则适合选择RDB;当对象实体关联少,则适合选择NoSQL数据库。作为非关系型类的数据库产品之一,MongoDB以文档的方式将相关联的数据进行存储,既支持复杂度相对高的数据结构,又能以此减少数据之间的关联操作。NoSQL遵循最终一致性原则和BASE原则,所以高性能是它最大的优势,并且NoSQL数据库可以通过数据的分布存储大幅地提供存储性能。如果考虑大数据量和访问速度的重要性,那么选择使用NoSQL数据库是比较合适的。RDB支持数据强一致性和事务管理,并且数据结构可靠性和稳定性都极高。这一方面的优势远远超过NoSQL数据库,NoSQL数据库难以在同一时间满足强一致性与高并发性。NoSQL数据库提供了强大的数据可用性,极大地避免数据不可用的风险。在实际应用中,一个项目不是只能选择一种数据库,可以将其业务拆开设计,将需要RDB特性的数据放到RDB中管理,而其它数据放到NoSQL中管理。NoSQL的特性与优势
NoSQL数据库能够快速响应现代企业的数据管理需求,其灵活性和可扩展性,促进了NoSQL更长远的发展。(2)NoSQL数据库产品通常都是开源项目,如HBASE、MongoDB等。(3)除图数据库外,大多数NoSQL数据库支持分布式,其研发动机主要是在集群环境中运行。(4)操作NoSQL数据库不需要使用“模式”,无需事先修改结构定义,便于添加字段,在处理不规则数据和自定义字段时效果更加显著。NoSQL数据库种类丰富,其共同的特点都是去掉关系数据库的关系型特性。数据之间无联系,易于数据扩展。因此增强了架构层面的扩展,同时也可将多种NoSQL进行整合。NoSQL无需预先为要存储的数据建立字段,随时可以存储自定义的数据格式。NoSQL在不太影响性能的情况下,可以方便地部署高可用的架构。比如Cassandra、HBase数据库,通过复制模型也可实现高可用。NoSQL数据库结构简单且无关联性,具有非常高的读写性能,在处理速度和海量数据的存储问题,表现十分优秀。CAP原则又被称作CAP定理、布鲁尔定理(Brewer's theorem),指的是在一个分布式系统中,不能同时满足一致性(Consistency,C)、可用性(Availability,A)和分区容错性(Partition Tolerance,P)三个需求。CAP原则的三大要素的解释如下所示。数据在系统执行过某项操作后依然保持一致。例如,某分布式系统成功执行更新操作后,所有用户都能够读取到最新的值,则此系统能够保证数据的一致性。每个请求在一定时间内无论成功还是失败均会返回结果。系统中任意信息的丢失或者失败,都不会影响系统对外提供满足一致性和可用性的服务。即使某些节点出现故障,则此系统仍然能继续运行。不同类型的NoSQL数据库和RDBMS在设计和实现时在CAP原则上作了不同的取舍。
按照CAP原则可以把数据库管理系统分成3类,分别如下所示。(1)满足CA原则的数据库:满足一致性和可用性的数据库管理系统如传统的关系型数据库MySQL、Oracle等。此类数据库对分区容错性要求低一些,与分布式系统的分区容错性背道而驰。(2)满足CP原则的数据库:满足一致性和分区容错性的数据库有MongoDB、HBase、Redis等。此类数据库在可用性方面会有所欠缺,当系统宕机后,需要等到数据节点恢复一致,用户才能访问到系统,致使用户体验感降低。(3)满足AP原则的数据库:满足可用性和分区容错性的数据库有CouchDB、Cassandra、DynamoDB、Riak等。此类数据库保证了系统的可用性和分区容错性,但是在节点数据一致性要求不高。一些大型网站数据库的设计一般本着AP原则,系统的可用性和分区容错性的优先级大于一致性。ACID特性
ACID是数据库管理系统中事务管理方面,必须同时满足的4个属性,即原子性(Atomicity)、一致性(Consistency)、隔离性(Isolation)和持久性(Durability)。这4个属性统称为ACID特性,具体含义如下所示。一个事务必须被视为像原子一样,不可分割的最小工作单位,对数据库的操作要么都执行,要么都不执行。如果一个事务中的任何操作失败,则整个事务将被回滚到最初状态,就像从未执行过一样。事务的执行结果应确保数据库的状态,从一个一致性状态转变为另一个一致性状态,一致性状态的含义是数据库中的数据应满足完整性约束。多个事务并发执行时,各个事务的执行不应影响其他事务的执行。一个事务一旦提交,它对数据库所做的修改应该永久保存在数据库中,任何事务或系统故障都不会导致数据丢失。以上是事务4个属性的概念,为了便于读者理解,接下来以转账的例子来说明如何使用数据库事务保证数据的准确性和完整性,例如账户A和账户B的余额都是1000元,账户A给账户B转账100元,则需要6个步骤,具体如下所示。对应如上6个步骤理解事务的4个属性,具体如下所示。l 原子性:保证步骤1~6所有过程都执行或都不执行。只要在执行任一步骤的过程中出现问题,就需要执行回滚操作。例如执行到第5步时,账户B突然不可用(比如被注销),那么之前的所有操作都应该回滚到执行事务之前的状态。l 一致性:在转账之前,账户A和B余额共有1000+1000=2000元。在转账之后,账户A和B余额共有900+1100=2000元。实际上,在执行该事务操作之后,数据从一个状态改变为另外一个状态。l 隔离性:在账户A向B转账的整个过程中,只要事务还未提交,查询账户A和B时,两个账户中金额都不会产生变化。如果在账户A给B转账的同时,有另外一个事务执行了账户C给B转账的操作,那么当两个事务都结束时,账户B中的金额应该是账户A转给B的金额,加上账户C转给B的金额,再加上账户B原有的金额。l 持久性:只要提交事务使得转账成功,两个账户中的金额数就会真正发生变化,即会将数据写入数据库做持久化保存。另外,事务的原子性与一致性是密切相关的,原子性的破坏可能导致数据库的不一致,但数据的一致性问题并不都和原子性有关。例如转账的例子中,在第5步时,为账户B只加了50元,该过程是符合原子性的,但数据的一致性就出现了问题。因此,事务的原子性与一致性缺一不可。BASE理论
BASE理论是对CAP原则的完善,此理论的核心思想是:即使无法做到强一致性(满足CAP原则的三个要素),但每个应用也可以根据业务自身特点,采用适当的方式使系统达到最终一致性。NoSQL数据库最主要的优势就是分布式集群架构,保证系统的可用性和分区容错性,在一致性方面做出让步,满足最终一致性即可。BASE理论包括基本可用(Basically Available)、软状态(Soft-state)、最终一致性(Eventually Consistent)三大要素,其含义解释如下所示。当系统出现了不可预估的故障时,系统仍然可用,但与正常系统相比,存在响应时间和功能上的损失。允许系统中的数据存在中间状态,并且该中间状态不会影响系统的整体可用性,可以理解为允许系统在不同节点之间进行数据同步时存在一定的延迟。允许数据不满足实时的一致性,但在一定时间内,数据达到一致的状态。通过对ACID特性和BASE理论的介绍,可以看出两者截然相反,但各有优势。从应用方面来说,比如支付转账业务,应该采用严格的ACID事务管理系统。比如某些超过能够管理的数据,可将系统架构转变为分布式系统,把要处理的大数据进行扩展。最终一致性详解
按照强度的不同,数据的一致性可以分为强一致性和弱一致性。其中,强一致性指的是分布式系统中所有节点的状态和数据副本保持实时性一致;弱一致性指的是不要求分布式系统各节点状态及数据副本保持实时性一致,但是要求各节点的最终状态及数据副本保持一致。最终一致性属于弱一致性的一种特殊形式,要求系统中所有数据副本在一段时间后,最终达到一致的状态。此处的时间期限由网络延时、系统负载、数据复制方案设计等因素决定。1.“因果”一致性(Causal Consistency)如果节点A更新并通知节点B更新了某项数据,节点B之后的访问和更新都基于节点A更新后的值,与节点A无因果关系的C节点不受这样的限制,只遵循一般的最终一致性原则。2.“读己之所写”一致性(Read-your-writes Consistency)节点A在更新完某项数据后,它自身总能访问到已更新后的值,不能访问到更新前的旧值。“读己之所写”一致性是“因果”一致性的一种特例。3.“会话”一致性(Session Consistency)将对系统数据的访问进程放到一个会话当中,如果会话存在,那么系统保证在同一个会话中实现“读己之所写”一致性;如果会话因网络不稳定或宕机等事件而终止,那么需要重新建立会话。4.“单调读”一致性(Monotonic Read Consistency)一个节点从系统中已经读取过数据对象的某个值,那么系统对于该节点的任何后续都访问不到这个值之前的值,即保证客户端在以后的任意请求中,都会返回最新的值。5.“单调写”一致性(Monotonic Write Consistency)最终一致性的5个形式往往是结合使用的,用来构建一个具有最终一致性的NoSQL分布式集群系统。数据复制与分片
NoSQL集群保证读取数据的并行性和分区容错性的主要机制是数据的复制和分片。数据复制,不言而喻,指的是数据的拷贝,在集群中指的是同一份数据拷贝到多个节点。数据分片指的是将数据进行划分,然后存放到不同的节点上,以此实现横向扩展。数据复制和数据分片,可以结合使用,也可以单独使用。数据复制有两种形式,分别为主从复制和对等复制,具体描述如下所示。在数据库集群中将服务器节点按主从(Master/Slave)模式设定为主节点和从节点,通常主节点负责数据的写入,从节点负责数据的读取。主从复制主要目的是实现数据备份,防止单点故障导致数据丢失或者不可用。主、从节点按照一定的策略进行交互,将写入的数据复制到从节点上。在数据库集群中将服务器节点按对等(Peer to Peer)模式设定,各节点地位平等,均可以写入任何数据,节点间相互协调以同步其数据。即使不一致,也能由应用程序或者Raft选举算法来解决。NoSQL数据库几乎都支持自动分片,能够自动地在多台服务器上分发数据,而不需要应用程序增加额外的操作。数据分片的两种方式,分别如下所示。(1) 将不同的数据分片分布到多个节点中,每一个数据子集都由一个专门的节点服务器负责。(2) 将数据复制到多个节点上,每份数据都能在多个节点中找到。一个成熟的NoSQL数据库管理系统是将分片和复制策略结合起来,例如以下方式。(1) 主从复制与分片结合:整个系统中有多个主节点,但对于每项数据,负责它的主节点只有一个。根据配置需要,同一个节点既可以做某些数据的主节点,也可以充当其他数据的从节点,也可以指派全职的主节点或从节点。(2) 对等复制与分片结合:将每个分片数据放在多个节点上,一旦某个节点出错,那么上面保存的那些分片数据会由其他节点重建。NoSQL分类
键值对存储数据库
按照数据存储类型,NoSQL数据库可以分为5大类型,分别为键值对存储数据库、文档存储数据库、列式存储数据库、图形存储数据库。NoSQL不同类型的数据库的产生根源和主要应用场景如下所示。(1) 解决传统关系型数据库无法解决的数据存储及访问问题。其中,键值对存储数据库使用简单的键值方法来存储数据。键值对数据库以键值对为集合存储数据,其中键作为唯一标识符。键值对数据库不仅是高性能、髙度可分区的,而且支持水平扩展,能够实现海量数据的存储与访问。
Key-Value(键值对)数据模型有一个特定的Key和一个指针指向特定的Value,这实际上是一种映射关系,其中key(键)是查找每条数据的唯一关键字,value(值)是该数据实际存储的内容。例如键值对:(“20221225”,“山水画”),其中key为“20221225”是该数据的唯一关键字,value为“山水画”是该数据实际存储的内容。键值对中的值可以是字符串、列表、对象、图像、视频等。Key-Value数据模型采用哈希函数通过对Key进行排序和分区操作直接定位到Value,以此完成存储和检索,能够实现快速查询,支撑起大数据量和高并发查询。若从Value入手,需要对全表的数据进行遍历查找,易造成资源浪费。键值对数据库按照读写方式可以分为两种:面向内存的key-value存储和面向磁盘的key-value存储。采用哪一种键值对数据库,通常由数据量的大小和对访问速度的要求决定。面向内存的key-value存储数据库有Redis、Memcached等产品,适用于数据量不大但需要对特定的数据进行高速并发访问的场景。面向磁盘的key-value存储有RocksDB、LeveIDB等产品。键值对数据库不适合类似于关系型数据库中的关联查询,不但因为实现的代码复杂,而且数据量太大,会导致查询效率低下。采用Key-Value(KV)形式存储数据,无需使用复杂的数据模型,满足增加和删除操作。无需指定数据类型,便于添加新数据。数据驻留保存在内存,在RAM(Random Access Memory,随机存取存储器)中读取和写入速度较快。Redis可以把内存中的数据持久化至磁盘中。由于数据存在内存,这就需要释放以存储新的数据,可使用算法实现,如LRU(Least Recently Used,最近最少使用算法)。文档存储数据库
文档存储数据库以文档的形式存储数据。文档是文档存储数据库的基本单位,文档可以很长、很复杂、内容结构不固定。

档的格式可以是JSON(JavaScript Object Notation)、BSON(Binary JSON)、XML(Extensible Markup Language)等,文档以“字段-值”成对的形式存储数据,存储的内容是文档型的嵌套结构。一个文档的存储内容就相当于关系型数据库中的一行,也就是一条记录。比如存储一个用户的信息,文档存储语句如下所示。
{ "_id": 1, "first_name": "leo", "email": "Mike@example.com", "spouse": "陆西", "likes": [ "Mountain climbing", "swiming", "live tweeting" ] }
文档存储数据库不像关系型数据库要求表格中每行数据的模式都要相同,每个文档的“数据模式”都可以不同,但是也可以放在同一个“集合”内。向文档中新增数据时,不需要预先定义,也不需要修改已有文档内容。文档存储数据库是目前功能最丰富的NoSQL数据库。(1) 文档模型:数据存储在文档中。这些文档类似字处理文档,并且呈现嵌套的键值树形结构,可以包含映射表、集合和纯量值。(2) 结构灵活:不要求固定的数据结构,且结构灵活易于修改,一个集合中的文档之间不需要定义相同的字段,若要修改或添加新字段,不会影响其他文档。(3) 高可用性:支持主从式数据复制,以及快速、安全、自动化的集群节点故障转移。(4) 高效查询:支持视图查询和索引机制,支持复杂的查询条件。文档存储数据库主流产品有MongoDB、CouchDB、OrientDB等。文档存储数据库主要应用于事件记录、网站分析与实时分析、电子商务应用程序、内容管理系统及博客平台等场景。文档存储数据库不适用包含多项操作的复杂事务,不适用于查询持续变化的聚合结构。列式存储数据库
列式数据库以列相关存储架构存储数据,适用于批量数据处理和即时查询。这种数据库不同于行式数据库,数据以行相关的存储体系架构进行空间分配,则适用于小批量的数据处理,常用于联机事务型数据处理。列式数据库将列值按顺序地存到数据库,可以把有关联、经常在一起查询的列设计为列族,以便于解决数据稀疏问题,达到数据的高效访问的目的。
列式存储数据库能够减少I/O操作以及充足利用存储空间,这是因为在列式数据库中,若列值不存在即遇到Null值,则不会存储。列式数据库的典型代表有HBase、Cassandra、Risk以及HyperTable等数据库。(1) 高效:根据不同的数据特征使用压缩算法,高效的压缩效率节省了磁盘空间、计算CPU以及内存空间。(2) 可扩展性:列式存储数据库具有伸缩性,以列的方式分割数据,可灵活增减数据,一个表可达到上亿行和百万列。(3) 延迟物化:列式数据库由于其特殊的执行引擎,在数据中间过程运算的时候一般不需要解压数据而是以指针代替运算,直到最后需要输出完整的数据。(4) 快速查询和写入:可在几秒钟内加载十亿行表,查询的并发处理性能高。(5) 跨平台部署:列式数据库支持Java、Python、Ruby等多种语言应用开发API。列式存储数据库本质上也是以KV形式存储,与键值数据库不同的是,把行和列一起作为键,值则利用时间戳在一起存储。文档存储模式、键值存储模式和列式存储模式通常被称为面向聚合的数据模型。这几种模式之间可以相互配合,没有绝对的界限。图形存储数据库以图形理论抽象的存储实体之间的关系信息,其中实体被看作图形的“节点”,关系被视为图形的“边”,边按照关系将节点进行连接。

数据模型使用节点(实体)和边(关系)来表示,其中,节点间的关系有多种类型,可带有描述属性;节点则可以带有不同类别标签,综合起来能高效地解决复杂的关系问题。
以社会网络中人与人之间的关系为例,难以使用关系型数据库存储“关系信息”数据,查询速度慢且复杂,而图形存储数据库是NoSQL数据库中的一种以图形结构存储实体之间关系信息的数据库,非常适合“关系信息”数据的管理。
常见的图形数据库有Neo4j、FlockDB、AllegroGrap、GraphDB、InfiniteGrap等,另外,还有其他一些图形数据库,如OrientDB、InfoGrid和HypergraphDB等。
图形数据库更加高效的对人际关系、事件关系及其他关系数据的管理与分析应用,如在微信、微博等社交应用场景。利用亲人和朋友之间的联系,图形数据库可以展现出用户在朋友圈的定位,以及与其他关联用户的共同特点,如爱好和兴趣等。图形存储数据库还常应用于欺诈检测、推荐应用、交通网络、金融领域等场景。
图形存储数据库的特点如下所示。
(1) 数据模型:使用关系型数据库表示多对多关系时,需要设计两个实体之间的关系,然后建立一个关联表,如果两个实体之间存在多种关系,那么需要额外建立多个关联表。这样的情况下,图形数据库则只需要标明两实体间的多种关系。若两个实体(节点)间存在双向关系,那为每个方向定义一个关系即可。
(2) 图形搜索能力:支持基于路径的高性能图数据遍历访问方法。
(3) 横向扩展能力:如单个Neo4j实例能够存储几十亿个结点及关系,这种扩展能力已经足够应对一般的企业级应用。支持分布式集群架构,可以支撑起数十亿节点的高效访问。
(4) 跨平台能力:支持Java、Python等多种开发语言,以及支持跨平台部署、简单易用。
目前市场上多达二十多个开源和商业的NoSQL数据库,这就涉及到选择合适的产品或云服务的问题。NoSQL数据库的架构和功能各有不同,选择最适合所需任务的类型,需注意以下6点。
(1) 数据库的选择并不是单一的,不同的业务模块可选择专用的数据库。
(2) 需要支持应用程序中的多个进程或微服务持久共享数据,优先选择键值对存储数据库。
(3) 需要对邻近度计算,欺诈检测或关联结构评估进行深层关系分析,则可以选择图形存储数据库。
(4) 需要快速地收集大量数据并进行分析,优先选择使用列式存储数据库。列式存储数据库也支持图形和文档存储。
(5) 对于初始项目的需求,重点考虑性能、规模、安全性,对各种工作负载(包括事务,运营和分析)的支持,与现有生态系统的集成,管理工作,云支持以及支持的用例类型。其中,安全性至关重要,考虑选择具有安全认证的NoSQL数据库,比如静态数据和运动数据加密等功能,以保护敏感信息。
(6) NoSQL数据库的普遍特点,并不代表是共同特点,比如并非所有NoSQL数据库都可以很好地扩展,某些关系数据库则具有更好地扩展和执行。如果要支持高度关键的类似银行的事务,关系数据库仍然是最佳解决方案。
来不及解释了,快上车!

欢迎新的小伙伴加入!在这里,我们鼓励大家积极参与群内讨论和交流,分享自己的见解和经验,一起学习和成长。同时,也欢迎大家提出问题和建议,让我们不断改进和完善这个平台。
↓↓↓ 点个在看,无需赞赏!
原文作者:运维book思议;如有侵权,请联系管理员删除。