DZ Online Tech：Postgres Professional

こんにちは



昨年、私はデジタルビジネスの変革のトピックに関する一連のプログラム/インタビューの撮影を開始しました（ 興味のある人のためにここにいます-サインアップ ） これらのプログラムは、ITとビジネスの交差点にありましたが、それでもビジネスに関するものでした。



その過程で、プログラマーの観点からかなりの深さを持つ多くのものがあることが明らかになりました。 そして今年、私たちは共通のラベル「DZ Online Tech」の下で一連のインタビューの撮影を開始しました-今では内部にあるものに重点を置いています。 もちろん、誰もがビデオを見るのが面倒なので、これらのインタビューは解読され、今日私は最初のインタビューを公開します-Postgres ProfessionalのIvan Panchenkoと。



誰がオリジナルを気にしている-ここにある：





（ところで、すべての問題が復号化されることを誓うことはできませんので、気に入った場合はYouTubeにサインアップしてください。



読むのが好きな人のために-復号化：



こんにちは、イヴァン。 Postgresは、インポート置換ツールとして広く受け入れられています。 そして、そのアプリケーションの最も有名なドライバーは、「西部のDBMSをPostgresに置き換えましょう」というアイデアです。 さらに、彼には多くの彼自身の価値があることが知られています。 それらについて簡単に説明したいと思います。 「インポート-インポートではなく」ではなく、ゼロから選択した場合、なぜですか？



こんにちは 第一に、ほとんどのPostgresはインポート置換のため選択しません。 外国のソフトウェアの輸入には、実際に政府の措置と制限があることは明らかです。 Postgres Proはレジストリにあるため、インポート置換に適しています。 実際、これはPostgresをますます選択する世界的な傾向です。 その反射のみが表示されます。 輸入代替で表現されたものは、実際には、より深い、より基本的なプロセスの結果である可能性があります。



Postgresは熟しています。 これは、古い商用データベースの優れた代替手段です。 世界中で、彼らはPostgresがクジラと同じクラスの製品であることを理解しています：Oracle、Microsoft SQL Server、DB2、最後のものはほとんど忘れられていますが、それにもかかわらず、これは良い製品です。



しかし、いずれにせよ、DB2はどこかから徐々に市場から離れていき、Oracle、Microsoft SQLが市場に出ています。 そして、Postgresは今や世界規模で市場に流れ込んでいる3番目の存在です。 かなり前に浮かんだと言わなければならない-10年前、PostgresにWindowsの良いサポートが登場したとき。 複製が彼に現れたとき、彼らは彼を知覚し始めました。 彼らは彼をビジネス、産業、そして深刻な何かのデータベースとして話し始めました。



あなたはまだ写真の中に「2つの良いものがあり、もう1つ良いものがあります」と言います。 しかし、彼を前に出し、他の人を好むようにするものは確かにあります。



はい、そのようなことがいくつかあります。 1つ目は、Postgresが特定のライセンスを持つオープンソース製品であることです。 彼は商用クローンも持っています。 それらの1つは私たちのものです。 しかし、それがオープンソース製品に由来するという事実自体が大きな利点です。



2番目のトピックは、Postgresが高度に拡張可能なデータベースであることです。 これも開発の推進力でした。



Postgresの拡張性の程度は、ロシアの貢献が最も顕著である場所であると言わなければなりません。 過去15〜17年間、私たちのチームは主に拡張メカニズムに取り組んでいます。



たとえば、2000年に現在の会社の同僚と初めて仕事をしたRamblerでは、Postgresの拡張性を使用して、Ramblerニュースサービスのパフォーマンスを30倍向上させました。 どうやって？ 私たちはドキュメントを読むことができるCプログラマです。 これらの2つのことにより、配列をすばやく検索するための新しいタイプのインデックスを作成できました。これは、従来のリレーショナルモデルの範囲を超えていますが、有用です。



特に、ランブラーでは、余分な結合をトリッキーなインデックスで検索できる配列に置き換えると、生産性が30倍向上しました。 それから、すべてのランブラーコンテンツプロジェクトは、最新のスマートフォンのパワーを超えないタイプライター（Pentium 2、400 MHz、500 MBのメモリ）でスピンしたことを理解する必要があります。 運がよければ、Pentium 3（当時登場した）最大800 MHz。 サーバーには、このようなPentium 3が2つある可能性があります。 そして、これらすべてが何百万ものリクエストに応えました。



当時はコードを非常に真剣に最適化する必要があったことは明らかで、そうでなければ機能しません。 Postgresの拡張性が役立ちました。 私たちは座って考え、許容可能な時間枠内で、1か月間言うことができます。そして、全文検索を使用して、JSONに関連する現在のPostgresにあるすべての基礎を形成しました。



このため、Postgresは構造化されていないデータのサポートを迅速に開発しました。 これは何ですか これらは、おおまかなキーバリューです。 2004年に、同じデータベースフィールドにキーと値の情報を保存するために、PostgresでHstoreを拡張しました。 それはまだJSONではなく、後に流行になりました。 そして、Hstoreがありました。 なぜhstoreなのか？ ハッシュを持つPerlを見て、Postgresでほぼ同じ構文でハッシュを作成しました。



最初は、このことは別個の拡張（拡張）として存在していましたが、Postgresに含まれるもののメインセットでコミット（コミット）されました。 そして彼女は同じように人気がありました。 つまり、JSONは最近、その人気を一巡しました。



ある意味で、同時に両方のプロパティを持つDBMSを作成することにより、SQLとnoSQLのこの愚かな議論に終止符を打つことがわかります。



ある意味、はい。 noSQLからは、トランザクションの損失、データの整合性、および通常のDBMSで通常発生するすべての損失なしに、優れた比較柔軟性が得られました。



だから、Hstore。 しかし、Hstoreは兄弟でした。 つまり、ハッシュは単一レベルです。 これはJSONではなく、単なるハッシュです。 そして、Postgresのプラス配列は私たちの前にありました。 インデックスをサポートしました。つまり、配列に含まれるものと、Hstore内にあるもの、キーと値の両方ですばやく検索できます。 これは便利なことです。 人々は世界中でそれを使い始めました。 次にJSONが登場しました。 彼は最近、Postgresで2011年から2012年に登場しました。 それを実装するための3つの異なる試みがありました。 その後、これらすべての試みがスローされ、異なる方法で行われました。 最初は、JSONは特別なフィールドにある単なるテキストでした。



あなたのチームはJSONを実行していましたか？



いいえ、私たちのチームはJSONに対して重要なことをしました。 JSONがPostgresに登場したとき、それは単なるテキストフィールドであり、そこから何かを抽出するために、検索値は毎回JSONを解析する必要がありました。 もちろん、これはゆっくりと働きましたが、マルチレベルのデータを保存できました。



しかし、そのようなテキストボックスにはあまり意味がありません。 たとえば、私のプロジェクトでは、特殊なタイプのフィールドと呼ばれることなく、弱い構造のデータをテキストフィールドに既に格納しています。 しかし、問題は、このJSONでは効果的に機能することも必要だったことです。 そして、2014年にチームで既に行ったことはJSON-Bです。



すでにレイアウトおよび解析されているため、高速です。 あなたがすぐに重要な価値を得ることができるように蒸しました。 JSON-Bを作成したときに、インデックスで検索する機能を固定し、それが非常に人気を博しました。



わかった 特定のプロパティに戻る：Postgresと他のDBMSを区別する他に何があり、それを使用する理由は何ですか？



これまで長い間JSONについて話してきたのは、すべてPostgresの柔軟性です。 展開できる場所がたくさんあります。 柔軟性のもう1つの側面は、ジオデータのサポートです。 JSON、配列、テキストによる検索など、特別なインデックスが作成されたのとまったく同じ方法で、地理情報、空間データによる迅速な検索のためにほぼ同じ場所でインデックスが作成されました。 また、この問題にかなり大きなロシアの手を入れました。



その結果、PostGISは、地理情報データを操作する世界で非常に一般的な方法です。



ユーザーはプロジェクト用にPostgres拡張機能を開発していますか？ これはアプリケーションのかなりの量ですか？



いいえ、もちろん、これらは上部にある「クリーム」のようなものです。 彼らの仕事がこれに成長するので、それを必要とする人々がいます。 まず第一に、これはすべての標準を非常によくサポートし、ほぼすべてのタスクに確実に適したユニバーサルデータベースです。



たとえば、スタートアップを開始する場合-Postgresを使用すると、間違えられません。 第一に、機能的に拡張可能であるためです。 次に、オープンソースバージョンを使用する場合は、購入する必要があるライセンスの人質にならないでください。



あなたは、商業掘りの従業員として、おそらく、それほど幸せではないと言っていますか？



これらは自然の法則であり、それに対する議論はありません。 オープンソースがあり、オープンソースビジネスがあります。 そして、これは通常のビジネスとは異なり、かなり珍しいことです。 しかし、将来的には、明らかに、オープンソースの役割は大きくなるでしょう。 少なくとも、これはPostgresの成功と、誰にとっても退屈なGartnerのスケジュールで見ることができます。オープンソースデータベースはますます使用されており、回避することはできません。







あなたは会社として、なぜあなたは必要なのですか？ ここで彼はオープンソースです：行って、ダウンロードして、すべて順調ですか？



実際、ダウンロードしてダウンロードしましたが、問題に遭遇しました。 遅かれ早かれ、人々は問題に遭遇します。 ほとんどのユーザーにとって、オープンソースバージョンが機能することは明らかです。 彼らには問題がなく、小さな基盤があり、成長しません。 しかし、場合によっては、専門家の助けが必要です。



以前は、モデルは単純でした。 この場合、さまざまな製品がこの進化の過程のさまざまな段階にあるため、Postgresについて説明しています。 Postgresはもともと単なる大学のプロジェクトでした。 人々はお金について考えませんでした。 彼らは問題の解決に興味を持っていました。 それから彼はボランティアプロジェクトでした：人々は自分でそれをしました。 さらに、彼らは私たちのようないくつかの企業で働いていました。



さて、ランブラーでどのように決断を下したのですか？



ランブラーは良い例です。 必要だったのでやった。 私たちはビジネスユーザーにまったく気になりませんでした。 他の誰かがそれを必要としているかどうか。



Postgresの企業は当初、ロシアではなく他の国で生まれ始めました。 しかし、富士通の資金により、このような会社が日本で初めて誕生しました。 かなりの投資が行われています。 そして、彼女はPostgresとほぼPostgresのものの開発を始めました。 その後、かなり短い時間で、2番目の象限（2番目の象限）がイギリスとアメリカのエンタープライズDBに登場しました。 これらはすべて、Postgresで収益を上げる企業です。 これらの会社はすべて、注文を執行するという事実から始まります。 彼らは従事しています...



カスタム開発。



DBMSレベルでのカスタム開発。 私たちもこれを行います。Postgresが拡大しているため、まだ会社ではないときにこれらのことを行いました。 「このように検索するだけでなく、フランス語のアクセントやドイツ語のウムラウトを正しく無視するためにも、全文検索が必要です。 完了-支払います。」 または：「JSONは非常に良いことです。 インデックスを添付できたらと思います。 そして、無料広告のポータルは他の誰よりも少し速く飛びます。」



これらの人たちは、個々の開発者にお金を払ったり、場合によっては若い新興企業に彼らが手に入れたい機能を注文したりして、開発に資金を提供しました。 そして徐々に、Postgresの商用バージョンの必要性が生じ始めました。



なぜ、そして一般的に、これらの商用フォークはどこから来たのですか？ まず第一に、Postgresには商用製品を合法的に製造することを法的に許可するようなトリッキーなライセンスがあります。 BSDライクライセンス。 これはGPLではありません。 変更を加えなくても、少なくとも同じコードを取得し、そこにライセンス契約の2行を残して、そこに何かを追加し、これを私の「Vasya Pupkin DB」と書いて販売しています。 市場に行き、少なくとも何十億ドルも売ることは重要です。 少なくともVasya Pupkinから「Vasya Pupkin DB」を購入するかどうかは別の問題です。 ほとんどありません。 そして、彼が彼自身のものをそこに持ってきたら？ そして、彼らはそれを始めました。



緑と赤の旗がPostgresの商用および非商用の分岐点を示している写真があります。 たくさんあります。 40〜50個を数えました。 それらのほとんどは、当然、成功していません。曲がっており、忘れられています。 たとえば、AmazonやSalesforceなどの一部の大規模な組織は、自分で分岐できます。 最も有名な商用フォークは、もちろん、EnterpriseDBのGreenplumです。 Postgres Proを含む、日本の富士通エンタープライズPostgres。







イギリス人も最近、Postgresのエンタープライズバージョンを作成しました。 何のために？ たとえば、Greenplumは、高度な並列性を備えた大規模な分析計算用のデータベースです。 約10年前にPostgresを使用し、スケジューラを大幅に変更し、そこに分散リクエストを追加しましたが、トランザクションの整合性は失われました。 ただし、分析データベースの場合、これは重要ではありません。すべてがすでに存在しているため、要求を収集してサーバー間で正しく分散する必要があります。 彼らはGreenplumを作りました。



このことは、ロシアでも使用されています。 特に、ティンコフ銀行はそれを持っていると自慢しました。 商業的にはある程度成功しているが、高いレベルの非互換性があるため、オープンソースに遅れをとっています。 彼らはスケジューラを大きく変更し、多くの良いことをしました。もちろん、彼らはこれを称賛することができますが、オープンソースの開発は他の方法で進んでいます。 そして、ここでの主なことは遠くまで行かないことです。 遠くに行くほど、後でマージするのが難しくなります。



最初の例は、特定の機能を備えたPostgresバージョンが作成された場合です。 これは、商業企業が生まれる理由の一例です。 そして、他に何がありますか？



Greenplumは、Postgresを非常に横方向に動かす非常に大きな機能を実行しました。 さらに、これはもはや普遍的な製品ではありませんが、重要な要求タスクを十分に解決します。



別のグループのフォークは、Postgres ProおよびEnterprise DBです。 奇妙なことに、後者は、アメリカの性格にもかかわらず、Oracleからの移行に従事しています。



アメリカでは、「くしゃみ」ごとに支払うのに費用がかかるため、Oracleから切り替えます。 誰もがそれを望んでいるわけではなく、誰もが支払うべきものを持っているわけでもない。 そのため、Enterprise DBはOracleからの世界的な移行サービスを提供しています。 また、クロールを簡単にするために、Oracleで利用可能ないくつかの機能をEnterprise DBに実装する道を歩みました。



そして、Postgres Proとは何ですか？ Oracleの機能（非同期自律型トランザクションなど）をいくつか実行しましたが、この道をたどらないことにしました。 しかし、長期的には、次のOracleのパスは表示されません。 「フォロー」とは、常に遅れをとることを意味し、とにかく100％の互換性は決してなく、少なくとも部分的な互換性を常に証明する必要があるからです。 これは難しい問題です。



OracleのPSQLのパーサーを作成できるという事実にもかかわらず。 神に感謝します、構文的に文書化されていますが、そのセマンティクスに関する非常に厳密な文書は見つかりません。 さらに、完全な互換性のために、「バグからバグ」を再現する必要があります。 それを試してみて、それが本当にそうであることを証明してください。 これは、移行の問題を実際には解決しないことがわかった。 前進する方が良いと判断しました。 最高の製品を作る方が良い。



その一方で、「バグからバグ」は言うまでもなく、そのような画像の完全なカバレッジのレベルで互換性を持たせる必要がありますか？ タスクは、移行コストの条件付き80％を終了することです。



本当にそう思われますが、実際には、システムを移行すると、次のようになります。完成したシステムを提供します。 これは黒い紙で包まれた黒い箱で、黒いロープで縛られています。 何が入っているのか分かりません。 これらの80％はありますか、それとも少しsheい出していますか？ 3階建ての「タイピングブランダ」方式で開発されたことがよくあり、1階の建築業者はどこかで長い間沈んでいました。



ですから、このことに移行するためには、リバースエンジニアリングを行う必要があります。書き直すためでなくても、それが機能するかどうかを理解するためです。 それは、あなたが完璧なテストカバレッジを持っているなら-はい、あなたは話すことができます...



決して起こらないことはもちろん..



...言うことができます。「エンジンを交換し、テストを実行します。 100％合格、すべてが検証されました。 行こう。」 実際には、これは起こりません。 これは理想的なケースです。 そのため、あなたは80％で販売しており、残りは依然として苦しんでおり、前もって何がわからないことがわかります。 移行には、さらに重大な問題があります。



各製品、各DBMSには利点があります。 たとえば、Postgresの場合、これはJSONおよび先ほど説明した配列で機能します。 このようにOracleで最適に記述された多くのことは、異なる方法でPostgresに記述した方が適切です。 したがって、「愚かに」移行する場合、両方と互換性のある最小限の機能のサブセットが得られます。 古いデータベースも新しいデータベースも利用しません。



未来について少し話してみましょう。 これはどこに行くのですか？ すべての競合他社を殺しますか？



すべての競合他社を殺すとは思いません。 原則として、私たちにはそのような「愛情深い」目標があります。 私たちは殺すために来たのではなく、建てるために来ました。 私たちのタスクは、非常に優れたデータベースを作成することです。 最高のために。



なに？ この良さの基準は何ですか？ Microsoftが非常に悪いデータベースを作成するタスクを持っていることを疑います。



はい、もちろん、誰もがこれに行きます。 そのため、データベースの世界には現在いくつかの傾向があります。 また、データ量は他のすべてよりも急速に増加しているため、現在のデータベースの主な傾向は分散です。 分散データベースの問題をよりよく解決できる人-それらはうまくやれるでしょう。



イワン・パンチェンコが一緒にいました。 ありがとう、イヴァン。



ありがとう