RDBはもちろん、スキーマレスなデータベースでもインデックスは重要

コンピュータ（電子計算機）が出来たばかりの頃は、いわゆる電卓的な用いられ方をしていたため、一時記憶のメモリがあればそれで十分だった。

UNIXが出来上がる頃、1969年になると、経理データや会計データなどの日々蓄積されていくデータを管理するために、IBMにより「データベース」という概念が生まれた。

その頃には磁気テープやフロッピーディスクやハードディスクといった磁気記憶メディアが登場し、巨大なデータの塊を扱えるようになっていた。

この頃のように、100キロバイトオーダのデータを扱うのであれば、Oracleのような数十万円もする大げさなデータ管理システムは必要ない。

その後、銀行システムのようなミッションクリティカルなシステムを作るにあたって、タイムシェアリングにおいて、複数のジョブを見かけ上同時に手続きする機能（トランザクション手続き）が必要になった。

そうなると、OracleやSybaseに代表される高価なミドルウェアとしてのデータ管理システムが必要になってきた。

現在、データベースは、単に業務系システムにおいて、トランザクションを並列手続きするだけでなく、ビッグデータを高速に扱う（統計をとったり、データ解析したりする）ことが重要視されてきている。

データベースには、大きく分けて、スキーマ型とスキーマレス型がある。

RDBMSのようにテーブル設計を事前に決めておく必要のあるタイプが、スキーマ型。

Jsonドキュメントやキーバリューストアでデータを管理し、スキーマを事前定義する必要なしに利用できるのがスキーマレス型である。

スキーマレス型タイプは、知識がなくても簡単に導入でき、利用者数などのスケールをハードウェアに容易に反映させることが可能だ。

スキーマ型タイプは、複雑なデータ構造のビッグデータを高パフォーマンスに検索できる。

それぞれ、使い方によって、メリットがある。

どちらの場合も、テーブル、行、列といった構造スキーマを定義しただけでは、シーケンシャルアクセスするだけであり、10億レコードのデータベースなら、10億回の突き合わせを行うため、効率的なデータ管理はできない。

私には理解できないことであるが、多くのプログラマはインデックスという概念自体を知らない。

インデックスとは、ファイルシステムにおけるiノードと同じように、目指すデータにランダムアクセスするための機構だ。

データベース（テーブル）のスキーマにindex（副キー）を定義することなしには、データベースの大きな機能であるランダムアクセスの恩恵は得られないのである。

それでも、多くのプログラマがインデックスを知らないか無頓着であるのには理由がある。

実は、indexの効果はアプリやシステム開発時に用意する少量のダムデータでは全くその必要性も効果も感じられないのである。

explain sqlコマンドでの実行計画の計測も、ダムデータでは計測できない。

もちろん、主キーだけでランダムアクセスできれば事足りるような簡易データベースはその対象外である。

さらに、MongoDB、FirebaseRD、Cloud Firestore、DynamoDBに代表されるスキーマレスなデータベースであっても、ランダムアクセスによるパフォーマンスを得るには、インデックス定義が必須なのだ。

私の経験上、インデックスを適切に適用した場合とそうでない場合において、十億オーダのデータを検索するために要する時間はこれほど異なる。

swift

・プラットフォーム

Google Cloud Platform Cloud Spanner

・テーブル結合

2

・レコード件数

10億オーダ

・適切でないインデックスでのパフォーマンス性能

数分経過しても結果が得られない

・適切なインデックスを適用したパフォーマンス性能

数秒で結果を得られる

インデックスを定義するということは、検索専用のテーブルを新たにつくるようなものなので、トレードオフとして、クラウドのデータベース容量を消費することになる。

そのため、インデックスの乱用は避ける必要がある。