(O+P)ut

OutPut Log by SE in SIer



(O+P)ut

Output Log by SE

レスポンスタイムに着目したNoSQLの登場背景

スポンサーリンク

NoSQLとはなんぞや

NoSQLとはNot only SQLということで、いわゆるRDBMS以外のDBMSを指す用語です。

例えば一例ですが、ドキュメント指向型NoSQLに分類されるMongoDBでは以下コマンドでデータにアクセスができます。

> db.XXX.find()
{ "_id" : "XXXX", "msg" : "test"}

非定型型のデータがあっても扱えたり、従来のMySQL等よりもとっつきやすいNoSQLですが、そもそもの登場背景について簡単に説明してみました。

データベースへのアクセスを高速化したい

数々の書物を読みましたが、NoSQLが登場した背景はここにつきると思っています。

というのも、従来のRDBMSはSQL文に対して結果を返しますが、そのSQL処理は以下のように細分化されています。

  • SQL構文解析
  • DBテーブルのオープン/ロック
  • SQL実行計画作成
  • レコードの取得
  • DBテーブルのアンロック/クローズ

ちなみに実行計画作成とはSQL文を実行する上での最適化のようなものです。

発行するSQLが逐一異なっている場合はSQL構文の解析やSQL実行計画作成が大いに役立ち、トランザクションとして一貫性を担保したい場合はDBテーブルのロック/アンロックは必要です。

一方で主キーだけの検索やトランザクション管理が不要である場合は先ほどのステップを以下にすることができます。

  • レコードの取得


シンプル。

要は、複雑なロジックを簡略化し、用意されたAPIにて直接データにアクセスをする仕組みがNoSQLです。

逆に言えばRDBMSが血眼になって保っているデータの一貫性保持が犠牲になっています。

もちろん、全てを諦めているわけではなくて下記の画像は分かりやすい一例です。
f:id:mtiit:20190730205754j:plain
https://www.atmarkit.co.jp/ait/articles/1106/23/news117_2.html より画像を抜粋

要するに

単純なアクセスパターンはSQLのようにがちがちにしなくてもよいのでは?といった思想と思っています。

もちろん非構造化データを扱うことができる点等の魅力もあるのですが、高いパフォーマンスが実現できるという一点を求めた設計に着目して説明してみました。

以上、ご参考になれば幸いです。


他の記事を読む