MongoDBの4.2の新解釈

ベースの分散システムと高性能ストレージ、高可用性アーキテクチャの3ノードのレプリカセットを提供し、災害復旧の切り替えをフライング、障害は完全に透過的に移行しました。そして、プロのデータベースのオンライン拡張、ロールバック、バックアップ、パフォーマンスの最適化ソリューションを提供しています。

MongoDBの世界2019のMongoDB 4.2ベータ版の新バージョンをリリースし、データベースは多くの新機能が含まれている、我々は、技術的な観点から解釈しよう。

_2019_06_21_11_45_20

全文検索

MongoDBは4.2前に、フルテキスト検索(全文検索)テキストインデックス、MongoDBの-4.2年、などのLuceneなどのMongoDB統合エンジンとアトラスのサービスに直接組み込まのフルテキストを検索する機能を提供を支援するために依存する機能。

MongoDBのFTS原則

  1. ユーザーはアトラス、オープンフルテキストインデックスのコレクションにすることができ、背景はLuceneのインデックス化エンジンを開かれます(インデックスエンジン、クエリエンジンを構成することができます)、在庫データをインデックス化。
  2. オープンケーブル構造、MongoDBのに新たに書き込まれたデータの収集の全文については、バックグラウンドサービスは、サブスクリプションの変更ストリームの道によるであろう、とのLuceneインデックス化エンジンへの更新。
  3. インデックスが提供するMongoDBのクエリの道に直接照会要求は、検索結果を構築するために受け取った、Luceneのエンジンに転送されます後、mongodは、クライアントの要求に対する応答を受け取ります。

全文検索の例

ここで全文検索は、全体的な経験は、アトラスコンソール上のインデックスを構築する必要性に加えて、この能力の改善とのMongoDBの通常の使用と他の違いは、ありません、非常に簡単です使用した簡単な例であり、あなたは、弾性検索の多くをカバーすることができますシーン。

ステップ1:データの準備

MongoDB Enterprise > db.fruit.find()
{ "_id" : 1, "type" : "apple", "description" : "Apples come in several varieties, including Fuji, Granny Smith, and Honeycrisp." }
{ "_id" : 2, "type" : "banana", "description" : "Bananas are usually sold in bunches of five or six." }

ステップ2:アトラスにFTSのインデックスを作成します

_2019_06_21_11_45_53

ステップ3:ワイルドカード、検索機能のプレフィックス様々なサポート、検索を行うにはMongoDBのクライアントを使用します

// 简单查询

db.fruit.aggregate([
  {
    $searchBeta: {
      "term": {
        "query": "Smith",
        "path": "description"
      }
    }
  }
])
{ "_id" : 1, "type" : "apple", "description" : "Apples come in several varieties, including Fuji, Granny Smith, and Honeycrisp." }

// Wildcard 查询
db.fruit.aggregate([
  {
    $searchBeta: {
      "term": {
        "query": "s*l*",
        "path": "description",
        "wildcard": true
      }
    }
  }
])
{ "_id" : 1, "type" : "apple", "description" : "Apples come in several varieties, including Fuji, Granny Smith, and Honeycrisp." }
{ "_id" : 2, "type" : "banana", "description" : "Bananas are usually sold in bunches of five or six." }

分散トランザクション

MongoDB 4.0 支持副本集事务,极大的丰富了应用场景;4.0 的事务存在最大修改 16MB、事务执行时间不能过长的限制,在 4.2 支持分布式事务的这些问题都解决了。分布式事务的支持也意味用户修改分片key的内容成为可能,因为修改分片key的内容,可能会导致key要迁移到其他shard,而在4.2之前,无法保证这个迁移动作(目标上新写、源上删掉)的原子性,而借助分布式事务,这个问题也就迎刃而解。

4.2 支持的分布式事务是硬核技术,目前具备这个能力的开源数据库本身也不多,MongoDB 采用二阶段提交的方式(细节以后再分析),实现在多个 Shard 间发生的修改,要么同时发生,要么都不发生,保证事务的 ACID 特性。

_2019_06_21_3_40_32

在使用上,4.2 的分布式事务跟 4.0 副本集事务使用方式完全一样,用户无需关心后端数据如何分布。

_2019_06_21_3_47_07

High Availablity

MongoDB 在保证数据库服务可用性方面持续努力,在 4.0 提供了 Retryable Write 功能,在新的 4.2 版本,MongoDB 增加了 Retryable Read 功能,对于一些临时的网络问题,用户无需自己实现重试逻辑,MongoDB 会自动重试处理,保证用户业务的连续性。

Improved Query Language

MongoDB 4.2 在查询语言的表达能力上进一步增强,update、aggregation、index 等方面都有巨大的提升,具体细节等 4.2 正式版文档发出可以详细了解。

Update 能力增强

4.2 之前,Update 操作基本上都是用确定的值更新某个字段,在新版本里,Update 能根据文档现有的字段内容来生成新的更新内容,如下的实例,根据文档 pay、tax 字段,加起来生成一个 total 字段;这个在 4.2 之前,用户需要先读取文档内容,获取 pay、tax 字段得到结果,然后调用 Update 设置新的字段。类似的特性还有很多,基本上 Aggregation 里能表达的更新操作,4.2 的 Update 命令都能支持。

db.orders.find()
{ "_id" : 1, "pay" : 100, "tax" : 17 }

// 这个操作发布会PPT上有写,但实际连 4.2 测试并不能工作,等正式版出来再看看
db.orders.update( {_id: 1}, 
    { "$set": {  
        "total": { "$sum": ["$pay", "$tax"]    }   
        }     
})

分析能力增强

Aggregation 方面,MongoDB 也做了大量的改进,来更好的支持业务分析场景;比如增加 $merge 操作符,能不断的将增量分析结果与原来的结果进行汇总(老的版本只支持 $out,把当次分析结果写到某个集合)。

Index 能力增强(Wildcard Index)

使用 MongoDB 时,经常会遇到一些场景,某个字段包含很多个属性,很多属性都可能需要用于查询,现在的解决方案时,针对每个属性,必须提前知道它的访问行为,建立必要的索引;MongoDB 4.2 引入 Wildcard Index,可以针对一系列的字段自动建索引,满足丰富的查询需求。

如下面的例子所示,书籍的 attribute 字段里包含很多熟悉,包括颜色、大小等信息,如果经常需要根据属性查找,可以针对 attribute 字段建立 Wildcard index。

db.books.find()
{ "_id" : ObjectId("5d0c5d931eefdf585ae9ca95"), "type" : "book", "title" : "The Red Book", "attributes" : { "color" : "red", "size" : "large", "inside" : { "bookmark" : 1, "postitnote" : 2 }, "outside" : { "dustcover" : "worn" } } }
{ "_id" : ObjectId("5d0c5d9e1eefdf585ae9ca96"), "type" : "book", "title" : "The Blue Book", "attributes" : { "color" : "blue", "size" : "small", "inside" : { "map" : 1 }, "outside" : { "librarystamp" : "Local Library" } } }
{ "_id" : ObjectId("5d0c5dac1eefdf585ae9ca97"), "type" : "book", "title" : "The Green Book", "attributes" : { "color" : "green", "size" : "small", "inside" : { "map" : 1, "bookmark" : 2 }, "outside" : { "librarystamp" : "Faraway Library", "dustcover" : "good" } } }

// 没有索引的时候,根据颜色属性查找,走全表扫描
db.books.find({"attributes.color": "green"}).explain()
{
    "queryPlanner" : {
        "queryHash" : "528C4C03",
        "planCacheKey" : "528C4C03",
        "winningPlan" : {
            "stage" : "COLLSCAN",
}

// 针对 attributes 字段所有的子字段建立 Wildcard 索引,针对 color、size 等的查询就都可以走索引
db.books.createIndex({ "attributes.$**": 1 });

db.books.find({"attributes.color": "green"}).explain()
{
    "queryPlanner" : {
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
}
db.books.find({"attributes.size": "small"}).explain()
{
    "queryPlanner" : {
        "winningPlan" : {
            "stage" : "FETCH",
            "inputStage" : {
                "stage" : "IXSCAN",
}

Field Level Encrytion

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

_2019_06_21_4_02_45

MongoDB and Kubernetes

Kubernetes 是工业级的容器编排管理平台,可以使用 Kubernetes 管理 MongoDB 集群的整个生命周期,但随着业务部署环境越来越复杂多样化,有的可能是私有云部署、有的是公有云的部署,使得集群的管理难度也越来越高。

在新版本 MongoDB Atlas(公有云), MongoDB Cloud Manager(私有云企业版管理) 都集成了 Kubernetes operators 的支持,使得用户可以使用 Kubernetes 统一管理 MongoDB 资源。

MongoDB Chart

MongoDB Chart 在去年的 MongoDB World 已经介绍过了,今年有做了多方面的增强,算得上是一个功能比较完备的 BI 分析工具了。有了 Charts,MongoDB 也无需支持 SQL 来去对接 BI 工具了。

Charts 在使用上还是有一定学习成本的,不是特别直观,需要配合教程,了解下运作原理,才能得到想要的图,比如这个例子里,针对电影集合,Released 的年份做了聚合分析,得到分布图。

_2019_06_21_4_43_04

MongoDB Realm

MongoDB 在4月份的时候收购了 Realm,一个为移动端开发而设计的新型数据库。MongoDB 去年发布了 MongoDB Mobile 来应对移动端的数据存储需求,在收购 Realm 后,二者会进行深度整合,Real Core 里会借助MongoDB提供的能力,增加非结构化数据存储到能力,比如 JSON、Dict、Set,让 Realm 变得更强大,同时发挥 Realm 在移动端生态以及 MongoDB 数据库存储的优势。

_2019_06_21_4_49_11

_2019_06_21_4_55_59

Atlas Data Lake (Beta)

在新版本 Atlas 服务里,提供了 Atlas Data Lake,能直接通过 MongoDB API 访问存储在 AWS S3 (未来支持 Azure、Google 的存储服务)里的数据。

_2019_06_21_5_05_43

ベースの分散システムと高性能ストレージ、高可用性アーキテクチャの3ノードのレプリカセットを提供し、災害復旧の切り替えをフライング、障害は完全に透過的に移行しました。そして、プロのデータベースのオンライン拡張、ロールバック、バックアップ、パフォーマンスの最適化ソリューションを提供しています。

おすすめ

転載: yq.aliyun.com/articles/706188