そうですね、NoSQL は今流行語になっているので、調べてみました。ColumnFamilies や SuperColumns などについてはまだよくわかっていませんが、データがどのようにマッピングされるかを調べてきました。
読んだあとこれ記事などによると、データは JSON のような形式でマッピングされているようです。
Users = {
1: {
username: "dave",
password: "blahblah",
dateReged: "1/1/1"
},
2: {
username: "etc",
password: "blahblah",
dateReged: "2/1/1",
comment: "this guy has a comment and dave doesns't"
},
}
RDBMS 形式は次のようになります。
Table name: "Users"
id | username | password | dateReged | comment
---+----------+----------+-----------+--------
1 | dave | blahblah | 1/1/1 |
---+----------+----------+-----------+--------
2 | etc | blahblah | 2/1/1 | this guy has a comment and dave doesn't
私がこれを正しく理解していて、上記の例が正しいと仮定すると、なぜ NoSQL 設計ではなく RDBMS 設計を選択するのでしょうか? 個人的には、JSON 構造で作業したいのですが... これは、たとえば MySQL ではなく NoSQL を選択する必要があるという意味でしょうか?
私が尋ねているのは、「RDBMS ではなく NoSQL を選択すべきなのはどのような場合か」ということだと思います。
余談ですが、前にも言ったように、私はまだCassandraデータベースの実装方法を完全に理解していません。つまり、作成する上記の Users テーブルを新しいデータベースに作成しますか? チュートリアルやドキュメントなどがあれば教えていただけると助かります。Google で検索しても、「ゼロから始める」という点では何も出てきません...
ベストアンサー1
Google であれば、RDBMS よりも NoSQL の方が使いやすい立場にいるかもしれません。そうでない場合、RDBMS が提供する多くの利点が役に立つでしょう。重要なのは、単一ノードでは、NoSQL は RDBMS に対してまったく利点がないということです。しかし、RDBMS は NoSQL に対して多くの利点があります。その利点は何でしょうか。
RDBMS は、所有するデータとユーザーが要求するデータを理解するのに、かなり高度な魔法を使っています。そのデータを可能な限り効率的に返せるようにするためです。ある列について要求しなかった場合、RDBMS はそれを取得するのに労力を無駄にしません。2 つのテーブル間で共通のフィールドを持つ行 (これは結合です) に関心がある場合、RDBMS は行のペアごとに一致をチェックする必要はありません。または、NoSQL データベースが通常行うことは、すべてを提供してユーザーがチェックすることです。RDBMS を使用すると、通常、使用しているデータに関するクエリ (「日付が火曜日かどうか」など) を作成できます。インデックスがそれをサポートしている場合 (そのクエリを頻繁に実行する場合は、そのようなインデックスを追加します)、それらの行を効率的に取得できます。
RDBMS が優れている理由は他にもあります。トランザクションは RDBMS では簡単ですが、NoSQL データベースでは正しく実行するのがはるかに困難です。ブログ エンジンを実装しているとします。投稿タイトル (URL に表示される) はすべての投稿で一意である必要があるとします。RDBMS では、誤って間違えることはないと簡単に確信できます。NoSQL データベースでは、何らかのトランザクション整合性をサポートしている場合、通常はシャード レベルでサポートされるため、そのような整合性を必要とする可能性のあるものはすべて同じシャード上になければなりません。任意の 2 人のユーザーが同時に投稿する可能性があるため、同じ効果を得るにはすべてのユーザーの投稿が同じシャード上になければなりません。そうすると、NoSQL のメリットはまったく得られません。