NoSQLの基礎知識を読んだ

はじめに

社内の有志で何か製品を作ってみよう！ということで動いています。そこでNoSQLの話になって、「自分NoSQL触ったこと無いんだよなぁ」と思ったので、その部分の担当に立候補しました。データベースと言ったらリレーショナルデータベースの方しか思い浮かばないレベルですので、入門的な本をカカカカックさんに紹介していただき「NoSQLの基礎知識」を読んでいます。NoSQLの製品名を少し知っているだけの自分だからこそ書けるものかと思うのでまとめメモとして残していきます。

NOSQLの基礎知識 (ビッグデータを活かすデータベース技術)

作者: 本橋信也,河野達也,鶴見利章,太田洋
出版社/メーカー: リックテレコム
発売日: 2012/04/25
メディア: 単行本（ソフトカバー）
購入: 7人クリック: 81回
この商品を含むブログ (7件) を見る

なぜNoSQLが求められるか

ビッグデータの時代にリレーショナルデータベースが対応できなくなってきた背景があるようです。ビッグデータを扱う際に求められることは、3つのVと呼ばれています。「Volume（膨大な量）」「Velocity（速さ）」「Variety（多種多様）」です。

Volume（膨大な量）

膨大な量というのは、一つ一つのサイズが大きいものではなく、小さなデータの集まりのことです。ツイッターで個人が呟いたりするのは微々たるものでも、世界中の人が呟いたらすごい数になります。このような小さなデータが膨大に集まり、大きなデータとなることをビッグデータと呼び、そのビッグデータを扱うことをNoSQLには求められています。

Velocity（速さ）

ビッグデータに対応するためには、素早く処理する必要があります。想像できないほどですが、

「Twitterには日次12テラバイトものデータが発生し、仮に、ハードディスクの書き込み速度が毎秒約80メガバイトのマシンを1台だけ使うとしたら、全てのデータを格納するだけでも約42時間（12TB÷80MB）かかることになる」と書かれています。1台のマシンで処理できることも限られていますので、同時並行して処理する環境が求められたり、高速に処理するソフトウェア技術が求められます。

Variety（多種多様）

ビッグデータは形が決まりきっているデータの集まりとは限りません。データ同士の構造が複雑化しています。それらを均一に揃えて利用していく構造化は困難となっています。そのため、この複雑な構造を持ったデータをそのまま格納し利用していくことがNoSQLには求められています。

まとめると、

ビッグデータへの対応は、「膨大かつ多種多様で激しく変化するデータの塊を、制限なしに保存しつつ、迅速に処理すること」
と書かれています。

NoSQLの種類は100種類以上ある

Oracle
MySQL
PostgreSQL
Microsoft SQL Server
MariaDB
Amazon Aurora この一覧は、AWSのAmazon RDSに載っているものです。非常に一般的な6種類です。それに比べてNoSQLは100種類以上存在しているようです。なぜこんなに多くのNoSQLが存在しているかというと、NoSQLが「Not Only SQL」という、SQLを使うリレーショナルデータベースに限らない技術を使っているものの総称だからです。NoSQLがSQLを使わないものをまとめた言葉だから、結果的に多くなってしまっているんですね。ということでNoSQLは細かく見ていけば、利用シーンを限定的にしたものの集まりです。豊富な機能を備えたリレーショナルデータベースとは違います。そんなNoSQLも大きく分類すると4種類に分類できます。

NoSQLは4つに分類することができる

NoSQLも大きく4つに分類することが出来ます。「キーバリュー型」「カラム思考型」「ドキュメント指向型」「グラフ型」です。 - キーバリュー型 - カラム思考型 - ドキュメント指向型 - グラフ型

細かく見ていきます。

キーバリュー型

キーとバリューを対にしたデータモデル
リレーショナルデータベースよりも処理の負荷が小さい
- 結果的に処理の遅延が発生しにくいので、複数サーバへの分散配置やスケールアウトが簡単にできる知っていた製品名は「Amazon Dynamo」「Redis」です文章中に紹介されていた製品名は「Dynamo」「Voldemort」「Riak」「Hibari」「Redis」「Scalaris」「Tokyo Cabibet/Tyrant」です

yoshitaku-jp.hatenablog.com