現在取り組んでいる OTLP プロジェクトで Db のパフォーマンスの問題が発生しています。別の開発者と私は、これまで蓄積してきたパフォーマンスに関する知識が限界に達したため、アプリケーションの高速化を支援してくれるチームに参加してくれる人を探しています。
背景として、データの一部を非正規化するためにスキーマを変更し、すべてのクエリを最適化し、複数のデータベース チューニング アドバイザーを実行してインデックスを適切に取得し、MSSql のサーバー オプションをチューニングしました。
参加が遅くなる可能性があることやデッドロックとは何かを教えてくれる人は必要ありません。上記のすべての手順を実行した後に何をすべきかを知っている人が必要です。
OLTP DBA を雇って共有するためのヒントや経験をお持ちの方はいますか? 面接プロセス中に DBA にどのような質問をすることができますか?
現在のチームよりも多くのことを知っている人が必要であることはわかっていますが、次のステップが何であるかがわからないため、どのような質問をすればよいかわかりません. それは理にかなっていますか？
わかりました、これは私に何かを教えてくれます：
背景として、データの一部を非正規化するためにスキーマを変更し、すべてのクエリを最適化し、複数のデータベース チューニング アドバイザーを実行してインデックスを適切に取得し、MSSql のサーバー オプションをチューニングしました。
あなたは、DBA と自称する 90% の人々ができることと同じか、それを超えています。
問題は、多くの DBA が実際にはプログラマーではなく、システム管理側にいるということです。TSQL が得意なだけでなく、他のプログラミング言語も熟知している DBA プログラマーが必要です。
私はこのようなデータベース チューニングの問題に多くの時間を費やしていますが、その解決策には、フロント エンドからデータベース スキーマに至るまでの大幅な再設計が含まれることがよくあります。これらの問題を単独で解決することはできず、アーキテクチャ全体を完全に制御 (および完全に理解) しなければ、必要なパフォーマンスを得ることはできません。
あなたはその仕事に最適な人物かもしれません。OLTP のパフォーマンスの問題に集中できるように、忙しい仕事を片付けてくれる人を雇う方が賢明かもしれません。
独自の最適化の前に DB を少しデチューンして、DB に渡します。行った変更と比較して、パフォーマンスが向上するように調整できるかどうかを確認します。
なぜその技術を選んだのか尋ねてください。
参考文献を取り上げて、それらが由来する環境のうち、自分の環境と最も一致する可能性が高いものを見つけてください。
Guru DBA を雇うことになり、彼にデータベースのパフォーマンスを大幅に改善させても、アーキテクチャに根ざしたアプリケーションの問題が残る可能性があります。
いくつかのアイデア:
最適化した最も複雑なクエリを QA 付きの候補 DBA に渡して、再度最適化してもらいます。何をどのように行ったかを説明してもらいます。
複数のファイル グループ、RAID アレイ、データ パーティション、64 ビットと 32 ビットのパフォーマンスなどを使用する場合は、この担当者がハードウェアを理解していることを確認してください。
ソフトウェア アーキテクチャのバックグラウンドを持っている人を探してください。
たとえば、いくつかの難しい SQL サーバーの質問をしてください。OVERステートメントとは何ですか? GUID は適切な主キーですか? int ID が望ましいのはなぜですか?
優れた DBA は、面接で次にどのようなステップを踏むかを大まかに説明することができます。問題の解決策ではなく、ここでの思考プロセスにもっと注意を払う必要があります。DBA がいくつかの解決策を示したら、戻ってクイズを行い、なぜその方法で問題を解決する必要があるのかを尋ねます。
この方法は、いわば男性と男の子を非常に迅速に区別します。
データベースの最大パフォーマンスにどれくらい近づいていますか? このテクノロジでは解決できない OLTP 問題を作成するのは非常に簡単です。エリックが言ったように、全体的なアーキテクチャの再設計が必要かもしれません。RAMを増やして、RAMを追加するだけです:)
確かに、データベースを見なければ、最適化の最善の方法を判断するのは困難です。これまでに行ったことを考えると、おそらく、データベース設計者を雇う必要があります。データベース設計者は、使用している規模の範囲でデータベースを設計および調整した経験を持つ人物です。問題にどのようにアプローチするかを尋ねる際に、インタビュアーがパフォーマンスの低いクエリを最初に調べ、プロファイラーを実行して何が起こっているかを確認し、それらを特定するかどうかを確認します。その人は、パラメーターのスニッフィングとそれを回避する方法、カーソルを回避するために使用できる方法、統計を更新する必要がある理由、クエリをサレガブルにするものについての特定の質問に答えることができる必要があります。パフォーマンス チューニングでよく見られることがいくつかあります。ネットワークが使い果たされていないか (データベースではない場合もあります)、全体的な設計が十分に考えられていないか、一般的にパフォーマンスが悪い SQL コードを使用していますか? たとえば、すべての検索で最初の文字としてワイルドカードを使用できる場合、それらを高速にすることさえできません。結合が複数列の自然キーにある場合、本来よりも遅くなります。1 つのフィールドに複数の情報を格納していて、データを取り戻すために多くの操作を行っていませんか? カーソルを使用していますか？関数を使用していますか？再利用すべきときにコードを再利用していますか? でしょうか？常に必要最小限の情報を返していますか? 接続を閉じていますか？デッドロックが発生していますか? 表の行が広すぎませんか? 特定のテーブルにレコードが多すぎませんか (古いレコードを削除するか、アーカイブ データベースに入れると、大きな違いが生じる可能性があります)。セット指向ではなく、行指向のコードはどれくらいありますか? これらは、経験豊富なデータベース担当者が見ている種類の例であり、インタビューで話すべき種類のものです。
いくつかの悪いコードの例 (既に最適化したものを知っている) から、彼らがどのようにチューニングするかについての良いアイデアを得ることができます。整然とした、SQL の深い知識を持っている人が必要です。
パフォーマンス チューニングに関する優れた本がいくつかあります。面接を受ける前に、それらを入手してよく理解することをお勧めします。