🐋

SQLを勉強した時のメモ1

2023/10/29に公開

SQL

NoSQL

tech

最初に

プログラミングを始めて間もない方、フロントエンドしかやったことない方、あるいは文系のみなさんはデータベースという単語を聞くと漠然と嫌な感覚を覚えるのではないかと思います。今回は自分がデータベースを勉強する過程で理解に役立ったデータベースのイメージや解釈などをメモ書き程度のイメージで皆さんに共有したいと思います。

今回扱う内容

今回扱うテーマはデータベースの全体像とプログラミングで最も使用される以下の2つのデータベースについて言及します。

データベース(概論)
リレーショナルデータベース
NoSQLデータベース
SQL
NoSQL

対象者

プログラミング始めた手でこれからデータベースを学ぼうとしている人
フロントエンド開発でSupabaseなどを使ってみたがいまいちわからない人
データベースという単語に負けて勉強するのをためらっている人

データベース(概論)

データベースはデータを入れておく箱だといわれるのは結構皆さん知っているんじゃないでしょうか。じゃあもう一段階深く聞いてみましょう。どんな箱だと思いますか？と聞かれればおそらくあなたは答えることができないでしょう。まあイメージ像に明確な正解なんてないんですが、一番近いイメージは地図です。

https://news.livedoor.com/article/detail/6158985/　より引用

計算機科学で機械語、アセンブリ言語について勉強した方はイメージをつかみやすいと思いますが、コンピュータがデータを扱う際はレジスタ(内容を記憶する装置)とメモリ(データ保管する所)に対して機械語という16進数の数字を使った言葉で命令をします。
(厳密にはこのような流れでプログラムを実行します)

ここで機械語に翻訳する前段階のアセンブリ言語表記でデータを保存する例を見せます

assembly

STORE R1, FF ;

このコードではレジスタ１のデータをメモリのFF番地に保存するという操作を行っています。番地を強調している理由は皆さんお分かりだと思います。そうです、これがぼくがデータベースを地図だと考える本質です。

以上の点を踏まえてまとめると、
データベースは巨大な地図で大規模開発であれば世界地図くらい大きくなります。データ一つひとつは住所(番地)の場所に居住しています。もちろんデータが別の住所(別の番地)に引っ越すことも可能です。そうするとデータベースを管理するプラットフォームで新しい地図が作られます

ここまでデータベースの全体像について簡単に説明していきました。次以降の章では具体的なデータベースの種類について、今回は特にもっとも使用される2つのデータベースについて言及していきます。

SQL vs NoSQL

この記事ではもっとも使用されるリレーショナルデータベースとNoSQLデータベースについてのみ解説しています。
最初に情報を整理しておくと、データベースにはデータモデルという概念があり

リレーショナルデータベース(RDBMS)

まず最初にリレーショナルデータベースについて解説します。このデータモデルはSQL(=Structured Query Language)というクエリ言語をサポートしておりこれを用いてデータを格納・運用します。

リレーショナルデータベースを理解するうえでもっとも想像しやすいイメージが高層ビルです。

ビル内には会社の様々なテナントや部署が入っています。一階にはエントランスと客室、二階には経理部、三階には総務部…といった風にビル内のカテゴリを定めていきます。ここでいうデータは人です。経理の田中さんは50歳で無能社員だとしたら、おそらく二階の窓際の席にいるはずです。そしておそらく彼のつるんでいる総務の佐藤さんも無能社員だろうから佐藤は三階の窓際でしょう、といったように一つ一つのデータを階層化(構造化)して格納します。これによりデータの位置をドンピシャで指定することができるので処理が軽量になりランタイムを抑えることができます。

効果を発揮する場面

リレーショナルデータベースを使うメリットとしてはデータでテーブル内が複雑になってしまうときやユーザのインタラクションをデータとして残したいときなどに構造化によって全体の容量を軽減しデータを引き出しやすくする(検索回数を減らす)ことができます。逆にデメリットとしていろいろなデータの種類を入れたいときすぐに階層が積みあがってしまい(垂直スケーリング)処理が重くなってしまうため向いていません。

リレーショナルデータベースを提供するSQL

以下の技術はリレーショナルデータベースを提供するのにもちいられます

SQLite: 小規模開発などに用いられるRDBMS。軽量でシンプルでDjangoなどにデフォルトで搭載
MySQL: SQLのスタンダードなRDBMS。高性能で大規模にも行ける the 王道って感じ
PostgreSQL: 大規模開発に向いたRDBMS。通称ポスグレ。SupabaseなどのBaaSでも搭載されてる
MariaDB: MySQLとの互換性がある新しい目のRDBMS。大規模で高性能だがメジャーではない

以上をまとめるとRDBMSの特徴は、

データが構造化されている(高度なクエリ最適化)
SQLをもちいてデータを保管・運用する
データの強い整合性・関連性
多すぎるデータの種類に弱い
垂直スケーリング

NoSQLデータベース

次にNoSQLデータベースについて解説します。といってもNoSQLデータベースとはかなり概念として広い言い方でNoSQLデータベースの中でもいろいろなデータベースを分類わけすることができます。

ドキュメントストア
カラム指向データベース
キーバリューストア
時間系列データベース
グラフデータベース
などいろいろタイプが存在しますが、NoSQLの方式は完全に適応されるので今回はNoSQLという大きい枠にのみ言及しますが興味がある方は自分で調べてみてください。

リレーショナルデータベースが高層ビルだというたとえに対していうと、NoSQLデータベースは地球です。

ここでは地球と高層ビルの物理的な大きさは考えないでください。

NoSQLデータベースは事前にスキーマ(データ型)を定義する必要がなく、いろいろな種類のデータを格納することができます。またデータが構造化されていないため一つひとつのデータに識別番号を持たせて格納したり(キーバリューストア)、データを列(カラム)単位で管理する(カラム指向データベース)など自由度が上がりいろいろなクエリを叩くことができます。

先ほど紹介したNoSQLが地球という例を見ていきましょう。ここで地球は一つの巨大なデータベースでこのなかにはアフリカ、ヨーロッパ、日本、アメリカなどの様々なコレクションがありそれぞれ人(データ)はコレクション内(国内)で一位の識別子object_idを持ちます。データベース内(地球)には様々な種類の人種(データ型の違うデータ)が存在し事前にスキーマ(人種)を定義する必要はありません。データベース(地球)が誕生したときからデータ(人間、動物)の種類が増えるとデータはほかの新しいコレクションを作ります。このときカテゴリはリレーショナルデータベースと違い同じ土地上ではなく異なる土地にできるので日にならないほどのデータを格納することができます(水平スケーリング)。

といった感じでNoSQLをとらえると理解しやすいと思います。次にもう少し原理的にNoSQLを解説していきます。

RDBMS(行指向) vs カラム指向(列指向)

先ほどは解説しましたがリレーショナルデータベースはビルのように一行ずつ積み上げていくような仕組みになっていて、これをロウ指向(行指向)といいます。一方でカラム指向は先ほどの通り列単位でデータを管理できます。一見仕組みの違いがなさそうだと思うでしょうが決定的に違います。カラム指向の場合新しい列(カラム)を作りたい場合横に付け足していくので先ほどの地球という例を考えればはるかに作れる量が多いです(一応テーブル形式なので列の考え方もある)。対してリレーショナルデータベースは一行ずつ積み上げていく場合に高度が上がりすぎて酸素が薄くなってくる(処理が重くなる)段階でこれ以上増やすことが難しくなるという弱点があります。カラム指向データベースの技術としてBig Queryがあり機械学習やビッグデータ解析などHOTなテーマで活躍します。

ドキュメントストア

ドキュメントストアはNoSQLの典型的なデータモデルの一つでJSON形式でデータを格納します。これによりデータの柔軟性が向上しより大量のデータを保管できます。ユーザ情報などの単純な情報を記録するのに用いられることが多く最近のトレンドワードであるビッグデータなどに多く活用されます。代表的な技術としてMongoDBがあります。

またフロントエンドエンジニアの方やモバイルエンジニアの方はいつもお世話になっているBaaSであるFirebaseのデータベースであるFirestoreもドキュメント指向を適応しているデータベースなので覚えておいたらいいことあるかも？

キーバリューストア

こちらは一つのデータに対してキー(固有番号)を振りクエリで呼び出したときにそのデータの持つ値(value)を返すように設計されたデータベース指向です。で固有番号を用いてデータを直接呼び出すので高速に欲しいデータまでアクセスできます。キャッシュというデータの保存方法に最適でデータ自体はシンプルなものを採用することが多いです。代表的な技術としてRedisがあります。

NoSQLのデメリット

先ほどまでリレーショナルデータベースとの比較をしてきてさも「NoSQLが最強か」のように勘違いしてしまう人がでると残念なので今からNoSQLのデメリットについて解説します(あとから出てきた概念なので優秀なのは当然です)。名前からわかるようにNoSQLデータの構造化に強くないクエリ言語です。ゆえにデータ間のトランザクションや複雑な結合に対して処理を実行することがかなり難しいです。またスキーマを事前に定義していないので当然クエリを最適化するのは超絶に大変です。ゆえにデータ一つひとつの解析が重要な場合はSQLのほうがはるかに正確な処理を効率的に実装できます。

以上を踏まえてNoSQLの特徴をまとめると

大規模なデータ管理に向いている
水平スケーリング
データ一つに対して高速にアクセスできる
データ一つひとつが重要な時は実装しずらい
多様なデータを受け入れることができる
事前のスキーマ定義が不要
キャッシュに向いている

終わりに(余談)

今回はデータベースについて全くわからない人が理解できるようになるための一番簡単な部分を記事にしてみました。おそらくこの程度の知識があればハッカソンでもデータベースについて困ることはないと思います。余談ですが、noteなどでも記事を書いているんですがやっぱりぼくは書くのが下手くそだなと痛感しました。頭の中にあるイメージを言語化しようと思うと情報が正しい順序で取り出せなくてそれを記事に正確に落とし込んでいくって難しすぎますね！ブロガーとかライターとかまじですごいわって日々感じてます。今回は僕の備忘録的な部分も兼ねているのでまあこんなもんでしょって思ってます笑。これからもできるだけ冗長にならないように気を付けていきたいなと思いました。
最後ですが僕のXのアカウント良ければフォローしてください。さいなら