先日、会社のスキルチェックシートを記載していた時のことです。
チェック項目の中に「NoSQLとは何かを理解しているかどうか」という内容がありました。
最初に見た時、「わからない。。。」というのが正直な感想でした。
そこで早速、NoSQLについて調べてみました。
調べていく中で分かったことは、NoSQLはデータベースの分類の名前のひとつであり、RDBMSが苦手とする処理が得意だということです。
今回は「NoSQLとは何かを理解する」ことを目的に、NoSQLの全体像を簡単にまとめておきたいと思います。
結論
NoSQLとは、データベースの分類の名前のひとつです。
言い方を変えるとRDBMSに属さないデータベース管理システムのことを大まかにNoSQLと呼んでいます。
NoSQLに分類されるデータベースは、レスポンスがはやかったり、大量のデータを扱っても性能が劣化にしくかったりといったメリットがあります。
しかし処理性能をアップさせるかわりに、堅牢なトランザクション処理がサポートされていない場合が多いです。
そのためデータの整合性を担保できないなど、苦手な分野もあります。
RDBMSとNoSQLには得意・不得意があるので、それぞれの長所を活かす設計や実装をしてあげるのがポイントです。
NoSQLが注目されている理由とRDBMSの3つの課題
近年、IT文化が急速に発展したことにより、過去に想像もできなかったビックデータを扱うことになりました。
その結果、NoSQLが注目され始めました。
確かにRDBMSでも良かったのですが、より大きなデータを扱う必要が出てきた時、RDBMSだと処理が難しくなってきました。
これを「RDBMSの3つの課題」と呼ぶのですが、それがデータ量の課題(Volume)、速度の課題(Velocity)、多様性の課題(Variety)です。
量の課題(Volume)
最近ビッグデータという言葉を聞くことが増えました。
ご存知の通り、IT技術の進歩により、大量のデータを扱う様になってきています。
RDBMSには、データの整合性を担保するためにトランザクション機能があります。
RDBMSで大量のデータを保持して処理するためには、たくさんのサーバーにデータを分散させて処理する必要が出てきます。
しかし、多くのサーバーにデータを分散させると、データの整合性を担保するためのトランザクションを正確に動かすのが難しくなってしまいます。
これがデータ量の課題です。
NoSQLでは整合性の管理をあえてしないことで、大量のデータを扱えるようになっています。
速度の課題(Velocity)
ここでいう速度とは、「頻繁に生み出される大量のデータを、リアルタイムで保存したり、参照したりする速度」のことです。
SNSでのテキストメッセージや動画データなど、たくさんのデータがリアルタイムで膨大に生み出されています。
RDBMSでは、データの整合性を維持するためのトランザクションを動かしたり、SQLの解析のための時間が必要だったりするため、オーバーヘッドが発生します。
あまりに頻繁に生み出される大量のデータをリアルタイムで保存したり、参照するといったデータ処理をRDBMSで行うと、オーバーヘッドが無視できなくなっていきます。
これが速度の課題です。
NoSQLでは堅牢なトランザクションをサポートしないことで、高い処理性能を実現しています。
多様性の課題(Variety)
ここで言う多様性とは、様々な構造・大きさのデータを表しています。例えば、ログファイル・画像・音声・センサーのデータ・メール・プレゼン資料など、様々な形式・大きさのファイルのことです。
これらのデータは、RDBMSのように表形式で事前にデータ型を定義する仕組みとは相性が良くないところがあります。
NoSQLではデータ型の定義などは必要ありません。
RDBMSとNoSQLの違い
RDBMSとNoSQLの主な違いについて、表にまとめてみました。
RDBMS | NoSQL | |
---|---|---|
SQLの使用 | SQLを使用する | SQLを使用しない |
データの定義 | どんなデータを入れるのか事前に決めておく必要がある | データ型の定義が必要ないので、意図していたものとは異なるものも扱える |
データの関連性 | データ同士の関連性を表現できる | データ同士の関連性は表現できない |
データの一貫性 | トランザクションの仕組みがサポートされており、ACID特性がある | 堅牢なトランザクションはサポートしていないものが多い |
読み書き | 速くない | 速い |
検索 | テーブルを結合して、複雑な条件の検索が可能 | 条件を指定した検索には不向きだが、シンプルな検索はレスポンスが速い |
拡張性 | 拡張するには技術力が必要かつ、コストがかかる | シンプルなデータ構造であるため拡張が簡単 |
スケールアウト | データの一貫性を保つため、データを分散させるのが困難な場合がある | データを分散させることが簡単 |
データの保存 | 大量のデータを保存するのには向いていない | 大量のデータを保存するのに向いている |
性能劣化 | データが肥大化して、性能が劣化しやすい | DB性能が劣化しにくい |
RDBMSを使用した方が良いパターン
RDBMSはデータの整合性を担保する必要がある場合に使用されます。
考えられるのはECサイトでのデータ管理です。
例えば本を販売するサイトがあったとします。
残り1冊しかない本があったとして、その本の購入ボタンを2人の人が同時にクリックしたとします。
このときに、どちらの人も購入できてしまったら、まずいですよね。
同時に購入ボタンをクリックされても、どちらも本が買えてしまうことが起こらないようにする必要があります。
こういった場合にはRDBMSを使用する必要があります。
NoSQLを使用した方が良いパターン
NoSQLの特徴は、大量のデータを保持するのに向いているところです。
例えば、取っておきたいけど、普段は利用しないデータなどを保存しておきたいときにNoSQLが便利です。
ログデータ・画像・動画・メールなどをストックしておくときなどに、利用されます。
NoSQLの種類
NoSQLにはいくつかの種類があります。今回は3つの種類を紹介します。おまけでグラフ型についても、取り上げます。グラフ型はNoSQLに分類されないこともあるようです。
キーバリュー型
キー(鍵)とバリュー(値)のペアというシンプルな構造でデータを表します。
大体NoSQLと言うと、このキーバリュー型を指すことが多いみたいです。
シンプルな構造なので、大量のデータを簡単に管理できますし、高速にアクセスできます。
バリューは、ほどんどデータ型などに縛られないので、動画や音声などのメディアデータも扱えます。
例えば、Keyに県の名前、Valueに県庁所在地を入れるなどが考えられます。
ワイドカラム型
キーバリュー型を拡張したもので、1つのキーに対して、複数の列を持つことができます。
ちなみに行ごとに異なる数の列を持つこともできます。
列方向の集約が高速であるため、ログデータの解析、集計処理にも適しています。
例えば、お店で扱っている商品の「品名」「値段」「生産者」などの項目を管理するなどに使われます。各商品の合計金額などを出そうと思ったら、即集計できます。
ドキュメント指向型
こちらもキーバリュー型を拡張したもので、テーブル定義などせずに、バリュー部分にJSONやXMLなどのデータを格納できます。
ドキュメントを使って詳細なデータをを表現できるのが特徴です。
また一般公開されているWebサービスやAPIサービスと連携しやすいといったメリットがあります。
例えば、会員ごとの「名前」「メールアドレス」「誕生日」などといった情報を、ドキュメント形式で保存するといった使用方法があります。
グラフ型
データ間の関係をグラフ構造で表現して、データ間の関連を高速に検索できる特徴があります。
人同士、物同士、場所同士などの相関関係を表現する際に、グラフ構造を利用します。
例えばカーナビの最短経路検索とかは、このグラフ型データベースを使用していることが多いようです。
データ間の関連性が強いため、複数台のサーバーにデータを分散してしまうと、機能させるのが難しくなります。
まとめ
NoSQLとは、データベースの分類の名前のひとつです。
レスポンスがはやかったり、大量のデータを扱っても性能が劣化にしくかったりといったメリットがあります。
一方で処理性能をアップさせるかわりに、堅牢なトランザクション処理がサポートされていない場合が多く、データの整合性を担保できないなどのデメリットもあります。
RDBMSとNoSQLにはそれぞれ得意・不得意があるので、それぞれの長所を活かす設計や実装をしてあげるのがポイントです。