LASSIC Media らしくメディア
キーバリューストアとは｜高速な読み書きの型
Webサービスやアプリの裏側では、利用者からのアクセスに素早く応えるために、さまざまな種類のデータベースが使い分けられています。なかでも、決まった読み書きをとにかく速くさばく用途で重宝されてきたのが、キーバリューストア（KVS）です。会員のセッション情報や、画面に何度も出る集計結果を一時的に置いておく、といった場面でよく顔を出します。
ただ、名前は耳にするものの「表形式のデータベースと何が違うのか」「どんなときに選べばよいのか」がつかみにくい、という声も少なくありません。この記事では、発注者やプロジェクトマネージャー、これからシステムの設計に関わる方に向けて、キーバリューストアの仕組みと使いどころ、選ぶ際におさえておきたい点を、かみくだいて整理していきます。
キーバリューストアとは
キーバリューストア（Key-Value Store、KVS）とは、「キー」と呼ばれる目印と、それに結びついた「バリュー（値）」の組み合わせでデータを預かるデータベースの一種です。キーを指定すれば、対応するバリューをまっすぐ取り出せる——この単純明快な仕組みが、いちばんの特徴といえるでしょう。辞書で見出し語を引くと語釈にたどり着くのと同じ発想だ、と考えるとイメージしやすいかもしれません。
身近なたとえでいえば、コインロッカーが近いでしょう。番号（キー）さえ分かれば、その扉の中身（バリュー）をすぐに取り出せます。ほかのロッカーを一つずつ開けて探し回る必要はありません。キーバリューストアも同じで、キーが分かっていれば、大量のデータの中から目当ての一件へ一足飛びにたどり着けるのです。
この割り切った構造のおかげで、キーバリューストアは読み書きの速さを出しやすく、扱うデータが増えてもサーバを足して規模を広げやすい、という性質を備えています。一方で、後述するように「キーが分からないと探しにくい」といった不得手も抱えています。得意な形に用途がはまるかどうかが、採否を分ける勘所といえるでしょう。
この記事のポイント
- キーバリューストアは、キーと値の組でデータを預かり、キー指定で値を直接取り出す仕組みのデータベースです。
- 構造を単純に割り切ることで読み書きが速く、サーバを足して規模を広げやすい反面、複雑な検索や結合は不得手です。
- キャッシュ・セッション管理・ランキングなど、キーが定まる高頻度アクセスに向き、用途の見極めが採否を分けます。
データモデルと基本の操作
キーバリューストアのデータの持ち方は、拍子抜けするほど素直です。中身は「キー」と「バリュー」がひもづいた組の集まりで、それ以上でもそれ以下でもありません。下の図は、その対応関係を表したものになります。
操作もごく限られています。基本は、キーと値を書き込む「PUT（登録・更新）」、キーを指定して値を読み出す「GET（取得）」、キーの組を消す「DELETE（削除）」の三つです。この少なさが、動きの読みやすさと速さにつながっています。表を設計してから使い始めるリレーショナルデータベースと比べると、あらかじめ列を決めておく必要がなく、手軽に書き込み始められる身軽さもあります。
バリューに何を入れるかは、製品によって幅があります。単なる文字列や数値だけを扱うものもあれば、リストやハッシュ（入れ子の項目）、集合といった構造を値として持てるものもあるのです。用途に合わせて、この表現力の幅も選定の材料になってきます。キーの付け方にも工夫の余地があり、「user:1001」「session:a1b2c3」のように種類と識別子を区切って並べる名づけが、運用上よく用いられています。
リレーショナルデータベースとの違い
キーバリューストアの性格は、表形式のリレーショナルデータベース（RDB）と並べてみると、輪郭がはっきりします。両者は優劣ではなく、得意分野が異なる道具だと捉えるのが実際的でしょう。
RDBは、行と列からなる表でデータを管理し、複数の表を結びつける「結合（JOIN）」や、条件を指定した柔軟な検索を得意とします。会計や在庫のように、データ同士の関係が入り組み、整合性をきっちり保ちたい領域で力を発揮するのです。反面、構造がしっかりしているぶん、極端なアクセス量に対して規模を広げる際には、設計上の工夫が要る場面も出てきます。
対するキーバリューストアは、キーを手がかりにした一件ずつの読み書きに的をしぼっています。そのぶん、値の中身をまたいだ複雑な検索や、複数データの結合は不得手です。「条件に合うデータをまとめて探す」といった用途は、そもそも想定の外にあると考えたほうがよいでしょう。下の表に、大まかな違いを整理します。
| 観点 | キーバリューストア | リレーショナルデータベース |
|---|---|---|
| データの持ち方 | キーと値の組 | 行と列からなる表 |
| 得意な操作 | キー指定の読み書き | 結合・条件検索・集計 |
| 検索の柔軟さ | キー中心で限定的 | SQLで柔軟に指定できる |
| 規模の広げやすさ | サーバ追加で広げやすい | 工夫が要る場合があに |
| 向く場面 | 高頻度の単純アクセス | 関係が複雑で整合性重視 |
そのため、実際のシステムでは片方だけを使うとは限りません。基幹のデータはRDBに預けつつ、アクセスが集中する部分だけをキーバリューストアで受け止める、といった組み合わせがよく採られます。適材適所で使い分けるのが、現実的な進め方です。なお、SQL系とNoSQL系の全体像については、別記事「SQLとNoSQLの違い｜使い分けの基準」もあわせてご覧いただくと、位置づけが立体的につかめるでしょう。
代表的な製品と向くユースケース
キーバリューストアと一口にいっても、製品ごとに持ち味は異なります。ここでは、よく名の挙がるものと、それぞれが力を出しやすい場面を見ていきましょう。
| 製品の例 | 特徴と向く場面 |
|---|---|
| Redis | メモリ上でデータを扱い、応答が速い。リストや集合など多様な値を持て、キャッシュやセッション、ランキングの集計に広く使われる |
| Memcached | 機能をキャッシュ用途に絞った軽量な設計。単純な文字列の一時保存を数多くさばく場面に向く |
| Amazon DynamoDB | クラウド上のマネージドサービス。運用の手間を抑えつつ、規模の大きい読み書きに応じやすい |
用途の側から見ると、キーバリューストアが選ばれやすいのは、次のような場面です。いずれも「キーが定まっていて、同じ形の読み書きが数多く発生する」という共通点があります。
一時データの保管（キャッシュ）
データベースへの重い問い合わせの結果や、生成に手間のかかる画面部品を、しばらく手元に置いておく使い方です。二度目からは、元をたどらずキーひとつで取り出せるため、応答が軽くなります。多くのサービスで、まず取り入れられる用途といえるでしょう。
セッション管理
利用者がログインしている状態や、買い物かごの中身など、画面をまたいで引き継ぎたい情報を預ける使い方です。利用者ごとのキーで出し入れするため、キーバリューストアの形にきれいにはまります。複数のサーバで受けるサービスでも、状態を一箇所にまとめておけるのが利点です。
ランキングやカウント
閲覧数の集計や、上位の並べ替えといった処理を素早くこなす用途です。Redisのように順位づけ向けの機能を備えた製品なら、こうした集計を手軽に組み立てられます。刻々と変わる数値を、軽い負荷で更新し続けられる点が向いています。
導入前におさえておきたい点
手軽で速いキーバリューストアですが、任せる範囲を広げすぎると、思わぬところでつまずくこともあります。導入を検討する段階で、次の点を確かめておくとよいでしょう。
データの消えにくさ（永続化）
メモリ上でデータを扱う製品は速い一方で、電源が落ちれば中身が消えかねません。多くの製品はディスクへ書き出す仕組みを備えていますが、その設定しだいで、直近の書き込みが失われうる幅は変わってきます。消えては困るデータを預けるのか、消えても作り直せるキャッシュとして使うのか——扱うデータの重みに応じて、持たせ方を決める必要があります。
整合性の考え方
規模を広げるために複数のサーバへデータを複製する構成では、書き込んだ内容が全体に行き渡るまでにわずかな時間差が生じ、直後に読むと古い値が返ることがあります。この「結果整合性」と呼ばれるふるまいは、多くの場面では気になりませんが、残高のように食い違いが許されないデータには向きません。用途との相性を、あらかじめ見極めておきたいところです。
キー設計とデータ量
キーが分からないと目当てのデータへたどり着きにくいのが、この仕組みの弱点です。だからこそ、あとから引きやすいキーの名づけを、設計の早い段階で整えておくことが効いてきます。あわせて、メモリ上で扱う製品では預けられる総量に上限があるため、古いデータを自動で消す期限（TTL）の設定などで、量をならす工夫も欠かせません。
発注・外注で気をつけること
キーバリューストアの採用は、単体で決められるものではなく、システム全体の構成と切り離せません。外部へ開発を委託する場合も、丸ごと任せきりにするより、要点を押さえて対話できるほうが、望む形に近づきやすくなります。発注の場面で意識しておきたい点を挙げておきましょう。
どのデータをどこに置くかを言葉にする
「速くしたい」という要望だけでは、設計は定まりません。消えては困るデータ、多少古くても差し支えないデータ、一時的で作り直せるデータ——このあたりの区別を発注側でも言葉にできると、キーバリューストアに任せる範囲の線引きがはっきりします。委託先との認識もそろいやすくなるはずです。
運用まで見すえて相談する
導入して終わりではなく、データ量の見張りや、障害時の復旧、設定の見直しといった運用が続きます。作って渡すところまでで区切るのか、公開後の面倒まで含めて頼むのかで、体制の組み方は変わってきます。はじめの相談の段階で、運用まで含めて見通しを共有しておくと、後々の食い違いを避けられるでしょう。
特定製品ありきで縛りすぎない
「Redisで作ってほしい」と製品名から入ることもありますが、本当に解きたいのは、その裏にある性能や運用の課題のはずです。要件を先に整理し、それに見合う製品を一緒に選ぶ進め方のほうが、無理のない構成に落ち着きやすくなります。技術の引き出しを持つ委託先であれば、こうした相談にも応じられます。
まとめ
- キーバリューストアは、キーと値の組でデータを預かり、キー指定で値をまっすぐ取り出す仕組みのデータベースである。
- 構造を単純に割り切ることで読み書きが速く規模も広げやすい反面、複雑な検索や結合は不得手である。
- リレーショナルデータベースとは得意分野が異なり、基幹データと高頻度アクセスで使い分けるのが現実的である。
- Redisやメモリ型・マネージド型など製品ごとに持ち味があり、キャッシュ・セッション・ランキングに向く。
- 永続化や整合性、キー設計を用途に照らして見極め、運用まで含めて委託先と対話することが望ましい。
よくある質問
キーバリューストアとリレーショナルデータベース、どちらを選べばよいですか。
扱うデータの性質で見分けるのがおすすめです。データ同士の関係が入り組み、結合や条件検索、整合性の維持が要るなら、リレーショナルデータベースが向いています。一方で、キーが定まっていて同じ形の読み書きが数多く発生する部分、たとえばキャッシュやセッションには、キーバリューストアがはまります。実際には片方に絞らず、基幹はリレーショナルデータベース、アクセスの集中する箇所はキーバリューストア、と組み合わせる構成もよく採られます。
キーバリューストアに、消えては困るデータを預けても差し支えありませんか。
製品と設定しだいです。メモリ上でデータを扱う製品は速い反面、電源が落ちると中身が消えるおそれがあります。多くはディスクへ書き出す仕組みを備えていますが、その設定によって、直近の書き込みが失われうる幅は変わってきます。残高のように食い違いが許されないデータは、リレーショナルデータベースなど別の仕組みに預け、キーバリューストアは作り直せるデータ中心に使う、といった線引きが手堅い進め方でしょう。
Redisとキーバリューストアは、同じものを指しますか。
厳密には別の言葉です。キーバリューストアは、キーと値の組でデータを扱う仕組みの総称で、Redisはその考え方にもとづく製品の一つにあたります。Redisはリストや集合といった多様な値を扱え、順位づけの機能も備えるため、単純なキーバリューストアより表現力が広いのが持ち味です。ほかにもMemcachedやAmazon DynamoDBなど、性格の異なる製品が複数あります。
導入すれば、システムはどんな場合でも速くなりますか。
用途がかみ合えば効果が出やすい、という言い方が正確です。キーが定まった高頻度の読み書きには向きますが、値の中身をまたいだ複雑な検索や、複数データの結合には不得手です。向かない処理まで任せると、かえって設計が入り組むこともあります。どの部分に使うかを見極めることが、成果を左右します。まずは、アクセスが集中する箇所や、繰り返し取り出す一時データから当てはめて考えるとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
LASSICでは、国内ニアショア開発体制を活かし、データストアの選定やキャッシュ・セッション設計から実装、公開済みシステムの見直しまでを一貫して支援する体制です。要件定義の段階から実装、テスト、リリース後の運用・保守まで、工程を分けずに任せられる点も強みでしょう。アクセス集中への備えやデータストアの構成でお困りの際も、ご相談いただけます。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
