遅いのはコードではなく、テーブル設計かもしれない

画面の表示に何秒もかかる。夜間バッチが朝までに終わらない。サーバーを増やしても改善しない——そういうとき、原因がアプリケーションではなくデータの持ち方にあることは珍しくありません。

正規化されていない、索引が効いていない、増え続ける履歴が同じ表に溜まっている。作った当初は問題が無くても、件数が二桁増えれば設計の粗は必ず表に出ます。

私たちはまず実行計画を見ます。推測でチューニングしても当たりません。どのクエリが何を舐めているかを数字で押さえたうえで、直す順番を決めます。

止めずに移すまでの道のり
  1. db migrate --zero-stop-plan
  2. [1/5] 実測 実行計画を見る ✓
  3. [2/5] 設計 索引と構造を直す ✓
  4. [3/5] 予行 手順を一度通す ✓
  5. [4/5] 移行 停止時間を詰める ✓
  6. [5/5] 監視 傾向を見て手を入れる ✓
  7. ✓ 数字で押さえてから、直す順番を決めます
データの持ち方を決める軸
  1. db model --axis freq,volume
  2. # 縦軸: 更新の頻度 / 横軸: データ量
  3. - 単純な台帳 更新多め・量は少なめ ✓
  4. - 設計が効く 更新も量も多い ✓
  5. - 参照中心 更新少なめ・量も少なめ ✓
  6. - 分析用に分離 更新少なめ・量は多い ✓
  7. ✓ 読み書きの比率から、持ち方を選びます

止めずに移す。設計から移行手順まで

データベースの移行は、設計より段取りが難しい仕事です。オンプレミスからクラウドへ、あるいは古いバージョンからの脱却。いずれも「いつ止めるか」「戻せるか」を先に決めておかないと、当日に判断できません。

私たちは移行手順を書いてから移します。差分同期で停止時間を詰める方法、切り戻しの条件、データの整合をどう検証するか。システムマイグレーションと同じ考え方で、リハーサルを含めて設計します。

移行先はAWS・Google Cloud・Azureのマネージドサービスが中心。運用の手離れが良く、バックアップと冗長化を自前で組む必要がありません。PostgreSQL・MySQL・SQL Server・Oracle に対応します。

ご提供する内容

実行計画の分析

遅いクエリを実測で特定します。推測から始めると、たいてい外します。

索引とテーブル設計の見直し

索引は多ければ良いものではありません。書き込みとの釣り合いで決めます。

正規化と非正規化の判断

教科書どおりが最速とは限らない。読み書きの比率から選びます。

データ量増加への備え

履歴の分割や保管方針を先に決めておく。後から効いてきます。

移行手順の設計とリハーサル

本番の前に一度通す。想定外は必ずここで出ます。

停止時間の最小化

差分同期で切り替えの窓を詰めます。止められない業務には必須。

整合性の検証

移した後に件数と値を突き合わせます。移せたことと正しいことは別です。

移行後の監視と保守

負荷の傾向を見て手を入れ続けます。保守運用へ続きます。

データベース設計・移行のご提供内容
  1. db service --list
  2. [1/8] 実行計画の分析 遅い箇所を実測する ✓
  3. [2/8] 索引とテーブル設計 書き込みとの釣り合い ✓
  4. [3/8] 正規化と非正規化の判断 読み書きの比率から ✓
  5. [4/8] データ量増加への備え 履歴の分割と保管 ✓
  6. [5/8] 移行手順とリハーサル 本番の前に一度通す ✓
  7. [6/8] 停止時間の最小化 差分同期で窓を詰める ✓
  8. [7/8] 整合性の検証 件数と値を突き合わせ ✓
  9. [8/8] 移行後の監視と保守 負荷の傾向を見る ✓
  10. ✓ 移せたことと正しいことを、両方確かめます

MODEL CASE 費用のモデルケース

製造業 遅くなったデータベースの性能改善
価格の目安: 50万〜300万円
EC事業者 データベースの設計見直しとインデックスの改善
価格の目安: 50万〜300万円
医療法人 古いデータベースのバージョンアップ
価格の目安: 50万〜300万円
事業会社 オンプレミスからクラウドへのデータベース移行
価格の目安: 300万〜1,000万円
物流業 複数システムのデータベース統合と移行
価格の目安: 300万〜1,000万円

実在の案件ではなく、よくあるご依頼をもとにした想定例です。価格は当社の目安で、範囲や要件により変わります。領域ごとの目安は費用の考え方をご覧ください。

FAQ よくある質問
Q 表示が遅いのですが原因はデータベースですか?
A 調べてみないと分かりません。まず実行計画を確認し、どのクエリが何を読んでいるかを実測します。推測でチューニングしても当たらないため、測ることから始めます。
Q サーバーを増やせば解決しますか?
A 設計に原因がある場合は解決しません。索引が効いていない、履歴が同じ表に溜まり続けているといった構造の問題は、台数を増やしても改善しない性質のものです。
Q 索引を追加すれば速くなりますか?
A 読み取りは速くなりますが、書き込みは遅くなります。索引は多ければ良いものではないため、読み書きの比率を見て必要なものだけを足します。
Q どのデータベースに対応していますか?
A PostgreSQL・MySQL・SQL Server・Oracle が中心です。クラウドのマネージドサービスにも対応し、移行先としてのご提案も行います。
Q オンプレミスからクラウドへ移行できますか?
A できます。AWS・Google Cloud・Azure のマネージドサービスが移行先の中心です。運用の手離れが良く、バックアップや冗長化を自前で組む必要がなくなります。
Q システムを止めずに移行できますか?
A 差分同期を使えば停止時間を大幅に詰められます。完全に無停止にできるかは構成によるため、どこまで詰められるかを事前にお伝えします。
Q 移行に失敗した場合は戻せますか?
A 戻せる条件を事前に決めておきます。切り戻しの判断基準と手順を移行計画に含め、リハーサルで実際に通してから本番に臨みます。
Q 移行したデータが正しいかどうか確認できますか?
A 確認します。件数と値を突き合わせる検証を移行手順に組み込みます。移せたことと正しく移せたことは別なので、ここは省きません。
Q 費用はどのように決まりますか?
A 対象のデータ量と、移行先の構成、停止できる時間の長さで変わります。まず現状を調査し、範囲を確定してからお見積りします。
Q 調査だけの依頼もできますか?
A 承ります。実行計画の分析と設計の評価だけを行い、改善案をお渡しするご依頼も可能です。その結果を見てから実装を判断いただけます。
Q バージョンアップのみの相談も可能ですか?
A 可能です。サポート期限切れへの対応は多いご相談です。互換性の確認とリハーサルを含めて計画します。
Q データ量が増え続けているのですが対策はありますか?
A 履歴の分割や保管方針の見直しが有効です。増える前提で設計しておくと、後から効いてきます。分析用のデータを分離する構成もご提案します。
Q 期間はどのくらいかかりますか?
A 調査だけであれば数週間、移行を含めると数か月規模が目安です。停止できる時間の制約が厳しいほど、準備に時間をかける必要があります。
Q 既存の開発会社がいる状態でも依頼できますか?
A 可能です。データベースの部分だけを分担するご依頼も承っています。役割の切り分けを最初に決めてから進めます。
Q バックアップと復旧の設計もお願いできますか?
A お請けします。取るだけでなく、実際に戻せるかを確認するところまで設計します。復旧手順を試していないバックアップは、あるとは言えません。
Q 個人情報を含むデータの移行も対応できますか?
A 対応します。当社はISO/IEC 27001とプライバシーマークの運用下で情報を扱います。移行作業時のアクセス範囲と記録の取り扱いも設計に含めます。
Q 移行後の監視もお願いできますか?
A お請けします。負荷の傾向を見て手を入れ続けることが、性能を保つうえで有効です。保守運用まで一貫してご支援します。
Q 設計書が残っていないのですが依頼できますか?
A 可能です。現状のスキーマとクエリから構造を読み解くところから始めます。ドキュメントの整備もあわせてご依頼いただけます。
Q どのくらい速くなりますか?
A 実測してからでないと申し上げられません。原因の特定ができれば改善幅の見込みはお伝えできますので、まず調査からご相談ください。
Q まず何を伝えればよいですか?
A どの画面や処理が遅いか、いつから遅いかを教えてください。データ量の増え方が分かればさらに絞り込めます。資料の準備は不要です。

ご発注は請負・準委任・労働者派遣・ラボ型のいずれにも対応しています。
費用の考え方 | 開発の流れ | 契約形態の選び方 | 対応技術 | 対応パッケージ・ツール

開発会社・SIer の方はこちらのご案内もご覧ください。

OTHER SERVICE その他のWebシステム開発サービス一覧

TECH BLOG テックブログ