ToB企服应用市场:ToB评测及商务社交产业平台

标题: MongoDB 从4.4到7.0各个版本特性概览 [打印本页]
作者: 万有斥力    时间: 2024-10-18 05:40
标题: MongoDB 从4.4到7.0各个版本特性概览

  速览
  本文将从以下方面介绍数据库 MongoDB 4.4、5.0、6.0、7.0版本：
  
  引言
  在数据库技术日新月异的今天，MongoDB作为领先的NoSQL数据库之一，持续地推出新版本以满足不停变化的企业需求和技术寻衅。从MongoDB 4.4至7.0，每一版都融入了创新特性，旨在提升性能、扩展性、安全性和易用性，同时也反映了行业趋势和用户反馈。本文旨在全面分析这些版本中的关键新特性，不仅是为了记录技术演进的历史，更是为了赋能数据库管理员、开发者和架构师，使他们能够充分理解并使用这些新功能，从而优化数据管理和应用性能。
  MongoDB 4.4版本新特性
  隐蔽索引
  MongoDB 4.4版本中新增了隐蔽索引，众所周知数据库维护太多的索引会导致写性能降落，但是往往业务上的复杂性导致了运维人员不敢轻易去删除一个潜在的低效率索引，担心误删除会带来业务性能的抖动，而重修索引的代价也非常大。
  为了办理上述题目。该功能支持通过collMod下令隐蔽现有的索引，保证该索引在后续的查询中不会被使用。在观察一段时间后，确定业务没有非常即可以放心删除该索引。
  1. db.runCommand( {
  2.    collMod: 'testcoll',
  3.    index: {
  4.       keyPattern: 'key_1',
  5.       hidden: false
  6.    }
  7. } )
复制代码
重界说分片键
  MongoDB4.4版本中，您可以通过refineCollectionShardKey下令给现有的Shard Key增长一个或多个Suffix Field来改善现有的文档在Chunk上的分布题目。例如在上面描述的订单业务场景中，通过refineCollectionShardKey下令把Shard key更改为{customer_id:1, order_id:1}，即可避免单一分片上的访问热门题目。
  并且，refineCollectionShardKey下令的性能开销非常低，仅更改Config Server节点上的元数据，不需要任何情势的数据迁移，数据的打散仍旧在后续正常的Chunk自动分裂和迁移的流程中渐渐进行。别的，Shard Key需要有对应的Index来支撑，因此refineCollectionShardKey下令要求提前创建新Shard Key所对应的Index。
  由于并不是全部的文档都存在新增的Suffix Field，因此在4.4版本中隐式支持了Missing Shard Key功能，即新插入的文档可以不包罗指定的Shard Key Field。但是由于很容易产生Jumbo Chunk，因此并不建议使用。
  1. db.adminCommand( {
  2.    refineCollectionShardKey: "test.orders",
  3.    key: { customer_id: 1, order_id: 1 }
  4. } )
复制代码
复合哈希分片键
  在最新的4.4版本中参加了复合哈希索引，即您可以在复合索引中指定单个哈希字段，位置不限，可以作为前缀，也可以作为后缀，进而也就提供了对复合哈希片键的支持。
  1. sh.shardCollection(
  2.   "examples.compoundHashedCollection",
  3.   { "region_id" : 1, "city_id": 1, field1" : "hashed" }
  4. )
  5. sh.shardCollection(
  6.   "examples.compoundHashedCollection",
  7.   { "_id" : "hashed", "fieldA" : 1}
  8. )
复制代码
对冲读
  页面的相应速度和经济损失直接挂钩。Google有一个研究报告表明，假如网页的加载时间高出3秒，用户的跳出率会增长50%。针对这个题目，MongoDB在4.4版本中提供了Hedged Reads功能，即在分片集群场景下，mongos节点会把一个读请求同时发送给某个分片的两个副本集成员，然后选择最快的返回结果回复客户端，来淘汰业务上的P95（指过去十秒内95%的请求延迟均在规定范围内）和P99延迟（指过去十秒内99%的请求延迟均在规定范围内）。
  Hedged Reads功能作为Read Preference参数的一部门来提供， 因此可以在Operation粒度上进行设置，当Read Preference指定为nearest时，系统默认启用Hedged Reads功能，当指定为primary时，不支持Hedged Reads功能，当指定为其他时，需要显式地指定hedgeOptions才可以启用Hedged Reads。如下所示：
  1. db.collection.find({ }).readPref(
  2.    "secondary",                      // mode
  3.    [ { "datacenter": "B" },  { } ],  // tag set
  4.    { enabled: true }                 // hedge options
  5. )
  6. 此外，Hedged Reads也需要mongos开启支持，配置readHedgingMode参数为on，使mongos开启该功能支持。
  7. 参考代码：
  10. db.adminCommand( { setParameter: 1, readHedgingMode: "on" } )
复制代码
同步建索引
  4.4 之前的版本中，索引的创建需要在主库中完成之后，才会到备库上实行。备库上的创建动作在不同的版本中，由于创建机制和创建方式的不同，对备库Oplog的影响也大有不同。
  但即使在4.2版本中统一了前背景索引创建机制，使用了相当细粒度的加锁机制（只在索引创建的开始和竣事阶段对集合加独占锁），也会由于索引创建本身的CPU、IO性能开销导致复制延迟，或是由于一些特别操纵，例如使用collMod下令修改集合元信息，而导致Oplog的应用阻塞，乃至会由于主库历史Oplog被覆盖而进入Recovering状态。
  在4.4版本中，主库和备库上的索引创建操纵是同时进行的，如许可以大幅淘汰上述情况所带来的主备延迟，即使在索引创建过程中，也可以保证备库访问到最新的数据。
  别的，新的索引创建机制规定，只有在大多数具备投票权限节点返回成功后，索引才会真正生效。以是，也可以减轻在读写分离场景下由于索引不同而导致的性能差异。
  复制读请求
  在4.4版本中，MongoDB针对上述题目实现了Mirrored Reads功能，即主节点会按一定的比例把读流量复制到备库上实行，来帮助备库预热缓存。这是一个非阻塞实行（Fire and Forgot）的举动，不会对主库的性能产生任何实质性的影响，但是备库负载会有一定程度的上升。
  流量复制的比例是可动态设置的，通过mirrorReads参数设置，默认复制1%的流量。
  1. db.adminCommand( { setParameter: 1, mirrorReads: { samplingRate: 0.10 } } )
  2. 此外，还可以通过db.serverStatus( { mirroredReads: 1 } )来查看Mirrored Reads相关的统计信息，如下所示：
  5. SECONDARY> db.serverStatus( { mirroredReads: 1 } ).mirroredReads
  6. { "seen" : NumberLong(2), "sent" : NumberLong(0) }
复制代码
基于时间保存Oplog
  在4.4版本中，MongoDB支持通过storage.oplogMinRetentionHours参数界说需要保存的Oplog时长，也可以通过replSetResizeOplog下令在线修改这个值，参考代码如下：
  1. // First, show current configured value
  2. db.getSiblingDB("admin").serverStatus().oplogTruncation.oplogMinRetentionHours
  3. // Modify
  4. db.adminCommand({
  5.   "replSetResizeOplog" : 1,
  6.   "minRetentionHours" : 2
  7. })
复制代码
MongoDB 5.0版本新特性
  原生时间序列平台
    创建时间序列数据集合的下令示例：
  1. db.createCollection("collection_name",{ timeseries: { timeField: "timestamp" } } )
复制代码
在线数据重新分片
  
数据库版本
特点
实现方法
MongoDB 5.0从前
重新分片过程复杂且需要手动分片。
方法一：先dump整个集合，然后用新的分片键把数据库重新加载到一个新的集合中。
由于这是一个需要离线处理的过程，因此您的应用步伐在重新加载完成之前需要中断停服较长时间。例如：在一个三分片的集群上dump和重新加载一个10 TB以上的集合大概需要几天时间。
方法二：新建一个分片集群并重新设定集合的分片键，然后通过定制迁移方式，将旧分片集群中需要重新分片的集合，按新的分片键写入到新的分片集群中。
该过程中需要您自行处理查询路由和迁移逻辑、不停查抄迁移进度，以确保全部数据迁移成功。
定制迁移是高度复杂的、劳动密集型的、有风险的任务，而且耗时很长。例如：某个MongoDB用户花了三个月才完成100亿个document的迁移。
MongoDB 5.0开始
运行reshardCollection下令即可启动重新分片。
重新分片的过程高效。
并不是简单地重新平衡数据，而是在背景将全部当前集合的数据复制并重新写入新集合，同时与应用步伐新的写入保持同步。
重新分片是完全自动化的。
将重新分片耗费的时间从几周或几个月压缩到几分钟或几小时，避免了冗长繁杂的手动数据迁移。
通过使用在线重新分片，可以方便地在开发或测试环境中评估不同分片键的效果，也可以在您需要时修改分片键。
您可以在业务运行（数据不停增长）的情况下，按需改变集合的分片键（Shard key），而不需要数据库停机或在数据集合中进行复杂的迁移。您只需要在MongoDB Shell中运行reshardCollection下令，选择您需要重新分片的数据库和集合，指定新的分片键即可。
reshardCollection: "<database>.<collection>", key: <shardkey>
阐明
<database>：需要重新分片的数据库名称。
<collection>：需要重新分片的集合名称。
<shardkey>：分片键的名称。
当您调用reshardCollection下令时，MongoDB会克隆现有集合，然后将现有集合中全部oplog应用到新集合中，当全部oplog被使用后，MongoDB会自动切换到新集合，并在背景删除旧集合。
  Write Concern默认Majority级别
  从MongoDB 5.0开始，Write Concern默认级别为majority，仅当写入操纵被应用到Primary节点（主节点）且被持久化到大多数副本节点的日志中的时间，才会提交并返回成功，“开箱即用”地提供了更强的数据可靠性保障。
  阐明
  Write Concern是完全可调的，您可以自界说设置Write Concern，以平衡应用步伐对数据库性能和数据持久性的要求
  连担当理优化
  默认情况下，一个客户端毗连对应后端MongoDB服务器上的一个线程（net.serviceExecutor设置为synchronous）。创建、切换和烧毁线程都是消耗较大的操纵，当毗连数过多时，线程会占用MongoDB服务器较多的资源。
  毗连数较多或创建毗连失控的情况称为“毗连风暴”，产生该情况的原因大概是多方面的，且常常是在服务已经受到影响的情况下发生。
  针对这些情况，MongoDB 5.0接纳了以下步伐：
  
  以上步伐，加上之前版本在mongos查询路由层的改进，进一步提升了MongoDB遭受高并发负载的本领。
  长时间运行的快照查询
  长时间运行的快照查询增长了应用步伐的通用性和弹性。您可以通过该功能运行默认时间为5分钟的查询（或将其调整为自界说持续时间），同时保持与实局势件性数据库划一的快照隔离，也可以在Secondary节点（从节点）上进行快照查询，从而在单个集群中运行不同的工作负载，并将其扩展到不同的分片上。
  MongoDB通过底层存储引擎中一个名为Durable history的项目实现了长期运行的快照查询，该项目早在MongoDB 4.4中就已实现。Durable history将存储自查询开始以来全部变化的字段值的快照。通过使用Durable history，查询可以保持快照隔离，即使在数据发生变化的情况下，Durable history也有助于低沉存储引擎的缓存压力，使得业务可以在高写入负载的场景下实现更高的查询吞吐量。
  新版MongoDB Shell
  为了提供更好的用户体验，MongoDB 5.0从头开始重新设计了MongoDB Shell（mongosh），以提供一个更当代化的下令行体验，以及增强可用性的功能和强大的脚本环境。新版MongoDB Shell已经成为MongoDB平台的默认Shell。新版MongoDB Shell引入了语法高亮、智能自动完成、上下文帮助和有用的错误信息，为您创造一个直观、互动的体验。
  可恢复的索引创建任务
  MongoDB 5.0支持将正在进行中的索引创建任务在节点重新启动后自动会恢复至原来的位置，淘汰计划中维护动尴尬刁难业务的影响。例如：重新启动或升级数据库节点时，您不需要担心当前正在进行的大集合索引创建任务失效。
  MongoDB 6.0版本新特性
  可查询加密
  紧张
  可查询加密功能现在是预览（Preview）版本，不建议直接在生产环境使用。预览（Preview）版本的更多信息，请拜见MongoDB Releases Queryable Encryption Preview。
  MongoDB 6.0新推出可查询加密功能，允许用户从客户端加密敏感数据，将其作为完全随机的加密数据存储在数据库服务器端，并对加密数据进行丰富的查询。
  可查询加密只允许在客户端检察敏感数据的明文，在查询到达服务器端时会同时包罗从KMS获取的加密密钥，然后在服务器端以密文进行查询并返回，末了在客户端使用密钥解密后以明文出现。
  可查询加密的特点如下：
  
  集群同步
  无论是数据的同构同步（Mongo-to-Mongo）还是异构同步（Others-to-Mongo & Mongo-to-Others）都是MongoDB生态中的一部门，开源MongoDB推出了多种工具，比如mongoimport、mongoexport、mongodump和mongorestore等，但是这些工具并没有很好的规划数据同步。
  MongoDB 6.0推出了新的同步工具mongosync，它能支持跨实例数据同步（两个MongoDB实例间连续且单向的数据同步）。用户还可以实时控制和监控整个同步过程，按需启动、停止、恢复乃至反转同步。
  时序集合
  分别从索引、查询以及排序多个方面增强了时序集合。
  
  场景示例：跟踪夏日冷链运输车的温度变化情况、监测特定航线上的货运船燃料消耗。
  
  变动流
  
  阐明
  MongoDB 6.0之前的版本仅支持检察变动后的视图，从MongoDB 6.0版本开始，支持检察变动前后的视图。前后视图的更多信息，请拜见Change Streams with Document Pre- and Post-Images。
  
  聚合
  聚合功能允许用户处理多个文档并返回计算结果。通过将多个操纵符组合到聚合管道中，用户可以构建出足够复杂的数据处理管道以提取数据并进行分析。MongoDB 6.0在原有聚合功能的基础上，推出了如下新特性以及优化项：
  
  查询
  新增$maxN、$topN、$minN、$bottomN、$lastN和$sortArray等操纵符。通过操纵符可以将更多的计算从业务层下沉到数据库中，使得业务层更加轻量化。
  弹性
  MongoDB 6.0在原有弹性的基础上，推出了如下新特性以及优化项：
  
  示例：数据规模特别大的分片表，将数据块规格调整到256 MB。数据规模相对较小但盼望在分片上分布更匀称的分片表，将数据块规格调整到64 MB或32 MB。
  
  您可以通过configureCollectionBalancing下令设置自动整理磁盘碎片，设置自动整理后您无需再自动使用compact下令来整理磁盘空间碎片，即可有效控制磁盘空间使用率
  安全性
  MongoDB 6.0在原有安全性的基础上，对客户端字段级加密（CSFLE, Client-Side Field-Level Encryption）功能进行了优化。CSFLE将支持任何符合密钥管理互通协议（KMIP，Key Management Interoperability Protocol）的密钥管理提供商，即除了基于KeyFile的当地密钥管理外，MongoDB支持通过KMIP与第三方密钥管理设备集成，为用户提供更安全的保障。
  MongoDB 7.0版本新特性
  支持分片元数据划一性校验
  MongoDB 7.0版本中新增了checkMetadataConsistency下令，以查抄不同分片中元数据不划一的情况，示例如下。
  示例1：
  1. // Command
  2. db.runCommand( {
  3.    checkMetadataConsistency: 1,
  4.    checkIndexes: true
  5. } )
  6. 示例2：
  9. //mongosh
  10. db.checkMetadataConsistency()
  11. db.collection.checkMetadataConsistency()
  12. sh.checkMetadataConsistency()
  13. 您可以在日常运维中增加该巡检项，尽早发现可能不一致的风险。更多信息请参见checkMetadataConsistency。
复制代码
支持采样查询与分析分片键
  支持基于采样查询（Sampled queries）的结果来分析集合的分片键是否合理，可以帮助您更好地设计Schema以及分片键、更合理使用分片架构。核心下令analyzeShardKey的语法如下：
  1. db.adminCommand(
  2.    {
  3.      analyzeShardKey: <string>,
  4.      key: <shardKey>,
  5.      keyCharacteristics: <bool>,
  6.      readWriteDistribution: <bool>,
  7.      sampleRate: <double>,
  8.      sampleSize: <int>
  9.    }
  10. )
复制代码
阐明
  尽管该下令并不会阻塞集合上的读写操纵，但为了低沉对业务的影响，建议配套使用secondary或secondaryPreferred模式的Read preference实行。mongos默认为secondaryPreferred模式。
  更多信息请参考analyShardKey与configureQueryAnalyzer。
  自动合并
  MongoDB 7.0为自动均衡器（Balancer）实现了一个新的自动合并器（AutoMerger），当数据或索引分布不均衡、存在过多分片或进行数据迁移时，自动合并器会集并Chunks，以均衡数据并进步性能。MongoDB 7.0默认开启该功能，您也可以通过Balancer运动窗口的控制该功能。
  之前版本引入用于单个集合数据均衡的configureCollectionBalancing下令也支持了AutoMerge：
  1. db.adminCommand(
  2.    {
  3.      configureCollectionBalancing: "<db>.<collection>",
  4.      chunkSize: <num>,
  5.      defragmentCollection: <bool>,
  6.      enableAutoMerger: <bool>
  7.    }
  8. )
  9. 除此之外，您也可以通过mergeAllChunksOnShard命令将一个分片上所有可合并的Chunk（或Range）进行手动合并：
  12. db.adminCommand( { mergeAllChunksOnShard: "db.coll", shard: "Shard0" } )
复制代码
分片
  除了上文提到过的AutoMerger以外，还有以下优化项：
  
  下面的SQL将"myDB"更换为所需要查询的DB名称即可 var dbName = "myDB";
  1. db.getSiblingDB(dbName).getCollectionNames().forEach(function(collName) {  print("————————————————————————");  print("Collection: " + collName);  db.getSiblingDB(dbName).getCollection(collName).getShardDistribution();});
复制代码
安全性
  
  聚合
  新增了以下操纵符，支持位计算和百分位数：
  
字段名
描述
$bitAnd
返回Int或Long类型数值的按位与运算的结果。
$bitNot
返回Int或Long类型数值的按位取反运算结果。
$bitOr
返回Int或Long类型数值的按位或运算的结果。
$bitXor
返回Int或Long类型数值的按位异或运算的结果。
$median
返回近似中位数，相当于50百分位数。
$percentile
返回指定的百分位数。
  时序集合
  
  其他优化
  
  

  公众号内直接回复加群也可以,扫码加群也可以，觉得帖子写的不错，点点关注，点点赞，多多转载，请多多支持。

免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！更多信息从访问主页：qidao123.com:ToB企服之家，中国第一个企服评测及商务社交产业平台。



欢迎光临 ToB企服应用市场:ToB评测及商务社交产业平台 (https://dis.qidao123.com/) Powered by Discuz! X3.4