DBA ボットのジョー。 アナトリー・スタンスラー (Postgres.ai)

バックエンド開発者は、SQL クエリが「本番」で適切に機能することをどのように理解しているのでしょうか? 大企業や急速に成長している企業では、誰もが「製品」にアクセスできるわけではありません。 また、アクセスする場合、すべてのリクエストを簡単にチェックできるわけではなく、データベースのコピーの作成には数時間かかることがよくあります。 これらの問題を解決するために、私たちは人造 DBA、ジョーを作成しました。 すでにいくつかの企業で導入が成功しており、十数社の開発者を助けています。

ビデオ：

こんにちは、みんな！ 私の名前はアナトリー・スタンスラーです。 私は会社に勤めています postgres.ai。 私たちは、開発者、DBA、QA から Postgres の作業に伴う遅延を取り除くことで、開発プロセスをスピードアップすることに取り組んでいます。

私たちには素晴らしいクライアントがいます。今日のレポートの一部は、彼らとの仕事中に出会ったケースに当てられます。 非常に深刻な問題の解決を私たちがどのように支援したかについてお話します。

複雑で高負荷な移行を開発および実行するとき、私たちは「この移行はうまくいくだろうか?」という質問を自問します。 私たちはレビューを利用し、より経験豊富な同僚や DBA 専門家の知識を利用します。 そして、それが飛ぶかどうかを知ることができます。

しかし、フルサイズのコピーで自分たちでテストできればもっと良いかもしれません。 そして今日は、テストに対する現在のアプローチがどのようなものであるか、またテストをより良く行うにはどうすればよいか、またどのようなツールを使用すればよいかについてお話します。 また、このようなアプローチの長所と短所、およびここで修正できる点についても説明します。

これまでに本番環境で直接インデックスを作成したり、変更を加えたりした人は誰ですか? かなりの量です。 そして、これがデータの損失やダウンタイムの発生を誰にもたらしたのでしょうか? そうすれば、この痛みがわかります。 ありがたいことにバックアップがあります。

最初のアプローチは、本番環境でのテストです。 あるいは、開発者がローカル マシン上でテスト データを使用している場合、ある種の限られた選択肢が存在します。 そして本番環境にロールアウトすると、この状況が得られます。

痛いし、高いし。 おそらくそうしないほうがいいでしょう。

そして、それを行うための最良の方法は何ですか?

ステージングを行って、そこで本番の一部を選択しましょう。 せいぜい、実際の製品、すべてのデータを取得しましょう。 そして、ローカルで開発した後、さらにステージングを確認します。

これにより、エラーの一部を削除できるようになります。つまり、本番環境でエラーが発生するのを防ぐことができます。

問題点は何ですか?

• 問題は、この演出を同僚と共有していることです。 そして、ある種の変更を加えると、データがなく、作業が無駄になることが非常によくあります。 ステージングは​​数テラバイトに達しました。 そして再び上昇するまで長い時間待たなければなりません。 そして明日最終決定することにしました。 以上、開発が完了しました。
• そしてもちろん、そこでは多くの同僚、多くのチームが働いています。 そしてそれは手動で行う必要があります。 そして、これは不便です。

データベースに変更を加えたり、データに触れたり、構造を変更したりする場合、試行は XNUMX 回だけであるということも重要です。 また、何か問題が発生した場合、移行中にエラーが発生した場合、すぐにロールバックすることはありません。

これは前のアプローチよりも優れていますが、依然として本番環境で何らかのエラーが発生する可能性が高くなります。

各開発者にテストベンチ、つまりフルサイズのコピーを提供することを妨げるものは何でしょうか? 何が妨げになっているかは明らかだと思います。

テラバイトを超えるデータベースを持っているのは誰ですか? 部屋の半分以上。

そして、これほど大規模な生産がある場合、各開発者にマシンを維持するのは非常に高価であり、さらに長い時間がかかることは明らかです。

すべての変更をフルサイズのコピーでテストすることが非常に重要であることを認識しているクライアントもいますが、データベースは XNUMX テラバイト未満であり、各開発者用のテストベンチを維持するリソースがありません。 したがって、ダンプをローカルのマシンにダウンロードし、この方法でテストする必要があります。 とても時間がかかります。

インフラストラクチャ内で実行したとしても、200 時間あたり XNUMX テラバイトのデータをダウンロードできるのは、すでに非常に優れています。 ただし、論理ダンプを使用し、クラウドからローカルにダウンロードします。 彼らにとって、その速度は XNUMX 時間あたり約 XNUMX ギガバイトです。 そして、論理ダンプからの方向転換、インデックスのロールアップなどには依然として時間がかかります。

しかし、製品の信頼性を維持できるため、このアプローチを使用しています。

ここで何ができるでしょうか？ テストベンチを安価にして、すべての開発者に独自のテストベンチを提供しましょう。

そしてこれは可能です。

そして、このアプローチでは、開発者ごとにシン クローンを作成すると、それを 10 台のマシンで共有できます。 たとえば、10 TB のデータベースがあり、それを XNUMX 人の開発者に提供したい場合、XNUMX TB のデータベースを XNUMX 個用意する必要はありません。 XNUMX 台のマシンを使用して開発者ごとに薄い分離コピーを作成するには、XNUMX 台のマシンのみが必要です。 仕組みについては少し後ほど説明します。

実際の例:

• DB - 4,5 テラバイト。

• 独立したコピーを 30 秒で取得できます。

テストスタンドを待つ必要も、その大きさに依存する必要もありません。 数秒で取得できます。 完全に分離された環境になりますが、それらの間でデータを共有します。

これは素晴らしい。 ここでは魔法と並行世界について話します。

私たちの場合、これは OpenZFS システムを使用して機能します。

OpenZFS は、すぐに使えるスナップショットとクローンをサポートするコピーオンライト ファイル システムです。 信頼性と拡張性に優れています。 彼女はとても扱いやすいです。 文字通り XNUMX つのチームに展開できます。

他にも次のオプションがあります。

• LVM、

• ストレージ (Pure Storage など)。

私が話しているデータベース ラボはモジュール式です。 これらのオプションを使用して実装できます。 しかし、特に LVM に問題があったため、現時点では OpenZFS に焦点を当てています。

使い方？ データを変更するたびに上書きするのではなく、この新しいデータが新しい時点、つまり新しいスナップショットからのものであることを単にマークすることによってデータを保存します。

そして将来、ロールバックしたいとき、または古いバージョンから新しいクローンを作成したいときは、「わかりました。このようにマークされたデータのブロックをください」と言うだけです。

そして、このユーザーはそのようなデータセットを操作します。 彼は徐々にそれらを変更し、独自のスナップショットを作成します。

そして分岐していきます。 この場合、各開発者は編集する独自のクローンを持つ機会があり、共有されるデータは全員で共有されます。

このようなシステムを自宅に導入するには、次の XNUMX つの問題を解決する必要があります。

• XNUMX つ目はデータのソースです。データの取得元です。 本番環境でレプリケーションを設定できます。 設定したバックアップはすでに使用できると思います。 WAL-E、WAL-G、またはバーマン。 また、RDS や Cloud SQL などのクラウド ソリューションを使用している場合でも、論理ダンプを使用できます。 ただし、それでもバックアップを使用することをお勧めします。このアプローチを使用すると、ファイルの物理構造も保持され、存在する問題を検出するために運用環境で確認されるメトリクスにさらに近づけることができるからです。

• XNUMX つ目は、データベース ラボをホストする場所です。 それはクラウドの場合もあれば、オンプレミスの場合もあります。 ここで、ZFS がデータ圧縮をサポートしていると言うことが重要です。 そしてそれは非常にうまくいきます。

そのようなクローンごとに、ベースで行う操作に応じて、ある種の開発が成長することを想像してください。 このためには、開発者にもスペースが必要です。 ただし、ベースを 4,5 テラバイトとしたため、ZFS はそれを 3,5 テラバイトに圧縮します。 これは設定によって異なる場合があります。 そして私たちにはまだ開発の余地があります。

このようなシステムはさまざまな場合に使用できます。

• これらは開発者であり、クエリ検証や最適化を担当する DBA です。

• これは、本番環境に展開する前に特定の移行をテストするための QA テストで使用できます。 また、実際のデータを使用して QA 用の特別な環境を構築し、新しい機能をテストできるようにすることもできます。 また、数時間待つのではなく数秒で完了し、シン コピーが使用されない場合には数日かかる場合もあります。

• そして別のケース。 会社に分析システムがセットアップされていない場合は、製品ベースのシン クローンを分離し、それを分析に使用できる長いクエリまたは特別なインデックスに割り当てることができます。

このアプローチでは次のようになります。

1. すべての変更をフルサイズのデータ​​でテストしたため、「本番環境」でエラーが発生する可能性が低くなります。

2. 私たちにはテストする文化があります。なぜなら、自分のスタンドを得るために何時間も待つ必要がなくなったからです。

3. また、テストの間に障壁や待ち時間はありません。 実際に行って確認することも可能です。 そして、開発をスピードアップするにつれて、この方法はより良くなるでしょう。

• リファクタリングが少なくなります。 最終的に本番環境に残るバグは少なくなります。 後でそれらのリファクタリングを減らします。

• 不可逆的な変化を元に戻すことができます。 これは標準的なアプローチではありません。

1. テストベンチのリソースを共有するので、これは有益です。

すでに優れていますが、他に加速できるものは何でしょうか?

このようなシステムのおかげで、このようなテストに参加する敷居を大幅に下げることができます。

現在、開発者が実際のフルサイズのデータ​​にアクセスするには専門家にならなければならないという悪循環が生じています。 彼はそのようなアクセスを信頼できるに違いありません。

しかし、それがない場合はどうやって成長するのか。 しかし、使用できるテスト データのセットが非常に少ない場合はどうなるでしょうか? それでは本当の経験は得られません。

このサークルから抜け出すにはどうすればよいでしょうか？ あらゆるレベルの開発者にとって便利な最初のインターフェイスとして、Slack ボットを選択しました。 ただし、他のインターフェイスでもかまいません。

それによって何ができるようになるのでしょうか？ 特定のクエリを取得して、データベースの特別なチャネルに送信できます。 シン クローンは数秒で自動的にデプロイされます。 このリクエストを実行してみましょう。 私たちは指標と推奨事項を収集します。 視覚化を示してみましょう。 そして、このクローンは残り、このクエリを何らかの方法で最適化したり、インデックスを追加したりできるようになります。

また、Slack は、すぐにコラボレーションできる機会を与えてくれます。 これは単なるチャネルであるため、そのようなリクエストのスレッド内でこのリクエストについての議論を開始し、社内の同僚や DBA に ping を送信することができます。

しかし、もちろん問題もあります。 これは現実の世界であり、一度に多数のクローンをホストするサーバーを使用しているため、クローンが使用できるメモリと CPU パワーの量を圧縮する必要があります。

しかし、これらのテストが妥当であるためには、この問題を何らかの方法で解決する必要があります。

重要な点が同じデータであることは明らかです。 しかし、私たちはすでにそれを持っています。 そして、同じ構成を実現したいと考えています。 そして、このようなほぼ同一の構成を与えることができます。

実稼働環境と同じハードウェアを使用できれば素晴らしいですが、異なる場合もあります。

Postgres がメモリをどのように扱うかを思い出してください。 キャッシュは XNUMX つあります。 XNUMX つはファイル システムから、もう XNUMX つはネイティブ Postgres、つまり共有バッファ キャッシュからです。

共有バッファ キャッシュは、構成で指定したサイズに応じて、Postgres の起動時に割り当てられることに注意することが重要です。

そして、XNUMX 番目のキャッシュは利用可能なスペースをすべて使用します。

そして、25 台のマシン上で複数のクローンを作成すると、メモリが徐々にいっぱいになることがわかります。 そして、良い意味で、共有バッファ キャッシュはマシンで利用可能なメモリの総量の XNUMX% を占めます。

そして、このパラメータを変更しない場合、4 台のマシン上で実行できるインスタンスは 4 つだけ、つまり、このようなシン クローンすべてのうちの XNUMX つだけであることがわかります。 そしてもちろん、これは良くありません。なぜなら、私たちはもっと多くのものを持ちたいからです。

しかしその一方で、バッファ キャッシュはインデックスのクエリを実行するために使用されます。つまり、計画はキャッシュの大きさに依存します。 そして、このパラメータを取り出して減らすだけで、計画が大きく変わる可能性があります。

たとえば、本番環境に大規模なキャッシュがある場合、Postgres はインデックスの使用を優先します。 そうでない場合は、SeqScan があります。 そして、もし私たちの計画が一致しなかったら、一体何の意味があるのでしょうか？

しかしここで、実際には Postgres のプランはプラン内の共有バッファーに指定された特定のサイズには依存せず、effective_cache_size に依存するという結論に達しました。

Effective_cache_size は、利用可能なキャッシュの推定量、つまりバッファ キャッシュとファイル システム キャッシュの合計です。 これは構成によって設定されます。 そして、このメモリは割り当てられていません。

そして、このパラメータのおかげで、Postgres を騙して、たとえこのデータがなくても、実際には利用可能なデータがたくさんあると言うことができます。 したがって、計画は生産と完全に一致します。

しかし、これはタイミングに影響を与える可能性があります。 また、タイミングによってクエリを最適化しますが、タイミングは多くの要因に依存することが重要です。

• 現在本番環境にかかる負荷によって異なります。

• 機械自体の特性によります。

これは間接的なパラメーターですが、実際には、結果を取得するためにこのクエリが読み取るデータの量によって正確に最適化できます。

そして、本番環境で見られるタイミングに近づけたい場合は、最も類似したハードウェアを使用する必要があり、おそらくすべてのクローンが適合するようにする必要があります。 しかし、これは妥協です。つまり、同じプランが得られ、特定のクエリが読み取るデータの量がわかり、このクエリが良い (または移行) か悪いかを結論付けることができますが、まだ最適化する必要があります。 。

Joe が具体的にどのように最適化されているかを見てみましょう。

実際のシステムからリクエストを受け取ってみましょう。 この場合、データベースは 1 テラバイトです。 そして、10 件以上の「いいね！」がついた新しい投稿の数を数えたいと思います。

私たちはチャネルにメッセージを書き込んでいます。クローンがデプロイされました。 このようなリクエストは 2,5 分で完了することがわかります。 これが私たちが最初に気づくことです。

B Joe は、プランと指標に基づいて自動推奨事項を表示します。

クエリが処理するデータが多すぎて、比較的少数の行を取得できないことがわかります。 また、クエリ内にフィルタリングされた行が多すぎることに気づいたので、ある種の特殊なインデックスが必要です。

何が起こったのかを詳しく見てみましょう。 実際、ファイル キャッシュまたはディスクからほぼ 142 ギガバイトのデータを読み取っていることがわかります。 XNUMX 行しか得られなかったので、これは良くありません。

そして、ここにはインデックス スキャンがあり、すぐに処理されるはずだったのですが、フィルターで除外した行数が多すぎた (行数をカウントする必要があった) ため、リクエストはゆっくりと処理されました。

これは、クエリ内の条件とインデックス内の条件が部分的に一致しないという事実により、プランで発生しました。

インデックスをより正確にして、その後クエリの実行がどのように変化するかを見てみましょう。

インデックスの作成にはかなりの時間がかかりましたが、クエリを確認すると、2,5 分ではなく 156 ミリ秒しかかからず、十分な時間であることがわかります。 そして、読み取ったデータはわずか 6 メガバイトです。

そして今はインデックスのみのスキャンを使用しています。

もう一つ重要な話は、計画をもう少しわかりやすい形で提示したいということです。 Flame Graphを使用した可視化を実装しました。

これは別の、より強力なリクエストです。 そして、XNUMX つのパラメータに従ってフレーム グラフを構築します。これは、特定のノードが計画とタイミングでカウントしたデータの量、つまりノードの実行時間です。

ここで、特定のノードを相互に比較できます。 そして、どちらの処理にかかる時間が多いか少ないかは明らかですが、他のレンダリング方法では通常これを行うのが困難です。

もちろん、explain.depesz.com は誰もが知っています。 このビジュアライゼーションの優れた機能は、テキスト プランを保存し、ソートできるようにいくつかの基本パラメーターをテーブルに追加していることです。

また、このトピックをまだ深く掘り下げていない開発者も Explain.depesz.com を使用します。これは、どのメトリクスが重要でどのメトリクスがそうでないかを簡単に把握できるためです。

視覚化に対する新しいアプローチがあります - これは Explain.dalibo.com です。 彼らはツリーを視覚化しますが、ノードを相互に比較するのは非常に困難です。 ここで構造をよく理解できますが、大きなリクエストがある場合は、前後にスクロールする必要がありますが、オプションも必要です。

Коллаборация

そして、先ほども述べたように、Slack は私たちにコラボレーションの機会を与えてくれます。 たとえば、最適化方法が明確ではない複雑なクエリに遭遇した場合は、Slack のスレッドで同僚とこの問題を明確にすることができます。

フルサイズのデータ​​でテストすることが重要であるように思えます。 これを行うために、オープンソースで入手できる Update Database Lab ツールを作成しました。 Joe ボットも使用できます。 今すぐ入手して、自分の場所で実装できます。 すべてのガイドはそこで入手できます。

Delphix があるため、ソリューション自体は革新的ではありませんが、エンタープライズ ソリューションであることに注意することも重要です。 完全に閉鎖されていて、非常に高価です。 私たちは特に Postgres に特化しています。 これらはすべてオープンソース製品です。 参加しませんか！

これで終わります。 ありがとう！

質問

こんにちは！ ご報告ありがとうございます！ 少し前にほぼ同じ問題を解決したので、特に私にとっては非常に興味深いです。 そこで、いくつか質問があります。 少なくともその一部を得ることができれば幸いです。

この環境の場所はどのように計算しているのでしょうか？ このテクノロジーは、特定の状況下ではクローンが最大サイズまで成長する可能性があることを意味します。 大まかに言えば、10 テラバイトのデータベースと 10 個のクローンがある場合、各クローンが XNUMX 個の一意のデータを重み付けする状況をシミュレートするのは簡単です。 これらのクローンが住むことになるこの場所、つまりあなたが話したデルタをどのように計算しますか?

良い質問。 ここで特定のクローンを追跡することが重要です。 また、クローンに大きすぎる変更が加えられ、クローンが成長し始めた場合は、まずユーザーにこれについて警告を発するか、障害が発生しないようにこのクローンを直ちに停止することができます。

はい、入れ子の質問があります。 つまり、これらのモジュールのライフサイクルをどのように保証するのでしょうか? この問題と、まったく別の話があります。 これはどうして起こるのでしょうか?

クローンごとにいくつかの ttl があります。 基本的に、固定ttlがあります。

秘密ではないとしたら何でしょうか？

1 時間、つまりアイドル状態 - 1 時間。 使われない場合は叩きます。 しかし、数秒でクローンを作成できるため、これは驚くべきことではありません。 また必要な場合は、お願いします。

たとえば、何らかの理由で複数の方法を並行して使用するため、テクノロジーの選択にも興味があります。 なぜ ZFS なのか? なぜLVMを使わなかったのですか? LVM に問題があるとおっしゃいました。 何が問題でしたか? 私の意見では、パフォーマンスの観点から、最も最適なオプションはストレージを使用することです。

ZFS の主な問題は何ですか? 同じホスト上で実行する必要がある、つまりすべてのインスタンスが同じ OS 内に存在する必要があるという事実。 ストレージの場合は、さまざまな機器を接続できます。 そして、ボトルネックとなるのはストレージ システム上にあるブロックだけです。 そして、テクノロジーの選択の問題は興味深いです。 なぜLVMではないのでしょうか?

具体的には、ミートアップでLVMについて話し合うことができます。 ストレージについては、ただ高価です。 ZFS システムはどこにでも実装できます。 マシンにデプロイできます。 リポジトリをダウンロードしてデプロイするだけです。 Linux について言えば、ZFS はほとんどどこにでもインストールされます。 つまり、非常に柔軟な解決策が得られます。 ZFS 自体は、すぐに使える機能がたくさんあります。 好きなだけデータをアップロードでき、多数のディスクを接続でき、スナップショットもあります。 そして、先ほども言いましたが、管理は簡単です。 つまり、とても使い心地が良さそうです。 彼は試練を受けている、彼はもう何歳もいる。 彼には非常に大きなコミュニティがあり、成長し続けています。 ZFS は非常に信頼性の高いソリューションです。

ニコライ・サモクバロフ: さらにコメントしてもいいですか? 私の名前はニコライです。私たちはアナトリーと一緒に働いています。 収納が素晴らしいという意見には同意します。 また、当社の顧客の中には Pure Storage などを利用している人もいます。

アナトリーは、私たちがモジュール性に重点を置いていると正しく指摘しました。 そして将来的には、スナップショットの取得、クローンの作成、クローンの破棄という XNUMX つのインターフェイスを実装できるようになります。 すべて簡単です。 もしそうなら、ストレージもクールです。

しかし、ZFS は誰でも利用できます。 DelPhix はすでに十分であり、クライアントは 300 社あります。 このうち、フォーチュン 100 には 50 社の顧客がいます。つまり、NASA などを対象としています。誰もがこのテクノロジーを入手できる時代が来ています。 それが、私たちがオープンソースのコアを持っている理由です。 オープンソースではないインターフェイス部分があります。 これが今回ご紹介するプラットフォームです。 しかし、私たちは誰でもアクセスできるようにしたいと考えています。 私たちは、すべてのテスターがラップトップで推測するのをやめるような革命を起こしたいと考えています。 SELECT を書くと、それが遅いことがすぐにわかります。 DBA からの通知を待つのはやめてください。 ここが主な目標です。 そして、私たち全員がこれに到達すると思います。 そして私たちはこれを誰もが手にできるものを作ります。 したがって、ZFS はどこでも利用できるようになるためです。 問題を解決し、オープンソース ライセンスを取得したコミュニティに感謝します*

こんにちは！ ご報告ありがとうございます！ 私の名前はマキシムです。 私たちは同じ問題に取り組んできました。 彼らは自分たちで決めたのです。 これらのクローン間でリソースをどのように共有しますか? 各クローンはいつでも独自の作業を行うことができます。つまり、あるクローンはあることをテストし、別のクローンは別のことをテストし、誰かがインデックスを構築し、誰かが重い仕事をこなします。 CPU ごとに分割できる場合、IO ごとに分割するにはどうすればよいでしょうか? これが最初の質問です。

そして4つ目の質問は、スタンドの違いについてです。 ここに ZFS があり、すべてがうまくいっているとします。ただし、本番環境のクライアントには ZFS がなく、たとえば extXNUMX があるとします。 この場合はどうすればいいでしょうか？

質問はとても良いです。 私はリソースを共有しているという事実について、この問題について少し触れました。 そして解決策はこれです。 ステージングでテストしていると想像してください。 誰かがXNUMXつの負荷を与えると同時に、他の誰かがそのような状況になる可能性もあります。 その結果、理解できない指標が表示されることになります。 同じ問題が製品でも発生する可能性があります。 リクエストをチェックしたいときに、リクエストに何らかの問題があることがわかり、動作が遅い場合、実際には問題はリクエストにあるのではなく、ある種の並列負荷があるという事実にあります。

したがって、ここでは、計画がどのようなものになるのか、計画の中でどのようなステップを踏むのか、そのためにどれだけのデータを収集するのかに焦点を当てることが重要です。 たとえば、ディスクに何かがロードされるという事実は、特にタイミングに影響します。 ただし、このリクエストの負荷はデータ量によって推定できます。 同時に何らかの実行が行われることはそれほど重要ではありません。

質問がXNUMXつあります。 これはとてもクールなものです。 クレジット カード番号など、本番データが重要になるケースはありますか? すでに何か準備ができていますか、それとも別のタスクですか? XNUMX 番目の質問は、MySQL にこのようなものはありますか?

データについて。 そうなるまで難読化を行います。 しかし、正確に Joe をデプロイした場合、開発者にアクセス権を与えなければ、データにアクセスすることはできません。 なぜ？ ジョーはデー​​タを示さないからです。 表示されるのは指標と計画だけです。それだけです。 これはクライアントの要件の XNUMX つであるため、これは意図的に行われました。 彼らは、全員にアクセス権を与えずに最適化できるようにしたいと考えていました。

MySQLについて。 このシステムは、状態をディスクに保存するあらゆる用途に使用できます。 そして、私たちは Postgres を実行しているので、まず Postgres の自動化をすべて実行しています。 バックアップからのデータの取得を自動化したいと考えています。 Postgres を正しく構成しています。 私たちは計画を一致させる方法などを知っています。

ただし、システムは拡張可能なため、MySQL にも使用できます。 そしてそのような例もあります。 Yandex にも同様のものがありますが、どこにも公開していません。 彼らはそれを Yandex.Metrica 内で使用します。 あとは MySQL の話だけです。 ただし、テクノロジーは同じ ZFS です。

ご報告ありがとうございます！ 私もいくつか質問があります。 クローン作成は、追加のインデックスを構築するなど、分析に使用できると述べました。 どのように機能するかについてもう少し詳しく教えていただけますか?

それでは、スタンドの類似性、計画の類似性について、すぐに XNUMX 番目の質問をさせていただきます。 この計画は、Postgres によって収集された統計にも依存します。 この問題をどうやって解決しますか?

分析によると、まだ使用していないため、具体的なケースはありませんが、そのような機会はあります。 インデックスについて話している場合、クエリが数億のレコードと通常本番環境でインデックス付けされていない列を含むテーブルを追跡していると想像してください。 そこでいくつかのデータを計算したいと思います。 このリクエストが本番環境に送信された場合、リクエストはそこで XNUMX 分間処理されるため、本番環境では単純になる可能性があります。

OK、数分間停止しても問題ないシン クローンを作成しましょう。 分析を読みやすくするために、データに関心のある列にインデックスを追加します。

インデックスは毎回作成されますか?

データにアクセスしてスナップショットを作成し、その後このスナップショットから回復して新しいリクエストを実行するようにすることもできます。 つまり、既にインデックスが付けられている新しいクローンを生成できるようにすることができます。

統計に関する質問に関しては、バックアップから復元した場合とレプリケーションを行った場合、統計はまったく同じになります。 なぜなら、物理的なデータ構造全体を持っているからです。つまり、すべての統計メトリックも含めたデータをそのままの状態で持ち込むことになります。

ここに別の問題があります。 クラウド ソリューションを使用する場合、Google や Amazon では物理コピーの取得を許可していないため、そこでは論理ダンプのみが利用可能です。 問題が発生します。

ご報告ありがとうございます。 ここには、MySQL とリソース共有に関する XNUMX つの良い質問がありました。 しかし、実際には、これは特定の DBMS のトピックではなく、ファイル システム全体のトピックであるという事実にすべて帰着します。 したがって、リソース共有の問題も、最終的に Postgres であるということではなく、ファイル システムやサーバーなどで解決される必要があります。

私の質問は少し異なります。 これは、複数の層がある多層データベースに近いものです。 たとえば、100 テラバイトのイメージ更新を設定し、複製しています。 そして、私たちはこのソリューションを特にデータベースに使用します。 レプリケーションが進行中で、データが更新されています。 ここでは XNUMX 人の従業員が並行して働いており、常にさまざまなショットを発射しています。 何をすべきか？ 競合がないこと、競合を起動した後にファイル システムが変更され、これらの写真がすべて消えてしまったことを確認するにはどうすればよいでしょうか?

それが ZFS の仕組みであるため、それらは実行されません。 レプリケーションによるファイル システムの変更を XNUMX つのスレッドに個別に保持できます。 そして、開発者が古いバージョンのデータで使用するクローンを保持します。 そしてそれは私たちにとってうまくいき、これですべてがうまくいきます。

更新は追加のレイヤーとして行われ、すべての新しい写真はこのレイヤーに基づいてすでに移動されることがわかりました。

以前のレプリケーションからのものである以前のレイヤーから。

以前のレイヤーは削除されますが、古いレイヤーを参照し、更新で受け取った最後のレイヤーから新しい画像を取得しますか?

一般的に、はい。

その結果、最大 XNUMX つの層が得られます。 そして時間が経つと圧縮する必要が出てくるのでしょうか？

はい、すべて正しいです。 何かの窓があります。 私たちは毎週のスナップショットを保持します。 それはあなたが持っているリソースによって異なります。 大量のデータを保存できる場合は、スナップショットを長期間保存できます。 彼らは自ら立ち去ることはありません。 データの破損は発生しません。 スナップショットが古いと思われる場合、つまり会社のポリシーに依存している場合は、単純にスナップショットを削除してスペースを空けることができます。

こんにちは、レポートありがとうございます！ ジョーについて質問です。 顧客は全員にデータへのアクセスを許可したくないと言っていました。 厳密に言えば、Explain Analyzeの結果を持っている人はデータを覗くことができます。

そのようなものです。 たとえば、「SELECT FROM WHERE email = to that」と書くことができます。 つまり、データそのものはわかりませんが、間接的な兆候はいくつか確認できます。 これは理解しなければなりません。 しかし一方で、それはすべてそこにあります。 私たちはログ監査を行っており、開発者が何をしているかを見る他の同僚を管理しています。 そして、誰かがこれを行おうとすると、セキュリティサービスが彼らのところに来て、この問題に取り組むでしょう。

こんにちはご報告ありがとうございます！ 短い質問があります。 会社が Slack を使用していない場合、現在 Slack にバインドするものはありますか? それとも、開発者がテスト アプリケーションをデータベースに接続するためにインスタンスをデプロイすることは可能ですか?

現在、Slack へのリンクがあります。つまり、他のメッセンジャーはありませんが、他のメッセンジャーもサポートしたいと考えています。 何ができるでしょうか？ Joe なしで DB Lab をデプロイすることも、REST API または当社のプラットフォームを利用してクローンを作成し、PSQL に接続することもできます。 ただし、画面がなくなるため、開発者にデータへのアクセスを許可する準備ができていれば、これを行うことができます。

この層は必要ありませんが、このような機会は必要です。

それなら、はい、できます。

出所： habr.com