1. ERP5 に見るストレージ技術
13-D-1 奥地 秀則
株式会社 Nexedi
代表取締役社長

2. 自己紹介
 学生時代は数学とか生物学とか
 趣味で長年フリーソフトウェア開発
 GRUB とかが有名らしい
 去年「日本 OSS 貢献者賞」とか貰っちゃいました
 フランス Nexedi SA で CTO を五年ほど
 ERP5 の開発とか
 雑用とか
 現在は株式会社 Nexedi で社長業

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 年代から

爆発的に普及
 大学のデータベース論で教えられるもの

9. データベースの過去
 昔はリレーショナルだけじゃなかった
 例えば、ネットワーク・データベース
 グラフのエッジを保存するので、ジョイン不要
 例えば、オブジェクト・データベース
 オブジェクトの扱いはオブジェクト自身が知ってい
る
 メソッドをデータベース内部に持つタイプと、外部
に出すタイプがあり
 最近は ORM によって似非 ODBMS が流行

10. RDBMS の何がイケてない？
 スキーマが露骨に現れるので、データ構造の
変更に弱い
 ALTER TABLE はテーブル・ロックかかる
 ちょっとでも違う構造のオブジェクトを入れよう
とすると、
テーブル増やしまくってパフォーマンス劣化か、

補助テーブル増やしてジョイン激重か、

要るとは限らないカラムをがんがん増殖させて

（略
 私はこれを「じょじょにせきか」と呼ぶ

11. RDBMS は速い？
 インデックス増やせば、 INSERT / UPDATE
はどんどん重くなる
 Next-Key Locking とか、案外余計なロック
がかかる
 デッドロックの最大要因の一つ
 クライアント側でデータ更新を検知しにくいの
で、クライアント側でキャッシュしにくい
 大体そんなに速かったら memcached なん
て要らない

12. ORM ってどうよ？
 所詮は単なるマッピング
 RDBMS の欠点をそのままオブジェクト指向の世
界に持ち込んでいる
 オブジェクトの生データをそのまま検索に使い
たいとは限らない
 結局余分にテーブルを作ることになり、隠蔽でき
ない
 インデックス更新のせいで書き込みが遅い
 検索結果に即時に反映されないでいいことも多
いのに

13. ERP5 はこうしている
 生データは、 ZODB へ
 検索用データは、 Z SQL Catalog で MySQL
へ
 インデックス作成は、 CMF Activity で遅延＆
分散

14. ZODB って何？
 Zope の標準データベース
 オブジェクト指向
データは pickle してそのまま突っ込まれる

内部データ構造は気にしない

OID でオブジェクトを同定

 ストレージは交換可能
 大抵の人はログ型の FileStorage か分散対応の
ZEO
 楽観的トランザクション

15. 楽観的トランザクション？
 悲観的トランザクションの逆
 失われつつあるテクノロジーの一つ
 悲観的トランザクションは、
 衝突する前にロックする
 起きるかもしれないってだけで回避するので悲観的
 楽観的トランザクションは、
 とりあえずやってみて、衝突したらロールバックしてリ
トライ
 起きないだろうと淡い期待を抱くので楽観的

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/