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