Alexeyと彼の同僚は、1Cプラットフォームを使用するビジネス向けのプロフェッショナルサービスに従事しています。 PostgreSQL + Linuxバンドルで1Cを効果的に使用する方法を顧客に教えます。 問題はプラットフォーム自体にあるのではなく、不適切な操作にあることが非常に多いことがわかります。 PG Day'17 Russiaで、アレクセイは1CのPostgreSQLへの移行に関するマスタークラスを提供します。コード名はFighting Fearsです。
本日の出版物の一部として、アレクセイは、彼らが提案する方法論が成功した理由を明確に示します。 そして、彼はあなたがマスタークラスでどのような具体的な実践スキルを習得するかについても詳しく説明します。
PG Day：アレクセイ、あなたについて教えてください。 あなたは誰ですか、何をしていますか、どのようにして専門分野に行きましたか？
アレクセイ ：私は自分をオートメーション駆動開発の伝道者と呼んでいます。 これは、「ITスペシャリストの自動化から」という概念であるため、開発者とインフラストラクチャスペシャリストは、面倒な作業のために日常的な作業や空き時間をなくします。 過去4年間、私はCICD（継続的インテグレーションと継続的デリバリー）の概念を使用して、開発者とインフラストラクチャエンジニアという2つの世界の友達を作ろうとしてきました。 このために、私たちのチームが編成されました。 さらに、プロセスの観点から最も自動化されていないため、主な優先事項はまさに「1Cの世界」です。
どうやってこれに来たの？ 大企業には多くの規制があります。 それらに準拠するには、手動プロセスが必要です。 このために、「マニュアル」の人々は区別されます。 監査を受けて大企業に行くと、従業員の時間の80〜90％がこのルーチンに費やされていることがわかります。データベースの更新、パフォーマンスの測定、監視、結論の引き出し、手動テストの実行です。 時間の80％は完全に非効率的です。 それは企業のリスクの観点から正当化されます、私はこれに同意します。 大企業では、ある種の事故やその他すべてに対する答えとして非常に多くの規制が生まれていることを理解しています。 これらの80％のみが自動化の明確な候補です。
ちなみに、何らかの理由で、IT担当者はサービスユニットであり、収益を得ていないと見なされることがよくあります。 ルーチンを減らすことで、面白いことを始められるとは誰も思いません 。 ビジネスを自動化し、自分のスタートアップにとって画期的なものを考え出すのがより効率的です-新しい仮説をテストしたり、生地を切ったりします。
これから、私たちが手で行う「すべてをジャンプ」します。
ビジネスでは、2000年代以降、1Cプラットフォームが最も効果的であると考えられており、古いバージョン7.7以降、MicrosoftサーキットとMS SQL DBMSで実行されます。 私はこれがなぜ起こっているのかのビジョンを持っています。 当初、MicrosoftはDBMSの世界で画期的なテクノロジーでした。 その後、Postgresは多くのLinux（第8版など）であり、おそらく1C会社自体はあまり面白くありませんでした。 それから、主なことは迅速な結果を得ることでした。 このMS SQLはそうしました。 MS SQLは1Cで安定していると見なされます。 一般的に、これはおそらく真実です。 そのクエリオプティマイザーは対応を開始し、テーブルの設計およびテーブル間の関係にエラーを表示しません。 最小限のデータ量で起動された、MS SQLに関連した論理的にエラーのある1Cプロジェクトは、特定のしきい値の後にのみ失敗し始めます。 また、Postgresでは、これらのエラーは情報システムの起動の初期段階でも検出されます。DBMS構造の論理エラーはすぐにクラッシュし、誤解がすぐに現れ、すべてがゆっくりと動作します。 したがって、通常、誰もがPostgresをscり始めます。開発者をscる人はいません。
私はこれを言う： 1CとPostgresはうまく機能します！ 問題は彼らにあるのではなく、問題はサーキットの所有者の能力にあります。 大量のデータベースでも、前例があります。 たとえば、圧縮されたデータベースの合計ボリュームがテラバイト以上の場合（このようなインストールもあります）。 しかし、実践が示すように、これらはこの回路の所有者（開発者と開発者）の能力レベルに直接比例します。 彼らの能力レベルは、MS SQLで毎秒同じ量のデータとトランザクションで同じインストールを所有している人よりもはるかに高いです。 理解できない仲間をそこに置くことは可能であり、彼らは何かをコーディングします。彼らの能力の低レベルはMS SQL自体によって補われます。 違いはPostgresとMS SQLではありません-唯一の違いは能力です。
したがって、コース、github-accounts、およびスクリプトのさまざまな出版物を含むストーリー全体。 個人的には、私の社会的な目標は 、1Cの世界のパフォーマンスの専門家（実際、回路全体を管理するシステム管理者— 1CアプリケーションサーバーとDBMSの両方）が能力を高めることです。
どうやってこれに来たの？ トレーニングには200個の1Cニックネームがあり、タスクはLinuxで少なくとも100の情報システムを実行することだと想像してください。 過去5年間、私はこのような魔法のような経験をしました。戦略的な焦点をMS SQLループからPostgresに移さなければなりませんでした。 2006年、Infostartの一環として、1C + Postgresコミュニティを組織しました（オタク向けにさらに設計されています）。 システムの少なくとも一部をPostgresに移行することを任されました 。 問題はPostgresにも1Cにもまったくないことが判明しました。 問題は、DBMS、1Cニックネーム、開発者などを担当する管理者の能力レベルにあります。 PostgreSQLをDBMSとして使用する場合、彼らは単に仮説をテストする方法を知りません。 彼らは彼らが生産的に迅速に展開されているように見えます-そして、すべてが動作します。 その後、何かを締めるだけです。 これはPostgresには当てはまりません。
まあ、私は自分自身に言うことができます。 私はDevOpsエンジニアリングプラクティスの伝道者なので、これが機能することを自分の手で証明しなければなりません。 「Postgres-our everything」という旗を持って歩くことはできません。 彼らは私に言う：「証明する」。 私はチームと一緒に座ります（ちなみに、私たちはそれほど多くありません）。そして、うめき声、港湾労働者、あらゆる種類の自動化されたスクリプトを通して、私たちが正しいことを証明します。 私たちはポピュリストだけではないと確信しています。
PG Day：興味深いトピック-Windows MsSQLプラットフォームからPostgresを使用したLinuxへの移行の問題に触れました。 この移行を支援するよう求められた場合、これらの問題を解決するために、あなたの実践に基づいてどのようなアドバイスをしますか？
アレクセイ ：「移行中の異議との戦い」と呼ばれるチェックリストを作成しました。 1Cは典型的な情報システムを作成します。 現在では、企業の複雑な自動化（給与から財務会計まで）を展開したい場合が通常です。 1Cをインストールします-完全なERPを取得して先に進み、ビジネスを行い、自動化に煩わされません。 この場合、あなたが勝ちます。
しかし、あなたが「ビジネスをする」とき、あなたは自分でそれを修正し、 「それを置く」 ことを余儀なくされます。 さまざまなレベルで開発者とインフラの専門家を雇わなければなりません。 そして、彼らはあなたを「仕上げ」ます。 過去15年間で、1Cインストールの95％は非定型です。 ロシアには、約50万の異なる非標準インストールが存在するという統計があります。 彼らは、特定のビジネスマンのために、品質の異なるレベルの一部の仲間によって「完成」されました。 「親」企業が、テーブル構造が多かれ少なかれデバッグされる情報システムをリリースした場合（1C企業内では、モデルのデバッグが引き続き行われます：IDEFダイアグラムとERwinの両方、おそらくすべてがそこでうまく動作します）。 特定のビジネスマンに関しては、開発者は「終了」し、データモデルまたは集合論について何も知らない場合があります。 データスキームをロールできることは、単に不可能です。
したがって、 私たちが戦っている最初の反対は、システムがまったく起動するかどうかです。 最初に表示する必要があります。 情報システム全体をアンロードして別のDBMS回路にロードできます。これは、1Cの世界では非常に便利な機能です：pg_dumpまたはMS SQLバックアップを使用せずに、独自の内部ツールを使用して転送できます。 だから、それを取り、Postgresの輪郭に転送してください。
ただし、1つの機能があります。1Cサーバーは、結局のところLinuxではなくWindowsにインストールした方がよいのです。これは、Active Directoryとkerberosライブラリに問題があるためです。 これはPostgresとは関係ありませんが、CentOS、Ubuntu、およびそれだけではなく、kerberosライブラリの静的リンクの特性に関係しています。 一般に、LinuxではPostgresのみをインストールすることをお勧めします。 同時に、Windowsで実行しないように抵抗します。 Windowsサーバーで1Cを実行したままにして、データベースを転送します。 データベースが転送される時間を測定します-バックアップから展開し、生産的な状態に入ります。 ベースがテラバイトの場合、マジックメータリングは36時間です。 サードパーティの手段により、MS SQLからPostgresに移行する場合、もちろん高速になります。 しかし、それにもかかわらず、通常のツールを選択しますが、それは長くなりますが、リスクは最も低くなります。
馬鹿げたことを展開して実行する-たとえば、ある種のレポート。 これが最も重要です。 レポートは15〜20％速く動作し始めます。 これは証明可能です。 1つの回路で実行し、2番目の回路で実行すると、レポートが20％高速になります。 これはそのような最初のすごい効果です。 ところで、これが起こる理由でさえ知られています。 最終的に、「それ」が機能することを証明します。
「完全に」という言葉から、誰もがLinuxを恐れています。 Postgresを展開し、一部の操作でより高速に動作することを証明しましたが、依然としてLinuxを恐れています。 Linuxは存在せず、Postgresが存在すると確信する必要があります。 インストールされたパッケージといくつかのコマンドがあります-apt-get installまたはyum。 管理者に基本的なコマンドを教えます-ブロックデバイスがあり、それらはWindowsとは少し異なって見えること、そしてこれを浮浪者ファイルとしてスクリプト化します。 彼が製品にPostgresの設定を大まかに繰り返す、浮浪者の形でゲーム用のLinux仮想マシンを展開できるように、どのように機能するかを示します。 そして彼と一緒に遊び始めます。彼はさまざまなLinuxコマンドを起動し、一般的な更新の動作、バックアップの操作方法、コンソールpg_dumpなどを監視します。
通常、管理者はMS SQLの管理に使用していたWindowsの世界から来ています。 彼らは言う：「どのようにバックアップしますか？」（結局、彼はMS SQLで採用されている特定のメンテナンス計画を持っています）。 MS SQLでどのように処理したか、Postgresでどのように実行されたかを示すタブレットを彼に準備します。統計の再計算方法（およびPostgreSQLでの一般的な呼び出し方法）、長いクエリプランの確認方法などです。 通常、15〜20のキーポイントで構成されます。 その結果、 彼は怖がるのをやめました -彼が以前にやったことはすべて、ある程度PostgreSQLのループに存在しています。
そして、Postgresのアウトラインを楽しんでください。 これは、実際には、Microsoftが採用した「マウスガイド」がないことを説明する際の主な問題でもあります。 nanoまたはvimのいずれかがあり、パラメーターを変更します。 さらに、新しいバージョンを起動できる場合は、すでに彼に代替システムの構築を示しています。 ほとんどのDBAにとって、これは理解可能な設計です。システム変数を変更できますが、ほとんどではありませんが、トレースフラグMS SQLに類似しています。 メモリの計算方法、Excelでの接続量の計算方法、1秒あたりのトランザクション数のカウント方法、一般的には魔法ではないPostgresコンターの操作方法を学びます。 当然、すぐにBartunovのビデオまたはPostgres Proの公開トレーニングへのリンクを提供します。 5〜6の小さなウェビナーのリストをすぐにグループ化します。それらにはすべての仕組みが染み込んでいます。 繰り返しますが、Githubにリンクします。
そして、実験は、浮浪者で行われたことを思い出します。 1つの例：DBMSの速度が低下し（1CとDBMSは複数のインフラストラクチャサーバーに配置されます）、 誰もが1Cであることに慣れており、誰も何もしません 。 また、Postgresを起動すると、ネットワークインフラストラクチャに問題があることがすぐにわかります。 iperfおよびその他のLinuxツールを使用して測定する必要があります。 これにより、割り当てられたインフラストラクチャ間に奇妙なネットワークルートが存在することが明らかになります。 問題は1CにもMS SQLにもありませんが、問題はそれらの間のネットワークにありますが、MS SQLはどういうわけか生き残っており、PGではもはや不可能です。 奇妙なジャンプ、理解できないノード間の遷移-これもすぐに検出されます。 何らかの理由で、Postgresの監視ツールは非常に面白くて低レベルなので、これらの数値を十分にすばやく表示できます。 インフラについて子供たちにそのような魔法を伝え始め、彼らはすぐに浸透します。 以上です。
主な目標は、ベースを翻訳し、生産的にそれを所有することを学ぶことです。 生産的な回路を自分で構成し、Vagrantで作成したスクリプトを繰り返します。 私たちは生産性に登りません-これが私たちのテクニックです。 実際、生産性が高いことがわかりました。 彼らが何を見せたかわからない場合は、トレーニングや証拠などを続けます。
ところで、私たちは製品サポートを扱っていません。 より専門的にこれを行う人がいます-私たちは彼らをお勧めします。 彼らは直接の管理者です。 Postgresの世界では、誰が何に特化しているかを誰もが知っています。一般的なサーキットと浮浪者、つまりPostgresと1Cの受け入れサーキットを専門としています。 しかし、製品が移転されるとすぐに、私は言います。「皆さん、製品のPGを専門とする人々のリストです。すべての質問があります。 ロシア語を信じないでください-2ndQuadrantにお問い合わせください。 すぐにひげと片手でvimの下に閉じ込められたキーボードで生まれた人々がいます。 この夜、彼らはLinuxカーネルを精神的に再構築します。 したがって、私は生産的なチームには参加しませんが、同じpgBadgerに関する開発者の問題を特定するためにそこから監視を行います。
これは、インフラストラクチャマネージャにとってPostgresの世界からのすばらしい機能です。レプリカを使用したデータベースの存続方法を示します。 このレポートと調査に「月に突入」できます。 はい、MS SQLにはそのようなものがありますが、非常に高価です。 そして、ここでは、GitHubのドッカーボックスから、ほとんどインストーラーのように： 起動して忘れました 。
要約すると-あなたは「標準的な異議を唱えて」、一歩ずつ戦います。 Postgresで動作することを示し、一部のシナリオではより速く動作し、スクリプト自体を表示します。
Linuxに対する異議との戦いは次のとおりです。1Cサーバーを通常のWindowsに残し、LinuxでPostgresを実行します。 だから、あなたは最初の異議を閉じます-ノーノーノー、Linux上のすべてではなく、Postgresだけ！ Linuxの少し。
立ち上げ、小さなLinuxを追加し、すべてが機能することを実証し、強調した-どのシナリオがより高速か。 最初に、必要に応じて無料の情報を取得するエコシステムを示し、次に、このビジネスをより便利に管理できる拡張機能を接続しました。 その後、彼は順次、オプティマイザーがどのように機能するかを示し、明確になるようにサービスプランを復元しました。 Postgresが恐ろしくなく、簡単だと確信するために、すべてを順番に実行します。
タスクは、Postgres輪郭を所有するときに受け入れられる原則に没頭することです。これにより、情報の入手先とデバッグ方法が明確になります。 私たちはパラダイムで仕事をしています-生産性については何も変更せず、まず見てから適用します。
私たちの証拠はgithubスクリプトです。 これもそのような立場です-パブリックドメインの初期の開発でさえ広げる。
PG Day：カンファレンスでのワークショップについて詳しく教えてください。 作品はどのように構築されますか？ プラットフォーム上での1Cの運用に関する偏見は、あなたが話したようなチェックリストで決定されますか？
Alexei ：はい、イデオロギーはこれになります。Postgresの輪郭を広げます-「ストック」モードでいくつかのボックスが表示されます。 結果を表示する特別なツールがあります。たとえば、「マイクロ波」モードで、基本設定なしで、ストックPostgres Proで1Cがどのように動作するかを示します。
次に、作業を4つのセクションに分割します 。データ、PostgreSQL、WAL、pg_dumpログです。 そして、これより前のシナリオと同じシナリオで結果を見ます。 この後、3番目のボックスは、特にテスト回路の一般的なユーザー向けに、通常の負荷でpostgres.confで既に構成されています。 レジスタの計算、レポートの実行、ディレクトリの書き込み、アクティブな読み取りなどを行います。 レポートには、テスト回路がどのような原理で動作するかが示されているため、誰でも後でテスト回路を繰り返すことができます。 その後、基本的なpostgres.confインフラストラクチャの正しい構成の結果を示します。
それから次のセクション-1Cでの主な「レーキ」の見方、主な間違い？ これは、1Cプログラマーの典型的なエラー（さらに、ZUPやUTなどの典型的な構成で）を見ることができる拡張機能に関するものです。 それらは既知です-一時ディレクトリ、ネストされたクエリの一時テーブル（1Cのニックネームはこのような間違いを犯すのが好きです）、理解できない複合結合、暗黙の結合1Cが変換され、インデックスへの古典的な非フォールバックがある場合の楽しい作業です（これは直接問題1C、1Cです） -プログラマーは、インデックスを作成してそれらにアクセスすることを「耐えることを嫌います」。 これをすばやく特定する方法、開発者がミスを犯した場所を確認する方法-これを2番目のセクションで示します。
つまり、1Cがどのように動作するか、どのように見えるか、どのように識別し、場所を見つけるかというシナリオがあります。 1Cには標準ツールがありますが、有料です。 したがって、これを宣伝することはありません。すべての1Cニックネームは、これがPerformance Management Centerであることを既に知っており、クエリプランを解析します。 しかし、無料であり、「開発者ツール」と呼ばれます。 まず、Postgresを使用したリクエストプランと、それを引き起こした1Cのコードを確認します。 あなたがあなたを興奮させるリクエストの基準を知っているなら、 あなたは無料で問題の場所を見つけることができます 。 30万の企業ツールキットを購入する必要はありません。 したがって、推奨事項を示します。 または、あなた自身が開発者の場合...あなたがパフォーマンスの専門家であり、Postgresにアクセスし、このkonfを飲んでいる場合（これは1Cの世界で頻繁に発生します）、自分で修正できます。 彼が間違っていた場所が明らかになります。
: , , , Postgres, , Alpine, 1 – , , . . . , , , 1 . , 1 .
, , “1” . . OLAP OLTP. 2,5 – . “-”.
. 1 . , . , , . , . bloat. – . , . , 1. . , 1. .
.
, , -. Postgres – . , , . , MS SQL, – . Postgres , , , ( , , ). . , MS SQL . , . «».
. .
PG Day: , . , , - , . , !