NoSQLとMongoDB

NoSQLプロパティ

データ間の関係を定義しない
データを定義しないアーキテクチャ(アーキテクチャは動的)

MongoDB特性

にはJoinがないので、Joinを避けるためにデータを構造化する必要があります.

のデータを構造化し、json形式で

を格納する.

メモリマッピング形式のファイルエンジンDBは、メモリ

に依存する.

メモリサイズ決定性能

アーキテクチャは固定されておらず、多様な形式のデータを格納できる

読み取り/書き込みに優れた

Scale Out簡単、

Documentデータモデル

属性の名前と値からなるペアのセット

属性は文字列または数値であり、日付

であってもよい.

SQLクエリー/MongoDBクエリー比較

SQL/MongoDb
SQL
MongoDB
CREATE TABLE USERS (a int, b int)
db.createCollection("mycoll")
INSERT INTO USERS VALUES(3, 5)
db.users.insert({a:3, b:5})
SELECT a,b FROM USERS
db.users.find({}, {a:1, b:1})
SELECT * FROM USERS WHERE age = 33
db.users.find({age: 33})

MongoDB Index

index事前ソートデータによるデータベースの検索の高速化
MongoDBには固定モードはありませんが、インデックスとして必要なデータフィールドを指定することで、結果をすばやく検索できます.
Documentを追加または変更すると、Indexにも新しいDocumentが含まれて変更されます.
MongoDB Idnex注意点
データが変化すると、インデックスの順序も再編成され、Wrtieの動作性能が低下します.

Shardingシステムの特性

沙丁システムの最大の目的は分散処理による効率の向上である.

の性能を確保するため、サードとして3台以上のサーバを使用することを推奨します.

が2台あれば、サードサーバを構築できます.

シャードサーバを使用すると、以前の1台のサーバを使用した場合に比べてメモリ使用量が20%から30%増加します.

(Mongos、OpLog、Barangerプロセスは追加のメモリを使用)

Sharding方式

1.Range Sharding

キー値の範囲でデータ

を割り当てる.
いくつかのデータは、

鍵に集約される可能性があります

2.Hash Sharding

Keyを受信hash関数にデータを割り当てた結果

.

HotSpot防止、平均配分

を再割り当てする必要がある場合、ハッシュ値を使用してデータ

全体を再割り当てする.

サーバの構成

1.構成サーバーはShadingシステムの必須構造である
2.少なくとも1台の構成サーバが必要であり、障害によるサービス停止を回避するために追加の構成サーバ設定が必要である
3.Configサーバは各グリッドサーバ上のデータがどのように分散して格納されているかを格納する

Shared Metaについて

は、Mongosによって処理されるブロックリストおよびブロックの範囲情報を含む

分散ロック
構成サーバを導入してMonosとのデータ通信同期を実現
分散ロック

を使用して、砂丁演算を実行する

Mongosサーバ

のデータをSharedサーバに配信するプロセス(ルータ-スイッチ)

1つ以上のプロセスを有効にすることができる

3.Configサーバからメタデータをキャッシュします.

MongosはConfig Serverに接続されます.複数のConfig Serverがある場合、1つの接続ができなくても、Mongosは接続に失敗した場合を処理します.

Mongosはデータを格納せず、他のMongos間に接続されていないためconfigサーバを使用してデータ同期を行います.

Chunk

1.Collection을 여러 조각으로 파티션하고 각 조각을 여러 샤드 서버에 분산해서 정하는데, 
이 데이터조각을 Chunk라고 한다.

2.군등하게 저장하기 위해 큰 청크를 작은 청크로 split하고 청크가 많은 샤드에서는 적은 샤드로
Chucnk Migaration을 수행한다.

SHared Cluster Balancer

バックグラウンドプロセス

は、各ShardのChunk数を監視する

ShardのChunk数が移動の臨界値に達すると、イコライザは自動的にスライスブロックを移動し、各Shardは同じ数のブロック

を保持する.

Sharding Systemの注意事項

データは1台のShardサーバに集中し、分散が不均一である

適切なShared Keyが選択されていない場合、

が発生する.

が均一に分散できないと判断した場合、Chung size(

)を減らすべきである

砂山のバランスが不均一である

のデータを入力すると適切なロード・バランシングが行われますが、ユーザーのニーズに応じてサーバ上のデータを削除または移動した場合、このバランシングは破壊されます.

Chunckの移行が過剰になると、クラスタの動作が停止します.

コピー

高性能データベースで最も重要な機能
同じデータを持つmONGODBサーバを複数設計します.
mASTER/Slave Replication

レプリケーション動作の原理

通常のマスター-スレーブと同じ書き込みはマスターノードのみで行います.
モンゴドビーで書き込みを行う場合は、データストレージとOpplog領域に格納します.
データ・リポジトリには、書き込み操作の結果のみが格納されます.
Opplogは、演算の実行に関連するコマンド自体をタイムスタンプとともに保存します

ReplicaSet

DBノードに障害が発生するか、dbに問題が発生した場合に障害に迅速に応答してリカバリ時間を短縮する利点

.
24172 ReplicaSetの最大の目的は、サービス内のMongoDBインスタンスに問題が発生した場合に、ReplcSetのメンバーレプリケーションノードの1つが障害に対応できるようにすることです.
3.基本的で物理的なデータベース設計方式は、クライアントおよびdbとの通信を任意の場合に構成して継続的に実行できるようにすることができる

ReplicationSetメンバー

マスタ:クライアントからのデータベースの読み込みと書き込み

Secondary:Primaryからデータを同期します.

Arbiter:データの非同期はReplicaSetのリカバリに役立ちます.

Primary
ReplicationSetには、プライベートノードが1つしか存在しません.Primaryのみがクライアントと直接情報を交換するため、Primaryに障害が発生したり、ネットワークに問題が発生したりした場合、実際のReplication setが構成されていても、第三者がPrimaryにアップロードしたときに実際のデータの読み書きを一時停止します.
Secondary
第2世代サーバの最も重要な役割は、ベースノードからデータを同期し、障害が発生したときにベースノードに変換することです.Primareに障害が発生した場合、どのSeconderyノードをPrimaryにアップグレードするかを決定する投票権があります.
Arbiter
親ノードの役割は、ReplicaSetを3つ以上の奇数に設定できない場合、投票権のみを使用してReplicaSetを監視することです.

ReplicaSet機能

プライマリ・サーバは、HeartBeatがデータと同期していることを確認するために、秒単位でステータスをチェックします.

Heartbeatの受信結果は,セカンダリサーバが使用できない場合でもデータレプリケーションを中断するのみである.

プライマリ・サーバに障害が発生した場合は、セカンダリ・サーバをプライマリ・サーバに作成します.

初級になる資格条件は優先権や選挙などです.

ReplicaSet投票

Primaryノードに障害が発生した場合、ReplicaSetの選挙方法は「多数のメンバーの同意」で構成されます.