1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

SQL vs NoSQL 何が違っていて、どちらが良いのか???

Last updated at Posted at 2021-06-16

#SQL vs NoSQL: Which one is better to use?

海外のエンジニア系サイトGEEKSFORGEEKSで、上記タイトルの読みやすくて分かり易い記事があったので、適当に翻訳してみるぞ!流し読みしながらの翻訳なので、誤字脱字乱文はご容赦頂きたいぞ!

SQL vs NoSQL
##SQL vs NoSQL: Which one is better to use?

このままで良いのか、いけないのか、それが問題だ!

シェークスピアがこのフレーズを書いたとき、彼はデータベースの事を考えていたいたわけではないだろうが、この問いかけは、今現在多くの会社が直面している、批評的な問題だ。

データベースを決める時、SQLかNoSQLかを決めるのは大きな決断だ。

relational databaseは大抵どういったケースでも実行可能なオプションである一方、大きなデータセットや、ビッグデータの分析には向いていない。

これが、Google、Yahoo、Amazon等の巨大インターネット企業で、NoSQLが人気を得つつある大きな理由だ。
しかしながら、データベースの選択は、単純ではない。

SQL、NoSQL共に違った構造と違ったデータストレージの方法を持っている。

なので、SQLかNoSQLの選択は、個別のプロジェクトの性質によって変わってくる。

###何が違うのか?
SQLとNoSQLは結局同じ目的の為にある。

つまり、データを保存しておくっていう事だ。しかし、そのやり方には大きな違いがある。

SQLとNoSQLには沢山の違いがあり、そこを理解しておくのは、求められるデータベースの選択の際に非常に重要になる。

SQLとNoSQLの以下の重要な違いを心に留めておこう:

###1. Language:
イメージしてみよう。データベースの世界で、皆が言語Xでしゃべっているとする。

で、その中であなたが言語Yで話し始めると、とても困惑するだろう。

これはSQLデータベースのケースに当てはまる。SQLデータベースは、SQL言語を使って、データを操作する。今、もっとも世界で広く使われている言葉だ。

このことは、特に複雑なクエリを扱うときに安全ではある一方、限定的である。なぜなら、あなたがそれを使って、何か構造を変える前に、データ構造決定の為に元々定義されたスキーマを使わないといけないからだ。これはとっても混乱を招く。Y言語を使うようにね。

今一度、複数言語が話されているデータベース世界をイメージしてみよう。

この世界は一見カオティックだ。そして、Y言語を話すことは問題ない。なぜなら、あなたは同じようにそれを話したがる愚か者を見つけることができるんだから。これはまさに整理されていなデータを扱う、ダイナミックなスキーマを持つNoSQLデータベースの世界だ。

ここでは、データは色んな形で保存される。ドキュメント由来、コラム由来、図形ベースなどなど。この自由さは、ドキュメントが決められた形式を持たずに生成され、それぞれがユニークな構造を持つことを可能にしている。

###2. Scalability
あなたの近所にある背の高いビルを想像してほしい。もし、次のオプションが与えられるなら、より多くの新しく来た住人のために、既存のビルに新しいフロアを追加するか、新しいビルをまるまる作ってしまうか、どちらが良いだろう?

これは、まさにSQLとNoSQLデータベースの問題だ。

SQLは垂直的に拡張性がある。これは、シングルサーバーの積載量がRAM, CPUや SSDのようなデバイスによって増加する事を意味する。(新しいフロアを追加するのと同じ)。

一方、NoSQLは水平方向に拡張性がある。これは、より多くのトラフィックを分割したり、データベースにサーバー自体を増やすことによって現実出来る。(新しいビルを増やしていくのと同じ)。

長期的にみると、ビルを縦に伸ばし続けるより、新しい建物を増やしていった方が、持続性がある。(ピサの斜塔みたいにならないようにね!)
つまり、NoSQLは究極的により大きく、よりパワフルになる事が可能で、その事がより巨大で変わり続けていくデータセットに対して、より好まれるチョイスになっている。

###3,Schema Design
スキーマはデータベースの設計図のようなものだ。つまり、どのようにデータを整理するのか。

SQLとNoSQLのスキーマは全く違っている。

これを理解するためのジョークがある。

これは基本的にこういうことだ。哀れなデータベース管理人はNoSQLの中にテーブルを見つけられない。なぜなら、一般的なスキーマの定義がNoSQLデータベースには存在しないからだ。

それらは、 key-valueペアか、ドキュメントベースなのか、図形データベース、もしくは幅広の表がそれぞれのリクエストに応じて保存されている。

一方で、NoSQLデータベース管理人がSQL barに行くと、テーブルベースのスキーマを持つSQLにおいて、確実にテーブルを発見できる。

###4,Community
SQLはすでに成熟したテクノロジーであり、すでに多くの経験値の高いデベロッパーがいる(ちょうど歳を取った賢いおじさんのように)。同時に、全てのSQLデータベースのベンダーからは質の高いサポートが提供されている。また、大規模開発の為のデータベース開発を助ける、多くの独立系コンサルタントもいる。

一方、NoSQLはとても新しいテクノロジーだ(若くて楽しい親戚みたいな存在)。なので、NoSQLデータベースはコミュニティのサポートに頼っている。

また、巨大な規模のNoSQLの構築には限られたエキスパートしかいないのが現状だ。

SQL vs NoSQL

###大きな疑問!!!

NoSQLはSQLに比べて、最近のテクノロジーだ。

なので、特にビッグデータやデータ分析において、多くの疑問や質問が出てくるのは自然の事である。

幾つかのよくある疑問に関してはこちらに書いておこう。

###NoSQL はSQLより速いのか?

一般的に、NoSQL は SQLよりも速いということはなく、その逆も然り。速度に関しては、文脈による。

SQLはデータの重複や複製を防ぐために、データベースは様々な論理テーブルに分割され、正常化されます。このシナリオでは、SQLデータベースは結合、問い合わせ、更新等の作業において、NoSQLよりも速いといえます。

一方で、NoSQLは特に構造化されていないデータ向けにデザインされています。ドキュメント由来、表由来、図形ベース等。この場合、特定のデータは分け隔てなく、一緒に保存されます。なので、ひとまとまりのデータへの読み書きにおいては、 SQLと比べて速いといえます。

###NoSQLはビッグデータの取扱うアプリケーションに向いてるの?

”必要は発明の母”とはよく言われます。で、このことわざはNoSQLによく当てはまります。

ビッグデータを扱うためのNoSQLデータベースはGoogle, Yahoo, Amazon等のIT企業によって、開発が進んでいます。

現行のrelational databasesは増大するデータ処理の要求に対応できていません。

NoSQLデータベースはビッグデータに対応するダイナミックなスキーマを持っており、そのフレキシビリティはその要求にとても大切な要素です。
また、予測分析のための膨大な量の分析データも、NoSQLデータベースに保存可能です。例えば、 Instagram, Twitter, Facebook等のソーシャルメディアのデータがこれにあたります。

NoSQLは水平拡張性があるので、必要であれば、どこまでも大きく、パワフルになれる可能性があります。

これらの特徴が、ビッグデータを扱うアプリケーション開発にとって、NoSQLが選ばれる理由になっています。


オリジナルはこちら↓
https://www.geeksforgeeks.org/sql-vs-nosql-which-one-is-better-to-use/amp/

ご拝読ありがとうございました。

1
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
1
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?