私はNoSQLについて聞いてきましたが、DBの相互作用がWebの速度のボトルネックになることが多いため、最終的にはSQLDBストレージメソッドの代わりになる可能性があります。
だから私はいくつか質問があります:
正確には何ですか?
それはどのように機能しますか?
SQLデータベースを使用するよりも優れているのはなぜですか?そして、それはどれくらい良いですか?
テクノロジーはまだ実装を開始するには新しすぎるのでしょうか、それとも調査する価値がありますか?
NoSQL はバズワードです。
何十年もの間、人々がデータベースについて話すとき、それはリレーショナル データベースを意味していました。人々がリレーショナル データベースについて話しているとき、それは Edgar F. Codd の構造化照会言語で制御するデータベースを意味していました。他の方法でデータを保存しますか? 狂気!それ以外は単なるフラットファイルです。
しかし、ここ数年、人々はこの定説に疑問を持ち始めました。行と列を持つテーブルが本当にデータを表現する唯一の方法なのだろうかと人々は疑問に思いました。人々は思考とコーディングを開始し、データを整理する方法について多くの新しい概念を思いつきました。そして、これらの新しいデータ操作方法用に設計された新しいデータベース システムの作成を開始しました。
これらすべてのデータベースの哲学は異なっていました。しかし、これらすべてのデータベースに共通していたことの 1 つは、構造化照会言語がデータベースの使用に適さなくなったことです。そのため、各データベースは SQL を独自のクエリ言語に置き換えました。そのため、従来のリレーショナル データベース モデルに逆らうすべてのデータベース テクノロジのラベルとして、NoSQL という用語が生まれました。
実際、それほど多くはありません。
次のようなフレーズをよく耳にします。
本当?これらのステートメントのいくつかは、一般に NoSQL と呼ばれる一部のデータベースには当てはまりますが、少なくとも 1 つの他のデータベースには当てはまりません。実際、NoSQL データベースに共通しているのは、SQL を使用しないデータベースであるということだけです。それでおしまい。それらを定義する唯一のものは、それらを互いに区別するものです.
そのため、一般に NoSQL と呼ばれるこれらすべてのデータベースは、あまりにも異なりすぎてまとめて評価できないことを明確にしました。特定の問題を解決するのに適しているかどうかを判断するには、それぞれを個別に評価する必要があります。しかし、どこから始めますか?ありがたいことに、NoSQL データベースは、さまざまなユースケースに適した特定のカテゴリにグループ化できます。
ドキュメント指向
例: MongoDB、CouchDB
強み: 異種データ、実用的なオブジェクト指向、アジャイル開発
それらの利点は、一貫したデータ構造を必要としないことです。これらは、要件によってデータベースのレイアウトが絶えず変化する場合、または一緒に属していても見た目が非常に異なるデータセットを扱っている場合に役立ちます。「キー」と「値」と呼ばれる 2 つの列を持つテーブルが多数ある場合、これらを調べる価値があるかもしれません。
グラフ データベース
例: Neo4j、GiraffeDB。
強み:データマイニング
ほとんどの NoSQL データベースは、データ関係を管理するという概念を放棄していますが、これらのデータベースは、いわゆるリレーショナル データベースよりもさらにそれを取り入れています。
彼らの焦点は、他のデータとの関係によってデータを定義することにあります。他の 2 つのテーブルの主キーである主キーを持つテーブルがたくさんある場合 (およびそれらの間の関係を説明するデータもある場合)、これらはあなたにとって何かになるかもしれません。
キー値ストア
例: Redis、Cassandra、MemcacheDB
長所: 既知のキーによる値の高速検索
それらは非常に単純化されていますが、それが高速で使いやすいものになっています。ストアド プロシージャ、制約、トリガー、およびこれらすべての高度なデータベース機能を必要とせず、データの高速な保存と取得だけが必要な場合は、これらが最適です。
残念ながら、彼らはあなたが探しているものを正確に知っていると仮定しています。User157641 のプロファイルが必要ですか? 問題ありません。数マイクロ秒しかかかりません。しかし、年齢が 16 ~ 24 歳で、好物が「ワッフル」で、過去 24 時間にログインしたすべてのユーザーの名前が必要な場合はどうでしょうか。運が悪い。特定の結果に対する明確で一意のキーがない場合、KV ストアから簡単に取得することはできません。
一部の NoSQL 支持者は、お気に入りの NoSQL データベースは物事を行うための新しい方法であり、SQL は過去のものであると主張しています。
彼らは正しいですか?
いいえ、もちろんそうではありません。SQL には適していない問題もありますが、それでも SQL には長所があります。多くのデータ モデルは、相互に参照するテーブルのコレクションとして表現するのが最適です。特に、ほとんどのデータベース プログラマーは何十年にもわたってデータをリレーショナルな方法で考えるように訓練されており、この考え方をリレーショナルな方法で作成されていない新しいテクノロジに押し付けようとしても、うまくいくことはめったにありません。
NoSQL データベースは SQL の代替ではありません。代替手段です。
さまざまな NoSQL データベースに関するほとんどのソフトウェア エコシステムは、まだ成熟していません。進歩はありますが、一般的な SQL データベースで利用できるものほど成熟した強力な補助ツールはまだありません。
また、SQL に関するノウハウは他にもたくさんあります。何世代にもわたるコンピュータ サイエンティストは、何十年にもわたるキャリアをリレーショナル データベースに焦点を当てた研究に費やしてきました。それは次のことを示しています。データ用のリレーショナル データベースを構築する方法は十分に研究されているトピックであるため、一般的に受け入れられているベスト プラクティスが存在しないコーナー ケースを見つけるのは困難です。
一方、ほとんどの NoSQL データベースはまだ初期段階にあります。私たちはまだそれらを使用するための最良の方法を考え出しています.
正確には何ですか?
一方では特定のシステムですが、リレーショナル DB モデルに従わないさまざまな新しいデータ ストレージ バックエンドの総称にもなっています。
それはどのように機能しますか?
総称名でラベル付けされた各システムの動作は異なりますが、基本的な考え方は、汎用 RDBMS のすべての機能をサポートするわけではありませんが、有用な機能を十分に備えた DB モデルを使用して、より優れたスケーラビリティとパフォーマンスを提供することです。ある意味では、かつてトランザクションのサポートが欠けていた MySQL のようなものですが、まさにそのために、他の DB システムよりも優れたパフォーマンスを発揮することができました。トランザクションを必要としない方法でアプリを作成できれば、それは素晴らしいことです。
SQL データベースを使用するよりも優れているのはなぜですか? そして、それはどれくらい良いですか?
サイトを非常に大規模にスケーリングする必要があり、可能な限り最適化された最高のハードウェアで実行されている最高の RDBMS が負荷に追いつかない場合は、より良い結果が得られます。それがどれほど優れているかは、特定のユース ケースによって異なります (多くの結合と組み合わされた多くの更新アクティビティは、「従来の」RDBMS では非常に困難です) - 極端な場合には 1000 倍になる可能性があります。
テクノロジーはまだ実装を開始するには新しすぎるのでしょうか、それとも検討する価値はありますか?
主に、何を達成しようとしているかによって異なります。確かに使いこなすには十分な熟成です。しかし、それを大規模にスケーリングする必要があるアプリケーションはほとんどありません。ほとんどの場合、従来の RDBMS で十分です。ただし、インターネットの使用が常にユビキタスになっているため、それを行うアプリケーションがより一般的になる可能性が非常に高くなります (おそらく支配的ではありません)。
私の記憶が正しければ、それは必ずしもリレーショナル形式に従わないタイプのデータベースを指します。ドキュメント データベース、特定の構造を持たず、特定のクエリ言語として SQL を使用しないデータベースが思い浮かびます。
一般に、データベースのパフォーマンスに依存し、リレーション データベース エンジンのより高度な機能を必要としない Web アプリケーションにより適しています。たとえば、id インターフェイスによる単純なクエリを提供する Key->Value ストアは、対応する SQL サーバーの実装よりも 10 倍から 100 倍高速で、開発者のメンテナンス コストが低くなります。
1 つの例は、OLTPタプル ストアに関するこのペーパーです。これは、シングル スレッド処理 (同時実行が許可されていないため、同時実行の問題はありません) のためにトランザクションを犠牲にし、すべてのデータをメモリに保持します。同様のRDBMS駆動型システムと比較して、10 ~ 100 倍のパフォーマンスを達成します。基本的に、それは SQL とデータベース システムの「万能」ビューから離れつつあります。
実際には、NoSQL は、キー ベースのアクセス戦略を使用して大きなバイナリ オブジェクト (ドキュメント、jpg など) への高速アクセスをサポートするデータベース システムです。これは、英数字の値にのみ有効な従来の SQL アクセスとは一線を画しています。内部ストレージとアクセス戦略だけでなく、構文と表示形式の制限も従来の SQL を制限します。従来のリレーショナル データベースの BLOB 実装も、これらの制限に悩まされています。
舞台裏では、SQL モデルがあらゆる形式の OLTP や新しいデータ形式をサポートできないことを間接的に認めています。「サポート」とは、ストアだけでなく、標準モデルを使用したプログラムおよびクエリによるフル アクセス機能を意味します。
リレーショナル愛好家は、NoSQL の定義を Not-SQL から Not-Only-SQL にすばやく変更して、SQL を依然として全体像にとどめました。これは、現在ほとんどの Java プログラムが基礎となるリレーショナル モデルの ORM マッピングに依存していることを考えると、特に良くありません。新しい概念には明確な定義が必要です。そうしないと、SOA のようになってしまいます。
NoSQL システムの基礎は、ランダムなキーと値のペアにあります。しかし、これは新しいことではありません。IMS や IDMS などの従来のデータベース システムは、ハッシュ化された ramdom キーを (インデックスを使用せずに) サポートしており、現在もサポートしています。実際、IDMS にはすでにキーワード NONSQL があり、NONSQL と呼ばれる古いネットワーク データベースへの SQL アクセスをサポートしています。
それはジャグジーのようなものです:ブランドと一般的な名前の両方。これは特定のテクノロジーではなく、特定のタイプのテクノロジーであり、この場合は、GoogleのBigTableやCouchDBなどの大規模な(多くの場合、まばらな)「データベース」を指します。
NoSQL実際のプログラムは、バックエンドでフラット ファイルを使用して awk で実装されたリレーショナル データベースのようです。彼らは公言していますが、「NoSQL には本質的に恣意的な制限がなく、他の製品ができない場所でも機能します。たとえば、データ フィールドのサイズ、列の数、またはファイルのサイズに制限はありません」未来の大規模データベース。
Joel が言うように、 BigTableやHBaseのような非常にスケーラブルなデータベースは、はるかに興味深いものです。GQL は、BigTable と App Engine に関連するクエリ言語です。Google がボトルネックと見なす機能 (結合など) を回避するために、主に SQL を微調整しています。ただし、これが「NoSQL」と呼ばれているのは聞いたことがありません。
NoSQL は、文字列ベースの SQL クエリを使用してデータをフェッチしないデータベース システムです。
代わりに、提供される API を使用してクエリを作成します。たとえば、Amazon DynamoDB は NoSQL データベースの良い例です。
NoSQL データベースは、スケーラビリティが重要な大規模なアプリケーションに適しています。
NoSQL は非リレーショナル データベースを意味しますか?
はい、NoSQL は RDBMS や OLAP とは異なります。従来のリレーショナル データベースよりも緩やかな一貫性モデルを使用します。
一貫性モデルは、分散共有メモリ システムや分散データ ストアなどの分散システムで使用されます。
内部的にはどのように機能しますか?
NoSQL データベース システムは、多くの場合、検索および追加操作用に高度に最適化されており、多くの場合、レコード ストレージ (キー値ストアなど) 以外の機能はほとんど提供されていません。完全な SQL システムに比べて実行時の柔軟性が低下しますが、特定のデータ モデルのスケーラビリティとパフォーマンスが大幅に向上することで補われます。
構造化データと非構造化データで機能します。テーブルの代わりにコレクションを使用します
そのような「データベース」をどのように照会しますか?
SQL vs NoSQL : バックエンドの戦いをご覧ください。それはそれをすべて説明します。