NoSQLに画期的なものはありますか？[閉まっている]

私は非常に堅実なリレーショナルデータベースの男であり、第3正規形までのすべてを理解し、SQLの代数集合論の根を高く評価し、おそらく失恋を関係付ける（またはしない）ことができます。

私は妻とデートするためのリレーショナルデータベース構造を理解していませんが、妻とデートするためのリレーショナルデータベースプロジェクトについて考えました。

今、私はNoSQLについて聞いて、それを調査しています。簡単に言えば、画期的で数学的に斬新なNoSQLについて何かありますか、または「データをリレーショナルに整理する必要さえないので、これは非常に簡単です」タイプのアプローチですか？

NoSQLはデータ構造のスーパーシェルのようなものですか？私の考えでは、データには最終的に取得する構造が必要であり、検索は何らかの言語で定義する必要があります。

NoSQLは革命的というよりも進化的です。基本的に、「外部データベースストレージ」という既存のアイデアと「リレーショナルテーブルではなく、使い慣れたデータ構造を使用する」とを組み合わせます。

階層型データベースなど、リレーショナル型よりも多くの種類のデータベースがあります。今日の標準では古風ですが、データのデータ構造（COBOLレコードなど）と非常によく一致しています。重要なのは、データベース内のデータは、レコードを使用したプログラミング言語でのレコードのレイアウト方法に密接にモデル化されているということです。

リレーショナルデータベースの発明に早送りします。最終的にデータベースは関心事を分離し、適切に正規化すると、ほとんどのタイプのデータとデータ間の関係を視覚化する素晴らしい方法になります。他の種類のデータベースと比較して理解するのは本当に簡単です。ただし、プログラムでオブジェクトとクラスをミラーリングする方法でデータを保存することは、まったく失敗します。したがって、オブジェクトリレーショナルマッピングの発明。言い換えれば、データベースの設計は実際にはそれを使用するプログラムの設計の障害であるため、HibernateなどのORMライブラリが必要です。。清潔で一貫性がありますが、私の心の奥には、そこに何かが正しくないという疑わしい疑念が常にあります。

これにより、さらに2種類のデータベース、オブジェクトデータベースとNoSQLが発生しました。

どちらも、階層型データベースの驚くべき恐怖に私たちをさらすことなく、リレーショナルデータベースによってもたらされる問題を解決しようとします。データはいまだにテーブルに似ているリポジトリに配置されていますが、実際にはリレーショナルテーブルというよりもデータ構造のプログラミングに似ています。オブジェクトデータベースはほとんど明確に定義されたルールに従いますが、私の理解では、NoSQLはかなりarbitrary意的です。たとえば、テーブルはハッシュテーブルまたは配列として視覚化できます。Oracle SQL DeveloperやSQL Server Management Studioに類似した任意のツールを使用して簡単にクエリを定義する方法はありません。

アイデアは、希望するクエリを表現するのではなく、SQLデータベースエンジンに適したSQLクエリをつなぎ合わせるのではなく、コードで簡単に検索できるデータ構造を定義できるということです。たとえば、リレーショナルデータベースではあいまい一致または部分一致はより難しく、パフォーマンスが低下しますが、NoSQLデータベースはそのような検索に最適化された構造を持ち、短時間で完了することがあります。

NoSQLを照会するための言語があります。ただし、リレーショナルデータベース用のSQLのような普遍的な言語はありません。

後期編集：

私はNoSQLデータベースに十分精通していますが、この質問は、このトピックに関する質の高い本を購入し、最終的にはそのトピックの専門家になるという目標で読み始めるきっかけとなりました。残りのコメントは、NoSQL Distilled：Pramod SadalageとMartin Fowlerによるポリグロット永続性の新興世界の簡単なガイドに基づいています。

著者は、リレーショナルデータベースは、AmazonやGoogleなどのサイトに必要なデータを提供できるクラスターに十分に拡張できないと述べています。主に静的データを使用します（したがって、ACIDトランザクションはそれほど重要ではありません）。

さらに、NoSQLデータベースがスキーマを使用せずに動作するため（10ページ）、NoSQLデータベースがデータの構造をより簡単に変更できると仮定しています。SQLデータベースでもスキーマを変更できるため、この点で正式なスキーマの有無が重要かどうかはわかりません。とにかく、有名な2人の著者が主張しているので、調べる価値があります。

これらの主要な点はどちらも、NoSQLは革命的ではなく進化的であるという私の主要な点を強化するためだけに役立つと考えています。それらはまだデータを保存し、規模と変更可能性を徐々に改善します。彼らはまた、NoSQLがリレーショナルデータベースをデータストレージの王として奪うことを求めていないことを強調しています。データベースは十分にサポートしていません。

Erik Meijer＆Gavin Biermanによる「一般的な信念に反して、SQLとNoSQLは実際には同じコインの両面にすぎません」というタイトルの論文をぜひご覧ください。要するに、数学的に言えば両方のアプローチは同じ理論に基づいているが、いくつかの違いがあると主張している。

私の意見から、いくつかの興味深い違いは次のとおりです。クロスタイプの依存関係（SQLのFK）の方向はSQLとNoSQLの反対であり、コレクションタイプはNoSQLのセットに限定されません（したがって、いくつかのセット理論的な操作NoSQLの世界にはもう適用されないかもしれませんが、他のいくつかはまだ有効です）。この記事のもう1つの興味深い点は、SQLデータベースとNoSQLデータベースの両方を照会するために提案された単一の照会言語です。これはLINQと呼ばれ、以前にこの名前を聞いたことがあると思われる場合、あなたは正しいです。それはMicrosoftのC＃からのクエリ言語です。

Snowmanの答えは、SQLとNoSQLのデータ構造の違いとそれらへのアクセス方法を正しく説明しています。ただし、おそらくさらに重要な違いは、それぞれの問題領域です。

NoSQLはSQLの後継ではありません。むしろ、NoSQLのさまざまなブランチは、他のSQLをより良くするために、SQLのいくつかの品質を犠牲にします。CAP定理は、分散データベースシステムが以下のすべての特性を満たすことは不可能であると述べています。

• 一貫性
• 可用性
• パーティション許容差

したがって、一部のNoSQLバリアントは、代わりにBASE原則に従います。これは、従来のSQLデータベースの基礎であるACIDの常に完全な一貫性の制約を緩和します。一貫性の保証を失うことにより、大量のデータとユーザークエリを備えたWebサイトなど、広く分散したシステムで高可用性とパーティショントレランスを組み合わせる可能性が得られますが、完全な一貫性に対する要求はほとんどありません。したがって、このようなNoSQLデータベースは、Google、Facebook、およびAmazonの中心にあります。それで、あなたの質問に答えるために：はい、NoSQLはそのような大規模なWebサービスをほとんど可能にするという点で画期的です。

NoSQLは多様なフィールドであり、そのバリアントはCAP三角形内のパラメーターのほとんどすべての可能な組み合わせをカバーするため、これはほんの一例です。

NoSQLの一般的な使用事例は、一般的なSQLベースのデータベースと比較して、生産性の向上において画期的です。これにはいくつかの要因があります。

1つはハウスキーピングです。ほとんどのNoSQLはオープンソースであり、いくつかのコマンドを使用してワークステーションまたはVMにインストールでき、すぐに使用できる適切なデフォルトで動作します。私の経験では、PostgresとMySQLでさえそうではありません。通常、開発目的のワークステーションでも開始するには構成が必要です。

別の答えは詳細に説明されているように、別のものは便利な開発です。MongoのJSONインデックス機能、またはredisとRiakのキー/値セマンティクスは、すべての特定のwebappが仕事を成し遂げるために必要なものであり、APIは簡単です。一部のNoSQLは独自のRESTful APIを提供しますが、SQLでは通常、自分で作成する必要があります。

これらの要因により、NoSQLデータベースは小規模プロジェクトにとって魅力的です。ピックアップ時間が短くなる傾向があります。確かに、本番環境に行くときは、セキュリティとスケールを設定する必要がありますが、コーディングとコラボレーションを迅速に開始する機能は強力であり、画期的です。

また、上記に関連して、小規模なアプリケーション（社内またはアプリ間サービスなど）の場合、チームはDBAチームを関与させることなく、パフォーマンスや整合性を損なうことなく、本番のNoSQLデータベースを立ち上げることができます。結果として問題。専門のDBAはこれを好まないかもしれませんが、DBAを障害の原因（正しいか間違っている）として見ている開発者は、NoSQLを、それらに対処することを回避する方法と考えることがあります。私はこれを告白します-かつて小規模アプリケーションをPostgresからSQLiteに変更して敵対的なDBAを排除し、DBA承認プロセスとアクセス制限を避けるためにOracleではなくMongoに実装することを選択しました。どちらの場合も悪影響はありません。