データ量の爆増とDBと検索エンジン

これから本格的なWOT,IOT時代の幕開けに向けて、データの爆増が考えられます。
そこで、データをどう格納するかについて考えてみたいと思います。

最近、MySQLでは話にならないので、検索エンジンに変えたとの記事をよく目にします。

ワタシは個人的にはDBはあまり変更がないマスターデータを格納すべきで、コンテンツのメインとなるデータは検索エンジンに格納すべきだと考えています。

DBはトランザクションを使用して、きっちりinsert,update,deleteを行うために使用します。
しかし、データが膨大になるとデータを取得するためにものすごい時間がかかります。

よく、DBを張り付かせたら負けとのインフラエンジニアの話しを耳にしますが、
やはり、DBに膨大なデータを格納するのは最もやってはいけないアンチパターンです。
特に、複雑なSQL文が見られる場合は、そのプロジェクトはいずれ性能問題とシステム障害に直面します。

ファイルシステム上ではファイルを複数のプログラムで共有できない、データ管理が煩雑になるためにDBが開発されました。
DBはトランザクション制御を行って、同時アクセスを処理してくれます。

しかし、DBはデータが増えてくると同時に様々な問題の原因となります。

まず、メモリに乗り切らないデータにより、ディスクへのアクセスが発生して、パフォーマンスのボトルネックになり得ます。

コネクションが増えすぎるとDBサーバーへのアクセスがエラーになります。 コネクションプーリングを増やしすぎると今度はDBの処理に使えるメモリの量が少なくなります。

そこで、アクセスを分散させたり、データを分割します。

シャーディング

データを分割して、複数のサーバに分散させる機能

レプリケーション

あるデータベースとまったく同じ内容の複製(レプリカ)を別のコンピュータ上に作成し、
常に内容を同期させる機能
※マスター・スレーブ構成
※スレーブがポーリングを行ってマスターと同期を取ります

メモリキャッシュ(Memcached or Redis)

メモリ上にキャッシュを保持します

上記3つを組み合わせます。

まず、DBを動作させるのはメモリキャッシュ(キャッシュ専用サーバーが必要)がない場合にします。
メモリキャッシュがない場合に初めてアクセスはDBに到達します。
また、レプリケーションにより複数のDBサーバーにアクセスが分散されます。
そして、データはシャーディングされているため、素早くレスポンスを返すことができます。

しかし、これはあくまでカッチリした検索をするときだけです。

実際のデータは長文が多く、その中から該当するデータを取得する必要が出てきます。
ここで全文検索エンジンが必要になってきます。

DBのデータをjsonとして抽出して検索エンジンに食べさせます。

そして、データ取得の際には検索エンジンにリクエストを飛ばします。

転置インデックスとは - はてなキーワード

もちろん、キャッシュが存在しない場合です。

Googleの検索の仕組みを見ていただけるといいのですが、
絶え間なく書籍が増え続けている図書館のようなものにします。 クロールとインデックス – 検索サービス – Google

f:id:keiwt:20150228201303j:plain

こうしておけば後にデータを解析したいとなったときの時短効果はかなりの時間になります。

第1回 大規模データではRDBMSのどこがボトルネックになるのか?:RDBMSでも大規模データをあきらめないためには|gihyo.jp … 技術評論社