現在、3年ほど本番モードになっているWebアプリケーションがあります。歴史的に、さまざまな理由により、データベースを使用することが決定されました-顧客ごとのインストール。
今、私たちは今、展開が非常に遅いという事実に出くわしました。
環境の複雑さを軽減するために、すべてのデータベースを1つに戻すことを検討する必要がありますか？それとも危険すぎる考えですか？
私が今目にしている問題は、これらのデータベースをマージして参照整合性を保存するのが非常に難しいことです（異なるデータベースのテーブルの主キーを明確に区別することはできません）。
データベースはそれほど大きくないため、複数のデータベースを使用することで負荷を軽減できるというメリットはあまりありません。
移行されたデータの場合...顧客1のデータベースUUIDは10000000で開始でき、顧客2のデータベースUUIDは20000000で開始できます。顧客3のデータベースUUIDは30000000で開始できます。
私の意見では、顧客のデータベースをホストする場合、複数の顧客を処理する単一のデータベースの方が全体的に優れています。もちろん、顧客を記録するための「customers」テーブルと、テーブル内のすべてのトップレベルデータに「customer_id」列を追加し、すべてのSQLにチェックを含めて、顧客のビューが顧客に限定されていることを確認する必要があります。独自のデータ。
追加の列を使用して新しいデータベースをセットアップし、ダミーの顧客または3人でしばらくテストして、すべてのバグが消去されていることを確認します。次に、すべての顧客を1つずつ移行し、データが適合するかどうかを確認します。
あなたの質問はかなり広いです。
a）たとえば、それぞれが小さい場合でも1000個のデータベースがマージされる場合に、マージされたデータベースがJOINステートメントなどのパフォーマンスの低下に悩まされないようにします。参照整合性については...私がauto_increment基づいていると思います...スキーマを変更し、UUIDまたは同様の一意の非順次値を置き換えることで、これらの関係を置き換えることができます。または、自動インクリメントPKに加えて、代理キーペアもあります。
b）ベンチマークを実行して、アプリケーションがパフォーマンス制限内で応答することを確認します
c）これを行うための直接的なROIはありますか？移行の費用に対する長期的な費用便益は何ですか？複雑さの減少は、（もしあれば）コストを増やす価値がありますか？
d）これはバックアップと災害復旧計画にどのように影響しますか？それはそれらを安くしますか？もっとゆっくり？もっと高い？
抽象化および管理ツールのアプローチ：
私の場合、状況に応じて、クライアントごとのシャーディングに伴うスケーラビリティを維持し、1つの仮想データベースを抽象的に作成するための一連の管理ツールを作成します。これらのツールを使用すると、技術的な柔軟性を失うことなく、簡素化された管理を取得できます。（デプロイメントステートメントに基づいて）これらすべてのデータベースを管理するコストを簡素化したいと思います。ファームの「コントロールパネル」を作成することは、複雑なシステムを単純化するための良い方法です（特に、デプロイメントで異なるスキーマバージョンを使用する場合）。