PostgreSQLはRocket Scienceではありません。 卵は今いくらですか？

「PostgreSQLは私の小さなプロジェクトには複雑すぎるため、MySQLを使い続けます。」という一連の文に絶えず出くわします。

この記事では、MySQLを知っている人がPostgreSQLで開発を始めることは難しくないことを示したいと思います。





私は非常に遠くから始めます



古典的な供給と需要の経済法則は、製品の価格が下がると需要が自動的に増えることを示唆しています。 しかし、実際にはこれは完全に真実ではありません。なぜなら人々は完全な情報を持っていないからです。



朝食にスクランブルエッグを作りたいとしましょう。 そして、卵が必要です。



最適な結果を得るには、すべての店に行き、価格、品質を比較し、顧客レビューを聞いて、最終的に最低価格で受け入れられる製品を選択する必要があります。 当然、誰もこれを行いません。なぜなら、これらすべてをしている間、飢hungで死ぬ可能性が高いからです。



あるいは、例えば、あなたは最もクールなスタートアップ、世界を好転させるべきサイトを作りました。 しかし、彼のことを誰も知らなければ、彼はまったく知らないようです。 広告、マーケティングなどが必要



言い換えると、製品の品質と価格だけでなく、組織の問題によっては意思決定のコストも重要です。 そして、これはすべて非常に重要です。 この記事では、postgresql DBMSに切り替えるコストを少し削減したいと思います。 つまり 「卵価格」を提案します。



最後のpgdayで、Oleg Buninはスピーチを行いました。彼は、PostgreSQLは、そのクールさにもかかわらず、プロジェクトではあまり使用されないという多くの正しいことを述べました。 さまざまな理由がありましたが、そのほとんどは完全に同意します。



しかし！ 同時に、オレグはクライアントから新しいプロジェクトにMySQLを使用するように勧めたとき、彼の練習から例を挙げました。チーム全体（既に筋肉を鍛える方法を知っている）を最初からPostgreSQLから書き直すことはできないからです。 書籍、コースなどが少ない そして最終的に、ビジネスはこれに苦しむでしょう。



これは完全に真実ではないと思います。



典型的なMySQLプロジェクトを取り上げます。 そこで何が使われていますか？ 99％のケースでは、これらは最も単純なクエリです。これは、これまでのところ再帰CTE、ウィンドウ関数（将来のバージョンで計画されていますが）、カスタムデータ型、配列の高度な作業、式のインデックスなどがないためです。 qなど



さまざまなベースで単純なクエリの構文を比較しましょう。



MySQL：

SELECT name FROM users WHERE id = 5; UPDATE users SET name = '' WHERE id = 5; INSERT INTO users (name) VALUES ('');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

Postgres：

 --  SELECT name FROM users WHERE id = 5; UPDATE users SET name = '' WHERE id = 5; INSERT INTO users (name) VALUES ('');
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この機能はすでに多くのことを書くのに十分です。



申し分なく、申し分なく、いくつかのニュアンスがあります。



MySQLでは、複雑な識別子は`でエスケープでき、進行中に使用されます" （したがって、文字列定数では一重引用符を使用する必要があります）



MySQLはINSERT IGNORE ...を使用します。

posgres INSERT ... ON CONFLICTで...



進行中のINET_NTOA関数はありませんが、他の方法で同じことを行う方法がたくさんあります。



MySQLでは、この用語はDATABASEと呼ばれ、postgresでは、同じものがSCHEMAと呼ばれます。



MySQLでは、bigserialでBIGINT AUTO_INCREMENTを記述する必要があります



他にも違いがあり、一般的な「大規模」と同じです。



しかし、私に言ってください、引用符やその他の小さなニュアンスを理解することは非常に難しいですか？



いわゆる脳を肩に抱えている人は、これらの違いの信じられないほどの深さを理解するために本や講座を必要としないように思えます。 十分な手動または愚かなStackOverflow。



そして、これは実践によって完全に確認されました：多くのプロジェクトは単にpostgresに移行しました：最初はすべてmysqlのように1対1で使用していましたが、それから初めて、さまざまな機能を検討して新しい機能を導入し始めました



私はしばしば別の議論を聞きます：「ああ、まあ、これは私がマスターできないような宇宙船のようなものです。 これらすべてのCTEおよび部分インデックスは、これをすべて学ぶのが面倒です。 私のプロジェクトには十分なMySQL機能があります。



はい、気にしないでください。単純なプロジェクトの場合、拠点間に違いはまったくありません。 したがって、開発者の観点からは、postgresによる追加費用は発生しません。 （プロジェクト）が大きくなった場合、後でデータベースの高度な機能が必要になる場合があります。



-CTEで複雑なクエリを簡素化

-ウィンドウ関数を使用して、1つの要求で一度に多くのことを行います。

-複数のCREATE TABLE、ALTER TABLEなどを実行する機能 トランザクションの一部として（および何か問題が発生した場合は途中でロールバックします）

-CREATE INDEX CONCURRENTLY（データベースをラップせずに大きなテーブルにインデックスを作成します）

-マテリアライズドビュー

-式によるインデックス（この場合、個別の列を生成および維持する代わりに）

-部分インデックス（一部のクエリを高速化するため、または条件による一意性を確保するためなど）

-さまざまなインデックス（gist、gin、brinなど）。

-たとえば、unnestおよびarray関数を使用して、配列を操作します

-レプリケーションホットスタンバイ

-継承テーブル

-カスタムデータ型と変換ルール（型の作成、キャストの作成）。 たとえば、ip4rタイプでは、IPアドレスの範囲を簡単かつ迅速に操作できます（gistインデックスを使用して、範囲内のIP検索にインデックスを付けることができます）。

-カスタム演算子（CREATE OPERATOR）。 私は自分で試したことはありませんが、この方向を見ます

-さまざまな言語、たとえばjavascript（plv8）またはpythonのストアドプロシージャ

-タイムゾーン付きタイム（タイムゾーン付きタイムスタンプ）

-テーブル内の列をすばやく削除および追加

-インデックス可能なJSON（jsonbタイプ）

-チェックによるデータの検証（その中で、たとえば、jsonで必要な要素の有無を確認できます）

-auto_incrementの代わりに順序付け（ループを実行したり、複数のテーブルに共通するなど）

-外部データラッパー-sgresa、mysql、csvファイルのテーブルを1つのクエリで結合できます

-および100500のその他の機能、拡張機能、さらにはフォーク。 私は長年にわたって親と仕事をしてきましたが、常に新しい機会を開いています。



公平に言うと、mysqlは順調に開発され、レガシーを除去し始めているように見えることに注意してください。 つまり、5.5で起こったことと現在のことは大きな違いです（たとえば、デフォルトのストリクトモード）。 次のバージョンでは、システムテーブルでmyisamを使用することを拒否し、CTEとウィンドウ関数を追加すると言います。これは大きな前進です。 しかし、主観的には、当分の間、それはまだ、罪の背後に非常に遠く離れています。 これも、一般に、静止していません（ wiki.postgresql.org/wiki/Todo ）



上記に書かれていることはすべて、開発者の観点からは公平です。 管理者とdbaベースの観点から見ると、言うことは何もありません。 ただし、単純なプロジェクトの場合も、Googleとstackoverflowで十分です。



要約すると、筋肉質のチームが進行状況に基づいてプロジェクトを開始するには、特定の負荷プロファイルのベースを設定および強化する人だけが必要です。 （ただし、これはすべてのDBMSに当てはまります）。 このビジネスのためにいくつかのdbaを雇うことができます。 ただし、コード自体は問題なく記述できます。



これは単なる理論的な推論ではなく、私自身は本などを使わずにpostgresqlに移行したプロジェクトの一部として働いていました。 そして後に、新参者も一般に、開発にシームレスに注いでいます。 というのも、コードが最終的にsgresaの高度な機能を備えたとき、何をどのように尋ねられるのかという人々がすでにいるからです。



PS DBAが私に読んでいるなら、Habrの「PostgreSQLのインストールと設定方法」で初心者向けのわかりやすい記事を書いてください。 基本。」 私見、この記事は非常に必要です。