最近、私はの概念に遭遇し、私がNoSQL
理解している限り、膨大な量のデータを処理するのに適しています。
NoSQL
私の質問は、使用する価値がある制限は何ですか? Google や Facebook など、本当に膨大な量のデータを扱う企業だけのものなのか、それともデータ量が少なくても SQL データベースから切り替える価値はあるのでしょうか。
最近、私はの概念に遭遇し、私がNoSQL
理解している限り、膨大な量のデータを処理するのに適しています。
NoSQL
私の質問は、使用する価値がある制限は何ですか? Google や Facebook など、本当に膨大な量のデータを扱う企業だけのものなのか、それともデータ量が少なくても SQL データベースから切り替える価値はあるのでしょうか。
「NoSQL の概念」とは、さまざまなデータベース テクノロジの幅広い分野を包括する用語であるため、何を意味するのでしょうか。それらが共通しているのは、それらを互いに区別するものだけです。それらは「SQLではない(だけではない)」ということです。それらには、大きく異なる哲学、ユースケース、およびターゲットグループがあります。
概要を説明するために、NoSQL データベースの大部分をいくつか紹介します。
MongoDB や CouchDB などのドキュメント ベースのデータベースがあります。それらの利点は、一貫したデータ構造を必要としないことです。これらは、要件によってデータベースのレイアウトが絶えず変化する場合、または一緒に属していても見た目が非常に異なるデータセットを扱っている場合に役立ちます。「キー」と「値」と呼ばれる 2 つの列を持つテーブルがたくさんある場合は、これらを調べる価値があるかもしれません。
Neo4j や GiraffeDB などのグラフ データベースがあります。彼らの焦点は、他のデータとの関係によってデータを定義することにあります。他の 2 つのテーブルの主キーである主キーを持つテーブルがたくさんある場合 (およびそれらの間の関係を説明するデータがある場合)、これらはあなたにとって何かになるかもしれません。
次に、MemcacheDB、Cassandra、または Google の BigTable などの単純なキーと値のストアがあります。それらは非常に単純化されていますが、それが高速で使いやすいものになっています。ストアド プロシージャ、制約、トリガー、およびこれらすべての高度なデータベース機能を必要とせず、データの高速な保存と取得だけが必要な場合は、それらが最適です。
これらは、新しいデータベースの世界のほんの一部です。
しかし、リレーショナル データベースが優れている分野がまだ 1 つあります。それは、ACID の原則に従う場合です。ほとんどの NoSQL データベースは、次の 4 つすべてを完全には保証していません。
(* 公平を期すために、上記のデータベースのほとんどは、特に冗長なフェールオーバー クラスターとして簡単にセットアップできるものなど、かなり耐久性があります。