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.
ERP5 に見るストレージ技術



13-D-1   奥地 秀則
         株式会社 Nexedi
         代表取締役社長
自己紹介
 学生時代は数学とか生物学とか
 趣味で長年フリーソフトウェア開発
  GRUB とかが有名らしい
  去年「日本 OSS 貢献者賞」とか貰っちゃいました
 フランス Nexedi SA で CTO を五年ほど
  ERP...
今日言いたいこと
 歴史から学ぶべき
     古いことは悪いことじゃない
 
     埋もれた技術が多すぎる
 
     新しい方が金になるは本当かも、でも(略
 
 リレーショナルデータベースは万能じゃない
     一つのも...
ERP5 って何?
 Nexedi が中心となって開発しているオープ
  ンソース ERP
 小規模から大規模まであちこちで利用中
   中央銀行の事例だと、 1 時間 10 万トランザクシ
    ョンを処理
 言語はほぼ Pytho...
ERP って何なの?
 Enterprise Resource Planning の略
   要するに、業務の統合管理システム
   生産、購買、請求、会計、人事、 E コマース等々
 データ量が多い
 データ構造が複雑
   異な...
ERP の技術的難しさ
 相反するシステム要求
   複雑な大量データを高速に処理しないと
   なのに真面目なトランザクション処理必須
 止まらない機能変更
   ビジネスは日々変わる
   止まるとまずいのに、変えられないのもま...
RDBMS で OK ?
  RDBMS 原理主義者の主張
      RDBMS はスケールする
  
      RDBMS は数学的に完璧だから最高
  
      RDBMS に機能を足せば何でもできる
  
       ...
そもそも RDBMS って何?
  数学の集合論が理論的根拠

  データを関係性によって結び付け

  生のデータ構造を表に分解

  大手ベンダのマーケティングで 80 年代から

  爆発的に普及
 大学のデータベース論で教えら...
データベースの過去
 昔はリレーショナルだけじゃなかった
 例えば、ネットワーク・データベース
  グラフのエッジを保存するので、ジョイン不要
 例えば、オブジェクト・データベース
  オブジェクトの扱いはオブジェクト自身が知ってい
...
RDBMS の何がイケてない?
 スキーマが露骨に現れるので、データ構造の
  変更に弱い
  ALTER TABLE はテーブル・ロックかかる
 ちょっとでも違う構造のオブジェクトを入れよう
  とすると、
     テーブル増やしまく...
RDBMS は速い?
 インデックス増やせば、 INSERT / UPDATE
  はどんどん重くなる
 Next-Key Locking とか、案外余計なロック
  がかかる
  デッドロックの最大要因の一つ
 クライアント側でデータ...
ORM ってどうよ?
 所詮は単なるマッピング
  RDBMS の欠点をそのままオブジェクト指向の世
   界に持ち込んでいる
 オブジェクトの生データをそのまま検索に使い
  たいとは限らない
  結局余分にテーブルを作ることになり、...
ERP5 はこうしている
 生データは、 ZODB へ
 検索用データは、 Z SQL Catalog で MySQL
  へ
 インデックス作成は、 CMF Activity で遅延&
  分散
ZODB って何?
 Zope の標準データベース
 オブジェクト指向
     データは pickle してそのまま突っ込まれる
 
     内部データ構造は気にしない
 
     OID でオブジェクトを同定
 
 ストレー...
楽観的トランザクション?
 悲観的トランザクションの逆
 失われつつあるテクノロジーの一つ
 悲観的トランザクションは、
  衝突する前にロックする
  起きるかもしれないってだけで回避するので悲観的
 楽観的トランザクションは、
...
ZODB の長所
    スキーマの変更に強い

    オブジェクトを復元状態でキャッシュできる

    Persistent クラスさえ継承すれば透過的

     変更したオブジェクトは自動的にコミットされる
     ほとん...
ZODB の短所
 衝突率が高いと激遅
 トランザクションのコストが大きいと、衝突が
  発生したとき、ダメージ大きい
 検索には全く不向き
  データベースが内容を知らないので、関係ないオ
   ブジェクトも復元してみて全検索するしか...
Z SQL Catalog とは
  Nexedi で作ったオブジェクト・インデクシング
   ・エンジン
   ZODB 中のオブジェクトを他のデータベースへ好
    きなように突っ込んだり検索したり
   普通は RDBMS が対象...
Z SQL Catalog の長所
  何をどこにインデックスするかは、すべてあな
   たの自由
   メソッドの結果を突っ込めるので、データ構造を晒
    す必要なし
   検索に要らないデータは入れなくていいので、パ
    フォ...
Z SQL Catalog の短所
  自動的にテーブルの構造を考えたりはしてく
   れない
   私は余計なお世話だと思ってますが ...
  データ・モデルをちゃんと考えておかないと、
   結局 ORM の二の舞になる
   テ...
CMF Activity とは
  Active Object のフレームワーク
   Active Object は失われつつあるテクノロジーの
    一つ
   1980 年に Smalltalk の研究者が発案
   POSA ...
つまり、こういうこと

                    ERP5
     生オブジェクト                     検索



    ZODB                              MySQL


...
まとめ
 RDBMS を何にでも使おうとするべきじゃない
   英語版 Wikipedia の「 Object-relational
    impedance mismatch 」とか参照
 過去の研究にもいいものはいっぱいある
  ...
広告
 ERP5 : http://www.erp5.org/
 Nexedi: http://www.nexedi.co.jp/
Upcoming SlideShare
Loading in …5
×

【13-D-1】 ERP5に見るストレージ技術

  • Be the first to comment

【13-D-1】 ERP5に見るストレージ技術

  1. 1. ERP5 に見るストレージ技術 13-D-1 奥地 秀則 株式会社 Nexedi 代表取締役社長
  2. 2. 自己紹介  学生時代は数学とか生物学とか  趣味で長年フリーソフトウェア開発  GRUB とかが有名らしい  去年「日本 OSS 貢献者賞」とか貰っちゃいました  フランス Nexedi SA で CTO を五年ほど  ERP5 の開発とか  雑用とか  現在は株式会社 Nexedi で社長業
  3. 3. 今日言いたいこと  歴史から学ぶべき 古いことは悪いことじゃない  埋もれた技術が多すぎる  新しい方が金になるは本当かも、でも(略   リレーショナルデータベースは万能じゃない 一つのもので全部やることに無理がある  適材適所  データ構造剥き出しなので、低レベル向き 
  4. 4. ERP5 って何?  Nexedi が中心となって開発しているオープ ンソース ERP  小規模から大規模まであちこちで利用中  中央銀行の事例だと、 1 時間 10 万トランザクシ ョンを処理  言語はほぼ Python  アプリケーションサーバは Zope  RDBMS は MySQL がデフォルト  単純にパフォーマンス上の事情
  5. 5. ERP って何なの?  Enterprise Resource Planning の略  要するに、業務の統合管理システム  生産、購買、請求、会計、人事、 E コマース等々  データ量が多い  データ構造が複雑  異なる業務データが絡み合うから  ミッションクリティカル  止まるとやばい、くさるとやばい  整合性、安全性、超重要
  6. 6. ERP の技術的難しさ  相反するシステム要求  複雑な大量データを高速に処理しないと  なのに真面目なトランザクション処理必須  止まらない機能変更  ビジネスは日々変わる  止まるとまずいのに、変えられないのもまずい  つまり ...  スケールして変更が容易で安全で高速なシステ ムを作らないといけない
  7. 7. RDBMS で OK ?  RDBMS 原理主義者の主張 RDBMS はスケールする  RDBMS は数学的に完璧だから最高  RDBMS に機能を足せば何でもできる   ってゆーか、○○にあれもこれもない方がダメ  オブジェクト指向なんて、 ORM で余裕  でも、それって本当にそうなの?
  8. 8. そもそも RDBMS って何? 数学の集合論が理論的根拠  データを関係性によって結び付け  生のデータ構造を表に分解  大手ベンダのマーケティングで 80 年代から  爆発的に普及  大学のデータベース論で教えられるもの
  9. 9. データベースの過去  昔はリレーショナルだけじゃなかった  例えば、ネットワーク・データベース  グラフのエッジを保存するので、ジョイン不要  例えば、オブジェクト・データベース  オブジェクトの扱いはオブジェクト自身が知ってい る  メソッドをデータベース内部に持つタイプと、外部 に出すタイプがあり  最近は ORM によって似非 ODBMS が流行
  10. 10. RDBMS の何がイケてない?  スキーマが露骨に現れるので、データ構造の 変更に弱い  ALTER TABLE はテーブル・ロックかかる  ちょっとでも違う構造のオブジェクトを入れよう とすると、 テーブル増やしまくってパフォーマンス劣化か、  補助テーブル増やしてジョイン激重か、  要るとは限らないカラムをがんがん増殖させて  (略  私はこれを「じょじょにせきか」と呼ぶ
  11. 11. RDBMS は速い?  インデックス増やせば、 INSERT / UPDATE はどんどん重くなる  Next-Key Locking とか、案外余計なロック がかかる  デッドロックの最大要因の一つ  クライアント側でデータ更新を検知しにくいの で、クライアント側でキャッシュしにくい  大体そんなに速かったら memcached なん て要らない
  12. 12. ORM ってどうよ?  所詮は単なるマッピング  RDBMS の欠点をそのままオブジェクト指向の世 界に持ち込んでいる  オブジェクトの生データをそのまま検索に使い たいとは限らない  結局余分にテーブルを作ることになり、隠蔽でき ない  インデックス更新のせいで書き込みが遅い  検索結果に即時に反映されないでいいことも多 いのに
  13. 13. ERP5 はこうしている  生データは、 ZODB へ  検索用データは、 Z SQL Catalog で MySQL へ  インデックス作成は、 CMF Activity で遅延& 分散
  14. 14. ZODB って何?  Zope の標準データベース  オブジェクト指向 データは pickle してそのまま突っ込まれる  内部データ構造は気にしない  OID でオブジェクトを同定   ストレージは交換可能  大抵の人はログ型の FileStorage か分散対応の ZEO  楽観的トランザクション
  15. 15. 楽観的トランザクション?  悲観的トランザクションの逆  失われつつあるテクノロジーの一つ  悲観的トランザクションは、  衝突する前にロックする  起きるかもしれないってだけで回避するので悲観的  楽観的トランザクションは、  とりあえずやってみて、衝突したらロールバックしてリ トライ  起きないだろうと淡い期待を抱くので楽観的
  16. 16. ZODB の長所 スキーマの変更に強い  オブジェクトを復元状態でキャッシュできる  Persistent クラスさえ継承すれば透過的   変更したオブジェクトは自動的にコミットされる  ほとんどの場合、呪文は唱えなくていい  衝突率が低く抑えられれば激速  ときどきデータ構造に工夫が必要  衝突を解決するハンドラーを仕込めるケースも
  17. 17. ZODB の短所  衝突率が高いと激遅  トランザクションのコストが大きいと、衝突が 発生したとき、ダメージ大きい  検索には全く不向き  データベースが内容を知らないので、関係ないオ ブジェクトも復元してみて全検索するしかない  RDBMS 厨にウケが非常に悪い  違うものは全部嫌いらしい
  18. 18. Z SQL Catalog とは  Nexedi で作ったオブジェクト・インデクシング ・エンジン  ZODB 中のオブジェクトを他のデータベースへ好 きなように突っ込んだり検索したり  普通は RDBMS が対象  実は対象は何でもいい( LDAP とか)  Zope 添付の Z Catalog とほぼ API 互換  別のデータベースを併用することで、 ZODB の短所を補う
  19. 19. Z SQL Catalog の長所  何をどこにインデックスするかは、すべてあな たの自由  メソッドの結果を突っ込めるので、データ構造を晒 す必要なし  検索に要らないデータは入れなくていいので、パ フォーマンス良好  同時に複数のデータベースを使い分け可能  動作中にデータベースを作り直す機能あり  スキーマ変更時にも無停止を実現
  20. 20. Z SQL Catalog の短所  自動的にテーブルの構造を考えたりはしてく れない  私は余計なお世話だと思ってますが ...  データ・モデルをちゃんと考えておかないと、 結局 ORM の二の舞になる  テーブルやカラムを増やしすぎないように、統一 的なモデルを考えておくべき  ERP5 の場合、統合ビジネスモデルで基本要素を 5 つに限定している
  21. 21. CMF Activity とは  Active Object のフレームワーク  Active Object は失われつつあるテクノロジーの 一つ  1980 年に Smalltalk の研究者が発案  POSA にデザイン・パターンとして記述されている  実行しようとしている状態をそのまま保存し、 後で復元して、本当に実行  スケジューリング、結果レポート機能、分散処 理など
  22. 22. つまり、こういうこと ERP5 生オブジェクト 検索 ZODB MySQL 遅延 インデックス CMF Activity Z SQL Catalog
  23. 23. まとめ  RDBMS を何にでも使おうとするべきじゃない  英語版 Wikipedia の「 Object-relational impedance mismatch 」とか参照  過去の研究にもいいものはいっぱいある  流行っているものがいいとは限らない  ちゃんと考えなきゃいいものは作れない  ERP5 でいいからといって、あなたのところでもい いとは限らないので、自分で考えましょう
  24. 24. 広告  ERP5 : http://www.erp5.org/  Nexedi: http://www.nexedi.co.jp/

×