はじめに
ログ分析システムを構築するにあたり、ログを格納するDBは何にすればいいのかについて考える機会がありました。
この時、慣れているからという理由だけで行指向型DB(MySQL)を採用するのは非常に危険な考え方です。
もし深く考えずに安直な選択をした場合、DBのレコード数が増えて来た頃に1クエリ毎に1分近くも処理時間を待たなければならないという未来を迎えることでしょう。そしてそうなった時には後戻りが出来なくなってしまうのです。
今回はそうならないためにもNoSQLとSQL(行・列指向型DB)の3つを比較しながら、技術選定の観点をかんたんにまとめてみました。
行指向型DB
行指向型DBとはMySQLやPostgreSQLなどの最も一般的なDBです。
行単位でレコードを読み書きします。
メリット
- 少ないレコードへの読み込み・書き込みが速い
- 検索しやすい
デメリット
- レコードが多いほど読み込み(ディスクシーク)が遅くなる
HDDとアクセス速度
忘れがちですが、HDDに保存されたデータへのアクセスは結構遅いです。
レコードを読み取るということは、すなわち円盤の上のアームが回転して保存された磁気データを探しているということです。
つまりレコードが増えるほど回転量が増えて処理時間も長くなります。
列指向型DB
列単位でレコードを読み取る。列方向はデータ形式が同じで、同値が多いので圧縮保存される。BigQueryなどが代表的。
メリット
- 大量レコードでも読み込みが速い
- 検索しやすい
※列方向に圧縮して保存するので、HDDのデータシークの観点からレコードが増えても読み込み速度が速い
※クエリは行指向と変わらないので検索しやすい
デメリット
- 書き込みが遅い
※一行であろうと更新する際には、圧縮されたDBを展開してから更新して再度圧縮を行うため時間が掛かる
NoSQL
NoSQLはキーバリュー型やドキュメント型など種類が多くあります。
※ここではAWSのDynamoDBなどで代表的なキーバリュー型を想定しています。
メリット
- 読み込み・書き込みが速い
- 拡張性が高い
※インデックスキーを登録出来るので該当キーでの読み込みが速いです
※キーバリュー形式で様々なデータを格納出来る
インデックス
インデックスとは本で言う索引のようなもです。
インデックスのロジックはDB毎に様々ですが、ここでは二分探索木をイメージしています。
例えば1,000行のレコードがあるとして、1000番目のレコードを探索する際に頭から順番に検索するのではなく、1~500行目はここ、501行目~1000行目まではここという風にグルーピングされていればより速く検索することが出来ます。
細かい説明は割愛します。
デメリット
- 検索しにくい
- 設計が難しい
※RDBMSの様な複雑な検索は出来ません。また登録出来るインデックスキーの数に限りがある。
※どのキーで検索・ソートするのかなど、あらかじめ決めるべき項目が多いため設計が難しい
まとめ
各DBの説明は以上です。どのDBを採用するかは、レコード数や検索性、用途や予算などを整理した上で、各データベースの長所と短所を比較しながら選定することになるかと思います。
以上です。