(O+P)ut

アウトプット



(O+P)ut

Output Log

【入門】レスポンスタイムに着目した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実行計画作成が大いに役立ち、トランザクションとして一貫性を担保したい場合はDBテーブルのロック/アンロックは必要です。

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

  • レコードの取得

一気にシンプルになりましたが、これがNoSQLのイメージです。

要は複雑なロジックを簡略化し、用意されたAPIにて直接データにアクセスをする仕組みがNoSQLです。
逆に言えばRDBMSが血眼になって保っているデータの一貫性保持が犠牲になっています。

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

実際、銀行の取引トランザクションでは採用しづらいですがIoTのセンサのように毎秒データをレコードに保持する等であれば一部のデータが欠損しても許容できます。

要するに

単純なアクセスパターンはSQLのようにがちがちにしなくてもよいのでは?といった思想と思っています。
もちろん非構造化データを扱うことができる柔軟性も魅力ではありますが、高いパフォーマンスが実現できるという一点を求めた設計に着目して説明してみました。

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


他の記事を読む