No SQL

はじめに

最近職場でNoSQLである「okuyama」というデータベースを使用することになり、 そういえばNoSQLって実際きちんと把握していないなということで勉強がてらまとめることにしました。

NoSQLとは-

NoSQL（一般に "Not only SQL" と解釈される）とは、関係データベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である。 関係データベースを杓子定規に適用してきた長い歴史を打破し、それ以外の構造のデータベースの利用・発展を促進させようとする運動の標語としての意味合いを持つ。

(wikipediaより)

現在主流のOracle Database、Microsoft SQL Server、MySQLはRDBMSですので、これとは異なるものというわけです。

なぜRDBMSと異なるNoSQLができてきたのか

・RDBMSはデータベース内のデータに関係性があり、表形式で格納される （１つのデータを引っ張ってきた際にそのデータに関連するデータも参照することができる）

↓

・関係性があることにより一つのデータの形式を変更するとそれに紐付くデータに関しても変更が必要かどうか確認する必要がある

↓

たくさんのデータと紐付いている場合、メンテナンスが大変！

という流れから多種多様なデータに対応するようなデータベースとして設計されたNoSQLの需要が上がってきたわけです。

たくさんの紐づいたがんじがらめのテーブルではなく簡単に変更が効くのは仕様変更が多い職場などでは重宝されるのではないでしょうか。

RDBMSの弱点

RDBMSがボトルネックになりやすい原因は主に以下の２つになります。

１．データを一元管理し、厳密なトランザクション管理をするためにストレージを共有する構成を取る必要があり、ストレージがシングル・ボトルネックポイントになってしまう。（1台での管理となり、複数台に拡張することができない）

２．SQLの表現力が強力で柔軟であるため、よけいに複雑な処理として実行してしまう。

特に結合やサブクエリといった複雑な処理を大規模なデータに実行することが処理速度の低下を招くことがあります。

RDBMSのパフォーマンスの問題を解決する手段として考えられた方針は、大きく以下の２つです。

１．データモデルを単純化し、複雑なデータ操作を制限する

２．シングル・ボトルネックポイントをなくしてスケールアウト可能にする

昨今ネット人口が増えたり、回線も早くなり膨大なデータを扱う機会も増えてきました。大量データ処理ではCPU内で処理が完結することができれば高速ですが、コストの関係でどうしても複数台でネットワークを介して処理を行うことになりますが、ネットワーク性能はまだまだ時間がかかってしまいます。

最近聞いた話で東京から京都まで大容量のデータを転送する際はネットワーク転送だと時間がかかるため、新幹線で記憶媒体を運んでいるそうです。

（記憶媒体の軽量小型化はネットワーク転送より進んでいるわけですね）

ビッグデータというものが重要視されるようになっている今、分散データベースであるNoSQLはネットワークの遅さ をカバーしています。

NoSQLの種類

NoSQLの分類方法として ・どのような形でデータを持つか（データモデル） ・どのように分散してデータを持つか（アーキテクチャ） があります。 データモデルでは キーバリュー型 カラム志向型 グラフ型 ドキュメント志向型 の4タイプに分けられ、 アーキテクチャでは ・マスタ型 ・P2P型 ・イネーブラ型 　　-オンメモリ -オンディスク の4タイプの組み合わせに分けられます。

Okuyamaについて

自分が使用している「okuyama」はキーバリュー型、マスタ型（マスタ・スレーブ）であるため、以下の特性があります。

　

・key:valueの1:1の関係でデータを格納する（キーバリュー型の特性）

　

・シンプルなため、反応が早い（キーバリュー型の特性）

　

・１つのマスタが複数のノードを管理しており、okuyamaはさらにマスタ障害時のフェイルオーバーも自動的に実施してくれる（マスタ型の特性）

まとめ

NoSQLはRDBMSの不満点を解消するためにできた経緯はありますが、1977年に発表されてから今でも主流で使われているRDBMSの良い点を内包しているわけではありません。

今後はどう共存させていくかが課題になっていくのかなと思います。