MongoDB3.2 - 4.2新読書機能

MongoDBは、分散ファイル・ストレージベースのデータベースです。C ++言語で書かれました。WEBアプリケーションのためのスケーラブルで高性能データ・ストレージ・ソリューションを提供するために設計されています。

MongoDBは、リレーショナルデータベースのような豊かな、最も間のリレーショナルデータベースと非リレーショナルデータベース、非リレーショナルデータベース機能との機能を持つ製品です。

まず、レプリカセット

バージョン3.2

1. 選挙メカニズムはいかだプロトコル（PV1）、いじめの早期合意を導入している（キャンペーンコーディネーターの簡単なアルゴリズムPV0）

いじめっ子の契約に関しては、契約上の利益のいかだは、次のとおりです。選挙ロックの排除、用語を導入し、優先順位を弱めます。

場合は、ライブラリからの投票を完了した後に、重複投票の30代を防ぐために、グローバルロックを複数回投与の画面を生成することが早けれいじめ契約は、グローバルロックの追加で、いかだは、オートインクリメントに似（用語に、このような選挙サイクルを導入しましたこのような概念サイクル）、用語が1を追加し、選挙がライブラリからこの期間中にメインの出てきませんが、また、ランダム次のサイクルの投票が始まった場合、いかだは、優先順位を弱体化、メインライブラリの失敗は、高い優先順位に切り替えられますいかだは、この重量を弱める、主な優先順位として選択されます。協定の効率いかだが高くなります。

2. electionTimeoutMillisレプリケーション構成パラメータを増加させる、通信できないマスター・リポジトリのタイムアウトを決定します。ハートビートは、マスタースレーブによって検出されたメインライブラリーからライブラリロム場合は、正常であり、すぐに選挙を開始しませんが、しばらく待つように、とこの時間が経過するので、選挙がfalse選挙を減らし、上の打ち上げ後に行われました回数

バージョン3.4

もはや2020年1月31日の後に維持していません。

1. ディスク容量（最小1G、最大50G）の5％改善された初期総索引作成順序に同期したデータ量とデータoplog（バイナリログ内の類似のMySQL）を引きながらプロセスをコピーし、oplogデフォルト
   
   データのコピーを設定した場合：理由を改善このプロセスは時間がかかり、および書き込み操作は、長い時間のためにインデックスを作成する必要性と相まって、非常に高いです。oplogは、古いものを上書きします満たしている場合、このコレクションのoplogは、円形であることができ、上書きされることがあります。オンライン問題：大規模なインスタンスに直面したとき、その時点でのストレッチ増分記録oplog時間がカバーされているため、ノードを追加するときは、増加していない可能性があります。インデックスを作成するプロセスを削減しながら、3.4からは、ライブラリーに加えていない問題に解決します。64を含む10ギガバイトのデータがある場合、2つの索引フィールド、文書平均1キロバイト、20％程度の増加の全量の同期性能の3.4バージョン、データセットが大きく、同期プロセスである場合を含む各セット効果を高めるための書き込みは、より明らかであろう。

2. リワークの数を減少させる、プロセスの再試行ロジックをコピーするデータの総量を増加させます。ネットワークジッタた場合は、コピーが中断され、これは、操作および保守のための非常に苦痛であると考えました。したがって、再試行ロジックの添加。

3. 初期同期中に発生した同期失敗のセットを直接のREDO名前の変更につながることができます

4. 新catchUpTimeoutMillisレプリケーション構成パラメータは、新しいマスターは、データを更新するための最大時間を取得することを決めました。時間が不足しているデータに私を得たときに、この時間以上はまだ最新のデータを取得していない場合は候補ノードとして、その後の選挙サイクルの新ラウンドを入力してください

5. 増加writeConcernMajorityJournalDefaultパラメータは、書き込みに大半が書き込みメモリまたはディスクに判断します。あなたはwriteConcernMajorityJournalDefaultオプションを高めるために、レプリケーションセットを設定する場合、デフォルトでは過半数としてWriteConcernを指定する場合、であり、ノードへのジャーナルデータを書き込む最も成功したブラシ-時間だけすることを確認するために、真実であることに成功したクライアント;もしほとんどの偽の、書き込みデータノードのメモリは、それがクライアントに確認します。

バージョン3.6

1. 放棄された初期のいじめプロトコル（単純なアルゴリズムキャンペーンコーディネーターPV0）
2. 3.6を直接オンラインで編集することができます後にパラメータのタイムアウトreplSetResizeOplogコマンドとoplogInitialFindMaxSecondsを増やし、早期に再起動し、メインのライブラリを切り替える必要性は、それが、失敗に非常になりやすいです。大きなoplogのために、ストリーミングバックアップ場合は、このタイムアウトメカニズムがあそこに立ち往生されずに、それは一般的に60年代のタイムアウトセットです。
3. バージョン3.4フィックス問題のREDO原因データ同期プロセスの名前変更コレクションの全額を、

バージョン4.0

1. 削除いじめプロトコル（PV0）とマスター・スレーブモードクラスター構造
2. 直接エンジン重量レプリカセットのノードを使用して削除storage.journal.enabled許可されていません：偽。ジャーナルを開く必要があります
3. oplogロールバック最大rollbackTimeLimitSecsとcreateRollbackDataFilesパラメータ制御を増やし
   違いとの間でローカルにロールバックファイルを作成するかどうか。ライブラリとメイン図書館から30分遅れ、その後、ロールバックを実行しません。
4. 相互閉塞oplogビジネスアプリケーションを読んで、ライブラリ追加グローバルロックアプリケーションoplog原因の問題からスナップショットを読み込むことで解決しました。

バージョン4.2

1. 4.2最初から、管理者はより少ない遅延設定に保持された最大値に書き込まれたプライマリ・データベース・アプリケーションの速度を制限することができます。デフォルトでは、フロー制御が有効になっています。（FCVない読み取り懸念の大半の権限を有効または無効にする場合は、フロー制御が有効になっていません。）

第二に、スライスクラスタ

バージョン3.2

ミラーモード（SCCC）、複製セットコンフィギュレーションモード（CSRS）エンジンの導入を廃棄する設定ノードは、WTなければなりません。前後のメタデータ情報に格納されているメタデータのバージョンがミラー3によって記憶される、コンフィグノード構成は、3つのノードを更新するために変更します。このミラーモードの最大の問題は、ノードがハングアップやメンテナンスを必要とし、クラスタ全体の服用を中止する必要がされている場合ということです。代わりに、3.2モードでレプリカセットの、簡単に維持します。

バージョン3.4

1. スライスの各クラスタは、（断片化がクラスタ構成sharding.clusterRoleを設定しなければならない）フラグメンテーションの間違いを避けるために添加される全体の断片化されたクラスタ構成情報の全ての成分の存在を感知することができます。以前のバージョンでは、オンラインでの問題が発生する可能性がある2つのクラスターに属しスライスを、一貫性のないデータが得られ。
2. 設定ノードはもはやゾーン区分戦略は、タグモードを置き換えるために導入され、ミラーモード（SCCC）がサポートされていません。いくつかのデータは、1つ以上の破片を指定し、この機能は大幅のシャーディングクラスタを容易にするであろうに割り当てられた部屋全体に展開することができます
3. wiredTigerエンジンsecondaryThrottleの偽のデフォルト設定は、大幅にチャンクの移行率を向上させることができます。移行スライス2に放出する前に1つのフラグメントは、マスターライブラリで発生しただけでなく、同期させるためにデータを大幅チャンクの速度を低下させる、ライブラリから書き込まれます。バージョン3.4には、移行を加速します。
4. ノードをルーティング平衡データは、マスタライブラリノード設定レプリカセット、増加平行機構バランス（N / 2）とバランサ起動、停止、およびステータスビュー・コマンドからの転送を開始します。あなたが複数のノードを展開する場合、以前のバージョンでは、各ノードは最初のノードを開始することができ、すべてのget、分散ロックの、バランスのタスクを開始します。以前のバージョンは、A-からC-> Dへの移行を必要とするマイグレーションBの完了後>、パラレルバージョン3.4、A-> BおよびCながら> Dは、移動速度を増加させる、同時に行うことができます。

バージョン3.6

1. スライスは、強制的にシングルノードモードを許可していないコピーモードを設定する必要があります
2. MONOSにノードをルーティング接続ノードShardingTaskExecutorPoolMaxConnecting周波数スライシング制御を高めます
3. 最新のチャンクの移行後に制御パラメータorphanCleanupDelaySecsに元の文書のクリーンアップ時間を増やし、

バージョン4.0

1. チャンク移行データは、ほぼ40％の性能向上を達成してきたフェッチと同時動作を適用します
2. 作成および削除コレクションまたは削除データベース操作は、次のようなスライス開始過半数のサポートを書く（過半数）を追加

バージョン4.2

1. フラグメントキーフィールドの_idフィールドは不変でない限り、フラグメントは、文書のキーを更新することができます。バージョン4.2の前に、フラグメントのキーフィールド値文書は不変です。
2. あなたは、複数のドキュメントサービスクラスタの断片化を使用することができます

第三に、読み取り一貫性を向上

バージョン3.2

最初のバージョンではないロールバックを読んで達成することができ、PV1こと（エンジンのみがサポートWT）過半数を読み込む2つの戦略、のローカルおよび大部分をサポートしている必要がありますコピー、読書関連の特性（readConcern）で導入されました。この時点t3ノードがロールバックされません達成することができた後。

バージョン3.4

サポートが追加されましたの線形化（リニア一貫性）の

• 只能用于读primary及读单个文档
• 使用时建议增加maxTimeMS参数

读主库的单个文档的时候，读到的数据一定是在读操作之前写入的数据，这个数据也是写入到大多数节点的，加入这个超时参数，直接给主库发送线性读的情况下，如果从节点挂了，在没有加超时参数的情况下，这个读就可能会一直挂起，就可能引发故障。

3.6版本

增加“available”（可用性）的支持

• 用于分片集合读增加数据容错性但可能读到orphan (孤立)文档
• 读非分片集合的表现和local模式一样

分片集合的读：更宽松的一个隔离级别，甚至可以读到孤立文档，就是chunk迁移之后还留在原来的分片一些文档，理论上对业务来说是不可见的，但是如果你想要看到，那么可以配置这个参数。available用的不多，除非对一致性要求非常低。

4.0版本

1. 增加“snapshot”（快照读）模式，以支持多文档事务读

• 读可见性区分是否关联因果一致性( causally consistent session)

快照读的示例：
假设 x:1 在读事务T1开启前已经写入
事务+snapshot读+写大多数+非因果一致性会话= 读已写大多数的数据快照 (x:2)
事务+snapshot读+写大多数+因果一致性会话= 读T1开启前已写majority快照 (x:1)

4.2版本

1. MongoDB 增加了可重试读功能，对于一些临时的网络问题，用户无需自己实现重试逻辑，MongoDB 会自动重试处理，保证用户业务的连续性。

四、引擎相关的改进

3.2版本

• WiredTiger 核心特性：

• 压缩比：对于mongodb来说主要还是存储文档，所以大多数都是文档型数据，如果加入压缩特性，那么可以节约很多的空间，2~7倍。
  锁粒度：早期的基本上是全局的库就别或表集合级别的粒度， WiredTiger是记录级别的粒度，并发性大大的提高
  空洞率：早期的空洞率会很高，更新记录时如果原来分配的空间不够，会迁移到新的空间，空间分配是2ⁿ。新版的空洞率20%左右。例如一个400G的数据，导出后再导入，可能就占用只有250G了。
  Cache：早期的内存是叫给操作系统来控制的，WiredTiger 通过cacheSize参数来控制

1. 自3.0引入WiredTiger引擎后3.2版本在企业版本引入了WT加密配置项
2. 3.2版本WiredTiger作为默认引擎且已支持fsyncLock 创建一致性备份
3. 增加ephemeralForTest（测试引擎）及inMemory （内存引擎仅用于企业版）

3.4~4.0 版本

4.0开始WiredTiger引擎的副本集及分片集群不允许关闭 journal
4.0开始废弃MMAP V1引擎

4.2版本

4.2删除不推荐使用的MMAPv1存储引擎。

五、重要改进

ChangeStreams

3.6版本首次引入集合粒度的”变更流”，早期如果想获取某个集合的变更情况，需要去抓取oplog，而新版本中可以直接用变更流进行抓取。
4.0版本添加库及实例粒度的增强支持
4.0版本真正实现了只捕获“写大多数”
主要特点：
• 可只捕获变更或完整文档、可灵活指定过滤指定操作
• 分片集群中事件完全有序（通过一个全局逻辑锁来实现的）、非mongo shell 下断线重连。
• 只发布”写大多数”的变更 、变更流遵从权限控制系统，

多文档事务

MongoDB 4.0 支持副本集事务，极大的丰富了应用场景；4.0 的事务存在最大修改 16MB、事务执行时间不能过长的限制，在 4.2 支持分布式事务的这些问题都解决了。分布式事务的支持也意味用户修改分片key的内容成为可能，因为修改分片key的内容，可能会导致key要迁移到其他shard，而在4.2之前，无法保证这个迁移动作（目标上新写、源上删掉）的原子性，而借助分布式事务，这个问题也就迎刃而解。MongoDB 采用二阶段提交的方式，实现在多个 Shard 间发生的修改，要么同时发生，要么都不发生，保证事务的 ACID 特性。

• session.startTransaction() // 开启事务
• session.commitTransaction() // 提交事务
• session.abortTransaction() // 回滚事务

事务使用需要注意的问题：
只有副本集集群模式才支持；系统库/集合是不支持多文档事务；
事务部支持catalog操作（例如创建一个集合，删除一个索引），及explain（执行计划）在事务中都是不支持的；
读优先级策略值只支持读主库。

认证安全

权限管理

3.0版本首次具备完整的基于角色的权限管理体系， 后期版本持续增强
鉴权开启
3.4版本引入了transitionToAuth配置，确保集群可在线开通鉴权

白名单

3.6版本为了安全起见bindIp 默认绑定是的127.0.0.1 、 ipv6默认绑定::1
3.6版本自定义用户及角色引入authenticationRestrictions限制客户端及服务端的ip

认证策略

3.6版本开始废弃MONGODB-CR认证策略、 需要注意的是4.0版本彻底删除
自从3.0开始引入SCRAM-SHA-1策略(3.0-3.4都有性能问题)以来、4.0又新增SCRAM-SHA-256

SCRAM-SHA-1如果在高并发端连接的情况下，如果要获取一个随机的加密盐，如果要保证返回的不同，需要加一个spinlock的锁，所以可能会有性能问题。

优点：
可调迭代数 (默认15000) 客户及服务端随机加盐
比md5更强的hash函数 客户及服务端双向认证

4.2版本 引入「字段级加密」的支持，实现对用户JSON文档的Value 进行自动加密。整个过程在 Driver 层完成，传输、存储到服务端的文档Value都是密文，MongoDB 4.2 Drvier 支持丰富的加密策略，可以针对集合、字段维度开启加密，加密过程对开发者完全透明。

模型校验

3.2开始引入validation功能，因为同一个字段可能存储的数据会用混，可能存的时间可能存的数字。
3.6版本支持$jsonSchema

定义字段校验

db.createCollection( "test",
   {
      validator: { $or:
         [
            { phone: { $type: "long" } },
            { email: { $regex: /@huolala\.cn$/ } },
            { status: { $in: [ "bad", "good" ] } }
         ]
      },
      validationAction: "error"
   }
)

不符合校验规则的插入：

db.test.insert( { phone: 123456,email:"[email protected]", status: "bad" } )

符合校验规则的插入：

db.test.insert( { phone: NumberLong(123456),email:"test@huolala,cn", status: "good" } )

聚合框架

3.2版本首次引入 $ lookup 支持关联查询
3.4增加$grahpLookup支持层次递归查询
3.6版本进一步增强(支持多个关联字段)
4.2增加merge操作符，又称按需式物化视图，能不断的将增量分析结果与原来的结果进行汇总（老的版本只支持out，把当次分析结果写到某个集合）。

其他改进

• 3.4版本开始支持视图（view）
  语法：

db.createView(<view>, <source>, <pipeline>, <options>)

用例：

db.createView( 'test_view', // 视图名称
'sourceCollection', // 原集合
[ { $project: {'vField': '$name', age: 1 } } ] // 定义视图字段
) 

规定：
索引、只读、 视图上的视图、自然排序、shard集合、关联查询

• 3.6版本引入可重试写（Retryable Writes）
  场景：
  网络错误或遇到副本集切换
  规定：
  • 只重试一次解决暂时的网络错误
  • 只支持副本集和shard集群
  • 要求WiredTiger或in-memory存储引擎,mmapv1 不支持
  • 对于4.0版本多文档事务按整个事务进行
  • 无可以写primary 则等待serverSelectionTimeoutMS (默认30秒)（主库切换或选举过程中）
  用例：
  uri = “mongodb://example.com:7007/?retryWrites=true”

• 4.0版本引入Free Cloud Monitoring (仅支持单节点及副本集）
  db.enableFreeMonitoring() // 开启云监控
  {
  “state” : “enabled”,
  “message” : “To see your monitoring data, navigate………”,
  “url” : “https://cloud.mongodb.com/freemonitoring/…”,
  “userReminder” : “”,
  “ok” : 1
  }
  db.disableFreeMonitoring() // 关闭云监控
  db.getFreeMonitoringStatus() // 查看监控状态

3.2版本引入部分索引
• 与稀疏索引包含关系
• 唯一性索引约束范围
3.6版本嵌套字段查询可使用”覆盖索引”
3.6版本支持因果一致性
一个操作逻辑上依赖它之前的操作即认为两操作具备因果关系
因果一致性可为读写提供如下保障： • 读自己的写
• 单调性读 (w1->w2,r1->r2 如果r1 读到w2,那r2必然不会读w1)
• 单调性写(删除之前的插入) • 读然后写(先查询然后更新或插入)

ワイルドカードインデックスが導入4.2バージョンは、自動的に豊かなクエリのニーズを満たすために、フィールドの範囲のためにインデックスを作成することができます。以前のバージョンのいくつかのシナリオ、プロパティの数を含むフィールドに遭遇することが多い、多くのプロパティがありそうな問い合わせの必要性にあり、各プロパティの現在のソリューションは、あなたが必要なを確立するために、事前にその行動を知っている必要がありますインデックス。

バージョン3.6でlistdatabase改善
listDatabasesパラメータはnameOnlyコマンドを実行するか、ロック解除されたライブラリレベルのロック要求する追加コマンド
改善バージョン3.6 dropDatabaseを
すべてのsetコマンドを終えdropDatabase待ち降下はレプリカセットのメンバーの大多数に普及した後に実行される
4.0 listCollections改善
listCollectionsをパラメータがnameOnly追加コマンドを実行するコマンドアンロック又は要求集合レベルロック
バージョン4.0 killOpが向上
killOpキルmongosクラスタクエリ操作をノードルーティングmongosで直接行うことができる
バージョン4.0を表示するテーブルの改善
安全の考慮でのテーブルがもはやデフォルトのシステム・テーブル・システムによって表示される示さない。*
新たなワイルドカードの4.2バージョンインデックスは、またかなり特殊な、それは不確実性のフィールドを意味し、いくつかのフィールドを決定しますが、不確実性の照合フィールドのクイック検索を実行する必要があり、およびフルテキストインデックスの差が比較的大きい場合には、ドキュメントレベルのデータを提供することであるべきより柔軟インデックス。