#9 WebサーバーのベストプラクティスをNGINX中心で説明
WEBサーバーのベストプラクティスを説明していきます。
過去にiframeの代わりにapacheのrewriteを使っている設定があったり
apacheのrewriteだらけで、あきらかに不要と思っていても削除
するのが怖くてできないような設定を見かけました。
WEBサーバーの設定もバージョン管理しづらいのと変更しづらいので
できる限り最小の設定を心がける必要があります。
ただ単にバージョン管理ができるからだけではなく、エンジニアは自分が得意な
領域で設定したくなることがよくあります。
DBの得意な人はDBの機能を使いたがるし、nginxの設定が得意な人はnginxで
やってしまいます。同じくLinuxのIPtables, Firewalldしかり、他のエンジニア、
プログラマーができない事が優れていると勘違いしてそういう得意な分野で
誰もわからないようなブラックボックスの設定をしてしまいがちです。
本来は誰でもわかるようなサーバーサイドプログラミングでできるかぎり
機能を実装すべきです。
IPアドレスの制御をPHPなどのサーバーサイドプログラミング側で
制御するのかnginxの設定で制御するのか、LinuxのIPtablesの設定で
制御するのかWAF側で制御するのかですが、
この場合も特定のIPアドレスの許可、またはブロックは
サーバーサイドプログラミングで制御するのがベストかと思います。
ただ、国単位のアクセスを制御するとなると大量のIPアドレスを登録
しないといけないので、nginxのgeo関連のツールをインストール
した経験があります。
ただし、その設定をした場合もチーム全員に周知して、nginx.confの
設定ファイルもバージョンで管理すべきです。
nginx.confなどの設定ファイルは設定してから、後からリポジトリに
コミットする形なので忘れがちになりますが、nginx.confでの影響は
プログラミングよりも大きく、デバッグも難しいのでバージョン管理
はより徹底すべきかと思います。
ちなみにこの国ごとのアクセスを制御した設定をしてからの不具合は
ネット回線ベンダーが中国のIPアドレスを買収して日本にして日本からのアクセス
と認識するようになった場合、nginxの設定ではまだ中国でブロックの対象に
なっているという不具合があり、バイナリーファイルを更新して解決したという
事が起きました。
基本設定であるworker_process等などは色々変更しましたが、あまり効果が
なかったので、この設定で問題ないかと思います。
load_moduleでは先程のGEO関連の国単位でブロックするツールをインストールしています。
limit_req_zoneでは1秒に50アクセス、request以上はブロックするという設定をしています。
これはDDos攻撃というのを防ぐためですが、この設定でも不具合がでました。
1ページに50画像以上表示させると50以上から403が出るようになってしまいました。
その時は画像を削るなどの対応をして解決しましたが、やはり、初めは
なんでそんな不具合が起きたのか気づくのに時間がかかりました。
次にロードバランスの設定です。ここではmyserversのグループがいくつの
サーバーを保持しているかという設定です。
ここで上からどの振り分けにも該当しないアクセス、つまりデフォルトの
アクセスはmyserversにアクセスするように設定しています。
myserversとさきほどの192から始まる複数のサーバーが紐付いているので
負荷分散されるという事になります。
この時点でサーバーとポートを指定できるので、PHP,Goの場合は
直接php-fpmのポートやGoのポートを指定もできます。
TSVでロギングするように設定しています。
解析したい時にDBにいれやすいように思ったのですが、容量がおもすぎて
無理でした。
シェルを作成して毎週文をDBに入れるみたいな運用にすれば
いいかもですが、費用対効果が出ないので何もしてないです。
1つ目はgoaccessという解析ツールです。アクセスの全般的な解析はできますが、
特定のキーワード検索や国などで検索ができなかったので、今はその運用をしていません。
本来はできるのかも知れないですが、そんな要望もないので、放置しています。
2つ目はhttpsではなくてhttpのアクセスをリダイレクトしています。
その他にmmmzy.jpというサイトからのアクセスをブロックしています。
リファラーは書き換えることができるので、この設定はそこまで意味ないかと思います。
３つ目はwww2とexample.comにアクセスした場合、www.example.comに301リダイレクト
するように設定しています。移行時にこういった設定をしますが、
移行が終わればなるべく早く設定を削除すべきですが、削除はやはり、怖くて
できていません。
この画像はページキャッシュです。DBにアクセスもしないので済むので
負荷も軽くなる上、スピードも早くなりますが、データの変更がある場合は
キャッシュを毎回削除しないといけませんが、スピード改善の有効な方法の一つです。
この画像はSSLのセキュリティの設定でデフォルトよりもセキュリティが
高めに設定してあります。
クライアントや監査機関からチェックされる事があるので、このように
セキュリティが高い設定をしないといけない時があります。
この画像はブラウザキャッシュです。該当する拡張子で同じブラウザで同じURLを
アクセスすると２回目はキャッシュが効いてダウンロードしなくても済みます。
この設定では１年間キャッシュが有効に設定されてます。
apacheではなくnginxで説明したのは
これからWEBサーバーを構築する時はapacheよりもnginxだと思い
あえて比較するまでもないと思ったのでnginx中心に説明しました
細かい設定まで解説しすぎましたが、重要な点は
ロードバランサーなどで利用されるnginxはアクセスが集中する部分なので
設定や変更は最小限にして、バージョン管理は徹底するという所だと思います。
異論・反論があれば是非コメントしてもらえればと思います。
#7 将来のシェアNo.1のGo言語がなぜ優れているのかとベストプラクティス
今回はGo言語についてです。
第３回の「オブジェクト指向って古い」っていう動画でも少しGO言語に
ついて触れましたが、今回すこし詳細を詰めて説明していきます。
Go言語のメリット
速く、CPU、メモリリソースの消費量が少ない
他の記事でもよくみかけますが、GOはコンパイル言語なので、
PHP、Rubyなどのスクリプト言語に比べると早く
さらに、Javaにある互換性を保つためのマシンのJVMみたいなのがGoにはないので
コンパイル言語のJavaと比べてもその分速く、リソース消費が抑えられると
言われています。
「Go パフォーマンス 比較」で検索すると多く記事が見つけられるので、
ここではパフォーマンスの検証はやめておきます。
環境構築が簡単
使ってみた感想ですがPHPやJavaのように、
WEBサーバーを最低限動かすだけでも数々のモジュール
のバージョンをチェックして、インストールしないといけませんが、
Go言語の場合はインストールが必要なモジュールが少なく、
そのモジュールを入れて依存関係の問題やヴァージョン違いによるエラーに
なったことがないです。
PHPの場合はcomposerであったり、JAVAの場合はgradleであったり、
パッケージマネージャの設定をしないといけない場面が多いのですが、
Goの場合は直接githubのパスをGoのインポートの部分に記載すれば
パッケージが使えるので、簡単にライブラリが使えます。
Go言語でもGlideというのがあるのですが、特になくても問題ないです
この依存関係で一番苦労したのが個人的にはPythonです。
MySQLのクライアントですらエラー出まくってなかなかインストールできませんでした。
python python3 pip pip3などメジャーバージョンの互換性がないので、なかなか時間を
取らされました。
開発のテストはコンパイルをいちいちしなくてもrunコマンドで動かす事ができます。
都度都度runコマンドしないといけない所はスクリプト言語に比べて面倒ですが、
そこまでのタイムロスにはならないかと思います
IDEもVSCODEとかのテキストエディタよりのIDEでも十分コーディングできるので
JAVAの場合みたいに開発環境構築のドキュメントがEclipseありきになってる
って事もないです
デメリット？と思われる部分
静的型付け言語コード量が多くなって難しい？
PHPとかに慣れてる人は初め慣れないかもしれませんが、
慣れればそこまで難しくはないと思います。
Javascriptであえて静的型付けするTypescriptが流行ってる
ぐらいなので、デメリットとは言えないかと思います
継承、例外処理がない？
「オブジェクト指向って古い」っていう動画でも触れましたが
継承、例外処理がないぶんコードの書き方が統一されて
むしろメリットだと思います。
Goエンジニアの人口が少ない
google trendで見てみても、まだまだPHP等で比べると人気はないです。
人気がないと、ドキュメントの量も少ないですし、ライブラリの量も
少ないです。実質のデメリットとしてはこれぐらいかと思います。
Go言語のベストプラクティス
フレームワーク、ORMを使わない
Go言語標準でテンプレートも用意されているので、不要なうえ
誰が書いても似たようなコードに統一できる所をそういった
ライブラリを使用することで統一感がでなくなります。
フレームワークを使わなければセッション管理も自前で作成しないといけないですが、
システムの原理を知らずにフレームワークに頼ってブラックボックス的に
使用している事の方がリスクが高いと思います。
多くのエンジニアはベンダー、やライブラリの機能や使い方を覚えたがりますが、
提供されている機能の使い方を覚えるのではなくて、システムの原理を理解する必要があり、
システムの原理さえ理解していれば、どのプログラミング言語だろうと、
どのライブラリだろうと対応できます
なので、GoでもGin,EchoなどのフレームワークがありORMでもGORMとかありますが、
それらのライブラリを使用する限りGoのメリットを活かせる事はできないかと思います
できる限り共通関数を作成しない
MVCはWEBアプリケーションの設計パターンとして一般的ですが、MVCでの開発
をやり初めの頃からモデルが不要と思えて仕方ありませんでした。
そこでGoのコンセプトのorthogonalityに出会って「これだッ！」と思いました。
モデルがあるせいで、人によってビジネスロジックの解釈がちがっていたり
Model担当者、Contoroller担当者、View担当者を分けて開発する現場もあり、
非効率極まりなかったです。
なのでMVCもMなしのVCで問題ないです
多くのエンジニアは共通関数を作りたがります。そしてその関数を標準関数のように
使わせ、再利用させたがります
ただ、ビジネスロジックと関連した共通関数を作成した場合、そのビジネスが
どう変更するかわからないので、作成された共通関数を変更しないといけない時
はそれが使用されているシステムが多い程、影響範囲も大きくなってきます
なので、ビジネスロジックとは関係ないセッション管理など最低限の共通関数
にとどめておく事が重要かと思います
システム的な関数でもエラー処理の場合、自前で共通関数を作って失敗したと
GoのカンファレンスでDNAのエンジニアが発表してたので、エラー処理もGo標準の
関数で事足りるかと思います。
ログ処理に関しては微妙で、ログの内容によっては別ファイルに
書き出しなどしたい時もあります。しかし共通関数にせずにそのようなログシステム
が欲しい部分で直接コーディングする事の方がいいかと思います。
Goを使う上でGoのコンセプトであるorthogonalityという関数同士が干渉せず
独立性を保つこととされているので、先程述べたような思想がGoとマッチする
かと思います
説明欄にorthogonalityのwikipediaのURLを貼っておきます
go言語は人気がない
先程のorthogonalityの考え方でコーディングすると
似たような関数が合った場合はコピペしてベタ書き
SQLがコントローラ内にある
コード量が多くなる
経験豊富なプログラマーからすればダサくて汚くて、面白くない設計パターンです
しかしながら、コーディングに面白さを見出そうとすると不必要に
複雑にしてしまうので、コーディングはあくまでシンプルに初心者でもわかりやすいように
書くことが重要だと思います。
経験豊富なプログラマーが「美しい」コードを書いて、そのシステムを初心者になかなか
引き継げず、まるで初心者がその「美しく」複雑なコードについていけないのは
その初心者のスキル不足のせいになってしまい、そこのシステムは「美しく」複雑な
コードを書いた本人でないと対処できないって状況に陥る現場も経験しています。
そして、その経験豊富なプログラマーが属人的にすればするほど
そのプログラマーしか解決できないのでそのプログラマーが褒め称えられる
というような現場もありました。
シンプル、綺麗、簡単にコードを書くことは全員が一致している認識なのですが、
各々の綺麗などの捉え方が違うので、「初心者でも理解ができるコード」という事が
重要だと思います。多くのエンジニアがそう思っていない現実があります。
ここ２０年WEB開発で最新の設計だの、デザインパターンだのと日進月歩の勢いで
変わってるかのようです。Go言語はそういった思想を一切無視して
設計されているので、多くのプログラマーからは嫌われています。
しかし、WEB開発の根本的な所は大きく変わってないので、Go言語の思想は問題なく
正しいと思います。
安易に流行に振り回される必要はないかと思います。
Java,PHP,Python,Ruby,Javascript内での言語を変えて開発してみようと思う
プログラマーは多いのですが、オブジェクト指向ではないGo言語に躊躇してしまう
プログラマーが多いと思います。
しかし、小松がクイジェンを開発した上では詰まる所もなければ
違和感もなく開発ができ、そこまで言語の難しさも感じなかったです。
速く、リソース消費が少なく、フレームワークなしでコードが統一されるという
最強プログラミングなので、是非挑戦してもらえればと思います。
具体的なセッションであったり、DBとの連携などは実践編で紹介していきたいと思います。
https://en.wikipedia.org/wiki/Orthogonality_(programming)
https://www.youtube.com/watch?v=nJWtmhPN_5w
#6 インラインと外部スクリプトと圧縮の速さを比較
今回はインラインと外部スクリプト、外部スクリプトを圧縮した場合の
構成を比較検証していきます。
インラインのデメリットは
キャッシュできない
コードのサイズが大きい
の２点
圧縮なしの外部スクリプトのデメリットは
コードのサイズが大きい
ネットワーク通信が１つ多くなる
の２点
圧縮の外部スクリプトのデメリットは
ネットワーク通信が１つ多くなる
本番でのデバッグが難しくなる
開発環境を整えるのに時間がかかる
の３点
です。
まずはJavascriptを圧縮した時のサイズの違いはどれくらいなのか
検証してみました。
クイジェンのサイトで一番Javascriptが使われているクイズページの
Javascriptが圧縮する前で6.4KBです。
圧縮後は4.3KBで約2/3になっています。
ただこの2KBサイズを軽くする事がどれくらい重要なのかの検証が必要です。
Amazonでの商品の画像を見てみると73.8KBです。
エンジニアが時間をかけてJavascriptのコードを書いてそのコードが圧縮されて
サイズが小さくなるので、すごく圧縮されているように感じますが、コンテンツの
画像に比べれば圧縮されて小さくなるサイズはたかがコンテンツ画像の1/30にも
満たないです。
実際にPage Speed Insightでスピードを比較しました。
インラインの結果がこの画像です。
圧縮された外部スクリプトの結果がこの画像です。
JSファイルが6KB程度であれば、インラインで直接書いたほうが早いという
結果になりました。
もちろん、Page Speed Insightはキャッシュは考慮されないので、キャッシュ
なしでのパフォーマンスですが、SEOを考えた場合も検索エンジンクローラーが
ブラウザキャッシュをしないので、
SEO的にはインラインの方が早いという結果になりました。
どれくらいのJavascriptのコード量でインラインか外部スクリプトかの基準が
わからないですが、今回のサンプルのJavascriptコードは250行もありクイジェン
のサイトで一番コード量が多いページです。
それでもPage Speed Insightではインラインの方が速度が速かったので、
ほとんどのWEBページでは外部スクリプトにする必要がないのかもしれません。
それと引き換えのデメリットの本番でのデバッグがしづらいということが
どういうことかと画像を見せると
コンソール上でエラーが出ました。本来であればこのクイズの回答者のデータが
表示される所なのですが、表示されていません。
このコンソールのエラーからクリックしてデバッグ箇所に遷移しますが、
圧縮されて１行なので、簡単な変数ミスでのnot definedですらすごく見づらく
デバッグがしづらい状態です。
これらの結果から社内ツールやPV数が月間１００万未満のページなのであれば
インラインの方がメリットは大きく
月間１００万以上のページであっても
よほどのことがない限りCSS,JSはインラインにコードを
書いたほうがいいっていう結論でした。
#5 現場でVueJS好きのエンジニアが脱jQueryの議論する事が多いので作成
今回はVueJSとjQueryを比較した話です。
比べる対象ではないかもしれないですが、
jQuery派とVueJS派でソースコードの書き方が変わってきて
よく現場で話されているないようなので比べていきたいと思います。
jQueryのデメリットは2点
DOM操作が出来てしまうので機能が多くコードが多くなればなるほど
どこでDOM操作しているのかGREPしまくらないといけないとかになる
コールバックで書かないといけない部分が多々出てくる
次にjQueryと比べてのVueJSのデメリットは
javascriptレンダリングなので遅い
機能が少ない周辺ツールがない
並べ替えとかドラッグ＆ドロップとかのUI操作がしづらい
jQueryの場合はjQuery UIのdraggable, sortableとかがあって
歴史も古いので、ドキュメントも豊富で簡単に実装できたのですが、
jQueryなしで、はじめ実装しようとしたのですが、数時間たっても
なかなか進まなかったので、jQueryを使用することにしました。
POSTをjQueryで書くと簡潔にかけるのですが、jQueryなしで書こうとすると
FetchのAPIを使用して書くとコード量が増えます。
さらには、IEがFetchに対応していないので、それようのプラグインを使用しないと
いけないです。じゃあ初めからjQueryを使ったほうがシンプルでは！？
って所に戻ってきます。
以上のようなメリットデメリットを説明したので、実際にソースコードを書いて
検証していきましょう。
クリック2回するUIをjQueryとVueJSで書いてみました。
どちらがシンプルに見えるかは主観的ですが、思ってたより違いはなかった
かもです。
ただjQueryの方はcssの操作で表示・非表示しているので、コード量が多くなったら
どこでこの表示・非表示の操作をしているのかを探すのが大変になってきます。
次にAJAXがあるソースコードを書いて比べて見ます。
jQueryの場合はtableの部分が全て書き出しているので、これもコードが増えると
どこからこのtableタグが生成されているのかを探す手間がかかりそうです。
さらに、コールバックでないとクリック関数が効かないっていう事が起きています。
これはAJAXのレスポンスを受け取ってタグを生成しているため、タグがある前提で
jQueryのクリック関数があるので、クリック関数を正しく書いても動かないってバグに
陥ってしまいます。
レスポンスを受け取った後にクリック関数を記載すれば問題ないのですが、よく詰まって
しまうポイントかと思います。
これも機能が複雑になってくると、時系列的にどこにこういったクリック関数のようなコードを
記載しないといけないかを設計しないといけないので、工数がかかり、保守も難しくなります。
この点がjQueryの最大のデメリットだと個人的には思っています。
対象的にVuejsを見てみるとJSで意図的に生成してないので、わかりやすいかと思います。
HTMLの部分にfor文であったり、if文があるので、WEBデザイナーがこのHTMLの部分を書くことは
不可能ですが、エンジニア的にはシンプルでわかりやすいと思います。
ただ、AJAXの部分はFetchを使うとコード量が増えているのがわかります。
かつ、IEに対応していないので、それようのプラグインをいれるなり、XML requestを使うなりの
方法を考えないといけなくなります。
次にVueJSの方が遅いっというのを検証してみます。
PageSpeed Insightsで生のHTMLとVuejsでレンダリングしたHTMLで検証しました。
予想よりそこまで遅くはならなかったですが、speed indexの部分が3.5秒と2.8秒なので、0.7秒差
になっています。
SEOからしてもUXからしても0.7秒は大きいと捉えてもいいかと思います。
月間PVが1000万を超えるような大規模ならなおさらかと思います。
なので、結論はjQueryでtext()やhtml(),addClass(),css()とかは使わないようにする
かと言って脱jQueryに盲信的になり、余計な工数、手間がかかる方向に行かないように調整する
速度が求められるページはjQueryとVueJSのバランスを考えて使い分ける
jQueryの将来性はないですが、まだまだ、使いやすいツールではあるので、
次の使いやすいツールが確立されるまで使うのはありかと思います。
以上です。
#4 MySQLとPostgreSQLの比較を他のネットではやっていない観点から比較
今回はDBの比較の話です。
MySQL vs Postgres です。
ず〜〜っと、長い間議論、比較されている両者のDBなので
あえて今比較する必要もないのかもですが、色々な判断材料
が欲しい時もあるかと思うので、動画を作ってみました。
今回フォーカスした点は３つです。
シーケンステーブルの有無
Postgresは筋肉質
人気
Postgresはシーケンステーブルが合って、それをインクリメントしてるだけなので、
データ量が多くなってもSELECT NEXTVAL('id_seq')のスピードは変わらないのに対して、
MySQLはテーブルの値のMAXを取得する方法に近いので、LAST_INSERT_ID
が遅くなる可能性がある
他のWEBサイトを参照しても遅くなるのではないかっていう記事があり。
実際検証してみました。
MySQLに１０００万件以上のデータを登録して、insertしてLAST_INSERT_IDでIDを取得
してみます。
想定とは違い、LAST_INSERT_IDがすぐに取得できました。なので、LAST_INSERT_ID
が遅いというデメリットはなくなりました。
ただ、シーケンステーブルがないので、どうやって"LAST"つまり最後の値を取得している
のか気になったので、２つの端末で試してみました。
下の画面で登録したIDが上の画面で登録されるんじゃないかと疑ってみたのですが、
上は上の値、下は下の値がしっかり取得できていたので、同じコネクションでの
最後のIDが取得できるみたいです。
ただ、コネクションを別にするとどう取得できるのか見てみると
LAST_INSERT_IDが０と取得できませんでした。
同じコネクションでないとLAST_INSERT_IDっていうのが取得できないと言っても
そこまでのデメリットではないかと思いますが、少し不安と言えば不安です。
シーケンステーブルをプログラミングをする時に書き方が異なってきます。
シーケンステーブルがある場合は、まずはじめにユニークで且つauto incrementされた
IDを取得してそのIDを各テーブルやファイル名などに使えるのですが、
シーケンステーブルがない場合は、まずinsertしてそのLAST_INSERT_IDで取得しないと
いけません。
この実装方法だと何がまずいかというと、IDを取得するためだけにトランザクションを
追加するか範囲を広くする必要が出てきます。できるだけシンプルにコーディングしたい
時の妨げになります。
例えば支払い系の処理でIDを取得するためにinsertしてIDを取得して
そのIDで購入処理のAPIアクセスしてエラーが出た場合は初めにinsertしたレコードには
フラグを立てるか削除するとかの処理が必要になってきます。
他にシーケンステーブルのメリットはIDのローテーションがしやすい所です。
MySQLはそのテーブルの値のMAXを取得する方法に近いので、
なんらかの原因で大きな値が入ったら後戻りができないです。
LAST_INSERT_IDはプライマリーキーにしか対応していないので、
それ以外で利用したい時はできないです。
例えば、配送会社からトラッキングナンバーの範囲１万〜２万のナンバーを契約して
２万になったら、また１万から始めるというときは、DBのプライマリーキーではなく
ローテーションが必要なauto incrementなので便利です。
そこまでシーケンステーブルが欲しいのであれば、MySQLでも自前で作ればいいのでは
と思い作成した事があるですが、デッドロックが頻発したりして安定稼働までは
そこそこの工数が取られました。
Postgresの場合は「select nextval」であればトランザクションなしでも
ユニークで最新のIDが保証されているので、とても便利です。
PostgresとMySQLを調べるとPostgresは筋肉質でバランスが取れていると記載されています。
どういう事かというと、MySQLは買収を重ねているので、開発の方向性がよく変わる！？
らしいです。
オープンソースといってもDBのオラクルの会社のものなので、突然何が起こるかは
オラクル社次第となります。
実際に２０２０年１２月にCentOSが終了を発表して、
不安定なテスト版のstreamを使用して下さいってアナウンス
がRedHat社から突然発表されました。
なので、MySQLエンタープライズ版を作って有料にして、オープンソース版は終了という
ことも考えられなくもないです。
しかしPostgresのようなコミュニティベースでも、そのコミュニティが不活性になれば
開発終了という可能性もゼロではないです。
他に筋肉質と言われる理由はMySQLの場合は
プロセスの確認の時は「show full processlist」で見れるのですが、
クエリを全て見たい時はINFORMATION_SCHEMA.PROCESSLIST
から見ないといけないなど、一通りの方法ではなく方法がいっぱいある所が
あり、Postgresはpg_stat_activityを見ればわかるという一通りで済む所が
筋肉質だという理由みたいです。
MySQLにはテーブルエンジンをInnoDBやMyISAMなど選択できますが、事実上使えるのは
InnoDBのみです。間違えてMyISAMで運用している所があり、テーブルロックがかかって
大変な現場も目にしています。
Postgresはテーブルエンジンという概念がそもそもないので使う側が選択ミスせずにすみます。
そういった所も筋肉質と言われる理由かと思います。
シーケンステーブルの有無や筋肉質な点で
個人的にはPostgresが好きなのですが、
Google TrendではMySQLの方が人気のようです。
オープンソースで人気がどうかは結構大事で誰も使われなくなったら、
オンラインドキュメントの情報も少なくなったり、そもそも
開発がとまってしまう事もあります。
さらにはUberがPostgresが遅いから
MySQLに切り替えたというニュースがありました。
その切り替えに関してはPostgres側はそもそものアプリケーションの作り方が
悪いとの指摘などもあったのですが、実績がある有名な企業の切り替えだったので、
自分が携わる大規模案件の時にMySQLを選んだ大きな理由の１つになりました。
https://eng.uber.com/postgres-to-mysql-migration/
MySQLのもう一つのメリットは人気なのが原因なのもあってか周辺ツールは豊富です。
phpMyAdmin, MySQL Workbenchの方がPgAdminよりはるかに使いやすいです。
総合的な観点で会社を背負っての大規模なシステムであればMySQLかなぁっと思います。
社内ツールのような小さいシステムであればPostgresでやってもいいかと思います。
あと、チームの同意が取れればPostgresを個人的には選択したいのはあります。
比較している記事はよく見かけるのですが、シーケンステーブルのような
他の記事では見かけない事柄を取り上げて比較してみました。
ちなみにGCEのメモリ１GBのサーバーでテストデータを作成する時にPostgres
では簡単に１億件作成できたのですが、同じスペックでMySQLで作成しようと
insert into load1 (name) select load1.name from load1 limit 200000;
このSQLを２回実行するだけで、ハングったりして結構時間がかかりました。
