pl / pgsql上のアプリケーションサーバー

過去のPGデイの 1つであるプロジェクト111の IT部長Artem Makarovは 、Postgresで独自のERPシステムを構築し、ストアドプロシージャでアプリケーションサーバーを構築するなどのソリューションを企業がどのように決定できるかを語った。 これらのどれが悪い、良い面が続いた。 Artemが多くのコードを書いたにもかかわらず、決して本当のプログラマーではなかったことは注目に値します。 むしろ、彼は反マネージャーであり、伝道者であり、ITソリューションのビジネスに対するロビイストと呼ばれることがあります。 したがって、彼のレポートでは、ビューは技術専門家からだけでなく、マネージャーからのものでもあります。



私たちは誰ですか？



私たちの選択を説明するためには、会社の詳細を説明する価値があります。 Project 111 Webサイトを開くと（プログラマは既にスラッシュドット効果があるかどうかを確認しています）、eコマースのオンラインストアと非常によく似ていますが、オンラインストアのことではなく、B2Bです。 つまり、私たちには常連客がいて、彼らの多くがいて、マーケティングは狂っており、新しいスキーム、割引、プロモーションなどを考えているので、販売にはかなり複雑なビジネスプロセスがあり、長い時間がかかり、ほぼ1週間かかります。 サイトの顧客であるパー​​トナーは、ERPシステムの本格的な従業員です 。つまり、販売部門の非常に多くの機能を使用していますが、自分で支払いを行うことはできません。 そのため、システムはフロントエンドを含む非常に重いです。



私たちは中規模の会社です。 数はそれほど多くありません。2300人のユーザーがサイトにログオンしています（割引と条件を備えたパートナー）が、これらは「ヘビーユーザー」です。つまり、倉庫または財務の従業員と同じ負荷を作成します。 私たちは長い間インターネットに賭けてきました。 注文の97〜98％は オンラインで行われ、注文の60％は営業員の手に触れることなく、自動的に倉庫に行きます。



自分でシステムを構築するというアイデアをどのようにして思いついたのですか？



2000年代の初め、私たちがこれを行っていたとき、「高負荷」という言葉は聞こえず、アヤックスさえありませんでした。 全体として、Internet Explorer 5.5が少しありました。 会社の経営陣は、未来はインターネットにあり、電話で注文するのは悪い 、アプリケーションをパートナーに配布する、またはウェブサイトを持っている（そしてウェブサイトを持っている）のではないかと強く感じていました。 私たちのサイト（ドメイン）は1998年のように、Dellの5年後に登録されました。 そして私たちは周りを見回した。



2000年代初頭には、毎年、ERPシステムの墓地に新しい墓地のある新しい柱がいくつか登場しました。 そして、「購入するもの」、「将来のシステムを構築するもの」に関する選択は非常に困難でした。 つまり、ベンダーロックを恐れていましたが、一方で、これらのERPシステムのロードマップを理解していませんでした。 さらに、ERPシステムにはかなり厳しいライセンス制限がありますが、それらは依然として存在します。 あなたが思うなら、なぜ1Cを取り、Bitrixをそれにねじ込んで、力とメインと取引しますか？ 1Cには、Web APIのプロキシを許可しない明確に構造化された制限がまだあります。 何らかの種類のXML APIがあります。つまり、1Cメソッドをプルできます。 ただし、この方法で理論的に使用できるすべての接続にはライセンスが必要です。 つまり、1Cで動作するサービスをリアルタイムでサイトに投稿する場合、すべてのライセンスを購入する必要があります。 1万人のユーザーがいる場合、1万のライセンスがまだ存在する場合は購入する必要があります。



別のアプローチがあります。 これはスタンドアロンのERPシステムとスタンドアロンのサイトであり、それらの間には何らかの交換があります。 しかし、私たちは難しいビジネス販売プロセスがあると言いました。注文のコストを計算するために、おそらく12個半か2個のテーブルを尋ねます。 これらは、ボリュームディスカウント、ヒストリカルディスカウント、ディスカウントリスト、特定のクライアントの契約、契約条項、通貨であり、ヨーロッパのリストでも何らかの価格リストが採用されています。 このアルゴリズムを書くことは、ある意味で苦痛です。 また、ERPシステムでこのアルゴリズムを記述する必要がある場合はどうでしょうか？ 一人が書いた。 それからどういうわけか、PHPプログラマーに行き、ここにはXMLで複製された25個のテーブルがあり、このアルゴリズムも繰り返すと言います。 もちろん、彼は繰り返しますが、最初のアルゴリズムではエラーが発生する可能性があり、2番目のアルゴリズムではすべてが間違っていることがわかります。 つまり、同じジョブを2回実行します。



そのため、 サイト中心のERPを構築することにしました。つまり、すべてのデータ、すべてのビジネスロジック、およびラップされたすべてを所有する1つのコアが単なるインターフェイスになります。 彼らはすでにいくらかの知性を持っていますが、ビジネスブロックは実際には含まれていません。 約2時間前に、CMSシステムとBitrix、市場で尊敬されるパートナーと競合他社を観察する方法について議論しました。最近、企業の1つが1Cの次のバージョンに切り替えました。 彼らは、「最大の1Cパートナーは何らかの金であり、私たちのプログラマーチームは1年間働いて実装した」と報告し、6か月間すべての機能を失ったことがわかりました。 なんで？ 彼らは古いサイトを捨て、新しいサイトを作らなければならないからです。 したがって、予約は電話で行われます。 さて、最後の要因は、サイト中心性に加えて、「ボックス」への恐怖が絵が描くものです。 これができると信じていました。







一般に、ストアドプロシージャでビジネスロジックを実行することは良くないと考えられています 。 私も恥ずかしがり屋でした。 私たちはこれを何年も続けてきましたが、Romanは私に言ったように思われ、ある段階で実際には私たちのような人がたくさんいることが判明しました。 私だけではありません。



神話は何ですか？



異なるデータベース間の移植性は失われます。 はい、あります。 維持するのは難しいです はい、Eclipseのストアドプロシージャは、どういうわけか、そうではありません。 展開方法 まあ チームで開発を行うことは困難です。 確かに、pl / sqlプロシージャ、fig-fig、および他の誰かが既にそこでコンパイルしています。 理にかなっているようです。 最後に、ストアドプロシージャの作成を開始した場合、シャーディングはありません。何らかの合成キーを使用して分散構成をどのように行いますか？ それも理にかなっているようです。



しかし、これは技術的に異議を唱えるのが難しいです。 子どもたちの質問に答えましょう。 「データベース間の移植性、そして誰がそれを必要としますか？」そのような対話を想像してください。 クライアント：「教えてください、アプリケーションを別のデータベースに転送できますか？」はい、少なくとも毎日、Microsoft-Oracle、Microsoft-Oracle。 そして誰がそれを必要としますか？







データベース間の移植性は、製品を販売する販売者にとってプラスの機能です。 しかし、この製品を受け取って使用するときには、それほど重要ではありません。



次のポイント：メンテナンスが難しい。 はい、全国に100のインストールがある場合、ボックス化された製品を維持することは困難です。それぞれに個別のストアドプロシージャがあります。 突然、遊び心のあるペンを持ったクライアントが何かをコンパイルし、すぐになんとなく神経質になり、展開方法、ロール方法を教えてくれますか？ なんとなく難しい。



繰り返しますが、この製品の消費者である場合は、自分で作成して使用し、インストール数が1万個ではない場合、これは問題ではありません。 大規模なチームでボックスを運転するのは難しいですか？ 私たちは中小企業であり、HighLodではなく、Yandexではなく、Googleでもありません。私たちは普通の納税者です。 Avitoが高負荷で浮上しているとき、私はYandex、Mail.RUを知りません。その後、私たちは通常の納税者であり、1Cでひざまで立っています。 大きなチームにはお金がありません。そのような角のあるプログラマーにはお金がありません。 私たちのチームは小さいです。 時間が残っていて面白い場合は、実際にどのように設計および実装したかを説明します。



しかし、レガシーコードサポートを開始するまでに、古いシステム、まさに1Cなど、および2.5人がシステムの作成、更新、および移行を行っていました。2人の本物のプログラマと私です。 つまり、大きなチームに関するものではありません。



私たちは何を残しましたか？



神話は残っています ： シャーディング、分散構成 。 シャーディングに対して、議論するのは非常に簡単です。皆さん、Skypeについて読んだことがありますか？ ストアドプロシージャ、 pgbouncer 、 pl / proxyなどにすべてがあります。 データベースでアプリケーションがそれ自体に直接登ることができない場合は、ストアドプロシージャをデータベースにプルすることしかできず、内部ではアプリケーションをだますことができます。 つまり、ストアドプロシージャなどでシャーディングを行うために、これは可能なことではなく、リクエストで必要な場合にも必要です。 pl / proxy 、 dblink 、 foreign data wrapperがありますが 、これらは存在しません。 すぐにシャーディングを行う必要がありますか？ これは昨日のレポートですでに議論されました。 一般に、現在、中規模のビジネスでは、YandexではなくMail.ruでない場合、これはそれほど重要ではないかもしれません。



なぜPostgreSQLなのか？



まず、 成熟したpl / pgsql 。 彼は98年目、さらには97年目にも登場しました。 厳格さ、機能性、学術的アプローチ。 Postgresのドキュメントを見ると、良いチュートリアルのように書かれています。 つまり、ドキュメントを読む必要があるシステム管理者を受け入れるとき、FreeBSDのマニュアルとサイトのドキュメントを使用してテストします。つまり、良い英語があり、すべてが明確で1か所にあります。 オープンソースと無料ライセンス -ここで言うことはありません。さまざまなリスクが軽減されます。 2005年に1C 7を導入した場合、多くの苦痛を経験し、いくつかの情報システムを変更していました。 データベースの変更は、それとは何の関係もありません。



そして、98年目のどこかでこのような面白いWebサイトができました。98年目にはPostgreSQLを立ち上げて作業しました。 私はそこにいなかったので、1年半で参加しました。 私の意見では、リリース6.4でした。 さらに、明確な開発計画。 私たちはまだ、公開されたウェブサイトのみを計画しており、パートナーに閉鎖されているのではなく、誰もが来れば誰でも登録できます。 1年半から2年がT-Searchになることはすでにわかっていました。 チームには、相互作用のためのオープンな開発者、優れたコミュニティがあり、しばらくすると何が起こるかを理解し、現実的な計画を立てることができます。 そして、それらは実現します。







ストアドプロシージャの悪い 面と良い面 。 あなたは巨大なIT企業ではなく、ボックスシステムでは満足できないビジネスであり、独自のアプリケーションサーバーが必要だと想像してください。 古典的な道をたどれば、Java、Cでこのようなものを書くことができますが、プログラマーに対するインセンティブは非常に高くなければなりません。 そして、すべての痛みはこれらのプログラマーにあります。 メモリの分配、必然的に発生するリークについて考える必要があります。何らかの種類のスクリプト言語が必要です。お金、取引、applikuhaを稼ぐビジネスに1日に3回「展開」できないためです。 ビジネスは外出先で順応する必要があり、停止することはできません。 また、スクリプト言語を使用すると、外出先でビジネスルールを変更できます。 何らかのプロファイリングも必要です。 一般的に、それほど単純ではありません。 それで、sgresはそれをすべて自分自身に取ります。



メモリリークについてはまったく考えていません。問題はありませんでした。 私たちは数ヶ月間そこにオンラインでいます。 そして、それが非常に痛く、更新したい場合、更新されますが、ランタイムはまったく停止しません。 メモリリークはありません。 これらは非常に優秀なプログラマーが私たちのために解決したものです。 私たちは、通常の取引ビジネスとして手近にあります。 スクリプト言語はpl / pgsqlであり、それを使用して使用します。 権利とスタッフのチェック、プロファイリング-詳細は後ほど。 しかし、問題も解決されています。



つまり、ダミー用のアプリケーションサーバーを取得します。これには制限がありません。つまり、手をつなぐORMのようなものはありません。 ある程度まで。 シンプルな言語、エントリの低しきい値。 プロダクションを与えられなかったが、どのように何を書くかを示したが、彼がリレーショナル思考を持っている場合、それは達成される、私の意見では、オブジェクト思考よりも少し早く、彼はすでにプロダクションに入れることができる通常のコードをすでに生成できている見て。 私は実際に20年後に退職し、pl / pgsqlコードを理解し、自分自身を少なく書く能力を保持していますが、コードを最適化できます。 つまり、この知識は長期間保存されます。



セキュリティは、2000年代初期に私たちが考えていたものです。ストアドプロシージャを介したSQLインジェクションを詰め込むのは非常に困難です。本当に足を踏み入れる必要があり、うまく狙う必要があります。 なぜそれが重要だったのですか？ 誰もがCMSシステムを作成し、1秒ごとに穴がいっぱいになりました。 2001年から2002年にかけて、CMSの束と10分の15〜20％のサイトで、何らかのインジェクションを掘り起こすことができたようです。



スライドの次のポイントは非常に物議を醸す-これはインターフェイスからの分離です。 数回、フロントエンドアプリケーション、一部の内部開発、またはエンドカスタマーがアクセスできないサイトを、パートナーのみのために公開しました。 コードはあまりなく、すぐに別のテクノロジーに移植され、ビジネスロジックをまったく失うことはありませんでした。 インターフェースからの分離は、どこか善であり、どこか悪である。 そして、ビジネスロジックがパフォーマンスとは関係ない場合、フロントエンドでテクノロジを変更できます。



2000年代初期に戻りましょう。 そこで変更されたインターフェイステクノロジーの数は？ インターネットインフォメーションサーバー上のVisual Basicでプログラムする必要があります。 誰かが真珠、PHP、Rubyを見て、これらすべての言葉からどこにも行かない。 インターフェイステクノロジーは非常に急速に変化し、SQLはまだ生きています。 私たちのシステムで最も古い関数は、あなたが遺物に近づくにつれて1998年に書かれました。 確かに、先日見ましたが、このコードは機能します。 つまり、12年前に私たちが書いたものは、まさにそのランタイムで動作します。いずれにせよ、だれもこのサークルで「だれもPHPにいませんか？」 SQLは通常の言語ですが、どこかで制限されています。 ビジネスロジックの長寿命は便利です。







悪い面



断熱性が良い 、はい。 基本的に、優れたアプリケーションサーバーがあれば、ビジネスロジックがあり、ACLはインターフェイスと密接に関連しています。 従業員向けの内部プログラムとWebサイトという2つのインターフェイスがあります。 そして、両方のアプリケーションは非常に異なっています。 この知識とスキルを共有することは、長寿命のアプリケーションサーバーを入手するほど価値がありませんでした。



統合された開発ツールはありません—はい、本当です。 バージョン管理システムとの接続がpgAdminに統合されていて、コードが少し強調されている場合、それは置き換えられました...ここで、まだ痛みがあります。 私たちの中にはpgAdminで働いている人もいれば、自動置換のためにems-sqlが好きな人もいますが、やるべきことがあります。



次の瞬間。 キャッシングの問題は解決せず、 メモリの割り当ての問題も解決しないと言いましたが、十分なキャッシングがない場合は進歩しますが、新しい抽象化レイヤーがあります。 これはあまり良くありません。 フロントエンドを満たすことができないビジネスロジックを書いたプログラマーがいる場合、いくつかのミドルウェア（おそらくフロントエンドプログラマーが何らかのJavaまたはCで記述します）が表示されます。 これは実際には難しい問題です。 キャッシュとキャッシュの無効化は2つの問題の中で最も難しいため、理論的には最も困難です。 誰もが2番目のことを知っています-変数に正しい名前を付けるため。



場合によっては、ストアドプロシージャを作成するときに、時間通りに停止するのが難しいことがあります。 私たちのJavaプログラマーは、pl / perlとmimeで文字を作成して送信するストアドプロシージャを書いたので、私を捕まえました。 これはもうしません。







中身は？



これで9.4ができました。 開発は7.4から始まりました。 7.4を手にした人はいましたか？ ストアドプロシージャを作成しましたか？ この痛みを感じた人もいます。 見えなかった人にとっては、ストアドプロシージャの本文は一重引用符で囲まれていました。 そして、構文はそこに正確に強調されていませんでした、すべてが化膿した茶色でした。 しかし、これに決心した勇敢な人々がいました。 私たちのビジネスロジックは3千のストアドプロシージャであり 、それほど大きくはありません。コードの量で計算できます。 最初に多くのコードを作成した場合、現在は過去5.5〜6年間でそれほど多くないことに注意してください。 コードはかなりパフィーです、コメント、関数ヘッダーがあります。 これはおそらく、Andreiが話したコードではありません。プログラマが1日80行を取得するのは難しいことです。 データベースは十分に正規化されており、700のテーブルがあり、それらの数百は分析であり、近い将来にそれを引き出します。 おそらく少し速く成長していますが、ベースはほぼ同じです。



短い取引が大好きです。 短いトランザクションは高速な作業を意味し、膨張したインデックスの「オーバーヘッド」はなく、ロックを待機します。 短いビジネス関数を記述できる場合、それを短くします。 constrates 、 外部キーなどが大好きです。 なぜなら 、膨大な量のエラーがなくなるからです。 昨年、1つの機能で「定数」の違反が発生しました。これは、ほぼ6年間機能していました。 それに間違いがありましたが、それはめったに現れませんでした。 例を挙げるのは難しいです。 しかし、店主が左手で1箱、右手でもう1箱を取り出し、バーコードスキャナーを鼻で押してそこに何かを移動すると、このエラーが発生します。 そして彼女は起きなかった！ 制約が機能したため、私たちは彼女を捕まえました。 一般的に、制約は適切であり、足元で自分を撃つことはできません。



テーブルは正規化されていると言いますが、 非正規化が大好きです。 非正規化は主にサイトで必要です。 さまざまなデータをかなり広いテーブルに詰め込んでおり、サイトのインターフェースは非常に高速です。 与えるのは簡単で、「結合」はほとんどありません。



ORMと「コードジェネレーター」は嫌いです。ORM自体のイデオロギーは矛盾しますが、踏み込んだとき、なぜ私たちを混乱させるのかを説明できます。







フロントエンドはtomcat + nginxで 、いくつかの製品を実行します。 サイトに加えて、イントラネット製品（CMSとCRMは異なります）、レポート（Jasperのスタンドアロンサーバー）もあります。 Borland C Builderで開始された内部アプリケーションがあり、現在はEmbercaderoです（ほとんど開発されておらず、そのようなインターフェースはますます少なくなっています）。 これらはすべてpgbouncerを介して機能しますが 、これには個別の感謝の言葉があります。 分析、SEO、呼び出しを行うアスタリスクなど、まだ多くのことがあります。 また、データベースに統合されており、同じビジネスロジックを使用しています。







どうぞ 実際、1つの実稼働サーバーがあり、2つ目はレプリカであり、テスト用と分析用のオフロードです。サーバーはごく普通のものですが、ハードウェアを節約しませんでした。ご覧のとおり、負荷はそれほど大きくありません。LAは 3よりも高くありませんが、現在、夏、冬に深刻になる可能性があります。なんで？取引会社では、ソーシャルネットワークとは異なり、非常に小さなホットデータセット。 10万人の顧客から20個のアクティブな商品、10万人の顧客からのアクティブな商品があります。数字を明らかにすることができます：シーズンあたり40分間の粗利益（税引前純利益）により、このようなサーバーを購入できます。そして、これもまた、シャーディングについての言葉に戻ります。



これらの数値は、コードを控えめに記述する場合、アプリケーションで「SELECT *」サーバーを減算しないことを意味すると考えてくださいJavaのサイクルで2つのテーブルを結合せずに、非常に控えめなアイロンで対応できます。そして、オフロードにはレプリカをまだ使用していません。つまり、サイトからの読み取り要求は戦闘クラスターに送られます。



SSDは使用しません。ここで私は認めなければなりません、そのような間違いがありました：私たちにはサーバーを非常に細心にテストするネットワークエンジニアがいます。そして、私たちは現在、誤ってRAID5の「生産中」になっており、バッテリーが切れたときに誤って気付きました。







どうぞ私たちは笑いで終わりましたが、ここでは少し退屈になります。どのように機能しますか？前述したように、単一のアプリケーションが汚い手で直接データベースにアクセスするのではなく、各アプリケーションは独自の役割で実行されます。すべてのストアドプロシージャは、さまざまな方法でレイアウトされます。



ここで何が見えますか？ Webグループや雇用者グループ



などのフォルダーロールがあり、これらにはほとんど権限がありません。また、アプリケーションロールはこれらのフォルダーロールに詰め込まれています。アプリケーション「サイトのロール」（ウェブ）および一部のロール「従業員」（「従業員」アプリケーション用）。1万のステートメントタイムアウトに注意してください。。なぜこれが行われるのですか？これは、サイトが10秒以内に実行されない要求をプルすることに成功した場合、その要求は破棄されることを意味します。実際、答えは簡単です。どこかに何かが詰まっていて、サイトのユーザーがそれを弱め始めているが、データベースがそれを与えない場合、それは誰にとっても悪化するだけです。怠solを解く必要があります。ロールバックされたトランザクションはまだバッファキャッシュをウォームアップしていることに注意してください。ユーザーに何も提供しなかった場合でも、彼女はそれをバッファキャッシュに配置しました。数人の実行者（1万人、2人が実行）を取得すると、キャッシュベースをウォームアップし、3番目の要求は既に成功しています。そうしないと、プールがオーバーフローし、Javaが理解し、pgbouncerに十分なソケットがない可能性があります。



次に、スキームを作成し、各アプリケーションにスキームに対する権限を付与します。顧客がWebアプリケーション（WebGroup）と内部グループからのアプリケーションの両方を入力できることは明らかです。人がオフィス内ですべてを行う方法を知っている場合は、すべてがサイトにあるようにします。そして最後の段落では、アプリケーションが入力手順のコードとデータスキームを見ることを禁止しています。



実際、これはすでに多すぎます。誰かがあなたのアプリケーションをハッキングした場合、彼はあなたの秘密テーブルを見ることができません。彼はデータを読み取ることができず、ここでもストアドプロシージャの名前は表示されません。







関数はどのように見えますか？ in_SessionID



入力パラメーターを持たない最初の単一の関数は許可です。個人が、パートナーとして私たちと協力することではありません50同じ会社に所属しているので、ドメインレジストラのように私たちにとってより便利です。会社の入り口、1つのログイン、パスワードです。この関数はセッションを返し、定義に注意を払います。これはセキュリティ定義者であり、内部アプリケーションと外部グループの2つのグループをプルする権利があります。







他のすべての関数には入力パラメーターSessionIDがあります。これにより、一度ログインし、セッションをユーザーに関連付け、ブラウザーCookieまたはアプリケーションのメモリで発行し、他のすべての関数をプルできます。これらは常にSession入力パラメーターを持ち、誰が呼び出しているかを復元するために内部的に操作されます。つまり、OrderCreate関数、サイトまたは内部アプリケーションから呼び出され、単一のユーザーから実行されます。その内部で、システムのどの被験者が現時点でそれを引っ張っているのかを判断できます。



サイトにある機能についても説明します。OrderCreate関数には、顧客を指定するCustomer入力パラメーターが必要であることは明らかです。ここでそれをカバーします。CompanyIDはセッション中に表示され、ある会社は別の会社の注文を作成できません。







さらに、ACLで解決する必要があります。ここは非常に素早く滑るでしょう。なぜなら、これは深い領域であり、たくさんカットする必要があるからです。各ドメインテーブル（顧客、キャンペーン、注文、契約、価格項目）には、オブジェクトのテーブルへの投影があります。つまり、顧客のテーブルレコードには、object_idとobject_type = 84のテーブルレコードがあります。それは何を与えますか？プロパティ、ライフサイクル、いくつかの制限、サブジェクトエリア内のオブジェクトのこの統一された表現のロックを掛けて、この上に権利チェックを構築できます。







したがって、注文を配布し、マシンを出荷するサブジェクトエリアの各機能内には、権限をチェックする機能があります。この関数をプルして、オブジェクトID、オブジェクトのタイプ、および「アクション」のタイプを渡します。彼女は自分の内側でOKと言うか、例外を投げます。例外をスローすると、アプリケーションで簡単にキャッチできます。コネクタ（JDBC、カスタム）は、これらの例外を適切にキャッチし、クライアントに渡します。ユーザーはエラーを受け取り、分析できます。クライアントでエラーを診断する必要はなく、何かをフィルタリングするだけであれば、そのようなパラメーターを渡します。かなり厄介に思えますが、実際には、この方法で権利を確認することはプログラマの作業の目に見えない部分であり、ビジネスロジックの作成を妨げることはなく、統合を作成するだけです。







すべてが問題なくできましたか？



いやこれは、私たちが始めた瞬間を描いた悲しい写真です。写真の一番下にあるのは2009年の秋です。私たちは何を得ました。私たちにはウェブサイトがあり、約200人、300人が成長しました。 5〜6の接続が同時にプールに発行され、さらに60〜70の接続が内部アプリケーションによって占有されました。 60人のユーザーが社内で働いていたため、なぜプールを必要としたのかを直接判断しました。突然痛みを感じました。サーバ16個のコアは、すなわち4ソケット4コアはかなり2009年まで冷却して、そして我々が見たときLA 60、16コアを...



理由は何がありますか？



この問題はもう存在しませんが、私はあなたにそれを話さなければなりません、それは一種の自動訓練です。そして第二に、あたかも警告するかのように：常に長老に耳を傾けます。 pgbouncerは必要ないと考えました。原則として、すべてを通常どおりに実行する場合は必要ありません。ただし、進行中に開いた各セッションでは、ON COMMIT DELETE ROWSタイプのストアドプロシージャが初期化されました。 9.1または9.2より前のバージョンでは、後で学習した機能がありました。各トランザクションの開始時に、各接続のタイプON COMMIT DELETE ROWSの各一時プレートにTRUNCATEが提供され、トランザクションの終了時にTRUNCATEも送信されたことがわかります。つまり、100個の結合があり、それぞれにON COMMIT DELETE ROWSタイプの30個の一時テーブルがある場合、3,000個の一時テーブルがあります。そして、これらのテーブルがどれもトランザクションに関与していなくても、このTRUNCATE二度務めた。あなたは何が起こっていたか理解しています。



Postgresがオープンソースであることはどのように役立ちましたか？



しばらく苦労してクロールし、トランザクションの開閉を確認した「プログラマー」プログラマーがいます。 「通知」を入れて、この切り捨てが行われているのを見ました。私はサイトのウェブサイトに登り、壊れた英語で郵送に書いて、あなたがあれこれあれをするたびにそれを書いた。それに応えて、トムレーンが言ったとき、私はショックを受けました。一時テーブルをクリーニングしていることは驚くことではありませんが、それを含めて、私たちはあまり良くありません。」そして、ブルース・モムザンは自分自身を引き上げました。彼がここにいるなら、私はまったく期待していませんでした。そして彼はこう書いた：「皆さん、心配しないでください。これを個人のtodoリストに含めて、公式のtodoリストに載せようとします。」そしてそれが起こった。すぐに解決策を見つけました。まず、pgbouncerをコンパイルしました。そこでは7分かかりました。照明の7分後、この[約Ed。：スライドのグラフの右側をご覧ください]。つまり、負荷が低下し、非常に快適になり、接続がハングしなくなりました。トランザクションの開始中にいくつかの問題があり、15ミリ秒のわずかな遅延がありましたが、それで既に生きることができました。私の意見では、年末までに私たちはこのスキームで生活し、今シーズンの顧客数を3倍に増やしました。ブルースとコミュニティに感謝します。







問題があります。間違いがあり、それが何であるかのヒントさえあるような行があります。欠点がありますpl / pgsqlビジネスロジックコードがそうであるように、データベースは厳密であり、あなた自身を保護する機会がたくさんありますが、コードはあまりよくテストされていません。気づかない人は、val2とval3の間にコンマがありません。すべてのval-s（i1、i2、i3、i4）にユニットを渡すと、どの結果が通知を生成するかを推測します。 「通知」には4つの数字があります。どれ？最初と2番目はsingleで、3番目と4番目は？NULLになります。そして、それと一緒に暮らす方法は？ギャップを見て、進歩は単に他のすべてを無視します。このことについてはニュースレターにも書きましたが、誰が答えたのか覚えていません、グレッグ・スミス、「pl / pgsqlはSQLコードの遺産だからです。」SQLで使用できる構文は、ここで翻訳されています。はい、これは問題ですが、これは私たちが遭遇した数少ない問題の一つです。



次の問題はドキュメントです。これは、私たちが経験した最も重大な事故の物語です。テーブルにDROP CASCADEを配置すると、通知ですべての例外が除外され、カスケードで削除されるすべてのオブジェクトが表示されます。外部キーで関連付けられた5〜6個のテーブルがある場合、truncateと言います。テーブルに従って、2番目のテーブルがクリアされると回答されます。彼は彼女の後にさらに4人が掃除されるとは言わないでしょう。そして、私たちはそれに出くわしました。ドキュメンテーションで、そうだったと本当に言われましたが、そのようなことが起こります。



最後の問題は問題ではなく、むしろ驚きです。読み取り専用の要求がレプリカでオフロードされるように、pl / proxyを試すことにしました。pl / proxy はrefカーソルをサポートしていないことが判明し、refカーソルが本当に好きです。すべてのデータベースコネクタはカーソルをサポートしているため、簡単に変更でき、レコードとは異なり、機能間で転送できます。すべてがカーソル上に構築されているだけです。JSONがあった場合、JSONで構築します。現在、フロントエンドサイトをJSONに転送するかどうかを検討しています。その後、pl / proxyを介してアンロードし、ストアドプロシージャに基づいてすべてを「断片化」することは不可能であるという神話に反論することができます。カーソルを使用しない場合は可能です。







私たちの人生はどうですか？



プログラミングについては少しお話しますが、プログラマーは悪いですが、最適化については知っています。すべてのビジネスロジックがストアドプロシージャにある場合、誰が責任を負うべきかを常に把握できます。データベースにアクセスする人は誰でも、ストアドプロシージャをたどります。そしてpg_stat_user_functionsのおかげで、それに関するすべてを知っています。



何してるの？



このビューでは、pg_stat_user_functionsスキーム、プレートの名前、コールの合計数、合計実行時間、サブミリ秒の解像度を持つ関数の適切な実行時間があり、すべての場合に十分です。







1日2回、午前8時と午後8時に、ほとんどがモスクワとサンクトペテルブルクのクライアントであるため、このビューの結果である独自のプレートを挿入します。朝と夕方にスナップショットを保存します。







その後、更新します。コール数の差、合計時間の差、セルフタイムの差を計算します。これにより何が得られますか？







何かが遅くなったらすぐに確認します。先週、今週を過去と比較すると、どの機能がより頻繁に、またはより高価に呼び出されましたか？そして、彼女を見つけました。それだけでなく、絶え間ないリクエストがあります。これは、コンソールに表示され、劣化した機能を示しています。これらの障害はどこから来たのですか？いくつかの理由があります。第一に、それは可能性があり、スケジューラスキュー、忘れられたコードは、新しいバージョンを更新し、うまく機能するために使用任意のアルゴリズム、およびいくつかのコマーシャルを。すぐに点灯します。つまり、不明な要求を懐中電灯で追いかける必要はありません。要求は、どのフロントエンドから来たのか、誰が呼び出したのかが不明です。問題がすぐにわかります。



しかし、pg_stat_functionはすべての問題を解決するわけではありません。なんで？まず、カーソル。カーソルを返す関数がある場合、1分間フェッチでき、その関数は1ミリ秒間動作しました。つまり、上部に遅いカーソルは表示されませんが、多くのカーソルがあります。



関数には分岐があります。たとえば、注文を開始する機能があります。それは人の手で起動することができ、権利のチェックがたくさんあります。またはお金が来て、イベントを送信し、注文を処理しました。つまり、関数の分岐は、異なる条件で同じ関数を非常に異なる時間に呼び出すことができる場合です。ポイントロード



があります。非常に重要なビジネス機能があります。たとえば、1人は1日15分間そこで働いていますが、多くはこれに依存しています。そして、人からゆっくりと負荷が増加しますが、彼は気づきません。これも明らかになりました。もっと深く行きます。



pg_stat_statementsを使用します。また、作業シフトのデータを最初と最後に保存し、同じことを分析します。しかし、それはより多くを与えます。







これはpg_stat_statementsへのリクエストがどのように見えるかです。注目すべきは、ストアドプロシージャのアトミックリクエストがpg_stat_statementsに到達することです。そこに式があります：そこにデータを抽出し、セミコロン、改行、コメント、データを更新します。これらの2つのフラグメントは、コメントと「ユーザーフォーマット」など、非常に便利なpg_stat_statementsに分類されます。







外観は次のとおりです。一番上は一般的なリストのようで、一番下は興味のある断片です。参照カーソルを呼び出して返す関数内に1つのアトミック式があり、この「ビュー」に3回入ります。関数自体がキャッチされ、即座に機能し、地下2ミリ秒のどこかに配置されます。 SELECTカテゴリヒットのアトミッククエリとカーソルヒットのフェッチ。それらは簡単に識別できます。つまり、カーソルに問題がある場合、関連付けられている機能がわからないため、ほぼ時間的に一致し、呼び出し数が正確に一致するアトミッククエリとカーソルを自動的に分析し、それらを比較できます。役に立つトリック。



2行目では、名前付きカーソルをフェッチします。フロントエンドがストアドプロシージャを呼び出すときに、このプロシージャの名前でカーソルに名前を付ける方法を知っていれば、ログのどこにでも直接表示されます。また、便利なトリック。pg_stat_statementsに







感謝します潜在的に悪い場所を見つけるのは簡単です。どれ？第一に、更新は常に高価であり、第二に、私が言ったように、あなたのコメントさえもpg_stat_statementsに入る。したがって、誰かがリクエストに対して「TODO」または「ここで何かがおかしい」と書いた場合、pg_stat_statementsに行き、疑問のあるコメントを含むクエリがある場合は最初に探します。そして、あなたはすぐにそれらを見つけます。とても速いです。



そして今、痛みについて少し。 2枚目または3枚目のスライドを見ることができた私たちのフロントエンドサイトはLiferayに基づいています。そこからほとんどすべてを飲みましたが、何かが残っていました。そして、何かが休止状態です誰が彼がテーブルに書いたものをエミュレートする必要があります。はい、このLiferayはユーザープレートを作成します。実際、彼はキャッシュします。つまり、彼はそれのほとんどをキャッシュしますが、私たちが得た小さなものはここにあります。 Liferayを完全に休止状態で飲むと、実際には20倍以上が忘却のどこかに行きます。 Hibernateリクエストを表示したかったのですが、それが合わないことに気付きました。これは対処が難しいです。



しかし、人気のあるビジネスソフトウェアのサプライヤで問題が発生した場合。請負業者が導入したサービスを提供しないシステムが構築されています。彼女はMS SQLサーバーという例外を投げました64キロバイトを超える要求を実行できません。 64ビットのエンタープライズバージョンを購入する必要があります。一般に、MS SQL Serverの制限は、65536バイトの要求を実行できないことであり、これをサポートするバージョンはありません。セールスマネージャー、ヘルプデスクマネージャー、ビジネスロジックを書いた後輩、そして10メートルのどこかに1Cコードジェネレーターを書いた人がいるという事実のために、私たちは彼らに直接電話します。これが正常であると考えてください。



なぜこれが重要なのでしょうか？私たちは小さな会社です。小さなITスタッフがいます。多くの人々がこれらのレイヤーの責任を共有する必要があるため、このような重いテクノロジーを購入する余裕はありません。これに到達するのは難しいです。ここでの







最適化



は非常に短く、おそらく誰もが知っています。我々は持っている統計更新、挿入、除算 テーブルでは、死んだ「タプル」、インデックスの治療に関する統計を。これはどのように使用できますか？ とても簡単です。10ポジションの注文の各ビジネストランザクションについて、各ポジションを1回更新する必要があると思われる場合は、トランザクションを開始し、カウンターを削除し、トランザクションを完了し、カウンターを削除して、10回処理されたことを確認します。場合によっては、各アイテムがn階乗回数更新されることが判明します。nはオーダー内のアイテムの数です。そして、あなたは理論が実践と対立していることを理解しています。アルゴリズムを探していて、それを見つけています。これらはサイクルです。サイクルは常に痛みの原因です。これらは忘れられた条件です。つまり、データを正しい値で更新しますが、それ以上必要ない場合は「停止」と言い、それでも更新します。



時々、これはDISTINCTを行うのを忘れたサブクエリ、つまりWHEREリクエストです...ID INであり、多くの一意でない値を返すため、問題が発生します。そして、もちろん、忘れられたインデックス。







そして最後に、私は時々まれなビジネス機能があると言いました、人が1日に1回、渋々と彼らに近づき、機能がよりゆっくりとゆっくり動作するとき。記録は次のとおりでした：15分の仕事からの人は2時間の仕事に変わりました。そして、誰も彼のリーダーさえ知らなかった。偶然見つけたとき、ただの喜びとシャンパンのスプラッシュがありました。で、私たちはしなければならないことを常にログストアドプロシージャ探る、トップで機能pg_stat_statementsビューでは、キャッチ異常をpg_stat_functionsコードをクリーンアップするだけです。ブルックリンブリッジをペイントするようなものです。トップ5を最適化すると、さらに多くの新しいブリッジが表示され、円を描くように歩きます。しかし、これはユーザーの快適さの鍵です。



最終的に、一時テーブルを削除しました。一時テーブルは、2009年に痛みを引き起こしました。トランザクションごとに切り捨てる必要があったためです。レガシー コード、ウィンドウ関数、再帰クエリの削除に成功しました。これはある種の奇跡です。ほとんどの場合、この機能について記述したすべてのコードは、より高速にインストールされ、読みやすくなります。



最後に、何らかの複雑な場所がある場合、どのように関数をデバッグしますか：クロックタイムスタンプ前に通知し、後に通知し、時間を見ることができます、プロファイルすることができます。







どのようにコードを管理しますか？



先ほど言ったように、現在3,000の関数があります。昨年、私たちは非常に大きな更新を行い、ほとんどのビジネスロジックを改善し、サイト用に更新しました。誰もが満足していました。私たちは大量のコードを投げました：壊れたインターフェース、壊れた機能。それを取り除く方法は？ EclipseまたはIDE IDEAのどこかで、クラス、メソッド、これらすべてをリンクできますが、このアプリケーションが実際に使用されているかどうかはわかりません。ビジネスロジックがすべて関数で記述されている場合、pg_stat_user_functionを使用すると、関数が呼び出されているかどうかがわかります。



3か月間働いている場合は、統計を見てください。まったく呼び出されない関数が見つかります。そして私達はこうして千年にわたってほぼ千の死んだ機能を蓄積した。クエリの助けを借りて、1分（おそらく2時間）考えずに、これらの関数と回路の名前を受け取り、それらを " to-delete " スキームに転送するストアドプロシージャを作成しました。驚いたことに、2週間で機能が欠落している例外は2つしかありませんでした。 1つの機能はいくつかの制限を切り替え、それは「離婚」と呼ばれ、もう1つは私の個人的な機能でした。私は長い間公式のニーズからそれを呼び出しませんでした。



つまり、これは良い機会であり、おそらく他の場合には利用できません。 1つの統合環境でコードをプロファイリングおよび開発できるだけでなく、同じ環境で強力なコードを再設計できます。 UIDを取得する前に、SessionIDデータ型を再編集したら、int8を使用しました。 Liferayとの互換性のために、インターネットに出かけることにしたときは、UIDに切り替える必要がありました。 pg_procを分析するいくつかのスクリプトを使用して、DROP FUNCTION、CREATE FUNCTION、および変更されたデータ型を実行する大規模なSQLスクリプトを作成しました。これらはすべて、1トランザクションで夜間8分で実行されました。 2500のストアドプロシージャが変更されました。







希望と期待 JSONとJSONBに



大きな期待。：先ほど言ったように、これはカーソルの問題です。これを取り除いて、PL / Proxyを銀の大皿の上に置きます。第二に、いくつかのインターフェースをAndroidに転送するという期待があり、JSONは非常に便利です。サイトのあらゆる種類のフィルターとACLをJSONに絞り込んで、非正規化することは可能です。インデックスにはどんな素晴らしいことがあるかを考慮して、非常に高速に動作するはずです。BRINインデックスに非常に満足しています、分析があるため、別のデータベースに転送されます。そして、BDRと論理複製-なぜそれが必要なのかまだわかりませんが、実際に試してみたいと思います。まず、分析の問題を解決します。つまり、一部のデータを別のデータベースに選択的にプッシュできます。次に、分散システム（Avitoなど）を作成することもできます。



さて、Avito、Yandex、Zalando、Pivo​​talなどの小規模だが成功している企業と最大の国際的な企業の両方のリーダーからの最も興味深いサクセスストーリーのみを準備し続けています。レポートの申請は、会議Webサイトで確認でき、最も関連性のあるトピックに投票できます。