Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

The plan of Aniki 2.0

3,040 views

Published on

YAPC::Fukuoka 2017 HAKATA

Published in: Engineering
  • Be the first to comment

The plan of Aniki 2.0

  1. 1. The plan of Aniki 2.0 id:karupanerura YAPC::Fukuoka 2017 HAKATA
  2. 2. おことわり • AnikiというORMの2.0に向けたロードマップ に関するトークです • ORMやAnikiに関心が知識があると面白いと おもいます • 今すぐ cpanm Aniki しましょう • 裏は福岡のITの未来の話をやってます
  3. 3. だれ • id:karupanerura (Twitter/Hatena/Github) • Japan Perl Association / DeNA Co,.Ltd. • Perl/XS/Go/Crystal/Swift/Java/etc.. • CPAN Author (PAUSE:KARUPA) • Gotanda.pm / Mackerel UG Organizer
  4. 4. あじぇんだ • Anikiとは • Aniki 1.0まで • Aniki 2.0から • まとめ
  5. 5. Anikiとは YAPC::Hokkaido 2016 Sapporo https://speakerdeck.com/karupanerura/lai-rigaifalsearuorm-aniki-che-di-jie-shuo
  6. 6. Aniki採用企業 • 名前出していいのかわからないけど何社か導 入してくれているところがあると聞いてます • 弊社ではまだ使ってるところないらしい • 自分のプロジェクトは自分が入ったときに はTengだった
  7. 7. Aniki 2.0
  8. 8. …の前に おさらい
  9. 9. ORMにありがちな問題 • よくわからないクエリの発行 • N+1問題を作りがち • (大量の行を取得したとき)重い • 行Objectのライフサイクルが長くなりがち • 複数DBと相性が悪い
  10. 10. つらい 酒のみたい
  11. 11. つらいけど問題と向き合う
  12. 12. よくわからないクエリの発行 • 大概、オブジェクトの操作に寄せすぎ • プログラムとしてはキレイになる • パフォーマンスを考慮したコードを書くに はORMの深い知識が必要になって基本的に ハードルが高くて難しい • 操作とその副作用のクエリが暗黙的
  13. 13. N+1問題を作りがち • N+1問題を知らないひとはぐぐって! • 大概ORMの機能の無理解や誤解から起きる • 関連レコードをprefetchする機能を使うべき • とはいえTengなどサポートの無いORMもある • prefetchから何が起こるかイメージしにくい
  14. 14. (大量の行を取得したとき)重い • 大量のオブジェクトの生成はしんどい • 大量のメモリアロケーション • プールにないことが多い • 当たり前体操 • 1行づつfetchすればちょっとマシな場合も
  15. 15. 行Objectのライフサイクル • 長くなりがち • なんで長くなりがちかってmutableだから • setしてsetしてsaveとかやりがち • 状態引き回すことになりがち • ライフサイクル長いと状態が見えにくくなっ てバグ仕込みがち
  16. 16. 複数DBとの相性が悪い • そもそも複数DBが辛い • シャーディングとかシャーディングとか… • Slaveとのレプリ遅延も辛い • トランザクションまたぎが辛い • 大概、トランザクション管理の関係が問題で DBと一対一の関係にしているORMが多そう
  17. 17. Aniki 1.0
  18. 18. Aniki 1.0 • SQLに寄ったクエリ発行ベースのAPI • N+1が起きてからprefetchを仕込めな設計 • 大量のデータは生データで扱え(suppress_*) • 行オブジェクトがImmutable • 複数Slaveには対応
  19. 19. 解決しきれていない 問題がある
  20. 20. Aniki 2.0
  21. 21. コンセプト • 「使いやすい」から「改善しやすい」へ • ORMが持っている問題をもっと少なく • もっと開発者が楽になれて • DBの問題に対処しやすいように • コードもわかりやすいように
  22. 22. 新機能 • シャーディング/複数DB支援 • Lint機能 • Phantom Row Object • Iteratorサポート
  23. 23. ※構想です 気が変わって方針転換する可能性があります
  24. 24. シャーディング/複数DB支援 • クラスタ/シャード/スレーブ管理 • たぶん汎用的なモジュールとして切り出す • schemaに対するDSLも提供したい • DSL見ただけで系統やシャードの切り方が 分かったら素敵では???
  25. 25. Lint機能 • N+1問題を検出 • prefetchするべきかどうかはエンジニアが 判断するしかなかった→自動でやりたい • 生SQLと行Objectの対応がまずったら警告 • 静的検査したいけどそこまではできないかも
  26. 26. Phantom Row Object • MutableなRowの代わりの概念(idea) • Rowから魂(Phantom)を抜き出す • Phantomは実体を持たないので柔軟(?) • Phantomには干渉はできても見えない • Phantomをこねくり回してDBに反映!
  27. 27. Iteratorサポート • DBD::mysqlでは基本的にレスポンスをすべて ローカルにバッファする • mysql_use_resultで制御 • もう少しわかりやすいAPIを提供したい • メモリアロケーションが少なくなる工夫をし たい
  28. 28. まとめ
  29. 29. まとめ • ORMはパーフェクトじゃない • つらみはたくさん • とはいえつらみと向き合って変えていくこと が必要 • Aniki 1.0まででもある程度解消した • Aniki 2.0ではもっとつらみを減らしたい
  30. 30. ざっつ おーる
  31. 31. えにーくえっしょん?
  32. 32. Q. いつ2.0だすの A. 2018年前半には… (やる気しだい)
  33. 33. Q. 一番やる気ある機能は? A. Lint作ってる
  34. 34. Anikiは開発者を 絶賛募集しております
  35. 35. あなたとAniki いますぐcontribute!
  36. 36. さんきゅーふぉありすにんぐ ベストトークよろ

×