PostgreSQLの診断方法-ウラジミールボロディンとイルダスクルバンガリエフ

2015年のPG Dayカンファレンスで最も人気のあったレポートの1つは、危機後の拠点が病気になった場合のウラジミールボロディンとイルダスクルバンガリエフの話であり、それらを診断してボトルネックを探す必要があります。 レポートのすべての例は、実際のYandexの実践から取られており、イラストと「botnek」の検索に関する詳細なストーリーが添えられています。 データベースの9.4および9.5バージョンのコンテキストで問題が考慮されたという事実にもかかわらず、ウラジミールとイルダスのアドバイスの全体的な価値と実用的な適用性は変わっていません。 このレポートの転写を提供して喜んでいます。



イリヤ・コスモデミャンスキーによる紹介 ：今、私たちはあなたが本当にオラクルを持ちたいなら生きる方法についての物語を持ちますが、そうではありません。 実際、これは有用なレポートです。なぜなら、現在抱えている問題の1つは診断ツールの問題だからです。 一部の場所では、通常の診断ツールの代わりに診断ツールを使用できません。DBAではなくLinux開発者向けの非常に複雑なツールを使用する必要があります。 DBAの歯は、これらのスクリプトを見ると傷つき始めます。 また、YandexとPG Proのメンバーは、使用しているPostgresの診断方法、それらの使用方法、およびこの世界をどのように改善するかについて少し話します。







ウラジミール・ボロディン ：みなさん、こんにちは。 私の名前はVovaで、Yandexメールの管理者です。 レポートはIldusと共同で、Postgres ProでPostgreSQLを開発しています。



Postgres診断レポートとその重要なポイントは写真です。 レポートの最初の部分は、何をすべきか、モニタリングが失敗した場合に何をすべきかを説明しています。







この場合、どこで実行しますか？ 監視の爆発-これは非常に抽象的なことで、データベースに関連付けられた監視が爆発したことを意味します。







Postgresは優れたデータベースであると考えています。 良いデータベース、それがすべて悪いとき、それは原則として何かの上に置かれます。 ほとんどの場合、これは何らかのシステムリソースです。 彼女にはプロセッサーがありません。 彼女にはディスクもネットワークもありません。 重いロック、回線のロック、タブレットなどに耐えることができます。 しかし、ベースが他の何かにかかっている場合があります。







同じプロダクションからのいくつかの写真。 ここで、たとえば、プロセッサに置かれた1つのPostgresベースのhtop。 Load Average 200、多数のセッション、およびユーザー空間のプロセッサ全体、これが発生します。







ベースはホイールに載せることもできます。 sgresで非常に人気のあるもの。 一対のディスクでの廃棄はほぼ100％です。 大量のディスク読み取りを待ちます。







ディスクはiopsまたは帯域幅で終わるだけでなく、残念ながら所定の位置で終わる可能性があります。 これは、xlogセクションで終了したデータベースの写真です。







ベースがネットワーク上にあり、xlogをレプリカ、アーカイブ、または他の場所に転送してクライアントへの回答を「厚く」する状況があります。







メモリの場合、すべてがより複雑です。 原則として、問題がメモリにあることはわかりません。 オペレーティングシステムの設定方法に応じて、SWAPへのクロールを開始し、ディスクアクティビティの問題としてこれを確認するか、OOMが到着してバックエンドを強制終了し、結果としてPostgres全体が判明します。











これらはすべて、Postgresの外部のツールによって非常によく診断されます。 つまり、お気に入りのtop-likeユーティリティ、dstat、iostatなどです。 私は主にLinuxについて話します。 データベースが重いロックに置かれている場合、この情報はPGロックを介して表示できます。また、そこからの出力を目で簡単に解析できるようにするリクエストがいくつかあります。 しかし、それらはPostgres wikiでコンパイルされています。 実際、上記の例はすべてを美しく示しています。







爆発が発生し、何かに遭遇しました。 彼らが休んだもののために、悪魔は彼を知っています。 ほとんどの場合、この図のように、何かが変更されたり、何かが展開されたり、ベースの負荷が増加したり、要求の計画がなくなって、期待どおりに機能しなくなったりします。







バージョン9.4より前には、優れたpg_stat_statementsツールがありました。 最も時間がかかるクエリを検索できます。 つまり、ベースが最も多くの時間を費やすクエリです。 さて、それはすでに標準であり、分析を説明して、この時間をどこで過ごすか、何をするかなどを確認します。 ただし、データベースがクエリの実行に費やす時間は最良の指標ではありません。 この時間はさまざまなリソースに費やすことができます。 ディスクから読み取ったり、プロセッサを「強制」したり、何かをソートしたり、何らかのロックを期待したりできます。







9.4からは、pg_stat_kcacheと呼ばれる素晴らしいものがありました。これにより、ユーザー時間でのプロセッサ消費、システム時間でのプロセッサ消費など、リクエストまで確認できます。 そして、彼女ができる非常にクールなことは、ディスクからの物理的な読み取り値を共有し、オペレーティングシステムからページキャッシュデータを取得することです。







いくつかの例。 たとえば、上位のクエリに関する情報も表示するクエリ。 繰り返しますが、時間でソートされています。 しかし、システム時間、ユーザー時間、ディスクからの書き込み/読み取り、メモリからの取得量などでプロセッサをどれだけ消費したかも示しています。 これらのリクエストのテキストを見ることができます。











リクエスト自体は次のようになります。 このテキストはコピーできます。 彼はそれほど複雑ではありません。 ここではすべてが簡単です。 この特定のケースでは、pg_stat_statements、pg_stat_kcacheからデータを取得し、データベースがこのリクエストに費やした時間でソートします。







しかし、これはpg_stat_kcacheの最大の利点ではありません。 ディスクからの読み取り、ディスクへの書き込みなどでソートできます。 たとえば、同じpg_stat_statementsはshared_hitとshared_readを共有できます。 これは、共有バッファおよびその他すべてからの読み取りを意味します。 それ以外はすべて、オペレーティングシステムのページキャッシュから取得することも、ディスクから物理的に取得することもできます。 pg_stat_kcacheはそれらを分離できます。 彼はgetrusage（）システムコールを使用してこれを行います。このシステムコールは、各リクエストの後に痙攣します。







たとえば、読み取り値を持つディスク上に置かれたベースがあり、そのようなものを構築しました。ディスクからの物理的な読み取り値でソートするクエリです。 そして、これらは相対的な値です。 ここでは、最上位にあるリクエストがあることは明らかです。 数パーセントがディスクに到達し、ディスクから何かを読み取ります。 それ以外のすべては、共有メモリまたはオペレーティングシステムのキャッシュから提供されます。 つまり、このデータベースのキャッシュは非常に効果的に機能しました。 9.4を使用する場合は、必ずpg_stat_kcacheを使用してください。







一般に特定の要求によって決定されない、より複雑な問題があります。 たとえば、このような問題。 最初の矢印で、ディスクIOを増やします。 画像の中央にあるフィールドの説明。 これらの2つの列はiopsです。 iopsを1万から10万に増やします。 そして、しばらくしてから、ベースはシステム時間でプロセッサ全体を殺し始めます。 この時点で、すべてが悪くなり、一般的に彼女が何をしているかは明確ではありません。 そして、pg_stat_statementsまたはpg_stats_kcacheを見ると、システム時間に、システムがすべてのリクエストを少しでも実行することがわかります。 これは特定のクエリの問題ではありません。







プロセッサが無駄にしているものを診断するための素晴らしいパフォーマンスユーティリティがあり、DBAやカーネル開発者にとっては便利ではありませんが、サンプリングによって機能し、戦闘プロセスを傷つけません。 通常、システムを「強制」することはありません。 そして、ここで、プロセッサ時間のほとんどがスピンロックに費やされていることがわかります。 同時に、最も可能性が高いのは、軽量ロックを取得することです。 そして、最も可能性が高いのは、バッファキャッシュの領域です。 彼らは、PinBuffer、UnpinBuffer、ReadBufferなどを呼び出しました。 この結論のperf topを見ると、プロセスがシステム時間のどこで費やされているかを理解したり、データベース内で正確にどこで費やされているかを推測したりできます。







同じスピンロックを見ると悪い状況がありますが、同時に、このスピンロックの入手元とその処理方法は明確ではありません。







ミーム画像があるはずです。 もっと深く、そこで何が起こっているのか、何に基づいているのかを見ることができます。







これにはいくつかのツールがあります。 それらの1つは、dtraceとsystemtap（Linuxの場合）です。 その利点は、文字通りすべてを見ることができることです。 しかし、このためには、いくつかのコードを書く必要があります。 これが最初です。 次に、systemtapがPostgresにアクセスできるようにPostgresを再構築する必要があります。 そして最大の問題は、systemtapがどのような条件下でも適用できないことです。 負荷テスト用のスタンドで使用できます。 常に安定して動作するとは限らず、生産に追加される可能性があるためです。 これは私たちと何度か起こりました。 広告として、「ブログ」でsystemtapを使用したデバッグ状況について書きました。







別のツールは古典的なGDBデバッガーであり、それを使用します。 非常に簡単に言えば、プロセスに固執し、スレッドからバックトラックを削除します。Postgresの場合、1つのプロセス、1つのスレッドです。 したがって、バックトラックを削除するだけです。 そして、プロセッサから切り離します。







結論は次のとおりです。 バッファキャッシュを操作する領域で軽量ロックを待機していて、どこかで簡単ではなく、特定のソース行で作業していることがわかります。 591行bufmgr.cのソースコードに移動して、そこで何が起こるかを確認できます。 Cを知らなくても、非常に良いコメントがあり、どこで何が起こっているのかを理解できます。







GDBに不愉快な欠陥がある唯一のこと。 プロセスにしがみついてctrl + Cと言うと、 SIGTERMやSIGQUITではなくプロセスに飛びますが、 SIGKILLは飛び、Postgresはそれを追加します。 したがって、非常に愚かなバインディングを作成しました。 このバインディングに送信するすべてのシグナルをGDBに送信するわけではありません。 したがって、明るいバックエンドにも到達しません。



ストラップを使用すると、アドホックバックエンドからスタックトレースを削除できます。その後、彼らは目を凝視し、そこで何が起こっているのかを理解します。 プラスの点は、安定して動作し、「戦闘」を傷つけないことです。 これが機能するためには、何も再構築する必要はありません。 debuginfoパッケージをインストールするだけです：postgresql-debuginfo、libc-debuginfo、kernel-debuginfo、そしてあなたは満足するでしょう。 重要なのは、バックエンドが時間を費やしている正確な場所をコード行に対して正確に理解できるようにすることです。







プレゼンテーションの2番目の部分は、何らかのパフォーマンスの問題を思い付かなかった場合の対処方法に専念し、自信を持って再現します。 あなたは彼女をさらに治療する方法を知りません。 そして、彼らはあなたがニュースレターに何を書くべきかを教えて、何をすべきか尋ねます。 ただし、ニュースレターに書き込む前に、より多くの診断を収集できます。







いくつかの例。 たとえば、そのような状況がありました。 プロセッサ上にあるベースを撃ちました。 ここの2番目の写真では、黄色がユーザースペースのプロセッサであり、ほとんど何も食べずにすべて消費されていることがわかります。 同時に、このようなプロファイル負荷では、ベースが負荷をまったく処理しなかった最大2分の時間間隔がありました。 すべてが利害関係でした。 オペレーティングシステムからのバーストは表示されませんでした。







perftopの出力も目を引くものではありません。 その時点で注意を払った唯一のことは、この障害が出力に表示されると、ginを操作する呼び出しが表示されることです。 それに費やされる時間は非常に少ないという事実にもかかわらず。 しかし、ここで失敗するとすぐに、それらが表示されます。 すべてが良くなるとすぐに消えます。 このデータベースにはジンインデックスが1つありました。 まず、このgin-indexが使用するクエリをオフにしてオフにし、すべてが正常であることを確認しました。







それから彼らは理解し始めました。 いつものように、ドキュメントを読まなかったことが判明しました。 9.4では、ginのfastupdateが登場しました。 ほとんどの場合、挿入時間は短縮されますが、非決定的な挿入時間が発生する場合があります。 私たちにとって、時間の安定性は、相対的に言えば、この時間自体の間隔よりも重要です。 fastupdateをオフにしましたが、すべてが正常でした。 したがって、最初の推奨事項は、ニュースレターに書き込む前にドキュメントを読むことです。 ほとんどの場合、そこに答えがあります。







2番目の例。 繰り返しになりますが、撮影中に、非常識な秒単位の回答のバーストのスキャンを観察しました。 また、自動バキューム、チェックポイント、または他のシステムプロセスと時間的に相関しませんでした。







perfoの側面からは、このように見えました。 compaction_allocの最上部には、異常なものは何もありませんでした。 プロセッサ消費の古典的な図。







GDBでは、共有メモリの問題のように見えましたが、やはりバッファキャッシュの領域にありました。 重要なのは、9.4に更新した後に出始めました。 9.3ではそうではありませんでした。 9.4で大規模ページがサポートされ、赤い帽子ベースのオペレーティングシステムではデフォルトで透明な大規模ページがオンになり、うんざりしていたため、彼らはそれを見つけ始めました。 実際、私たちはこの問題に最初に遭遇したことにはほど遠い。







この問題を議論しているスレッドへのリンクはこちらです。 透明な巨大ページをオフにすると、すべてが飛び始めました。 これは2番目の推奨事項であり、ドキュメントの読み方が役に立たなかった分野です。 ただし、ケースの95％で役立ちます。 インターネットを検索するのは理にかなっています。おそらく、あなた以外の誰かがこの問題に遭遇したでしょう。







3番目の例。 ディスクIOの増加後しばらくしてから、データベースがシステムですべての時間を費やし始めたときの同じ問題。 プロセッサ全体。







また、perf出力では、スピンロックのように見えます。







一定数のbacktrace'ovを撮影し、さらに分析して、バッファキャッシュの操作に関するほぼすべてのことがわかりました。 ソースに行く必要さえありません。







この場合の古典的な推奨事項は、共有バッファを減らすことです。 通常、Postgresで作業を開始するユーザーは、共有バッファーに使用可能なすべてのRAMを切断します。 これは通常ひどく終わります。 従来の推奨事項は、すべてのメモリの25％ですが、8 GB以下です。 実際に、 8 GBに減らすと、この問題は解消されます。 でも、なんらかの理由で、共有バッファの下で多くを削減したかったのです。



ソースに行き、これらの行がどこにあるかを調べました。 バッファキャッシュのパーティションのロックの周りにあることがわかりました。 9.5では、128の値がデフォルトになります。 9.4で、まだ16です。 これにより、ロックの数が削減されました。 さらに、9.5には既に言及されたパッチがいくつかあります。 これは、多くのタイプのワークロードでパフォーマンスが向上します。 唯一のことは、これらのパッチは主に読み込みの負荷に関するものです。 そこに多くの読み取り値を持つデータベースがある場合、 共有バッファの下のほとんどすべてのメモリを切断でき、ほとんどの場合、問題は発生しません。



そこに多くのエントリがある場合は、遅かれ早かれこの問題が発生します。 邪悪なウィキは、将来この状況を改善する方法に関するアイデアを集めています。 実際、ドキュメンテーションを突然読んでインターネットを検索しても問題の解決策が得られない場合は、ソースを吸って1つの変数をねじることが理にかなっており、問題を解決します。 しかし、これは非常にまれなようです。







4番目の例。 問題の説明はこちらから入手できます。 本質はおよそ次のとおりです。サイズが約10億行の大きなタブレット、大きなBツリーインデックス（サイズが200 GB）。 このプレートでVACUUMと言い、15分以内にレプリカへの変更のロールオーバーが停止します。 ストリーミング複製についてです。







同時に、データ自体が存在するセクションから、レプリカがディスクから大量の読み取りを開始することは明らかです。 起動プロセスは、xlogを実行し、多くの信用を傷つけるものと同じであることがわかります。







この場合、プロセッサではなくAIにすべてを費やしているため、トップマークの出力を見るのは無意味です。 GDBでは、ディスクからの読み取りに本当にハングしていることがわかります。 これはlibc呼び出しです。 そして、1行のコードまで、これをどこで行っているかを見ることができます。 ソースに移動してそこで何が起こるかを見ると、ここで行われたことが最適ではないことが非ロシア語の白で直接書かれています。 改善できます。







この問題の議論へのリンク、それを解決する方法について。 これはすべて、Postgresのパッチで終わりました。これにより、レプリカのバックログを削減できます。 まったく取り外さないで、短くしてください。 この図には、2つのレプリカがあります。 緑色のものはパッチのないレプリカです。 青いものは、パッチのあるレプリカです。 グラフは遅れを示しています。 そして、これはディスクからの読み取りのグラフにあります[約。 Ed。：右側]。 読み取りボリュームは増加しません。 つまり、ドキュメントを読んで、インターネットを検索し、ソースを愚かに熟考してもあなたの質問に対する答えが得られなかったら、それらを修正するのはいいことだと思います。 しかし、私のようなCがわからない場合、この特定の状況では、大きなプレート、大きなBツリーインデックスがあり、そこにほとんど変更がなく、基本的に挿入のみのロードである場合、パーティション化するのが理にかなっていますそのような問題は発生しません。







この時点で、頭に次のことを考えておく必要があります。はい、うまく行かなかった、GDBは戦闘中、Postgresのソースコードにパッチを当てます。通常のDBAがこれを処理するわけではありません。 そして、この考えは正しいです。 私たちもそう思いました。 したがって、私はここでイルドゥスを招待します。イルドゥスは私たちを待っている明るい未来について教えてくれます。







Ildus Kurbangaliev ：みなさん、こんにちは。 私の名前はイルドゥスです。 私はPostgres Professionalで開発者として働いています。 現時点では、監視を行っています。 つまり、Postgresでこれらの期待を監視できるようにする監視パッチを作成しています。 待っていることがまさにPostgresの根幹です。 これは、たとえば、ディスク、ネットワーク、「ラッチ」、内部で発生する軽量の「ロック」、または重量のある「ロック」自体です。 これらの期待は多くのサブタイプに分けられます。 軽量ロックは50個、ロックは9個です。 ネットワーク-読み取りまたは書き込み可能。 ストレージは同じです。







別の監視ツールが必要なのはなぜですか？ 多くの場合、2番目のポイントは実際には最初のポイントです。 それらはたくさんあり、それぞれ個別に対処する必要があるためです。 これらを組み合わせたツールを使用することをお勧めします。 私にはそのような仕事がありました。たとえば、systemtapは優れたツールですが、実稼働では使用できません。







したがって、私はpg_stat_waitを開発しました。これは、プロファイリング、ファイルへのトレース、および待機履歴を実行できます。特別なパラメーターがあり、書き込みと保存ができ、個別に読み取ることができます。プロファイリングは、各期待値の期待値の数と時間を読み取ります。個々のプロセスのトレースを有効にできます。プロセスのPID、ファイル名、およびこのプロセスに対するすべての期待値がそこに書き込まれます。トレースのマイナス面は、大きなオーバーヘッドであることが判明し、オンラインで使用できないことです。プロダクションでプロダクションで使用できるようにしました。







ここで、設定された要件を記述しました。つまり、パッチはオンラインで動作するはずです。データベース自体に過負荷をかけないでください。すべての期待により、正確なデータを取得することが望ましいです。つまり、ミリ秒単位の時間、量、および主要な目標であり、多数のツールを1つにまとめることです。でそう見える。







このデータを返すだけの別個の関数を呼び出すプロファイラー用のチップがあります。つまり、予想ごとに、どれだけ時間がかかったか、量を確認できます。たとえば、美しいグラフを作成したり、予約を入れたり、もう一度質問したり、すべてが表示されるグラフを作成したりできます。ここでは、ここでの主な時間は「ラッチ」でネットワークを操作するのに費やされていることがわかります。そして、ここにLWLockが1つありました。







物語はこのように見えます。パラメーターが5,000の場合、最後の5,000の期待値を取得します。それらはすぐに消去されるため、すぐに要求する必要もあります。また、各期待値のパラメーターのみが表示されます。上のストレージには、特定のブロックが書き込まれているかを見ることができます。そして、アンロードするテーブル自体を計算します。











トレースの開始点は次のとおりです。関数（pid、file）を呼び出すと、そのような結果が表示されます。開始がいつ行われたかがここに表示され、すべてが終了すると、時間を計算して、この記録が行われた場所を確認できます。







実装について少し。当初、監視にはパラメータが1つしかありませんでした。これらの5つのタイプは、サンプリングによって収集され、プロファイルが作成されました。サンプリングは最初にプロセスのリストにブロックを置くため、これはあまり役に立たないことが判明しました。次に、検索が続行されると、他のプロセスがロックをかけることができ、それらはスキップされます。少し違ったやり方でやった。つまり、各バックエンドはそれ自体内で集計を収集し、共有メモリに時々ドロップします。そこから、プロファイルだけが与えられます。



ストーリーは黄色のコレクターによって収集されています。ProcArrayを反復処理し、現在そこで起こっていることを記録します。現在のビューがあります個別に、特定のプロセスが現在何をしているのかを見ることができます。オーバーヘッドを回避するために、すべてがブロックフリーアルゴリズムに実装されています。







以下に、このようなブロックのないアルゴリズムが履歴に対してどのように作成されるかの例を示します。期待ごとに2つのブロックを保持します。そして、バックエンドが一方に書き込むと、もう一方を読み取ります。したがって、ブロックを避けてください。















そして、私は多くのオーバーヘッド測定を行いました。これらのテストは、オーバーヘッドがこの場合0.5％未満であることを示しました。しかし、SELECTクエリでこれをテストしたことを明確にします。そのため、pg_benchの結果の散布図が取得されます。。そこでは、監視の有無にかかわらず、オーバーヘッドを評価することは不可能です。そして、誰かがこれを行う方法を思いついたら、私は非常に感謝します。安定した録音結果を得るのは非常に難しいためです。







ここで、コードはオープンソースで開かれており、gitgubではこのプロジェクトがあり、何かが足りない場合は問題を作成し、監視をテストし、データベースをチェックインし、バグも探します。これは非常に役立ちます。これらの問題に関する対応を確認できるリンクが2つあり、そこにも参加できます。







この監視の使用例があります。これについては、Vovaに伝えます。







ウラジミール・ボロディン：例について少し。 Ildusは、バグをダウンロード、試用、テスト、検索できると述べました。ダウンロード、試用、検索、テストを行いました。すべてのマシンですでに9.4が実稼働しています。パッチは9.4用であり、現在のマスター用のパッチがあります。これは現在、アップストリームにプッシュされています。



以前はどうでしたか？私たちには、何に対しても休まないように思えるが、それ以上それを発行しない基盤があります。 1秒あたり1万トランザクションおよびポイント。もう機能しません。 GDBでは、ProcArrayEndTransactionでハングし、軽量ロックを取得していることがわかりました。繰り返しになりますが、最大1行のコードで、ProcArrayLockでハングしていることがわかります。このGDBを接続し、特定のバックエンドでキャッチして、これを確認できます。







そして今、これは1つのSELECTクエリですpg_stat_wait_currentまたはpg_stat_wait_historyで、現在の状況を見ているか、過去の履歴を見ているかによって異なります。そして、ここでは、それらすべてがProcArrayLockにかかっていることがわかり、このProcArrayLockを待機するのにどれだけの時間を費やしたかがわかります。







これは視覚化できます。これは、各待機クラスでベースが費やす時間のグラフです。赤はディスク、緑は軽量ロック、青は重ロックです。ネットワークと「ラッチ」はここではオフになっています。これは通常、多くの時間がかかるためです。バックエンドがハングして何もしませんが、ネットワーク待機クラスがあり、待機時間が非常に長くなっています。チェックポイントがハングして何もしない場合、ラッチ待機クラスがあります、待機時間は無限です。まあ、無限ではないが、非常に大きい。そしてここで、ほとんどの場合、ベースは何かを待っているときにディスクIOを待ちますが、軽量ロックでハングすることがあります。 y軸は待機時間、x軸はカレンダー時間です。







軽量ロック内で何が起こるかと同じグラフをプロットできます。ほとんどすべてが黄色で、黄色がBufferPartitionLockであることがわかります。バッファキャッシュの同じロックとパーティションを、それだけではなく、16から128に増やしました。9.5のように、それらは大幅に最適化されました。







たとえば、これは、データベース内のすべてが不良になった瞬間の待機クラスの様子です。最初はそれらが爆発し、軽量のロックに期待してぶら下がったことがわかります。しばらくしてから、重量のあるロックにプレートのラインのレベルでロックアップしました。軽量ロックが







原因であるものを見ると、理論的には、ProcArrayLockとBuffFreelistLockがあるはずです。上絞首刑BuffFreelistLock「E、およびProcArrayLock」とあるため、バックエンドの大規模な数を作成するために、現時点では、多くがあった、新しい接続が開かれ、そしてこの-負荷ProcArray。この問題の主な原因はBuffFreelistLockであり、これは9.5ではなくなり、最適化の1つで見られました。







在庫を確認する時が来ました。これは待望の機能であり、他の多くのデータベースにあり、DBAの寿命を大幅に促進しているようです。







PG Day'17の次の夏、Yandexの専門家は、いくつかのクールなレポートを準備しています。Vladimir Krasilshchikが ビッグデータの聴衆と話をし、Vasily SozykinがYandex.MoneyでのPostgreSQLへの移行の壮大なストーリーを語り、人気のClickHouse分析データベースのリード開発者であるAlexey Milovidov が彼の発明の内部構造について語ります。今すぐ参加しよう！