スキーマレスデータベースシステムの魅力は何ですか？
MongoDB、CouchDB、SimpleDBなどのスキーマレス（多くの場合分散）データベースシステムについて多くの話を聞いています...
それらはいくつかの目的に役立つかもしれないことは理解できますが、ほとんどのアプリケーションでは、特定のタイプの特定の数のフィールドを持つオブジェクトを永続化しようとしています。リレーショナルモデルで自動的に考えます。私は常に、一意の整数ID、null/not nullフィールド、SQLデータ型、およびセットを見つけるためのselectクエリを持つ行の観点から考えています。
これらの新しいシステムの分散型の性質と簡単なJSON/RESTfulインターフェースに魅力を感じていますが、厳密に型指定されたキー/値ハッシュが開発にどのように役立つかわかりません。ルーズタイプのスキーマレスシステムがクリーンなデータセットを維持するのに適しているのはなぜですか？たとえば、日付がない可能性があるxからyまでの日付を持つすべてのアイテムを検索するにはどうすればよいですか？結合の概念はありますか？
多くのシステムには独自の違いと長所があることは理解していますが、パラダイムの違いに疑問を持っています。これは自由形式の質問だと思いますが、おそらくコミュニティの回答と、これらのシステムの利点を個人的に見た方法は、私や他の人に、これらの（明らかにもっとヒップな）システムをいつ使用したいかについて啓蒙するのに役立ちます従来のRDBMS。
私は1つか2つの一般的な理由を指摘します（人々はエッセイの答えを書くと確信しています）
高度に分散されたシステムでは、任意のデータセットが複数のサーバーに分散される可能性があります。これが発生すると、DBエンジンが保証できるリレーショナル制約が大幅に軽減されます。 参照整合性の一部は、アプリケーションコードで処理する必要があります。そうするとき、あなたはすぐにいくつかの問題点を発見するでしょう：
- ロジックは複数のレイヤー（アプリとデータベース）に分散しています
- ロジックは複数の言語に分散しています（SQLと選択したアプリ言語）
その結果、ロジックのカプセル化が少なくなり、移植性が低下し、変更にかかる費用が大幅に増加します。多くの開発者は、アプリコードでより多くのロジックを記述し、データベースではより少ないロジックを記述していることに気付きます。極端に言えば、データベーススキーマは無関係になります。
スキーマ管理（特にダウンタイムがオプションではないシステム）は困難です。スキーマの複雑さを軽減すると、その難しさが軽減されます。
ACIDは分散システムではうまく機能しません（ [〜＃〜] base [〜＃〜] 、 [〜＃〜] cap [〜＃〜] など）。 SQL言語（およびある程度のリレーショナルモデル全体）は、トランザクションACIDの世界向けに最適化されています。したがって、SQL言語の機能とベストプラクティスの中には役に立たないものもあれば、実際には有害なものもあります。一部の開発者は、「穀物に反対する」ことに不快感を覚え、要件に合わせてゼロから設計された言語を優先してSQLを完全に廃止することを好みます。
コスト：ほとんどのRDBMSシステムは無料ではありません。スケーリングのリーダー（Oracle、Sybase、SQL Server）は、すべて商用製品です。大規模な（「Webスケール」）システムを扱う場合、データベースのライセンス費用はハードウェアの費用を満たすか上回る可能性があります。コストは、OSSオファリングの上にカスタムソリューションを構築するための通常のビルド/購入の考慮事項を大幅に変更するのに十分な高さです（重要なNOSQLオファリングはすべてOSSです）
スキーマレスは、次の2つの理由で優れています。
- ドキュメントストレージの直感性を最適化する脳
- スパース行列 および エンティティ-属性-値 ストレージの問題を解決します。
Ruby on Rails。私はデータベースの専門家ではないので、ACIDや同様の用語をグーグルで検索することを告白する必要があります。私にはなじみがあります。
「あはは！最新の時流に乗っているもう一つの何も知らないトレンドフォロワー」とあなたは言うかもしれません。しかし、実際には、最新の2年前のアプリでMongoDBを使用するという私の決定に本当に満足しています。その理由は...
脳を最適化する直感性の裏側は、Magentoeコマースシステムでの私の経験でした。当時はうまく機能していたので、bashしたくありませんが、各製品の属性を計算しようとすると、プロセッサに大きな打撃を与えました。根本的な理由は、製品データのEntity-Attribute-Valueストアでした。キャッシュまたは気にしないことが解決策でした。
私にとっての主な利点は、本当に重要な唯一の場所での最適化です-あなた自身の脳。非常に多くのテクノロジが、メモリ、プロセッサ、ハードウェアの効率について批判されていますが、非常に直感的に理解できるDBを使用することには、独自のメリットがあります。データベースはモデル化している現実の世界に非常によく似ているため、コードに機能をすばやく追加できることがわかりました。私がeコマースクライアントに製品リストを提示するように頼んだとき、彼らは当然Excelを使用する傾向があります（テーブルストアを考えてください）。最初の列は簡単です。
- 商品名
- 価格
- 製品型 （
それからそれは難しくなり、メモ、色分け、他のテーブルへのリンクで覆われます（そうです..関係）
- カラー（一部商品のみ）
- サイズ（Xラージ、ラージ、スモール）-製品8'9'10の場合のみ、ゴルフクラブは異なるスケールを使用します
- 色2。猫の首輪には2つの色の選択肢があります。
- ワット数
- 固定タイプ（オス、メス）
そのため、Excelテーブルのひどい混乱に終わり、私には意味がなく、製品を毎日使用する人々にはあまり意味がありません。私たちは腕を空中に投げて、カタログを調べることにしました、そしてそれは私を襲います！カタログに載っているデータをそのまま保存できたらいいなと思いませんか！？その製品の属性をリストするだけの各製品のレコードのコレクション。次に、共通の属性を選択して、後日取得するためにインデックスを作成できます。もちろん、それはドキュメントストアです。
要約すると、ドキュメントストアは、疎行列の問題や、時間の経過とともに属性が変化するオブジェクトがある場合に最適です。 No-SQLの世界に2年間住んでいるので、世界自体がドキュメントストアのように見えるため、これらの機能を備えていない実際のアプリケーションは考えられません。
主な関心事は、データをどのように処理する必要があるかということです。膨大なデータセットがあり、従来のRDBMSがボトルネックであることがわかっている場合は、スキーマレスまたは [〜＃〜] nosql [〜＃〜] ソリューションを試してみることをお勧めします。
[〜＃〜] nosql [〜＃〜] ソリューションの使用を認識しているほとんどの環境でも、何らかの形式または方法でRDBMSソリューションを使用しています。 RDBMSベースのソリューションは、データの整合性が非常に重要であり、ACIDトランザクションが必要な場合の標準です。ただし、システムが高度なトランザクションベースではないが、スケールアップまたはスケールアウトする必要がある場合は、 [〜＃〜] nosql [〜＃〜] ソリューションが望ましい場合があります。
私はMongoDBで遊んだだけですが、本当に興味を持ったのは、ドキュメントをネストする方法です。 MongoDBでは、ドキュメントは基本的にレコードのようなものです。従来、RDBMSでは、「個人」レコードを取得して関連する住所や雇用者情報などを取得する必要がある場合、複数のテーブルに移動して結合し、複数のデータベースを作成する必要があったため、これは非常に便利です。呼び出します。 MongoDBのようなNoSQLソリューションでは、関連するレコード（ドキュメント）をネストするだけで、外部キー、結合、複数のデータベース呼び出しをいじる必要はありません。その1つのレコードに関連付けられているすべてがプルされます。
これは、オブジェクトを扱うときに特に便利です。多くの場合、オブジェクトを一連のネストされたドキュメントとして保存できます。
NoSQLデータベースはスキーマレスではありません。スキーマはデータに埋め込まれています。それらは適切に半構造化と呼ばれます。ただし、一部のKVデータストアでは、スキーマがコードに埋め込まれている場合もあります。半構造化アプローチの利点は2つあります。列が行の一部である柔軟性（1つの行に5つの列があり、別の行に5つの異なる列がある可能性がある）と、列の特性（可変長など）の柔軟性です。