• 关于 MongoDB关系 的搜索结果

回答

生命周期管理 API 描述 CreateDBInstance 该接口用于创建MongoDB副本集实例,同时也可用于克隆MongoDB副本集实例。 ModifyDBInstanceSpec 调用ModifyDBInstanceSpec接口变更MongoDB单节点或副本集实例的规格或存储空间。 DeleteDBInstance 调用DeleteDBInstance接口释放MongoDB实例。 RenewDBInstance 调用RenewDBInstance接口手动续费包年包月的MongoDB实例。 CreateShardingDBInstance 调用CreateShardingDBInstance接口创建或者克隆MongoDB分片集群实例。 CreateNode 调用CreateNode接口为MongoDB分片集群实例增加Shard节点或Mongos节点。 DeleteNode 调用DeleteNode接口删除MongoDB分片集群实例中的Shard节点或Mongos节点。 ModifyNodeSpec 调用ModifyNodeSpec接口变更MongoDB分片集群实例中节点的规格和存储空间。 DescribeRenewalPrice 调用DescribeRenewalPrice接口查询指定MongoDB实例续费一个月的价格。 实例管理 API 描述 DescribeRegions 调用DescribeRegions接口查看MongoDB实例可用的地域和可用区。 DescribeDBInstances 调用DescribeDBInstances接口查询MongoDB实例列表。 RestartDBInstance 调用RestartDBInstance接口重启MongoDB实例。 ModifyDBInstanceMaintainTime 调用ModifyDBInstanceMaintainTime接口修改MongoDB实例的可维护时间。 ModifyDBInstanceDescription 调用ModifyDBInstanceDescription接口修改MongoDB实例名称。 DescribeDBInstanceAttribute 调用DescribeDBInstanceAttribute接口查询MongoDB实例详情。 DescribeReplicaSetRole 调用DescribeReplicaSetRole接口查询MongoDB实例中的角色信息及连接信息。 DescribeShardingNetworkAddress 调用DescribeShardingNetworkAddress接口查询MongoDB分片集群实例的连接信息。 ModifyDBInstanceNetworkType 调用ModifyDBInstanceNetworkType接口切换MongoDB实例的网络类型。 SwitchDBInstanceHA 调用SwitchDBInstanceHA接口切换MongoDB实例中的主备节点。 AllocatePublicNetworkAddress 调用AllocatePublicNetworkAddress接口为MongoDB实例申请公网连接地址。 ReleasePublicNetworkAddress 调用ReleasePublicNetworkAddress接口释放MongoDB实例的公网连接地址。 UpgradeDBInstanceEngineVersion 调用UpgradeDBInstanceEngineVersion接口升级MongoDB实例的数据库版本。 DestroyInstance 调用DestroyInstance接口销毁MongoDB实例。 UpgradeDBInstanceKernelVersion 调用UpgradeDBInstanceKernelVersion接口升级MongoDB实例的数据库小版本。 DescribeKernelReleaseNotes 调用DescribeKernelReleaseNotes接口查询MongoDB实例的小版本发布日志。 ModifyDBInstanceConnectionString 调用ModifyDBInstanceConnectionString接口修改MongoDB实例的连接地址。 ModifyDBInstanceNetExpireTime 调用ModifyDBInstanceNetExpireTime接口延长MongoDB实例的经典网络保留时长。 MigrateAvailableZone 调用MigrateAvailableZone接口迁移MongoDB实例的可用区。 ModifyInstanceVpcAuthMode 调用ModifyInstanceVpcAuthMode接口开启或关闭MongoDB实例的专有网络免密访问功能。 DescribeRoleZoneInfo 调用DescribeRoleZoneInfo接口查询MongoDB实例的各节点的角色和所属的可用区 ReleaseNodePrivateNetworkAddress 调用ReleaseNodePrivateNetworkAddress接口释放MongoDB分片集群实例的Shard节点或ConfigServer节点的内网连接地址。 AllocateNodePrivateNetworkAddress 调用AllocateNodePrivateNetworkAddress接口为MongoDB分片集群实例的Shard节点或ConfigServer节点申请内网连接地址。 CheckCloudResourceAuthorized 调用CheckCloudResourceAuthorized接口查询KMS密钥是否已授权给MongoDB实例。 DescribeAvailableEngineVersion 调用DescribeAvailableEngineVersion接口查询MongoDB实例可升级的版本。 TransformToPrePaid 调用TransformToPrePaid接口将按量付费的MongoDB实例转换为包年包月(预付费)实例。 MigrateToOtherZone 调用MigrateToOtherZone接口迁移MongoDB实例到其他可用区。 标签管理 API 描述 UntagResources 调用UntagResources接口将标签从实例中解绑,如果该标签没有绑定到其他实例,则该标签会被删除。 TagResources 调用TagResources接口为一个或多个MongoDB实例绑定标签。 ListTagResources 调用ListTagResources接口查询MongoDB实例和标签的绑定关系。 DescribeTags 调用DescribeTags接口查询目标地域中所有的标签信息。 账号管理 API 描述 ResetAccountPassword 调用ResetAccountPassword接口重置MongoDB实例中root账号的密码。 DescribeAccounts 调用DescribeAccounts接口查询MongoDB实例的数据库账号信息。 ModifyAccountDescription 调用ModifyAccountDescription接口修改MongoDB实例中root账号的备注信息。 安全管理 API 描述 DescribeSecurityIps 调用DescribeSecurityIps接口查询MongoDB实例的IP白名单。 ModifySecurityIps 调用ModifySecurityIps接口修改MongoDB实例的IP白名单。 DescribeAuditRecords 调用DescribeAuditRecords接口查询MongoDB实例的审计日志。 DescribeAuditFiles 调用DescribeAuditFiles接口查询MongoDB实例的审计日志文件。 DescribeAuditPolicy 调用DescribeAuditPolicy接口查询MongoDB实例的审计日志是否开启。 ModifyAuditLogFilter 调用ModifyAuditLogFilter接口修改MongoDB实例审计日志的采集类型。 DescribeAuditLogFilter 调用DescribeAuditLogFilter接口查询MongoDB实例审计日志采集的日志类型。 ModifyDBInstanceSSL 调用ModifyDBInstanceSSL接口修改MongoDB实例的SSL配置。 DescribeDBInstanceSSL 调用DescribeDBInstanceSSL接口查询MongoDB实例的SSL设置详情。 DescribeDBInstanceTDEInfo 调用DescribeDBInstanceTDEInfo接口查询MongoDB实例的透明数据加密TDE(Transparent Data Encryption)是否开启。 ModifyDBInstanceTDE 调用ModifyDBInstanceTDE接口修改MongoDB实例的透明数据加密TDE(Transparent Data Encryption)状态。 ModifyAuditPolicy 调用ModifyAuditPolicy接口设置MongoDB实例的审计日志开关或日志存储时长。 DescribeSecurityGroupConfiguration 调用DescribeSecurityGroupConfiguration接口查询MongoDB实例绑定的ECS安全组信息。 ModifySecurityGroupConfiguration 调用ModifySecurityGroupConfiguration更改MongoDB实例已绑定的ECS安全组。 日志管理 API 描述 DescribeSlowLogRecords 调用DescribeSlowLogRecords接口查询MongoDB实例运行出现的慢操作日志明细。 DescribeErrorLogRecords 调用DescribeErrorLogRecords接口查询MongoDB实例的错误日志。 DescribeRunningLogRecords 调用DescribeRunningLogRecords接口查询MongoDB实例的运行日志。 性能监控管理 API 描述 DescribeDBInstancePerformance 调用DescribeDBInstancePerformance接口查询MongoDB实例性能数据。 ModifyDBInstanceMonitor 调用ModifyDBInstanceMonitor接口设置MongoDB实例的监控采集粒度。 DescribeDBInstanceMonitor 调用DescribeDBInstanceMonitor接口查询MongoDB实例的监控采集粒度。 参数管理 API 描述 DescribeParameterModificationHistory 调用DescribeParameterModificationHistory接口查询MongoDB实例参数的修改记录。 DescribeParameters 调用DescribeParameters接口查询MongoDB实例的参数配置信息。 DescribeParameterTemplates 调用DescribeParameterTemplates接口查询MongoDB实例默认的参数模板列表。 ModifyParameters 调用ModifyParameters接口修改MongoDB实例的参数。 索引推荐 API 描述 DescribeIndexRecommendation 调用DescribeIndexRecommendation接口查询MongoDB实例的索引推荐详情。 CreateRecommendationTask 调用CreateRecommendationTask接口为MongoDB实例创建索引分析任务。 DescribeAvailableTimeRange 调用DescribeAvailableTimeRange接口查询MongoDB实例索引分析报告的分析时间段和生成状态。 备份与恢复 API 描述 DescribeBackupPolicy 调用DescribeBackupPolicy接口查询MongoDB实例的备份策略。 ModifyBackupPolicy 调用ModifyBackupPolicy接口修改MongoDB实例的备份策略。 CreateBackup 调用CreateBackup接口手动备份MongoDB实例。 DescribeBackups 调用DescribeBackups接口查询MongoDB实例的备份列表。 RestoreDBInstance 调用RestoreDBInstance接口恢复数据至当前MongoDB实例。 DescribeBackupDBs 在为MongoDB实例执行单库恢复前,您可以调用本接口查询指定的时间点或备份集内包含的数据库。 CheckRecoveryCondition 调用CheckRecoveryCondition接口检查MongoDB实例是否满足数据恢复的条件。 附表 API 描述 错误码表 错误码表 实例规格表 实例规格表 实例状态表 实例状态表 性能监控表 性能监控表

保持可爱mmm 2020-03-29 12:36:58 0 浏览量 回答数 0

问题

云数据库MongoDB版和MongoDB有什么关系?

云栖大讲堂 2019-12-01 21:23:32 992 浏览量 回答数 0

问题

MongoDB与HDFS的关系

落地花开啦 2019-12-01 19:49:12 1611 浏览量 回答数 2

试用中心

为您提供0门槛上云实践机会,企业用户最高免费12个月

问题

MongoDB发布新引擎3.0版本 性能大幅提升安全仍需提高

少丰 2019-12-01 21:36:42 7372 浏览量 回答数 1

问题

Mongodb 的问题:谁能拿mysql说简单说一下Mongodb 数据结构是什么样子的

杨冬芳 2019-12-01 20:16:50 993 浏览量 回答数 1

回答

1、两个都要学,一个是NoSQL数据库,一个是缓存2、Mongodb理论优势是 1、数据模型灵活 2、高性能 3、易于伸缩 搭建集群。3、比较适合存储 灵活多变需求的互联网或者IOT数据。4、搭建容易,而且如果以后需求可能增加字段的情况,新浪微博的用户,微信的用户,不断改需求加字段。5、或者导航的数据,东航的机票的价格变化后的数据。这都在Mongodb存储。6、如果是大文件数据,建议HDFS。7、一般的数据只要不是强调关系特别强的,可以都可以使用MongoDB.8、如果你要学习MongoDB可以参加MongoDB大会,或者阅读我翻译的《Mongodb实战》第2版,或者我和阿里P9叶翔讲的《阿里云MongoDB高级开发实战系列课程》,不过是付费的。https://edu.aliyun.com/workshop/3/course/1044

徐雷frank 2019-12-02 01:48:14 0 浏览量 回答数 0

问题

用mysql简单介绍Mongodb 数据结构。

落地花开啦 2019-12-01 20:02:28 1180 浏览量 回答数 1

回答

其实官网的这篇设计哲学还是很不错的(http://www.mongodb.org/display/DOCS/S...)MongoDB和传统SQL schema设计上最大的区别就是关于模型关系用什么方法表示比较好(在MongoDB里即可以用Link,又可以用Embedded)简单总结下:FirstClass (比如“User”这种) 应该用独立的Collection"条目类型"的,应该 embedded两个模型之间如果是包含关系,用 embedded多对多关系,用 link(类似sql里面的foregin key)如果一个模型,其可能存的对象很少,那么就用独立的collection,这样有助于mongodb server做缓存embedded方式不利于做复杂的关联,复杂的查询embedded方式性能很有优势,如果你有“性能”方面的要求,可以考虑用embbed

a123456678 2019-12-02 03:00:29 0 浏览量 回答数 0

问题

python+django能够同时使用mongodb和mysql两种数据库的引擎吗?

落地花开啦 2019-12-01 19:46:46 3811 浏览量 回答数 3

回答

nosql比较宽泛,不同的数据库设计原则不同。比如mongoDB和redis都属于nosql,但是一个是文档型,一个是KV型,设计原则的区别特别大。mongoDB的设计原则还是比较靠近关系型数据库,它的collection和table比较类似,也是insert、remove、update、find这几个基本操作,可以参考关系型数据库来设计。但是它比关系型关系灵活。比如:一条微博可以插入9张图片,如果在MySQL中,可能这样设计:微博是一个table,图片信息是一个table,两只表做关联。或者这样设计:在微博那个table中加一个足够大的字符串类型的字段叫img_info,里面存放9张图片信息的json字符串。而在mongoDB中,天生就是支持上述的第二种设计的。记住,是天生支持,也是就天生对img_info里面内容crud操作都异常方便。然后回到你说的分页的问题:分页主要就是用到2个函数:limit和skip但是,数据量太大的时候,就不适合用skip分页了。《MongoDB权威指南》中给出的解决方案是:获取上一页的最后一条数据,然后使用gt和limit获取下一页的数据。关于redis的,@土豆2015 同学已经说的很详细了,就不累述了。提醒@土豆2015 一下,mongoDB是将部分数据做内存映射,最大化利用内存,持久化还是会保存在磁盘中的。如果没有持久化,把mongoDB重启一下,数据不就都没有了啊。就算是redis这样纯内存型数据库,也是有数据持久化的。

a123456678 2019-12-02 03:00:37 0 浏览量 回答数 0

问题

Nosql(MongoDB)如何书写数据库结构文档?

李博 bluemind 2019-12-01 19:37:06 291 浏览量 回答数 1

回答

其实官网的这篇设计哲学还是很不错的https://docs.mongodb.org/manual/data-modeling/ MongoDB和传统SQL schema设计上最大的区别就是关于模型关系用什么方法表示比较好(在MongoDB里即可以用Link,又可以用Embedded)简单总结下:1.FirstClass (比如“User”这种) 应该用独立的Collection2."条目类型"的,应该 embedded3.两个模型之间如果是包含关系,用 embedded4.多对多关系,用 link(类似sql里面的foregin key)5.如果一个模型,其可能存的对象很少,那么就用独立的collection,这样有助于mongodb server做缓存6.embedded方式不利于做复杂的关联,复杂的查询7.embedded方式性能很有优势,如果你有“性能”方面的要求,可以考虑用embbed

蛮大人123 2019-12-02 01:46:44 0 浏览量 回答数 0

回答

最大的不同就是1、MongoDB是非关系型NoSQL数据库的代表,排名第一,移动互联网公司比较多。2、MySQL是关系型数据库SQL的代表,互联网公司比较多。3、最大的不同在于Schema灵活性,MongoDB不固定表结构,MySQL需要固定设计字段,约束性强。4、如果说还有其他不同,MySQL体系更强大,支持存储引擎、语言、存储过程、包括事务、触发器等复制机制,重量级路线。5、MongoDB走的是轻量级路线,追求高性能,高并发,易于扩展伸缩。6、目前来看两个数据库有一部分是对方的功能,MongoDB也支持事务,MySQL开始支持JSON格式。7、MongoDB对于并发高,并且不确定数据结构,经常变换的项目,比如微博、微信等经常修改需求的数据模型非常适合。8、MySQL传统的数据存储,比较成熟的数据结构可以使用,目前来说还是使用非常多。2个可以结合使用,不冲突。

徐雷frank 2019-12-02 01:41:20 0 浏览量 回答数 0

回答

MongoDB 是对传统关系型数据库的补充,它非常适合高伸缩性的场景,它是可扩展性的表结构。基于这点,可以将预期范围内,表结构可能会不断扩展的 MySQL 表结构,通过 MongoDB 来存储,这就可以保证表结构的扩展性。此外,日志系统数据量特别大,如果用 MongoDB 数据库存储这些数据,利用分片集群支持海量数据,同时使用聚集分析和 MapReduce 的能力,是个很好的选择。MongoDB 还适合存储大尺寸的数据,GridFS 存储方案就是基于 MongoDB 的分布式文件存储系统。推荐阅读:http://blog.720ui.com/2017/db_better_db_use/

白岳 2019-12-02 01:48:13 0 浏览量 回答数 0

回答

MongoDB 是对传统关系型数据库的补充,它非常适合高伸缩性的场景,它是可扩展性的表结构。基于这点,可以将预期范围内,表结构可能会不断扩展的 MySQL 表结构,通过 MongoDB 来存储,这就可以保证表结构的扩展性。此外,日志系统数据量特别大,如果用 MongoDB 数据库存储这些数据,利用分片集群支持海量数据,同时使用聚集分析和 MapReduce 的能力,是个很好的选择。MongoDB 还适合存储大尺寸的数据,GridFS 存储方案就是基于 MongoDB 的分布式文件存储系统。推荐阅读:http://blog.720ui.com/2017/db_better_db_use/

白岳 2019-12-02 01:48:18 0 浏览量 回答数 0

回答

MongoDB 是对传统关系型数据库的补充,它非常适合高伸缩性的场景,它是可扩展性的表结构。基于这点,可以将预期范围内,表结构可能会不断扩展的 MySQL 表结构,通过 MongoDB 来存储,这就可以保证表结构的扩展性。此外,日志系统数据量特别大,如果用 MongoDB 数据库存储这些数据,利用分片集群支持海量数据,同时使用聚集分析和 MapReduce 的能力,是个很好的选择。MongoDB 还适合存储大尺寸的数据,GridFS 存储方案就是基于 MongoDB 的分布式文件存储系统。推荐阅读:http://blog.720ui.com/2017/db_better_db_use/

白岳 2019-12-02 01:50:28 0 浏览量 回答数 0

问题

MongoDB是否适合存储二进制数据,效率如何?

落地花开啦 2019-12-01 19:46:52 2335 浏览量 回答数 1

问题

【推新.聚优惠】mongoDB上云免费咨询/架构方案/7*24代维

sheroy 2019-12-01 21:08:21 8573 浏览量 回答数 0

问题

是否需要将 MySQL 换成 MongoDB?

李博 bluemind 2019-12-01 19:37:23 370 浏览量 回答数 1

问题

什么是MongoDB控制台

云栖大讲堂 2019-12-01 21:22:21 1103 浏览量 回答数 0

问题

MongoDB如何避免注入除SQL的其他语言问题?

落地花开啦 2019-12-01 19:46:27 1623 浏览量 回答数 1

回答

我的项目有些遇到过join的问题。我的解决办法就是存储对应的ObjectId们,通过mongodb的aggregation来达到join的目的。我是用了WiredTiger引擎,所以解决了在大量读写的时候锁死数据库的问题。还有在设计数据库上面尽量避免传统的sql设计思维跟开发逻辑。一个collection尽量对应一个事件。后来因为项目的扩大,我引入了worker的开发模式,将逻辑层的关系改成独立的线程的worker,目前来说应对大量无上线并发效果不错(类似于无上线人数抢红包的效果)。一点儿拙见仅供参考。还有就是对已习惯sql开发模式的人mongodb的局限性会让人很不习惯。但是在大数据时代mongodb的优势是显而易见。目前来说我的项目基本结构是:服务器: nginx+mongodb+php-fpm+ubuntu主程序: MVC(php) // 值提供逻辑关系交换辅程序: Workers // 多线程处理对应的逻辑关系做数据库互交

蛮大人123 2019-12-02 02:48:28 0 浏览量 回答数 0

问题

是否需要将 MySQL 换成 mongoDB?

西秦说云 2019-12-01 19:39:57 1331 浏览量 回答数 2

回答

MongoDB ACID事务支持 这里要有一定的关系型数据库的事务的概念,不然不一定能理解的了这里说的事务概念。 下面说一说MongoDB的事务支持,这里可能会有疑惑,前面我们在介绍MongoDB时,说MongoDB是一个NoSQL数据库,不支持事务。这里又介绍MongoDB的事务。这里要说明一下MongoDB的事务支持跟关系型数据库的事务支持是两码事,如果你已经非常了解关系型数据库的事务,通过下面一副图对比MongoDB事务跟MySQL事务的不同之处。 MongoDB是如何实现事务的ACID? 1)MongoDB对原子性(Atomicity)的支持 原子性在Mongodb中到底是一个什么概念呢?为什么说支持但又说Mongodb的原子性是单行/文档级原子性,这里提供了一个MongoDB更新语句样例,如下图: MongoDB是如何实现事务的ACID? 更新“username”等于“tj.tang”的文档,更新salary、jobs、hours字段。这里对于这三个字段Mongodb在执行时要么都更新要么都不更新,这个概念在MySQL中可能你没有考虑过,但在MongoDB中由于文档可以嵌套子文档可以很复杂,所以Mongodb的原子性叫单行/文档级原子性。 对于关系型数据库的多行、多文档、多语句原子性目前Mongodb是不支持的,如下情况: MongoDB是如何实现事务的ACID? MongoDB更新条件为工资小于50万的人都把工资调整为50万,这就会牵扯到多文档更新原子性。如果当更新到Frank这个文档时,出现宕机,服务器重启之后是无法像关系型数据库那样做到数据回滚的,也就是说处理这种多文档关系型数据库事务的支持,但MongoDB不支持。那么怎么解决Mongodb这个问题呢?可以通过建模,MongoDB不是范式而是反范式的设计,通过大表和小表可以把相关的数据放到同一个文档中去。然后通过一条语句来执行操作。 2)MongoDB对一致性(consistency)的支持 对于数据一致性来说,传统数据库(单机)跟分布式数据库(MongoDB)对于数据一致性是不太一样的,怎么理解呢?如下图: MongoDB是如何实现事务的ACID? 对于传统型数据库来说,数据一致性主要是在单机上,单机的问题主要是数据进来时的规则检验,数据不能被破坏掉。而在分布式数据库上,因为他们都是多节点分布式的,我们讲的一致性往往就是讲的各个节点之间的数据是否一致。而MongoDB在这点上做的还是不错的,MongoDB支持强一致性或最终一致性(弱一致性),MongoDB的数据一致性也叫可调一致性,什么意思呢?如下图: MongoDB是如何实现事务的ACID? MongoDB的可调一致性,也就是可以自由选择强一致性或最终一致性,如果你的应用场景是前台的方式可以选择强一致性,如果你的应用场景是后台的方式(如报表)可以选择弱一致性。 一致性 上面我们讲到了通过将数据冗余存储到不同的节点来保证数据安全和减轻负载,下面我们来看看这样做引发的一个问题:保证数据在多个节点间的一致性是非常困难的。在实际应用中我们会遇到很多困难,同步节点可能会故障,甚至会无法恢复,网络可能会有延迟或者丢包,网络原因导致集群中的机器被分隔成两个不能互通的子域等等。在NoSQL中,通常有两个层次的一致性:第一种是强一致性,既集群中的所有机器状态同步保持一致。第二种是最终一致性,既可以允许短暂的数据不一致,但数据最终会保持一致。我们先来讲一下,在分布式集群中,为什么最终一致性通常是更合理的选择,然后再来讨论两种一致性的具体实现结节。 关于CAP理论 为什么我们会考虑削弱数据的一致性呢?其实这背后有一个关于分布式系统的理论依据。这个理论最早被Eric Brewer提出,称为CAP理论,尔后Gilbert和Lynch对CAP进行了理论证明。这一理论首先把分布式系统中的三个特性进行了如下归纳: 一致性(C):在分布式系统中的所有数据备份,在同一时刻是否同样的值。 可用性(A):在集群中一部分节点故障后,集群整体是否还能响应客户端的读写请求。 分区容忍性(P):集群中的某些节点在无法联系后,集群整体是否还能继续进行服务。 而CAP理论就是说在分布式存储系统中,最多只能实现上面的两点。而由于当前的网络硬件肯定会出现延迟丢包等问题,所以分区容忍性是我们必须需要实现的。所以我们只能在一致性和可用性之间进行权衡,没有NoSQL系统能同时保证这三点。 要保证数据强一致性,最简单的方法是令写操作在所有数据节点上都执行成功才能返回成功,也就是同步概念。而这时如果某个结点出现故障,那么写操作就成功不了了,需要一直等到这个节点恢复。也就是说,如果要保证强一致性,那么就无法提供7×24的高可用性。 而要保证可用性的话,就意味着节点在响应请求时,不用完全考虑整个集群中的数据是否一致。只需要以自己当前的状态进行请求响应。由于并不保证写操作在所有节点都写成功,这可能会导致各个节点的数据状态不一致。 CAP理论导致了最终一致性和强一致性两种选择。当然,事实上还有其它的选择,比如在Yahoo的PNUTS中,采用的就是松散的一致性和弱可用性结合的方法。但是我们讨论的NoSQL系统没有类似的实现,所以我们在后续不会对其进行讨论。 强一致性 强一致性的保证,要求所有数据节点对同一个key值在同一时刻有同样的value值。虽然实际上可能某些节点存储的值是不一样的,但是作为一个整体,当客户端发起对某个key的数据请求时,整个集群对这个key对应的数据会达成一致。下面就举例说明这种一致性是如何实现的。 假设在我们的集群中,一个数据会被备份到N个结点。这N个节点中的某一个可能会扮演协调器的作用。它会保证每一个数据写操作会在成功同步到W个节点后才向客户端返回成功。而当客户端读取数据时,需要至少R个节点返回同样的数据才能返回读操作成功。而NWR之间必须要满足下面关系:R+W>N 下面举个实在的例子。比如我们设定N=3(数据会备份到A、B、C三个结点)。比如值 employee30:salary 当前的值是20000,我们想将其修改为30000。我们设定W=2,下面我们会对A、B、C三个节点发起写操作(employee30:salary, 30000),当A、B两个节点返回写成功后,协调器就会返回给客户端说写成功了。至于节点C,我们可以假设它从来没有收到这个写请求,他保存的依然是20000那个值。之后,当一个协调器执行一个对employee30:salary的读操作时,他还是会发三个请求给A、B、C三个节点: 如果设定R=1,那么当C节点先返回了20000这个值时,那我们客户端实际得到了一个错误的值。 如果设定R=2,则当协调器收到20000和30000两个值时,它会发现数据不太正确,并且会在收到第三个节点的30000的值后判断20000这个值是错误的。 所以如果要保证强一致性,在上面的应用场景中,我们需要设定R=2,W=2 如果写操作不能收到W个节点的成功返回,或者写操作不能得到R个一致的结果。那么协调器可能会在某个设定的过期时间之后向客户端返回操作失败,或者是等到系统慢慢调整到一致。这可能就导致系统暂时处于不可用状态。 对于R和W的不同设定,会导致系统在进行不同操作时需要不同数量的机器节点可用。比如你设定在所有备份节点上都写入才算写成功,既W=N,那么只要有一个备份节点故障,写操作就失败了。一般设定是R+W = N+1,这是保证强一致性的最小设定了。一些强一致性的系统设定W=N,R=1,这样就根本不用考虑各个节点数据可能不一致的情况了。 HBase是借助其底层的HDFS来实现其数据冗余备份的。HDFS采用的就是强一致性保证。在数据没有完全同步到N个节点前,写操作是不会返回成功的。也就是说它的W=N,而读操作只需要读到一个值即可,也就是说它R=1。为了不至于让写操作太慢,对多个节点的写操作是并发异步进行的。在直到所有的节点都收到了新的数据后,会自动执行一个swap操作将新数据写入。这个操作是原子性和一致性的。保证了数据在所有节点有一致的值。 最终一致性 像Voldemort,Cassandra和Riak这些类Dynamo的系统,通常都允许用户按需要设置N,R,W三个值,即使是设置成W+R<= N也是可以的。也就是说他允许用户在强一致性和最终一致性之间自由选择。而在用户选择了最终一致性,或者是W 3)MongoDB对隔离性(isolation)的支持 在关系型数据库中,SQL2定义了四种隔离级别,分别是READ UNCOMMITTED、READ COMMITTED、REPEATABLE READ和SERIALIZABLE。但是很少有数据库厂商遵循这些标准,比如Oracle数据库就不支持READ UNCOMMITTED和REPEATABLE READ隔离级别。而MySQL支持这全部4种隔离级别。每一种级别都规定了一个事务中所做的修改,哪些在事务内核事务外是可见的,哪些是不可见的。为了尽可能减少事务间的影响,事务隔离级别越高安全性越好但是并发就越差;事务隔离级别越低,事务请求的锁越少,或者保持锁的时间就越短,这也就是为什么绝大多数数据库系统默认的事务隔离级别是RC。 下图展示了几家不同的数据库厂商的不同事物隔离级别。 MongoDB是如何实现事务的ACID? MongoDB在3.2之前使用的是“读未提交”,这种情况下会出现“脏读”。但在MongoDB 3.2开始已经调整为“读已提交”。 下面说说每种隔离级别带来的问题: READ-UNCOMMITTED(读尚未提交的数据) 在这个级别,一个事务的修改,即使没有提交,对其他事务也都是可见的。事务可以读取未提交的数据,这也被称为“脏读(dirty read)”。这个级别会导致很多问题,从性能上来说,READ UNCOMMITTED不会比其他的级别好太多,但却缺乏其他级别的很多好处,除非真的有非常必要的理由,在实际应用中一般很少使用。 READ-COMMITTED(读已提交的数据) 在这个级别,能满足前面提到的隔离性的简单定义:一个事务开始时,只能“看见”已经提交的事务所做的修改。换句话说,一个事务从开始直到提交之前,所做的任何修改对其他事务都是不可见的。这个级别有时候也叫“不可重复读(non-repeatable read)”,因为两次执行同样的查询,可能会得到不一样的结果。 REPEATABLE-READ(可重复读) 在这个级别,保证了在同一个事务中多次读取统一记录的结果是一致的。MySQL默认使用这个级别。InnoDB和XtraDB存储引擎通过多版本并发控制MVCC(multiversion concurrency control)解决了“幻读”和“不可重复读”的问题。通过前面的学习我们知道RR级别总是读取事务开始那一刻的快照信息,也就是说这些数据数据库当前状态,这在一些对于数据的时效特别敏感的业务中,就很可能会出问题。 SERIALIZABLE(串行化) 在这个级别,它通过强制事务串行执行,避免了前面说的一系列问题。简单来说,SERIALIZABLE会在读取的每一行数据上都加锁,所以可能导致大量的超时和锁争用的问题。实际应用中也很少在本地事务中使用SERIALIABLE隔离级别,主要应用在InnoDB存储引擎的分布式事务中。 4)MongoDB对持久性(durability)的支持 对于数据持久性来说,在传统数据库中(单机)的表现为服务器任何时候发生宕机都不需要担心数据丢失的问题,因为有方式可以把数据永久保存起来了。一般都是通过日志来保证数据的持久性。通过下图来看一下传统数据库跟MongoDB对于数据持久性各自所使用的方式。 MongoDB是如何实现事务的ACID? 从上图可以看出,MongoDB同样是使用数据进来先写日志(日志刷盘的速度是非常快)然后在写入到数据库中的这种方式来保证数据的持久性,如果出现服务器宕机,当启动服务器时会从日志中读取数据。不同的是传统数据库这种方式叫做“WAL” Write-Ahead Logging(预写日志系统),而MongoDB叫做“journal”。此外MongoDB在数据持久性上这点可能做的更好,MongoDB的复制默认节点就是三节点以上的复制集群,当数据到达主节点之后会马上同步到从节点上去。

景凌凯 2019-12-02 02:05:12 0 浏览量 回答数 0

回答

MongoDB是一个可扩展、高性能的下一代数据库。MongoDB中的数据以文档形式存储,这样就能在单个数据对象中表示复杂的关系。文档可能由 以下几 部分组成:独立的基本类型属性、“内嵌文档”或文档数组。这样的灵活性让开发者能以一种易于管理且灵活的方式来对大量的问题进行建模,不必将数据打散到不同的数据表中。在数据不宜被构造成单独文档的情况 下,MongoDB有“DBRef”的概念,这是从文档的一个属性指向另一个文档的指针。从MongoDB数据库中获取和查询数据是十分灵活的——可以基于主文档、文档中的任意属性、任意内嵌文档、数组中的任意文档来动态地查询文档。可 以通过 “点”符号来访问内嵌文档。注意事项:只要 sudo apt-get install mongodb 应该就会装好。但是安装得朋友一定都会发现,装起来无法启动无法使用。在查找了一些资料后发现:这主要的问题在于少了 /usr/lib/libmozjs.so 这个软件库的文件。只要你有装 Firefox 或是 另外安装 xulrunner 就应该会有,不过路径是错得。所以就要这样:sudo apt-get install xulrunner-1.9.2安装好了以后,建立连结。ln -s /usr/lib/xulrunner-1.9.2.6/libmozjs.so /usr/lib/libmozjs.so然后重新启动 mongodb 试试看,应该就会看到 mongodb 正确启动。

落地花开啦 2019-12-02 01:42:29 0 浏览量 回答数 0

回答

现在互联网、物联网、大数据、医疗、航空航天、安全领域几乎到处是MongoDB身影。1、Mongodb理论优势是 1、数据模型灵活 2、高性能 3、易于伸缩 搭建集群。2、比较适合存储 灵活多变需求的互联网或者IOT数据。3、搭建容易,而且如果以后需求可能增加字段的情况,新浪微博的用户,微信的用户,不断改需求加字段。4、或者导航的数据,东航的机票的价格变化后的数据。这都在Mongodb存储。5、如果是大文件数据,建议HDFS。6、一般的数据只要不是强调关系特别强的,可以都可以使用MongoDB.

徐雷frank 2019-12-02 01:48:18 0 浏览量 回答数 0

问题

关于MongoDB数据库的疑问

蛮大人123 2019-12-01 19:54:02 1153 浏览量 回答数 1

问题

MongoDB中的chunk和extent是什么关系?

落地花开啦 2019-12-01 19:47:28 1274 浏览量 回答数 1

回答

MongoDB是一个文档数据库,提供好的性能,领先的非关系型数据库。采用BSON存储文档数据。2007年10月,MongoDB由10gen团队所发展。2009年2月首度推出。获得安装包和查看详细的API可以访问官网网址www.mongodb.com

montos 2020-05-22 23:05:19 0 浏览量 回答数 0

回答

关系型数据库 MySQLMySQL 是一个最流行的关系型数据库,在互联网产品中应用比较广泛。一般情况下,MySQL 数据库是选择的第一方案,基本上有 80% ~ 90% 的场景都是基于 MySQL 数据库的。因为,需要关系型数据库进行管理,此外,业务存在许多事务性的操作,需要保证事务的强一致性。同时,可能还存在一些复杂的 SQL 的查询。值得注意的是,前期尽量减少表的联合查询,便于后期数据量增大的情况下,做数据库的分库分表。文档数据库 MongoDBMongoDB 是对传统关系型数据库的补充,它非常适合高伸缩性的场景,它是可扩展性的表结构。基于这点,可以将预期范围内,表结构可能会不断扩展的 MySQL 表结构,通过 MongoDB 来存储,这就可以保证表结构的扩展性。此外,日志系统数据量特别大,如果用 MongoDB 数据库存储这些数据,利用分片集群支持海量数据,同时使用聚集分析和 MapReduce 的能力,是个很好的选择。MongoDB 还适合存储大尺寸的数据,GridFS 存储方案就是基于 MongoDB 的分布式文件存储系统。推荐阅读;http://blog.720ui.com/2017/db_better_db_use/

白岳 2019-12-02 01:42:23 0 浏览量 回答数 0
阿里云大学 云服务器ECS com域名 网站域名whois查询 开发者平台 小程序定制 小程序开发 国内短信套餐包 开发者技术与产品 云数据库 图像识别 开发者问答 阿里云建站 阿里云备案 云市场 万网 阿里云帮助文档 免费套餐 开发者工具 云栖号物联网 小程序开发制作 视频内容分析 企业网站制作 视频集锦 代理记账服务 2020阿里巴巴研发效能峰会 企业建站模板 云效成长地图 高端建站 云栖号弹性计算 阿里云云栖号 云栖号案例 云栖号直播