リレーショナルデータベース
強力なリレーショナルデータベースのSQL関数とACIDのプロパティがあります。以下についてのリレーショナルデータベースの利点：
①取引を介してデータの一貫性を維持することができ、及び、銀行振込データベースロックによって行うことができるように
②は、マルチテーブルにジョイン接続することができます。
開発の歴史の③20年、成熟しました
④は、様々なシステムに適用することができます
しかし、いくつかの欠点があります
①リレーショナルデータベース行に格納され、あなたはデータ結果を格納することはできません。その後、マイクロブログへの配慮、例えば、人々が懸念していることは、ユーザIDのリストで、このユーザIDテーブルクエリを経由して、データをステッチ、最後のショー。別の例は、いくつかの報告を行い、異なるテーブル、異なるデータベース、そしてステッチから情報を取得する必要があります。あなただけにして、複数行に分割リストを格納アセンブリをチェックアウトするリレーショナルデータベースを使用することができ、それがリストに直接保存することはできません
②不便なリレーショナルデータベースのスキーマ拡張が。スキーマリレーショナルデータベースのテーブル構造が強い制約である操作がエラー列に存在しない場合は、列がビジネスの変化にたくさんの悩みを拡大することで、あなたはDDLを実行する必要があります
（例えば、CREATE、ALTER、DROP、等のデータ定義言語）ステートメントを変更し、変更された長い時間（例えば、MySQLの表1時間にロックすることができる）のためのテーブルをロックすることができます。
③高いI / Oのシーンのための大規模なリレーショナルデータベースのデータは、
いくつかのテーブルに大量のデータは、リレーショナルデータベースのような統計を算出する場合であっても記憶装置からの列は、データ・メモリの行全体を読むなるだけ操作、リレーショナルデータベースであればためI / Oは、高くなります。このようなスパイク活動の淘宝網Lynxのダブル11として、リレーショナルデータベースならば、実現することはできません。
リレーショナルデータベースが比較的弱い④全文検索機能
フルテキスト検索のリレーショナルデータベースが唯一の全表スキャンマッチングのように使用することができ、パフォーマンスがインターネット検索では、この複雑なシーンは、ビジネス要件を満たすことができない、非常に低いです。
二、NOSQL（非リレーショナル）データベース
これらの問題に対応して、いくつかのシナリオでは、リレーショナルデータベースに比べて異なるのNoSQLソリューション、これらのプログラムを生まれてパフォーマンスが向上。しかし、空きランチ、プログラムののNoSQLメリットがない、本質的には、1つまたは少数のACID特性の犠牲であるので、我々は盲目的に迷信のNoSQLは銀の弾丸であることはできませんが、SQLへの強力な補完するものとしてのNoSQLする必要があります、NoSQLの！=いいえSQLが、NoSQLの=だけでなく、SQL。
共通のNoSQLプログラムは、4つのカテゴリに分類されます。
①K-Vストレージ：問題を解決するためのリレーショナルデータベースが示さRedisのにデータ構造を格納することができません。
②文書データベース：MongoDBのにリレーショナル・データベース・スキーマの制約を解決する強力な問題が表現しました。
③データベース列：ソリューションI / Oの問題の大リレーショナルデータベースのシーンデータ内のHBaseには表現しました。
④フルテキスト検索エンジン：表現をElasticsearchするリレーショナルデータベースの問題を解決するために、フルテキスト検索機能。
KVストレージ
識別データがキーであり、意味などのリレーショナルデータベースの主キーは、値が特定のデータであることを特徴とする請求KVストレージは、キー値ストアをスタンド。
RedisのはKVストアの典型的な代表は、オープンソース（BSDライセンスに基づいて）KV高性能キャッシングおよびストレージシステムです。文字列、ハッシュ、リスト、セット、ソートセット、ビットマップとhyperloglogなど、Redisの具体的なデータ構造の値は、それは多くの場合、サーバデータ構造と呼ばれています。
データ構造を一覧表示するには、例えば、Redisのは、これらの典型的な動作を（します。http：//redis.cn/commands.html#listリンクをご参照ください）用意されています。
要素のうち左キューからLPOPキー。
LINDEXキーインデックスは、そのインデックスリストで要素を取得します。
LLENキーは、キューの長さ（一覧）Aを得ました。
要素のうち右キューからRPOPキー。
Redisのストレージの制限：
文字列型：String型の最大値は512Mを記憶することができます
リストタイプ：4,294,967,295で最大2 ^ 32-1、リスト内の要素の数。
セットタイプ：4,294,967,295である2 ^ 32-1までの要素の数、。
ハッシュタイプ：4,294,967,295である2 ^ 32-1までのキーと値の数、。
ソートセットの種類：似たタイプで設定します。
リレーショナルデータベースが実装されている場合、これらの機能は、それが非常に複雑になります。例えば、LPOP操作キーに対応するリストの最初の要素を削除して返すことです。リレーショナルデータベースを格納する場合は、同じ目的で、次の操作を達成するために：
各データのデータ数（例えば、行ID）だけでなく、位置番号、最初のデータの決定するそうでなければ方法に加えて。我々はリストの先頭にデータを挿入するための行は、位置ID番号として使用することができないことに留意されたいです。
、最初のクエリデータ。
B、最初のデータを削除します。
C、第二開始からのすべてのデータの位置更新番号。
パフォーマンスが非常に低く、リレーショナルデータベースは厄介で、複数のSQL操作が必要になることが分かるであろう。
Redisのトランザクション機能を提供しながら、Redisの欠点は、主に、完全なACIDトランザクションをサポートしていませんが、トランザクションはRedisのトランザクション分離性と一貫性のみを保証することができ、非常に異なるRedisのトランザクションとリレーショナルデータベース、（IおよびC）であります、我々はアトミックと持続性（AとD）を保証することはできません。
Redisのは、厳密にはACIDの原則に従っていませんでしたが、実際に事業の大半は、厳密にはACIDの原則に従う必要はありませんが。例えば、上記の動作に注意をマイクロブログ、システムはB Aのファンではない場合でも、実際には、ビジネスへの影響は非常に小さい、リストに追加され、私たちはプログラムを設計している、我々はあなたがビジネスの特性や要件に基づいてのRedisを使用できるかどうかを判断する必要があり、そしてませんACID Redisのは、直接ギブアップの原則に従っていませんので。
文書データベース
リレーショナル・データベース・スキーマによって引き起こされる問題を解決するために、文書データベースがされて入ってきました。文書データベースの最大の特徴は、あなたが任意のデータを保存して読むことができ、無スキーマではありません。JSONデータが存在せず、SQL構文エラーの種類につながらないJSONフィールドを読み取り、事前定義されたフィールドを使用せずに、自己記述型であるため、現在のデータベース形式で格納された文書データの大部分は、JSON（またはBSON）であります。
事業開発への無スキーマプロパティの文書データベースには、いくつかの重要な利点をもたらしています。
1.簡単なフィールドを追加します。
テーブル構造を変更するリレーショナルデータベースのDDL文の最初の実装と同じもはや、新たな事業分野で増加しない、プログラムコードを直接読み取りおよび書き込みすることができます。
2.過去のデータが間違って行くことができません
でも新しい分野ならば、それはエラーが発生することはありません過去のデータについては、それだけで、コード互換のプロセスをすることができ、null値を返します。
3.あなたは簡単に複雑なデータを格納することができます
JSONは、複雑なデータ構造を記述することができ、強力な記述言語です。たとえば、私たちはユーザー管理システムを設計し、ユーザー情報は、ID、名前、性別、趣味、電子メール、アドレス、教育情報を持っています。リスト（あなたが複数の趣味を持っている可能性があるため）に興味がある、アドレスは省、市、不動産アドレスを含む構造であり、学校、主要な、卒業年度の登録情報を含む教育。、趣味（コラム：ID、趣味）、アドレス（カラム：省、市、区、フルアドレス：私たちは保存するために、リレーショナルデータベースを使用する場合は、基本的な情報（ID、名前、性別、電子メール列）を含む複数のテーブルを設計する必要があります）、教育（カラム：インテーク、卒業日、学校名、プロ）、および文書データベースを使用して、JSONは、それらのすべてを記述することができます。
{
"ID"：10000、
「名前」：「ジェームス」、
「性別」：「男性」、
"趣味"：[
"フットボール"、
「遊んで」、
「歌」
]、
"電子メール"： "[email protected]"、
"住所"： {
「省」：「広東省」、
「都市」：「広州」、
「地区」：「天河」、
"詳細"： "PingYun道163"
}、
"教育"： [
{
"開始"： "2000-09-01"、
"終了"： "2004-07-01" を、
"学校"： "UESTC"、
「主要な」：「コンピュータサイエンス＆テクノロジー」
}、
{
"開始"： "2004-09-01"、
"終了"： "2007-07-01" を、
「学校」：「スカット」、
「主要な」：「コンピュータサイエンス＆テクノロジー」
}
]
}
このサンプルでは、我々ははるかに便利かつ簡単にデータを記述するために、リレーショナルデータベースのテーブルを使用するよりもJSONデータの使用を記述するために、見てきましたが、簡単に理解すること。
特に電気・プロバイダおよびビジネスシナリオの種類のゲームのために、この機能の文書データベース、。電気供給業者との、例えば、異なる商品の特性に大きな差。例えば、図に示すように、ノートパソコン、冷蔵庫は、非常に大きい違いを属性と属性。

でも、同様の製品は、異なる特性を持っています。例えば、LCDおよびLEDディスプレイのために、2つのインジケータは、異なるパラメータを有します。あなたがデータを格納するリレーショナルデータベースを使用する場合は、このビジネスシナリオでは、それは非常に面倒になり、文書データベースを使用して、シンプルになり、非常に簡単に、新しいプロパティを展開することも簡単です。
特長問題なしスキーマデータベースは、これらの利点はまた、価格で来る、価格は最も重要なサポート取引ではありませんもたらします。たとえば、あなたが最初の注文を作成する前に控除インベントリに必要がある場合商品の在庫システムを格納するのMongoDBを使用してオーダーを作成します。これは、トランザクション操作で、達成するためのリレーショナルデータベースは非常にシンプルですが、MongoDBのが実装されている場合、あなたが取引を行うことはできません。異常な状況下では在庫が差し引かれます発生する可能性がありますが、順序は状況を作成していません。だから、ビジネストランザクションのシナリオのいくつかの厳格な要件は、文書データベースを使用することはできません。
別の欠点は、データベース・ファイルは、リレーショナルデータベース操作への参加を実現することができないということです。たとえば、私たちは、ユーザ情報や注文フォーム、OrdersテーブルバイヤーユーザIDのリストを持っています。あなたはシンプルに取得するために結合操作を実現するために照会し、リレーショナル・データベース「でアップルのラップトップユーザーの女性ユーザーを買う」にしたい場合は、および文書データベースにクエリに参加することができない、あなたは二回チェックする必要があります。1回Ordersテーブルを照会しますアップルのノートブックユーザーが購入し、その後、女性の利用者であるユーザに問い合わせます。
柱状データベース
名前が示唆するように、ラインは、データを格納するリレーショナルデータベースによるものであるため、「線データベース」と呼ばれる伝統的なリレーショナル・データベースに対応するデータを格納するデータベースへの列のデータベース列です。
主に次のような利点に、ラインに従ってデータを格納するリレーショナルデータベース。
これらの列が一列に一緒に格納されているので、複数の列が同時に、レートエージング操作を読み込まれ、ディスク操作がメモリに読み込まれた行の各データ列にできるようになります。
列に複数の列に一回書き込み操作を完了するために、整合性、データの行の書き込み操作のアトミック性を保証するために、そうでない場合、列格納場合、そこに、書き込み動作、一部の列の成功があってもよいです列には、一貫性のないデータが得られ、失敗しました。
我々は、行は、特定のビジネス・シナリオにおけるストレージの利点を実現するために、そのようなビジネス・シナリオが存在しない場合、その行格納された利点が存在しなくなり、さらに不利になる、典型的なシナリオは、大規模なデータであることがわかります統計。例えば、実際には、唯一の一人一人の体重と統計をすることができ、このコラムを読む必要があり、都市太り過ぎ人事データを計算し、最終ラインストレージの使用は一つだけでも削除されます場合でも、すべての行が読み出され。唯一の4バイトを1キロバイト秤量し、またはラインメモリを有する単一ライン加入者情報は、データの全て1キロバイト行全体がメモリに読み込まれている場合は、それは明らかな廃棄物です。列ストレージを使用する場合、各ユーザは、4バイトのデータ量であってもよいが読み取る必要があり、I / Oが大幅に低減されます。
I / Oを節約することに加えて、さらに高い圧縮率を記録した記憶を含むカラムには、より多くのメモリ空間を節約することが可能です。単一の列データ線は類似度に比べて高いので、1かそこら：約3の共通線データベース典型的圧縮比：1、及び圧縮比は、データベースの列8 :: 1 1〜30 5に一般的に、より高い圧縮率を達成することができます。
同様に、シーンチェンジ場合、柱状ストレージ強みは弱みに変わります。典型的なシナリオは、頻繁に複数の列を更新する必要があります。そしてラインが同じ行に格納されている場合、複数の列は、ディスク書き込み動作を連続した領域に格納され、異なる列は、柱状ストレージが複数の列を更新するために、ランダムなディスク書き込み動作の結果、連続した空間ではないディスク上に格納されるため完了することができ、ランダム書き込み柱状のストレージ効率は、書き込み効率・ライン・ストアよりもはるかに低いです。また、更新シナリオにおける柱状ストレージ高い圧縮比があるため、更新とは、圧縮され、最終的にディスクに書き込まれたときに記憶されたデータの解凍を更新する必要があるため、不利となるであろう。
このシナリオでは、主に一部の列のために操作されているため、ストレージの上記の長所と短所、大規模なデータ分析とオフラインの統計的場面で、一般的に円柱状のストレージアプリケーションに基づいていない、単一の行、更新後と記述する必要がなくなったデータを削除します。
フルテキスト検索エンジン
インデックスによる従来のリレーショナルデータベースは、高速クエリの目的を達成するために、しかし、フルテキスト検索のビジネスシナリオでは、インデックスが何もできない、主に反映さ：
フルテキスト検索条件を任意の順列と組み合わせすることができ、インデックスによって満たさ場合は、インデックス番号が非常に多くなります。
ファジーマッチングモード、フルテキスト検索、インデックスを満たすことができない、唯一のように照会し、全表スキャンのクエリのように、効率が非常に低いです。
私は、リレーショナルデータベースは、フルテキスト検索の要件を満たすことができない理由を確認するために、具体的な例を挙げてみましょう。私たちはその主な目的友人を見つけるために、プログラマを支援することです出会い系サイトを作るとしますが、伝統的な出会い系サイトの異なるモードがあり、「プログラマを検索するには、ユーザーが自分の情報を公開するプログラマ。」次のように設計されたプログラマの情報シート：
自己紹介の言語に興味を持ってID名・セックス・プレイスユニット
コードを書くために、複数の猫高尾北京工場、旅行、マラソンのJava、C ++、PHP技術専門家、シンプル、そして彼の熱意
PHP、Javaの花の美しさ、絶対的な美しさ、美しい花を歌っ2雌花のガチョウ上海工場見学、食品、
のは、この単純なビジネス検索シナリオを見てみましょう：
ビューティー1：私は、PHPプログラマは確かに最もお金で、PHPは、世界最高の言語であることを聞いたが、私の母は私が上海で探していることを主張しました。
美容検索条件1ここで、「PHP」は「場所」欄を照会するファジーマッチングクエリ「言語」欄、「上海」を使用し、「セックス+ PHP +上海」で、インデックスのサポート場合は、「場所」を確立する必要があり、このインデックス。
ビューティー2：あなたはより良い旅行に私を同行するガチョウの工場の兄を見つけることができれば、私は、ああ、これらの技術の兄を崇拝するようにしています。
2の美しさの検索条件は、「「ツアーは」ファジーマッチングクエリ「趣味」の欄を使用するには、「セックス+旅行+ガチョウの工場」とは、「ガチョウの工場は、」あなたは、インデックスのサポートを使用している場合、あなたが確立する必要がある、「単位」欄を照会する必要がありますユニット「インデックス。
ビューティー3：私は「女性のプログラマー」です、私は北京のJava技術の専門家で猫の植物を見つけるしたいと思います。
3美の検索条件は、「北京+猫工場が」インデックスで照会することができる「セックス+猫+工場北京+のJava +テクノロジーの専門家」、ですが、「ジャワ」、「技術的な専門家は、」唯一のあいまい一致で照会することができます。
4ハンサム：プログラマーズ妹はそれは美しいしていませんか？見てみてください。
4検索条件の男は「自己紹介」欄についてあいまい一致検索を通じて、「セックス+美しい+の美しさ」です。
これらは単なる一例であり、検索条件は、実際に完全なリスト、非常に多くの様々な順列と組み合わせないが、この単純な例では、我々は見ることができたときに、リレーショナルデータベースのサポートでフルテキスト検索の欠如。
1.フルテキスト検索の基本原理
「転置インデックス」（転置インデックス）と呼ばれるフルテキスト検索エンジンの技術的な原理は、また、多くの場合、転置インデックスと呼ばれる、またはアーカイブにファイルを逆に、インデックスメソッドで、基本的な原理は、Word文書を確立することですインデックス。彼らは、「逆」指数と呼ばれ、「容積」指標の相対的な基本原則、「前方のインデックスは、」文書を単語にインデックスされます。私たちは、簡単な例により、2つのインデックスの違いを示しています。
我々は、技術のさまざまな記事を集め、技術記事は、ユーザーが閲覧したり、サイト上の記事を検索することができますウェブサイトを持っていると仮定します。
フォワードインデックス例：
文書番号
記事名
記事の内容
1
アジャイルアーキテクチャの設計原理
詳細を省略し、文書の内容が含まれています：建築、デザイン、建築家や他の単語を
2
Javaプログラミングは次のようになります知っている必要があります
詳細を省略し、文書の内容が含まれています：Javaの、プログラミング、オブジェクト指向、クラス、建築、デザイン、つまり
3
オブジェクト指向の聖なるキヤノンは何ですか
詳細を省略し、文書の内容が含まれています：デザイン、パターン、オブジェクト、クラス、Javaおよび他の単語を
（注：記事のみ実証するために提供され、記事の内容が実際に格納されるコンテンツは、単語の数千です。）
フォワードインデックスは、ドキュメント名による文書の内容を照会するために適用されます。たとえば、サイト上のユーザーは、「聖なるキヤノンが何であるかを、オブジェクト指向」をクリックし、記事の記事のタイトルの内容に基づいてユーザクエリに表示されるウェブサイト。
転置インデックス例：
単語
文書IDのリスト
アーキテクチャ
1,2
デザイン
1,2,3
ジャワ
2,3
（注：各単語インデックスであるため、表は、単なる例示であり、しない完全な転置索引テーブル、実際転置インデックス、行の数千を持っています。）
転置インデックスは、キーワードクエリ文書の内容に適用されます。たとえば、ユーザーが単に「デザイン」に関連する記事を見たいと思って、ウェブサイトのコンテンツが記事に含まれる必要がある「デザイン」の記事は、ユーザに提示されている単語を検索します。
2.フルテキスト検索を使用します
全文検索エンジンのインデックス作成とドキュメントオブジェクトが言葉で、インデックスは、キーオブジェクト・リレーショナル・データベースとライン、二つの用語の間には大きな違い、単純に同一視することはできませんです。そのため、いくつかの変換動作を行う必要があり、フルテキスト検索エンジンは、フルテキスト検索、リレーショナルデータをサポートできるようにするために、文書データへのリレーショナルデータにについてです。
最も一般的に使用される方法は、JSONドキュメントなどのオブジェクトの形に合わせて、リレーショナルデータ変換を変換し、インデックスにJSONドキュメント全文検索エンジンを入力することです。私も基本的な情報テーブルを持つプログラマどのように変換の例。
JSONドキュメントプログラマの形で前のサンプルを変換し、プログラマは3つの情報に関連する文書を取得することができ、私は例として、プログラマ1午前：
{
"ID"：1、
「名前」：「ドロン」
「セックス」：「男性」
「場所」：「北京」
「単位」：「猫工場」
「趣味」：「ライト・コード、観光、マラソン」
"言語"： "ジャワ、C ++、PHP"、
「自己紹介」：「簡単な技術専門家、および彼の熱意。」
}
フルテキスト検索エンジンは、JSON文書と高速な全文検索に基づいて、フルテキストインデックスを確立することができます。例えば次のようにElasticsearchするには、インデックスの基本的な原理は次のとおりです。
Elastcisearchは、文書記憶を配布しました。これは、複雑なデータ構造を格納および取得することができます - リアルタイムに - 直列化されたJSONドキュメントであることを。
Elasticsearchでは、各フィールドの全てのデータは、デフォルトでインデックス化されています。つまり、各フィールドはすぐに転置インデックスの専用セットを取得する必要があります。そして、他のほとんどのデータベースとは異なり、あなたは同じクエリ内のすべての転置インデックスを使用することができ、そして驚くべき速さで結果を返します。
抜粋します。https：//www.elastic.co/guide/cn/elasticsearch/guide/current/data-in-data-out.html
RedisのとのMongoDBの長所と短所
https://blog.csdn.net/weixin_43160039/article/details/83544228