本記事は、新人SE向けに NoSQL の種類や使われ方を説明するための、自分用の備忘録としてまとめたものです。
NoSQL という言葉はよく聞きますが、実際の開発現場では「RDB の代わりに何となく使うもの」というより、特定の用途に合わせて選ぶデータストアとして扱われることが多いです。
ここでは、筆者がこれまで触れる機会のあった範囲を中心に、Web アプリケーション開発で見かけやすい NoSQL の種類と、採用時に注意したい点を整理します。
厳密な分類や製品ごとの差分までは踏み込みません。
まずは「どの種類が、どのような場面で使われるのか」を大づかみに理解することを目的にしています。
1. NoSQL とは
NoSQL は、一般的にはリレーショナルデータベース（RDB）以外のデータベースを指す言葉として使われます。
ただし、NoSQL はひとつの製品やひとつの仕組みを指す言葉ではありません。
キーバリュー型、ドキュメント指向、検索エンジン、カラム指向、グラフ型など、さまざまな種類があります。
そのため、NoSQL を理解する際は、
- RDB と何が違うのか
- どのようなデータ構造を得意としているのか
- どのような用途で採用されるのか
- 逆に、何が苦手なのか
を種類ごとに見ていくと分かりやすいです。
本記事では、Web アプリケーション開発で特に目にしやすいものとして、次の3つを取り上げます。
- キーバリュー型データベース（KVS）
- ドキュメント指向データベース
- 検索エンジン
2. キーバリュー型データベース（KVS）
参考: DB-Engines Key-value Stores
https://db-engines.com/en/article/Key-value+Stores
キーバリュー型データベース（KVS）は、キーと値の組でデータを扱うデータベースです。
名前の通り、基本的な考え方はとてもシンプルです。
- キーを指定してデータを登録する
- キーを指定してデータを取得する
- キーを指定してデータを更新・削除する
- 必要に応じて TTL（Time To Live）を設定する
TTL は、データの有効期限を設定する機能です。
期限を過ぎたデータは自動的に削除されるため、一時的なデータを扱う用途と相性がよいです。
KVS の大きな特徴は、構造がシンプルな分、軽量かつ高速に扱いやすいことです。
RDB のような複雑な検索や結合は得意ではありませんが、キーが分かっているデータを高速に取得したい場面では非常に有効です。
代表的な製品としては、Redis などがあります。
2.1 セッション管理
KVS の代表的な用途のひとつが、Web アプリケーションのセッション管理です。
従来、セッション情報はアプリケーションサーバのメモリ上で管理されてきました。
しかし、アプリケーションサーバを複数台構成にすると、アクセス先のサーバが変わったときにセッション情報を参照できなくなる場合があります。
たとえば、ユーザーがログインしたあと、次のリクエストが別のサーバに振り分けられると、「ログインしていたはずなのに未ログイン扱いになる」といった問題が起こり得ます。
そこで、セッション情報を KVS に外部化します。
各アプリケーションサーバが同じ KVS を参照するようにすれば、どのサーバにアクセスしても同じセッション情報を扱えます。
また、TTL を使うことで、一定時間操作のないセッションを自動的に破棄できます。
この点でも、KVS はセッション管理と相性がよいです。
2.2 DB キャッシュ
もうひとつの代表的な用途が、DB キャッシュです。
RDB への問い合わせ結果や、生成に時間がかかるデータを KVS に一時的に保存しておき、次回以降は KVS から取得する構成です。
RDB に毎回複雑なクエリを投げるよりも、KVS からキャッシュ済みデータを取得する方が高速で、RDB 側の負荷も軽くできます。
なお、キャッシュはあくまで一時的なデータであるため、元データが更新されたときにキャッシュをどう更新するか、古いデータが残っても問題ないか、といった点は設計時に考える必要があります。
KVS では、TTL を使って一定時間が経過したキャッシュを自動的に破棄できます。
3. ドキュメント指向データベース
参考: DB-Engines Document Stores
https://db-engines.com/en/article/Document+Stores
ドキュメント指向データベースは、JSON のような構造を持つドキュメント単位でデータを保存するデータベースです。
KVS と同じようにキーを指定してデータを取得できますが、KVS との大きな違いは、保存されたデータの中身に対して検索できる点です。
たとえば、次のような JSON データがあったとします。
{
"id": "user-001",
"name": "Yamada",
"address": {
"prefecture": "Tokyo",
"city": "Shibuya"
}
}
ドキュメント指向データベースでは、単に user-001 というキーで取得するだけでなく、address.prefecture が Tokyo のデータを検索する、といった使い方ができます。
RDB との違いは、厳密な表構造を前提にしない、いわゆるスキーマレスな点です。
テーブル、行、列という形にきっちり分解するのではなく、ある程度自由な構造のデータを、そのままドキュメントとして保存できます。
代表的な製品としては、MongoDB などがあります。
3.1 階層構造を持つデータの保存と検索
ドキュメント指向データベースは、階層的な構造を持つデータを扱いたい場合に向いています。
RDB では、階層の深いデータや項目の揺れが大きいデータを扱う場合、複数のテーブルに分割したり、関連テーブルを増やしたりする必要があります。
もちろん RDB でも設計は可能ですが、データ構造によってはテーブル設計が複雑になりやすいです。
一方、ドキュメント指向データベースでは、元の JSON に近い形で保存できます。
そのため、外部 API から取得した JSON データや、項目構造が変わりやすいデータを扱う場面で採用されることがあります。
スキーマレスではありますが、登録するデータの構造が把握できなくなると、検索や保守が難しくなります。
そのため実務では、登録するドキュメントのデータ構造をある程度しっかり設計しておくことが多いです。
3.2 JSON データの永続化ストアとしての利用
ドキュメント指向データベースは、JSON データの永続化ストアとして使われることがあります。
外部システムから受け取った JSON データや、アプリケーション内部で生成した JSON データを、そのまま保存しておきたい場合、単純にファイルとしてファイルサーバに置くこともできます。
また、キーを指定して保存・取得するだけであれば、KVS に保存することも考えられます。
しかし、バックアップ、レプリケーション、キャッシュ、アクセス制御など、データベースとしての管理機能や運用機能を使いたい場合は、ドキュメント指向データベースが選択肢になります。
つまり、JSON データを単なるファイルとして保存するのではなく、データベースとして管理・運用しやすい永続化データとして扱いたい場合に、ドキュメント指向データベースが選ばれることがあります。
4. 検索エンジン
参考: DB-Engines Search Engines
https://db-engines.com/en/article/Search+Engines
検索エンジンは、登録されたデータに対する検索機能に特化したソフトウェアです。
データを保存して検索できるため、広い意味では NoSQL の一種として扱われることがあります。
ただし、一般的な DBMS のように何でもこなすというより、高速で高度な検索を行うための仕組みと考えた方が分かりやすいです。
代表的な製品としては、Elasticsearch や Apache Solr などがあります。
検索エンジンでは、登録されたテキストをどのように分割し、どのようなインデックスを作るかが重要になります。
RDB の LIKE 検索では難しいような、大量データに対する高速な全文検索や絞り込み検索を得意とします。
4.1 全文検索
全文検索は、文章全体を対象にして、キーワードに一致する文書を探す機能です。
検索エンジンは、登録されたテキストを単語やトークンに分解し、検索しやすい形のインデックスを作成します。
これにより、大量の文書に対して高速な検索を行えます。
また、製品や設定によっては、次のような検索も実現できます。
- 類義語を考慮した検索
- 表記ゆれを吸収した検索
- 入力ミスをある程度許容するあいまい検索
- 関連度の高い順に並べるスコアリング
たとえば、ニュース記事、社内マニュアル、論文、商品説明文など、大量のテキストから目的の情報を探す機能で使われます。
4.2 ファセット検索
ファセット検索は、検索結果に対して、項目ごとの件数や内訳を同時に取得する機能です。
EC サイトで「スニーカー」と検索したときに、
- ブランドA: 50件
- ブランドB: 30件
- 1万円未満: 20件
- 1万円以上2万円未満: 40件
のような絞り込み条件が表示されることがあります。
このように、検索結果を見せるだけでなく、ユーザーがさらに絞り込みやすい情報を同時に返す用途で使われます。
RDB でも集計はできますが、検索と集計を高速に組み合わせたい場合、検索エンジンが有効な選択肢になります。
5. まず何から押さえるべきか
新人SEが Web アプリケーション開発を前提に NoSQL を学ぶなら、まずは KVS、特に Redis から押さえるのがおすすめです。
理由は、セッション管理やキャッシュなど、Web アプリケーションの現場で利用される場面が多いためです。
クラウド環境や複数台構成のアプリケーションでは、状態や一時データをアプリケーションサーバの外に出す設計がよく出てきます。
そのとき、Redis のような KVS の考え方を知っていると、構成の意図を理解しやすくなります。
一方で、ドキュメント指向データベースや検索エンジンは、プロジェクトの要件によって使われ方が大きく変わります。
独学の段階では、まずは主要な種類の特徴を広く浅く押さえておけば十分だと思います。
6. NoSQL を検討するときに大事なこと
NoSQL を実際のシステム設計で検討する場合、必ず考えたいことがあります。
それは、次の2つです。
- それは RDB ではなく NoSQL である必要があるか
- その NoSQL はシステムの必須要件を満たせるか
6.1 それは RDB ではなく NoSQL である必要があるか
RDB で問題なく実現できることを、わざわざ NoSQL で行う必要はありません。
MySQL や PostgreSQL などの RDB は、今でも多くの業務システムで中心的に使われています。
複雑な条件での検索、トランザクション、運用ツール、エコシステムの充実度などを考えると、RDB が適している場面は非常に多いです。
また、近年の RDB は JSON データを扱う機能を備えていることもあります。
クラウドのマネージドサービスを利用すれば、可用性やスケールの面でも扱いやすくなっています。
そのため、「NoSQL が流行っているから使う」のではなく、まずは RDB で十分ではないかを考えることが大切です。
NoSQL は RDB の完全な上位互換ではありません。
用途に合えば強力ですが、合わない場面で使うと、設計や運用がかえって難しくなります。
6.2 その NoSQL は必須要件を満たせるか
NoSQL を採用する場合、システムが絶対に必要とする要件を満たせるかを事前に確認する必要があります。
特に、次の点は注意が必要です。
- トランザクション
- JOIN のような複雑なデータ結合
- 複数台構成にしたときの機能制限
NoSQL は、パフォーマンスや分散処理を優先する代わりに、RDB ほど強力なトランザクション機能を持たないことがあります。
決済、在庫管理、会計処理など、厳密なデータ整合性が必要な処理では、RDB を中心に考えた方がよい場面が多いです。
また、RDB のように複数のテーブルを柔軟に JOIN して取得することは、NoSQL では苦手な場合があります。
JSONに対応しているとされる製品でも、RDBのJSON機能とは仕様や挙動が大きく異なる場合があります。
そもそも JOIN の考え方がない製品も多いため、データ取得時に複雑な結合が必要かどうかは事前に確認しておくべきです。
さらに、本番環境のように複数台のサーバで動かす構成にしたときに、開発環境のような1台だけで動かす構成では使えていた機能に制限がかかるケースもあります。
そのため、開発環境では動いていたのに、本番相当の構成では同じように動かない、ということが起こり得ます。
NoSQL を採用する場合は、できるだけ早い段階で本番に近い構成を用意し、必要な機能が本当に使えるかを検証することが重要です。
6.3 検索エンジンを使う場合の注意点（補足）
検索エンジンを導入する場合は、特に注意が必要だと考えています。
検索エンジンを安易にDBMSとして扱うと、他のDBとは異なるデータの保持方法や扱い方、システム管理上の最適化の違いにより、大きくつまずくことがあります。
また、マスターデータとの関係をしっかり検討する必要があります。
検索エンジンは、投入されたデータをもとに検索用のインデックスを作成し、そのインデックスに対して高速な検索を行う仕組みです。
そのため、Elasticsearch などを業務データの正式な保存先として扱うよりも、RDB などのマスターデータを別に持ち、そこから検索用データを同期する構成にすることが多いです。
また、検索エンジンに投入するデータを増やしすぎると、ストレージ使用量、インデックス作成時間、更新処理、検索性能などに影響することがあります。
そのため、検索に必要な項目は何か、検索結果として返す必要がある項目は何かを整理し、検索エンジン側に持たせるデータを設計しておくことが重要です。
RDB などのマスターデータから検索用データを同期する構成では、必ず同期のタイムラグが発生します。
つまり、RDB 側のデータを更新しても、検索結果に反映されるまで少し遅れる可能性があります。
さらに開発が進むと、要求の追加によって、RDB 側のデータから検索用データを作るための加工処理が複雑になり、同期のタイムラグが大きくなることもあります。
そのため、採用する検索エンジンの仕様や特性を十分に理解したうえで、
- 更新直後に検索結果へ反映されなくても問題ないか
- 同期に失敗した場合にどう復旧するか
- 検索用データをどう再作成するか
- 検索エンジン側にどの項目を持たせるか
といった点を設計しておく必要があります。
まとめ
NoSQL は、RDB 以外のデータベースを広く指す言葉です。
ただし、ひと口に NoSQL といっても、種類によって得意なことは大きく異なります。
本記事では、代表的なものとして次の3つを整理しました。
- キーバリュー型データベース（KVS）
- ドキュメント指向データベース
- 検索エンジン
KVS は、セッション管理やキャッシュのような一時データの高速な読み書きに向いています。
ドキュメント指向データベースは、JSON のような構造化された文書データを、データベースとして保存・管理・検索する用途に向いています。
検索エンジンは、大量のテキストに対する全文検索や絞り込み検索を得意とします。
一方で、NoSQL は RDB の代わりに何でも解決してくれるものではありません。
トランザクション、複雑な検索、JOIN、運用のしやすさなどを考えると、RDB を選ぶべき場面も多くあります。
新人SEの学習としては、まず RDB を基本として押さえたうえで、NoSQL は「特定の課題を解決するための選択肢」として見るのがよいと思います。
そのうえで、Web アプリケーション開発でよく出てくる Redis などの KVS から触れていくと、実務の構成も理解しやすくなるはずです。
なお、Redis にも、1台構成では使えても、複数台構成にすると使い方に制限が出る機能があります。
Redis を学ぶ際は、基本的な操作だけでなく、本番運用で使われる構成ではどの機能に制限があるのかもあわせて調べてみるとよいと思います。