PHPカンファレンス関西 2016 聞いた内容を短くまとめた
「要約出来るようになれ」と上司から言われているので、
今回参加したPHPカンファレンス関西2016で僕が聞かせてもらったカンファレンスの内容をなるべく短くまとめてみた。
[基調講演] Composerを速くするために必要だったもの
中野 拓 さん
スライド：
Composerを速くするために必要だったもの /composer-keynote // Speaker Deck
Composerの動作が遅かったので、早くするためのプラグインを自分で作ったら、
githubで凄いスターをもらえた。(日本のphperで一番)
GitHub - hirak/prestissimo: composer parallel install plugin
便利なツールや評価されているツールはスーパープログラマーが作っていると思っていたが、実はそうではなく、問題に立ち向かう姿勢を持ったプログラマーが作っているのではないか？
このプラグインはごく一般的なプログラマーが出来ることで出来ている。
今自分が出来る範囲でも、影響あるツールは作れるはず。
大量のデータで困ってませんか？
高橋 邦彦 さん
google cloud platformのBig Queryというサービスについての話。
データ量が多すぎてRDBSで集計しようとすると
結果が帰ってくるまでに数時間とかかかってしまうような場合、
BIg Queryを使うことでスグに結果を得ることが出来る。
「集計したい時にだけRDBSのデータをデータをBig Queryに上げて、集計処理し、データを削除する」
というような使い方をすればお金もあまりかからない。
ただし、集計処理の指示の方法によっては扱うデータ量が無駄に大きくなり、無駄にお金がかかってしまうので、扱うデータ量が小さくなるように工夫するようにする。
ビューのソースコードコンフリクトから解放される、PHPerのための次世代Webアプリケーション開発への道。
岸田 健一郎 さん
スライド:
ビューのソースコードコンフリクトから解放されるPHPerのための次世代Webアプリケーション開発への道 / PHP Conference Kansai 2016 // Speaker Deck
SPAでサイトを作る場合、Polymerを使うと綺麗に開発できておすすめですよという話。
PHPerに知ってほしいDB設計の話 7F メインホール
曽根 壮大 さん
スライド：
PHPerに知ってほしいRDBの事 その3 // Speaker Deck
検索とINDEXについて
- indexの使われ方、実行計画を理解すれば、遅いクエリはなぜ遅いか理解できる。mysql workbenchの実行計画はみやすい。
- JOINは掛け算で、走査するレコードがJOINするたびに倍々に膨れ上がるので、遅いならばJOIN前に範囲を絞ったほうがよい
- PostgreSQLは複数indexを使えたり、JOINのアルゴリズムも複数あったり、相関サブクエリも早かったりとmysqlよりも優れている点が多い
スキーマレスについて
json型のカラムを定義することができる。(mysqlは5.7以上、postgreSQLは昔から)
TEXT型にjsonを入れるのと違い、json中の値で検索できたり、indexをはったりできる。ただし、ユニーク制約や、外部キー制約はできない。
仕様変更などで扱うデータ項目が変わる度にDB構造を変更するのは大変だが、json型なら簡単に対応できる。
あらたな選択肢として持っておく。
※ただし、ORMを使うのには向いていない。
