移行を決断するまでの経緯

移行を決断するまでの経緯

   ところが6,000万件を超える辺りから、インスタンスを増設しても改善されず、以下のような性能劣化が発生しました。

• システム負荷が高い（CPUロードアベレージが常時20以上）
• 定期的に行っていたオンラインVACUUM（注1）が数日かけても終了せず、ディスク容量を圧迫しはじめた

   さらにアプリケーション側からの検索処理は可能でも、蓄積したデータから統計情報を収集する際にSQLの反応が戻ってこない、データの登録処理が遅くなるなどの影響もでていました。

   こうした状況から、データ増加速度に対して今後もPostgreSQLでの運用やスケーラビリティに限界を感じ、他のデータベースへの移行の必要性を痛感していた折、タイミングよく日本オラクルによるOSSデータベースからの移行セミナーが開催されました。

   そこで、大容量のデータを自動的に分割・管理し、性能も維持できる「パーティショニング機能」を知り、「Oracleを採用すればすべての問題がクリアになる」と感じたそうです。

   同社ではすぐに評価版を入手し、さっそく検証を開始しました。そして実際に約500万件のサブセットデータをOracle Databaseにインポートすることで既存データを移行できると判断。またアクセスが集中した状態を想定するため、データベースへの同時書き込みの多重 度を40〜50程度に上げた状態でCPUへの負荷テストを実施し、パフォーマンスを測定したところ問題なく動作することを確認しました（ロードアベレージ は1以下）。

   このテストにより移行前のデータベースサーバ2台、PostgreSQLのインスタンス5つという状態（図1でいう左下のデータベースサーバ2台で稼働）から、サーバ1台でインスタンス1つという理想的な構成での運用が可能と判断したのです。

図2：移行前後のデータベースサーバ構成

   PostgreSQLでの運用開始からたった半年で、データ量が1億件に到達する事が確実となったこともあり、これ以上PostgreSQLでのデータ分割では対処できないと判断しました。

移行方法の決定まで

   Oracle Databaseへの移行を固めつつある頃、別件で弊社とのやり取りがあった関係もあって、筆者は移行作業の技術的なコンサルティングを担当することになりました。

   この時点で作業上の要件は以下のようなものでした。

• PostgreSQL V8.0.3 → Oracle10gR2 (OSはMIRACLE LINUX V4.0 x86-64)
• 移行対象表の最大データ数は1億件以上
• 停止可能期間は仮に最大2日間

   データ件数とシステムの停止可能期間を考えると、かなり難しい作業となることが予想されました。そこで移行を実施する上でまず最初に提案したのは、ハードウェアを新たに準備してもらい、新旧環境の平行稼働が可能な環境を構築することでした。

   これは下記の目的を狙ってのことでした。

   これにより、平行稼働でなければ移行作業そのものが難しい状況をカバーすることとなりました。