NoSQLテクノロジー
4360 ワード
過去の長い間、リレーショナル・データベース(Relational Database Management System)は最も主流のデータベース・ソリューションであり、実際の世界の物事と関係を用いてデータベース内の抽象的なデータ・アーキテクチャを説明してきました.しかし、情報技術の爆発的な発展の今日、ビッグデータはすでにクラウドコンピューティングに続いて、ユビキタスネットワークの後の新しい技術革命になって、関係型データベースはビッグデータ量を処理する時すでに骨が折れ始めて、開発者は絶えずデータベースを最適化することを通じてデータ量の問題を解決するしかありませんが、最適化は結局長期的な方案ではありません.そこで、ビッグデータ時代の到来であるNoSQL(非リレーショナル・データベース)を迎える新しいデータベース・ソリューションが提案されています.
データベースを人間にたとえると、MongoDBは完全に神童と言える.5歳の彼は一人でおじさん級の人物たちに挑戦し、ここ数年の発展速度から見ると、PgSQLを超えて4位になるだろう.しかし、このような技術が爆発した時代には何が不可能だったのだろうか.
なぜMongoDBを選んだのですか?
1.性能
ビッグデータ時代において、ビッグデータ量の処理はデータベースを考慮する最も重要な原因の一つとなっている.MongoDBの主な目標は、データベースのパフォーマンスを最大限に維持することであり、MongoDBの設計を大きく決定します.従来の機械的ハードディスク(HDD)が主導していた時代には、ハードディスク(HDD)がパフォーマンスのショートボードになる可能性が高く、MongoDBはメモリリソースをキャッシュとして利用して優れたパフォーマンスを交換するために最大限を選択し、クエリーのために最も高速なインデックスを自動的に選択しました.MongoDBは、データベースをできるだけ簡素化し、クライアントにできるだけ多くの操作を渡すことで、MongoDBが優れたパフォーマンスを維持できる理由の一つです.
2.拡張
現在、インターネットのデータ量は過去のMB、GBから現在のTBレベルに変わり、単一のデータベースは明らかに耐えられず、拡張性が重要な話題となっているが、現在の開発者は拡張方式を選択する際に困難を犯すことが多い.果たして横方向拡張なのか、縦方向拡張なのか.
——————————————————————————————————————————————————————————————
横方向拡張(scale out)は、パーティションを増やしてデータベースを異なるブロックに分割して異なるマシンに分散する利点であり、拡張コストは低いが管理が困難である.
縦拡張(scale up)縦拡張と横拡張の違いは、元のサーバをアップグレードし、より強力なコンピューティング能力を持つことです.このような利点は、拡張に伴う多くの問題を考慮する必要がなく、管理が容易であることですが、コストが高いという欠点も明らかです.1台の大型機の価格は往々にして非常に高価であり、このようなアップグレードはデータが限界に達したとき、計算能力のより強い機械が見つからない可能性があります.
———————————————————————————————————————————————————————————————
MongoDBは、より経済的な横方向の拡張を選択し、データを異なるサーバに簡単に分割することができます.また,データ取得時に開発者もマルチサーバがもたらす問題を考慮する必要がなく,MongoDBは開発者の要求を自動的に正しいサーバにルーティングし,開発者を横広がりによる弊害から脱し,プログラムの開発に専念させることができる.
3.使用
MongoDBはNoSQLのデザインを採用しており、データをより柔軟に操作できます.従来のRDBMSでは、数十行以上100行以上の複雑なSQL文に遭遇したことがあります.従来のRDBMSのSQL文には、関連付け、サブクエリなどの文が多く含まれており、複雑さを増すと同時にパフォーマンスのチューニングがさらに困難になります.MongoDBのドキュメント向け設計では、RDBMSの行の代わりにデータモデルとしてより柔軟なドキュメントを採用しており、ドキュメント向けの設計では、開発者がデータを取得する方法がより柔軟になり、開発者が複雑なネスト関係を1つの文で検索することができ、開発者がデータを取得するために頭を悩まなくてもよい.
NoSQLが従来のデータベース設計思考に与える影響
1.事前設計モードと動的モード
従来のデータベース設計の考え方では、プロジェクトの設計段階では、データベーステーブルのフィールド名、フィールドタイプを規定する必要があります.設計に合わないデータを挿入しようとすると、データベースはこのデータを受け入れてデータの完全性を保証しません.
NoSQLでは、集合(表のような)の文書(行のようなもの)を動的に追加します.集合の作成時にデータ型は制限されず、どの文書も任意の集合に追加できます.たとえば、このような2つの文書を1つの集合に追加できます.
MongoDBのドキュメントのフォーマットは、一般的なJSONと似ています.これにより、最初は「name」、「song」の2つのフィールドを持っていますが、2番目は「name」、「age」、「email」の3つのフィールドを持っています.これは、事前設計モードのデータベースでは挿入できませんが、MongoDBのダイナミックモードでは可能です.このような利点は、いくつかの数を少なくする必要はありません.しかし、多くの種類のフィールドは単独でテーブルを設計し、単独のテーブルに集中して格納することができるが、このような弊害も明らかであり、データを取得する際に同じテーブルの異なるドキュメントを区別し、開発上のコード量を増やす必要がある.したがって,設計当初は動的モードの優劣を考慮してテーブル内のデータ型を選択する必要がある.
2.正規化と逆正規化
モデル化(normalization)は、リレーショナルモデルの発明者であるエドガー・コードが1970年に提案した概念であり、モデル化はデータを異なるテーブルに分散させ、リレーショナルモデルを用いて関連付けを行うことにより、後期に修正を行う際に、それに関連するデータに影響を及ぼさず、自己修正のみで済むという利点がある.
逆パターン化(denormalization)は、パターン化に対して提案された反対の理念であり、逆パターン化は、現在のドキュメントのデータを分割ではなく、このテーブルに集中的に格納します.
正規化と逆正規化の間には優劣の問題はありません.正規化のメリットは、書き込み、変更、削除時により高いパフォーマンスを提供し、逆正規化によりクエリー時のパフォーマンスを向上させることです.もちろん、NoSQLには関連クエリーは存在せず、クエリーのパフォーマンスを向上させることができますが、関連テーブルIDをテーブルに格納する方法でモデル化できます.しかし、このように、NoSQLの理念の中で反モデル化の地位はモデル化より大きい.
モンゴDBはまだ若い
MongoDBには優れたデザインがたくさんありますが、MongoDBには依然として苦手な問題がたくさんあります.
1.MongoDBはトランザクションをサポートしておらず、現在も多くのソフトウェアでトランザクションの管理が必要とされているため、トランザクションの一貫性に要求されるプログラムはソフトウェアレベルでしか管理できず、データベースから管理できません.
2.他のツールのサポート範囲では、MongoDBがリリースされてから5年も経っていないため、多くの言語に対応していないツールパッケージに直面しているため、使用する言語に対応するパッケージがなければ、MongoDBを使用できない最大の障害になる可能性があります.
3.コミュニティの資源量、この問題は第2の問題と同じようにMongoDBが若すぎるためで、他の大規模なデータベースのコミュニティに比べて、MongoDBは明らかに比較できないが、コミュニティも往々にして重要な考慮要素の一つであり、コミュニティの資金源の不足は問題解決周期の延長を招き、仕事を遅らせる.
ここ数年の技術の発展の速さは人の心を奮い立たせて、毎年すべて人の目の前を明るくする製品が現れて、しかしそれはすべて時間の蓄積を経てやっと1つの成熟した製品になることができて、MongoDBはまだ成長しなければならなくて、しかし彼の優秀な設計、きっとますます多くの発行者にそれを受け入れさせます.
転載先:https://www.cnblogs.com/lfzfriend/p/4079596.html
データベースを人間にたとえると、MongoDBは完全に神童と言える.5歳の彼は一人でおじさん級の人物たちに挑戦し、ここ数年の発展速度から見ると、PgSQLを超えて4位になるだろう.しかし、このような技術が爆発した時代には何が不可能だったのだろうか.
なぜMongoDBを選んだのですか?
1.性能
ビッグデータ時代において、ビッグデータ量の処理はデータベースを考慮する最も重要な原因の一つとなっている.MongoDBの主な目標は、データベースのパフォーマンスを最大限に維持することであり、MongoDBの設計を大きく決定します.従来の機械的ハードディスク(HDD)が主導していた時代には、ハードディスク(HDD)がパフォーマンスのショートボードになる可能性が高く、MongoDBはメモリリソースをキャッシュとして利用して優れたパフォーマンスを交換するために最大限を選択し、クエリーのために最も高速なインデックスを自動的に選択しました.MongoDBは、データベースをできるだけ簡素化し、クライアントにできるだけ多くの操作を渡すことで、MongoDBが優れたパフォーマンスを維持できる理由の一つです.
2.拡張
現在、インターネットのデータ量は過去のMB、GBから現在のTBレベルに変わり、単一のデータベースは明らかに耐えられず、拡張性が重要な話題となっているが、現在の開発者は拡張方式を選択する際に困難を犯すことが多い.果たして横方向拡張なのか、縦方向拡張なのか.
——————————————————————————————————————————————————————————————
横方向拡張(scale out)は、パーティションを増やしてデータベースを異なるブロックに分割して異なるマシンに分散する利点であり、拡張コストは低いが管理が困難である.
縦拡張(scale up)縦拡張と横拡張の違いは、元のサーバをアップグレードし、より強力なコンピューティング能力を持つことです.このような利点は、拡張に伴う多くの問題を考慮する必要がなく、管理が容易であることですが、コストが高いという欠点も明らかです.1台の大型機の価格は往々にして非常に高価であり、このようなアップグレードはデータが限界に達したとき、計算能力のより強い機械が見つからない可能性があります.
———————————————————————————————————————————————————————————————
MongoDBは、より経済的な横方向の拡張を選択し、データを異なるサーバに簡単に分割することができます.また,データ取得時に開発者もマルチサーバがもたらす問題を考慮する必要がなく,MongoDBは開発者の要求を自動的に正しいサーバにルーティングし,開発者を横広がりによる弊害から脱し,プログラムの開発に専念させることができる.
3.使用
MongoDBはNoSQLのデザインを採用しており、データをより柔軟に操作できます.従来のRDBMSでは、数十行以上100行以上の複雑なSQL文に遭遇したことがあります.従来のRDBMSのSQL文には、関連付け、サブクエリなどの文が多く含まれており、複雑さを増すと同時にパフォーマンスのチューニングがさらに困難になります.MongoDBのドキュメント向け設計では、RDBMSの行の代わりにデータモデルとしてより柔軟なドキュメントを採用しており、ドキュメント向けの設計では、開発者がデータを取得する方法がより柔軟になり、開発者が複雑なネスト関係を1つの文で検索することができ、開発者がデータを取得するために頭を悩まなくてもよい.
NoSQLが従来のデータベース設計思考に与える影響
1.事前設計モードと動的モード
従来のデータベース設計の考え方では、プロジェクトの設計段階では、データベーステーブルのフィールド名、フィールドタイプを規定する必要があります.設計に合わないデータを挿入しようとすると、データベースはこのデータを受け入れてデータの完全性を保証しません.
-- :NAME, SONG
INSERT INTO T_INFO VALUES('John','Come Together'); --
INSERT INTO T_INFO VALUES(' ', 20, '[email protected]'); -- NoSQLでは、集合(表のような)の文書(行のようなもの)を動的に追加します.集合の作成時にデータ型は制限されず、どの文書も任意の集合に追加できます.たとえば、このような2つの文書を1つの集合に追加できます.
{"name" : "John", "song" : "Come Together"}
{"name" : " ", "age":"20", "email" : "[email protected]"}MongoDBのドキュメントのフォーマットは、一般的なJSONと似ています.これにより、最初は「name」、「song」の2つのフィールドを持っていますが、2番目は「name」、「age」、「email」の3つのフィールドを持っています.これは、事前設計モードのデータベースでは挿入できませんが、MongoDBのダイナミックモードでは可能です.このような利点は、いくつかの数を少なくする必要はありません.しかし、多くの種類のフィールドは単独でテーブルを設計し、単独のテーブルに集中して格納することができるが、このような弊害も明らかであり、データを取得する際に同じテーブルの異なるドキュメントを区別し、開発上のコード量を増やす必要がある.したがって,設計当初は動的モードの優劣を考慮してテーブル内のデータ型を選択する必要がある.
2.正規化と逆正規化
モデル化(normalization)は、リレーショナルモデルの発明者であるエドガー・コードが1970年に提案した概念であり、モデル化はデータを異なるテーブルに分散させ、リレーショナルモデルを用いて関連付けを行うことにより、後期に修正を行う際に、それに関連するデータに影響を及ぼさず、自己修正のみで済むという利点がある.
逆パターン化(denormalization)は、パターン化に対して提案された反対の理念であり、逆パターン化は、現在のドキュメントのデータを分割ではなく、このテーブルに集中的に格納します.
正規化と逆正規化の間には優劣の問題はありません.正規化のメリットは、書き込み、変更、削除時により高いパフォーマンスを提供し、逆正規化によりクエリー時のパフォーマンスを向上させることです.もちろん、NoSQLには関連クエリーは存在せず、クエリーのパフォーマンスを向上させることができますが、関連テーブルIDをテーブルに格納する方法でモデル化できます.しかし、このように、NoSQLの理念の中で反モデル化の地位はモデル化より大きい.
モンゴDBはまだ若い
MongoDBには優れたデザインがたくさんありますが、MongoDBには依然として苦手な問題がたくさんあります.
1.MongoDBはトランザクションをサポートしておらず、現在も多くのソフトウェアでトランザクションの管理が必要とされているため、トランザクションの一貫性に要求されるプログラムはソフトウェアレベルでしか管理できず、データベースから管理できません.
2.他のツールのサポート範囲では、MongoDBがリリースされてから5年も経っていないため、多くの言語に対応していないツールパッケージに直面しているため、使用する言語に対応するパッケージがなければ、MongoDBを使用できない最大の障害になる可能性があります.
3.コミュニティの資源量、この問題は第2の問題と同じようにMongoDBが若すぎるためで、他の大規模なデータベースのコミュニティに比べて、MongoDBは明らかに比較できないが、コミュニティも往々にして重要な考慮要素の一つであり、コミュニティの資金源の不足は問題解決周期の延長を招き、仕事を遅らせる.
ここ数年の技術の発展の速さは人の心を奮い立たせて、毎年すべて人の目の前を明るくする製品が現れて、しかしそれはすべて時間の蓄積を経てやっと1つの成熟した製品になることができて、MongoDBはまだ成長しなければならなくて、しかし彼の優秀な設計、きっとますます多くの発行者にそれを受け入れさせます.
転載先:https://www.cnblogs.com/lfzfriend/p/4079596.html