Schemalessデータベースシステムの魅力は何ですか？

Question

MongoDB、CouchDB、SimpledBなどのスキーマレス（しばしば分散）データベースシステムについて多くの話を聞いてきました...

私はそれらがいくつかの目的で価値があるかもしれないと理解できますが、私のアプリケーションのほとんどで特定のタイプの特定の数のフィールドを持つオブジェクトを持続しようとしているので、リレーショナルモデルで自動的に考えています。私は常に、一意の整数ID、null/not null fields、sqlデータ型、およびセットを見つけるための選択クエリを持つ行を備えた行について考えています。

私はこれらの新しいシステムの分散された自然と簡単なJSON/RESTFULインターフェイスに惹かれていますが、キー/バリューのハッシュがどれほどゆるくタイプされているかは、私の開発にどのように役立つかを理解していません。緩いタイプされたスキーマレスシステムは、クリーンなデータセットを維持するのに適しているのはなぜですか？たとえば、XとYの間に日付が日付がない場合の日付を持つすべてのアイテムを見つけるにはどうすればよいですか？参加の概念はありますか？

私は多くのシステムに独自の違いと強みがあることを理解していますが、パラダイムの違いに疑問に思っています。これは自由回答形式の質問だと思いますが、おそらくコミュニティの答えと彼らが個人的に見た方法は、これらのシステムの利点を私に啓発するのに役立ちます。従来のRDBMS。

Answer 1

私は1つか2つの一般的な理由を呼びます（人々はエッセイの答えを書くと確信しています）

1. 高度に分散されたシステムを使用すると、特定のデータセットが複数のサーバーに広がる場合があります。それが起こると、DBエンジンが保証できるリレーショナル制約が大幅に減少します。 いくつかの 参照整合性の整合性は、アプリケーションコードで処理する必要があります。そうするとき、あなたはすぐにいくつかの問題点を発見します：

   • あなたのロジックは複数のレイヤー（APPとDB）に広がっています
   • あなたのロジックは複数の言語に広がっています（SQLと選択したアプリ言語）

   結果は、ロジックのカプセル化が少なく、携帯性が低く、変更がはるかに高価であるということです。多くの開発者は、アプリコードでより多くのロジックを書いており、データベースでは少ないことに気づきます。極端に進むと、データベーススキーマは無関係になります。

2. スキーマ管理、特にダウンタイムがオプションではないシステムでは、困難です。スキーマの複雑さを減らすと、その難易度が軽減されます。

3. 酸は分散システムではあまりうまく機能しません（ベース, キャップ, など）。 SQL言語（およびある程度のリレーショナルモデル全体）は、トランザクション酸の世界に最適化されています。したがって、一部のSQL言語機能とベストプラクティスは役に立たず、他の言語は実際に有害です。一部の開発者は、「穀物に反する」ことについて不快に感じ、要件のためにゼロから設計された言語を支持してSQLを完全に削除することを好みます。

4. コスト：ほとんどのRDBMSシステムは無料ではありません。スケーリング（Oracle、Sybase、SQL Server）のリーダーはすべて商用製品です。大規模な（「Webスケール」）システムを扱う場合、データベースライセンスコストはハードウェアコストを満たすか、それを超えることができます！コストは、通常のビルド/購入の考慮事項をOSSの提供の上にカスタムソリューションの構築に劇的に変更するのに十分な高さです（重要なNOSQLの提供はすべてOSSです）

Answer 2

Schemalessは2つの理由で優れています。

1. ドキュメントストレージの直感性を最適化する脳
2. 解決します スパースマトリックス と エンティティアトリブの価値 ストレージの問題。

Ruby on Railsの生産アプリケーションにSQLとNO-SQLの両方を使用しました。私はデータベースの専門家ではありません。酸をグーグルでグーグルで告白しなければなりません。

「ああ！最新の時流にジャンプするもう一つの知らないトレンドフォロワー」と言うかもしれません。しかし、実際には、最近の2年前のアプリでMongodbを使用するという私の決定に本当に満足しています。

脳を最適化する直感の裏側は、Magento eコマースシステムでの私の経験でした。当時はうまく機能していたので、バッシュしたくありませんが、各製品の属性を計算しようとしてプロセッサを強く攻撃しました。根本的な理由は、製品データのエンティティアトリブと価値のストアでした。キャッシュまたはのろわれたものが解決策でした。

私にとっての主な利点は、本当に重要な唯一の場所での最適化です - あなた自身の脳. 。多くのテクノロジーは、メモリ、プロセッサ、ハードウェアの効率性について批判されています。データベースは、私たちがモデリングしている現実の世界によく似ているため、コードに機能を追加することがすぐにわかりました。電子商取引のクライアントに製品リストを提示するように頼んだとき、彼らは当然Excelを使用する傾向があります（Think Table Store）。最初の列は簡単です：

1. 商品名
2. 価格
3. 製品型 （

その後、メモ、カラーコーディング、他のテーブルへのリンク（うん。

4. 色（一部の製品のみ）
5. サイズ（x大きく、大、小） - 製品8'9'10製品のみ、ゴルフクラブは別のスケールを使用しています
6. 色2.猫の襟には2つの色の選択肢があります。
7. ワット数
8. 固定タイプ（男性、女性）

ですから、それは私にとって意味のないエクセルテーブルのひどい混乱で終わり、毎日製品と仕事をしている人々にはあまり意味がありません。私たちは空中に腕を投げて、カタログを通過することにしました。データがカタログに表示されているように保存できれば、それは素晴らしいことではないでしょうか！？その製品の属性をリストするだけの各製品のレコードのコレクションだけです。その後、後日、検索のためにインデックスに共通の属性を選択できます。もちろん、それはドキュメントストアです。

要約すると、ドキュメントストアは、まばらなマトリックスの問題や、時間の経過とともに属性を変異させるオブジェクトがある場合に最適です。 NO-SQLの世界に2年間住んでいたので、世界自体がドキュメントストアのように見えるため、これらの機能を持たない現実世界のアプリケーションは考えられません。

Answer 3

主な関心事は、データで何をする必要があるかです。巨大なデータセットがあり、従来のRDBMSがボトルネックであることを見つけている場合は、SchemalessまたはAAを試してみることができます。 nosql 解決。

私が使用していることを知っているほとんどの環境 nosql ソリューションは、RDBMSソリューションを何らかの形またはファッションで使用します。 RDBMSベースのソリューションは、データの整合性が非常に重要であり、酸トランザクションが必要な標準です。ただし、システムが高度にトランザクションに基づいていないが、実際に迅速にスケールアップまたはスケールアップする必要がある場合は、 nosql 解決策が望ましい場合があります。

Answer 4

私はMongodbでしか遊んでいませんが、私が本当に興味を持っていることの1つは、ドキュメントをネストする方法でした。 Mongodbでは、ドキュメントは基本的にレコードのようなものです。これは本当に素晴らしいことです。伝統的に、RDBMSでは、「個人」レコードを引いて関連するアドレス、雇用主情報などを取得する必要がある場合は、頻繁に複数のテーブルに移動し、結合し、複数のデータベースを作成する必要があります。電話。 MongoDBのようなNOSQLソリューションでは、関連するレコード（ドキュメント）をネストするだけで、複数のデータベース呼び出しを結合したり、参加したりする必要はありません。その1つのレコードに関連するすべてが引かれます。

これは、オブジェクトを扱うときに特に便利です。多くの場合、オブジェクトを一連のネストされたドキュメントとして保存することができます。

Answer 5

NOSQLデータベースはスキーマレスではありません。スキーマはデータに埋め込まれています。それらは適切に半構造化されています。ただし、一部のKVデータストアでは、スキーマをコードに埋め込むことさえあります。半構造化されたアプローチの利点は2つの折り目です。列が行の一部である柔軟性（1つの行には5つの列があり、別の列には5つの異なる列があり、列の特性に柔軟性があります（たとえば、変数長）

Answer 6

通常、魅力はヘビ油の魅力です。ほとんどの人が彼らを支持することは、リレーショナル定理についての手がかりがなく、専門家を吐き出すレベルでSQLを話します。酸性条件が何であるかはわかりません。

彼らが有効な用途を持っていないと言っていません....ほとんどの魅力は、彼らが知っておくべきことを知らない人々であると言うだけで、愚かな結論を出します。繰り返しますが、誰もがそのようなものではありませんが、それらを支持するほとんどの開発者は、データベースシステムが何に対して責任を負っているかを理解するのには良くありません。