NoSQL_システム設計ノート 12

前置き

リレーショナルデータベースの場合、（必要に応じて）非正規化を通じて書き込みパフォーマンスの一部を犠牲にして、より高い読み取りパフォーマンスを得ることができますが、前提はまず范式设计を満たすことで、その後この基础上で局部調整を行い、意図的にいくつかのルールを破ることです

最初に正規化し、パフォーマンスのボトルネックに遭遇してから非正規化を行うよりも、最初から非正規化設計を考慮する方が良い——直接 NoSQL を採用します

一.NoSQL とは何か？

リレーショナルデータベースとは異なり、NoSQL データベース（非 SQL または非リレーショナルデータベースとも呼ばれる）が提供するデータ保存、検索メカニズムは��関係に基づくモデリングではありません：

A NoSQL (originally referring to "non SQL" or "non relational") database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.

データテーブルがなくなれば、 naturalmente 複数テーブルの結合検索（join操作）のパフォーマンス懸念もなくなり、范式制約と非正規化の選択も存在しなくなります

しかし、データテーブルがなくなれば、データはどのように組織し、関係はどのように記述すればよいのでしょうか？

実際、SQL（リレーショナルデータベース）は唯一の選択ではありません

Not Only SQL

NOSQL について、もう一つの面白い理解は Not Only SQL で、リレーショナルデータベース以外の広大な世界では、データは必ずしも平らにして二次元テーブルに保存する必要はなく、関係も主キー、外部キー、関係テーブルだけで記述する必要があるわけではありません

データベースタイプという観点から言えば、NoSQL はリレーショナル以外の其它タイプのデータベースを指し、つまり非リレーショナルデータベース（NoREL, Non Relational）です。例えば MongoDB、CouchDB など

使用観点から見ると、NoSQL を実践するには必ずしも NoSQL データベースを選ぶ必要はなく、「NoSQL」の方式で MySQL などのリレーショナルデータベースを使用することももちろん含まれます：

You can stay with MySQL, and use it like a NoSQL database.

例えばデータテーブルに JSON 文字列の列を保存し、この列をキーバリューデータベースとして使用します

二.4 種類の NoSQL データベース

リレーショナルデータベースのテーブル構造とは異なり、NoSQL データベースはより柔軟なデータ構造をサポートし、いくつかの操作をより速くします

キーバリューストア

キーバリューストア（Key-value store）は最もシンプルな NoSQL データモデルで、キーバリューペアのみ保存でき、key でのみ検索可能 です。保存される値はデータベースシステムに対して不透明（BLOB に類似）であり、値の特征に基づいて検索またはインデックスを作成することはできません

P.S.一部のキーバリューデータベースは key をソートでき、範囲検索（特定の区間内の key のデータを検索）をサポートします。例えば従業員番号が 100000 より大きい新人情報の検索

データモデルはハッシュテーブルであり、O(1) の読み書きパフォーマンスを達成でき、シンプル、または頻繁に変更されるデータに適し、メモリキャッシュとしてよく使用されます。例えば Memcached、Redis

ドキュメントストア

ドキュメントストア（Document store）はドキュメント（XML、JSON などの半構造化データ）を中心にモデリングし、強化版のキーバリューストアに相当し、ドキュメント面向でより精細なデータ操作を提供 します。キーバリューストアとの最大の違いは、データベースが保存される値（つまりドキュメント）を理解して処理でき、値の特征（つまりドキュメントの内部構造）に基づいて検索およびインデックスを作成できることです

さらに、ドキュメントはネストをサポートし、MongoDB、CouchDB などのドキュメントデータベースは SQL に類似したクエリ言語も提供し、複雑なクエリをサポートします

永続化保存に適し、頻繁に変更されないデータを保存するために使用され、リレーショナルデータベースの一般代替案として

ワイドカラムストア

ワイドカラムストア（Wide column store）では、列（column）が最小のデータユニットで、各列は名値ペア（およびバージョン管理と競合解決のためのタイムスタンプ）であり、列の上にはスーパー列（super column）というレベルがあります：

列のみを含む行を列族（column family）と呼び、スーパー列を含む行をスーパー列族（super column family）と呼び、各行（つまり、列族またはスーパー列族）は 1 つのエンティティを表し、そのエンティティのすべての関連情報を含みます：

データモデルは二次元 Mapで、高性能と良好な拡張性が特徴であり、非常に大きなデータセットに適し、Twitter、Facebook などのソーシャルネットワークが海量ユーザーが生成するデータを保存するために使用しています

P.S.例えば Google が最初に発表した Bigtable、Hadoop エコシステム中の HBase、および Facebook が発表した Cassandra

グラフデータベース

データはグラフに基づいてモデリングされ、グラフ中の各ノードは 1 つのレコードを表し、各エッジはノード間の関係を表します。そのため、データオブジェクト間の複雑な関係を簡単に記述できます。例えば関係モデル中の複雑な外部キーと多対多関係

グラフデータベースの実際応用はまだ十分に成熟しておらず、広く採用された標準化クエリ言語さえまだありませんが、その接続性優位性は複雑な関係を持つデータモデル（例えばソーシャルネットワーク）に特に適し、期待に値します：

P.S.例えば Neo4j、Oracle Spatial and Graph、ArangoDB など

三.NoSQL は何を意味するか？

シンプルな NoSQL モデル（キーバリューストアなど）を採用することは、一部の作業をデータベース層からアプリケーション層に移転することに相当します：

Joins will now need to be done in your application code.

データベース層と比較して、アプリケーション層は通常（横方向に）拡張しやすく、そのためこの作業量移転はシステムの拡張性向上に役立ち、複雑なデータ操作をアプリケーション層に処理させ、より大きな最適化空間を求めます

トランザクションなどの強一貫性保証さえアプリケーション層で処理する必要があります。多数の NoSQL データベースはトランザクションサポートを提供しないためです：

Most NoSQL stores lack true ACID transactions, although a few databases have made them central to their designs.

ACID vs. BASE

リレーショナルデータベースで追求される ACID（トランザクションの 4 大特性）とは異なります：

Atomicity（原子性）：一連の操作はすべて成功するか、失敗してすべてロールバックする
Consistency（一貫性）：トランザクション実行前後にデータベースは一貫性状態でなければならない（既定のすべての一貫性制約を満たす）
Isolation（隔離性）：並行トランザクション操作の結果状態は順序通りに実行するのと同じ
Durability（持久性）：トランザクションがコミットされると、データの変更は永久的であり、障害に遭遇してもコミットされた結果は失われない

NoSQL は CAP の選択で C に妥協し、最終一貫性を許可します。つまり BASE です：

Basically Available（基本可用）：読み書き操作は可能な限り可用を保証するが、いかなる一貫性も保証しない
Soft state（軟状態）：一貫性保証がないため、一定時間後、最新状態を読み取れる可能性があるだけで、まだ収束していない可能性がある
Eventual consistency（最終一貫性）：システムが正常に実行されれば、十分な時間を待った後、最終的に最新状態を読み取れる

つまり、分散環境では、（大多数の）NoSQL データベースは最終一貫性のみを保証し、最新データを即座に読み取れない可能性があります

四.SQL or NoSQL?

それと比較して、SQL データベース（リレーショナルデータベース）の優位性は：

トランザクション操作をサポート
明確な拡張モードがある
開発者、コミュニティ、ツールなどが比較的成熟

主な欠点は：

複雑なテーブル結合クエリによりデータ読み取りパフォーマンスが良くない
拡張しにくい（手動シャーディング）
関係モデルと OOP の間に大きな差異がある（Object-relational impedance mismatch）
構造化データの保存と取得のみサポートし、関係モード（テーブル構造など）は事前に定義する必要があり、変更コストが高い

P.S.Object-relational impedance mismatch に関する詳細情報は、Why is MongoDB wildly popular? It's a data structure thing. を参照

NoSQL データベース（非リレーショナルデータベース）の優位性は以下に集中：

複雑なテーブル結合クエリが存在しない
拡張しやすい（一部の NoSQL データベースは自動シャーディングをサポート）
OOP データモデルと一致し、使いやすい
データモードを事前に定義する必要がなく、急速に変化する構造化、半構造化、非構造化データの保存と取得をサポート
読み書きパフォーマンス（IOPS）が高く、データ集約型作業に適す