1

すべてのクエリ/テーブルなどを調整する前に、Webサイトで公開する前に（すでに6か月遅れているため、これは理想的なシナリオではありませんが）、公開する必要があるように見えます。 -そういうことです）。

今では弾丸を噛まなければならない場合です。それは、私たちが「それを噛む」ことになると、その弾丸がどれほど大きくなるかを理解しようとする単なる事例です。データベースがライブになると、ライブデータであるため、気まぐれでデータを変更することはできません。私はほとんどのdbスキーマにかなり自信を持っています。たとえば、テーブルはほとんどの3番目と4番目の正規形であり、データの整合性を確保するために制約が使用されます。私はまた、いくつかの列にいくつかのインデックスを入れましたが、これは非常に急いで行われ、テストされていませんが、クエリで頻繁に使用されます-これは私が心配しているビットです。

明確にするために、私は卸売り構造の変更について話しているのではありません。テーブル自体が変更される可能性はほとんどありませんが（個人的に、または誰かを雇うことによって）、ある段階でテーブルを調整する必要があることはほぼ確実です。

これがどれだけの仕事か知りたいです。具体的には、数ギガバイトのデータベース（これまでのところ約300テーブル）を想定しています。

今後数か月以内にテーブルの50％を調整する必要があると仮定します。

  1. チューニングの実行にはどのくらい時間がかかりますか（これは「弦の一部の長さ」タイプの質問です）-しかし、必要な作業の主な決定要因は何ですか？したがって、どのくらいの時間がかかる可能性があるかを計算できます取った？

  2. インデックスの再作成中にデータベースのセクション（または特定のテーブル）をロックすることは可能ですか、それともデータベース全体をオフラインにする必要がありますか？（私はデータベースとしてmySQL 5.xを使用しています）

  3. 私が説明すること（すべてのテーブルが完全に調整される前にライブになる）は、法外に危険/望ましくありませんか？（これまでのところ、これが私を引き起こした眠れない夜の数ヶ月を正当化するのでしょうか）？

4

4 に答える 4

2

一般に、既存のレコードを処理する必要があるため、稼働後にパフォーマンスの問題を引き起こしている不十分なデータベース設計を修正することははるかに困難です。さらに悪いことに、少数ではなく多くのレコードがある場合、ライブになってから数か月後まで、貧弱なデザインが明らかにならない可能性があります。これが、データベースをパフォーマンスを念頭に置いて設計する必要がある理由です（これは時期尚早の最適化ではありません。一般に他の手法よりも優れたパフォーマンスを発揮する既知の手法があり、設計で考慮する必要があります）。データベースは、次のような一連のテストレコードに対してテストする必要があります。数年後に得られるであろう記録の予想レベルに近いか、それを上回っています。

不適切に設計されたデータベースを完全に修正するのにかかる時間については、数か月または数年です。多くの場合、最悪の部分は設計の中心となるもの（EAVテーブルなど）であり、ほとんどすべてのクエリ/sp/ビューが必要になります。より良い構造に移行するために調整されるUDF。次に、すべてのレコードが新しいより適切な構造に移動されていることを確認する必要があります。このような間違いを早めに修正する方がよいでしょう。1億よりも、数千のレコードを新しい構造に移動する方がはるかに優れています。

構造は問題ないがクエリが悪い場合は、パフォーマンスが最も悪い上位10件（実行の合計時間だけでなく、実行時間Xに基づいて選択）を取得し、修正、すすぎ、繰り返しを行うことができます。

貧弱なデータベースを修正している最中なら、この本が役に立つかもしれません：

http://www.amazon.com/Refactoring-Databases-Evolutionary-Database-Design/dp/0321293533/ref=sr_1_1?ie=UTF8&s=books&qid=1268158669&sr=8-1

于 2010-03-09T18:19:06.653 に答える
1

少なくとも、アプリケーションから生成されたアクティビティがいつそのしきい値に近づいているかがわかるように、稼働する前にデータベースの制限を定量化しようとします。

アプリケーションからデータベースの一般的な使用法を（可能な限り自動的に）シミュレートし、データベースが機能しなくなる前に、データベースが処理できる同時ユーザー/セッション/トランザクションなどの数を確認することをお勧めします。これにより、少なくとも「眠れない夜」の問題を解決できるはずです。

原作は「どれくらい簡単…？」質問、答えは明らかに多くの要因に依存します。ただし、少なくともデータベースを微調整する必要があるかどうかを判断できるので、上記の分析は間違いなく役立ちます。

于 2010-03-09T17:48:12.853 に答える
1

タイトルの質問に答えるには、本番環境にデプロイした後、DBを調整するのはかなり簡単だと思います。

任意の環境にデプロイした後、パフォーマンスを向上させることをお勧めします。プロダクションであることは、スケジュールとともに、少しプレッシャーを加えます。Prodにデプロイして、期待どおりに実行することをお勧めします。次に、測定を開始します。

  • さまざまな時間にレポートXを実行する時間（アプリにそのような概念がある場合は、ピーク時と営業時間外）。
  • これらの重要なユースケースでアプリを使用するときのユーザーエクスペリエンスはどのようなものですか？

次に、Prod環境のバックアップを取り、Prod以前の環境を作成します。そこで、アップグレードスクリプトを実行して、「どのくらいの時間」タイプの質問があるかを測定できるようになります。インデックスの作成、アップグレードのダウンタイムなど。クエリなどを調整するときは、本番データとボリュームでどのように機能するかを理解できます。確かに、これらのユーザーが同時にこれらの挿入を実行するという利点はありません。

そのバックアップを複数回の反復、失敗したアップグレード、新しい/準備ができていない問題などのために保持します。

DBの次の改善ラウンドをテストできるように、各展開後にバックアップを作成し続けます。

于 2010-03-09T18:47:50.683 に答える
1

  1. 何をチューニングしているかによります。いくつかのテーブルにインデックスを追加したり、テーブルタイプをMyISAMからInnoDBなどに変更したりして、十分な大きさのテーブルを使用すると、ハードウェアに応じて5〜10分でこれらの処理を実行できるとします。何時間もかかりません。とはいえ、深夜にライブデータベースのチューニングを行うのが最善です。

  2. 電話をかけることで読み取りロックを取得できますFLUSH TABLES WITH READ LOCKが、安全のために、アプリに「メンテナンスを行っています」というメッセージを15〜30分間表示することをお勧めします。

  3. リスクは状況に固有のものであり、深刻な問題が発生した場合はどうなりますか。私は通常、よりカウボーイのアプローチを取り、物事をライブで行います。特に、負荷が高くない場合は、問題点を簡単に見つけて修正できるようにします。これがミッションクリティカルなシステムである場合は、いいえ、負荷テストなど、できる限り準備ができていることを確認するために最初にできることは何でもかまいません。また、発生するすべての問題を予測できるわけではないことに注意してください。インデックスが適切であれば、おそらくそれを公開して、何に取り組む必要があるかを確認することができます。

于 2010-03-09T18:49:49.853 に答える