 |
||||||||||
|
||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||
|
||||||||||
| 移行を決断するまでの経緯 | ||||||||||
|
ところが6,000万件を超える辺りから、インスタンスを増設しても改善されず、以下のような性能劣化が発生しました。
表1：発生した問題点
※注1：
VACUUMについては、連載「徹底比較!! Oracle & PostgreSQL 第３回：アーキテクチャ比較 ファイル構造の違い」を参照 http://www.thinkit.co.jp/cert/compare/1/3/3.htm さらにアプリケーション側からの検索処理は可能でも、蓄積したデータから統計情報を収集する際にSQLの反応が戻ってこない、データの登録処理が遅くなるなどの影響もでていました。 こうした状況から、データ増加速度に対して今後もPostgreSQLでの運用やスケーラビリティに限界を感じ、他のデータベースへの移行の必要性を痛感していた折、タイミングよく日本オラクルによるOSSデータベースからの移行セミナーが開催されました。 そこで、大容量のデータを自動的に分割・管理し、性能も維持できる「パーティショニング機能」を知り、「Oracleを採用すればすべての問題がクリアになる」と感じたそうです。 同社ではすぐに評価版を入手し、さっそく検証を開始しました。そして実際に約500万件のサブセットデータをOracle Databaseにインポートすることで既存データを移行できると判断。またアクセスが集中した状態を想定するため、データベースへの同時書き込みの多重度を40〜50程度に上げた状態でCPUへの負荷テストを実施し、パフォーマンスを測定したところ問題なく動作することを確認しました（ロードアベレージは1以下）。 このテストにより移行前のデータベースサーバ2台、PostgreSQLのインスタンス5つという状態（図1でいう左下のデータベースサーバ2台で稼働）から、サーバ1台でインスタンス1つという理想的な構成での運用が可能と判断したのです。  図2：移行前後のデータベースサーバ構成 PostgreSQLでの運用開始からたった半年で、データ量が1億件に到達する事が確実となったこともあり、これ以上PostgreSQLでのデータ分割では対処できないと判断しました。 |
||||||||||
| 移行方法の決定まで | ||||||||||
|
Oracle Databaseへの移行を固めつつある頃、別件で弊社とのやり取りがあった関係もあって、筆者は移行作業の技術的なコンサルティングを担当することになりました。 この時点で作業上の要件は以下のようなものでした。
表2：移行作業の要件 データ件数とシステムの停止可能期間を考えると、かなり難しい作業となることが予想されました。そこで移行を実施する上でまず最初に提案したのは、ハードウェアを新たに準備してもらい、新旧環境の平行稼働が可能な環境を構築することでした。 これは下記の目的を狙ってのことでした。
目的：バックアップ採取、復元のリスクを排除
なぜかというと、もし何かトラブルが発生した場合はPostgreSQL環境へ速やかに戻し、継続して稼働できることが必須の条件と考えたためです。そして結果的には下記にあげる副次的な効果をもたらしました。
副次的効果：平行稼働可能な環境を構築することで柔軟な移行スケジュールをたてられる
これにより、平行稼働でなければ移行作業そのものが難しい状況をカバーすることとなりました。 |
||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||
|
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
|
||||||||||
|
|
||||||||||
-
-
連載
