従来の業務システムは、Oracleに代表されるRDBMSによる集中的なデータ処理が一般的だ。しかし最近のシステムでは、処理量が増大し、その構成では追いつかない。
集中構成のRDBMSで“きっちり”処理をこなす形から、分散処理で高速に実行し、アプリケーションで“ゆるく”データの正しさを確保する“ゆるハヤ”設計が常識になってきている。
現場の取材で分かった8つのデータベース新常識を解説する。
従来の業務システムは、Oracleに代表されるRDBMSによる集中的なデータ処理が一般的だ。しかし最近のシステムでは、処理量が増大し、その構成では追いつかない。
集中構成のRDBMSで“きっちり”処理をこなす形から、分散処理で高速に実行し、アプリケーションで“ゆるく”データの正しさを確保する“ゆるハヤ”設計が常識になってきている。
現場の取材で分かった8つのデータベース新常識を解説する。
Part4 [運用編]枯れていない技術に対応する
サーバー台数が多いほど、お互いを支え合う集団が大きくなり、動作が安定する。不具合解消でバージョンアップが必要になっても、止めずに対処できる。バックアップの標準手法は未確立。自チームで最適なやり方を見つける。
Part3 [設計・開発編]分散する設計が鍵を握る
新たなDBでは画面と結び付けて設計し、必要なデータを事前準備する。同時アクセスを防ぐロック機能が必要なら、ZooKeeperや自作のロックテーブルの利用を検討しよう。トランザクション処理については、拡張性を犠牲にしない緩いやり方を取る。
Part2 [アーキテクチャー編]分割して並行処理する
処理量が増えてもレスポンスが落ちないDBを構築する方法は、いくつもある。RDBMSでも条件次第では、列指向DBに負けないレベルの速さを実現できる。速さを勝ち取るには、DBにより異なる特性や制約を押さえることが大切だ。
Part1 [単体RDBの限界]遅い、スケールしない
処理量が増大すると、単体RDBMSがシステムのボトルネックになりがちだ。応答性を確保するには、集中型から分散型のDBへの移行が欠かせない。それにより、クラウドのポテンシャルを最大限に引き出せるようになる。