seasoft さま,

情報の公開&性能向上の改修ありがとうございます!

やっと開発ができそうな環境になってきたので, 当方でも負けじとコミットしていけたらと思っております.

# そもそも, また本業が炎上しかねないので, どれだけできるかわかりませんが...orz

返信が大変に遅れまして申し訳ございません。

> 環境構築方法や, 使用したテストプログラムなど, よろしければ公開していただけませんでしょうか?

環境につきましては、パフォーマンス [EC-CUBE メモ] に概要を書いておきました。

使用したデータは、私どもの顧客企業の商品データをCSVインポートして使用しました。(もともと、顧客からの依頼による検証でして。興味深いデータでしたので、その一部を一般公開する承諾をいただき、掲載いたしました。)

特段のテストプログラムといったものは使用しておらず、通常にインストールした EC-CUBE と、Firefox を利用しております。時間計測の際には、画像読み込みやレンダリング時間の影響を極力排除するため、通信レベルでの記録を行っています。

何気にネックだったのは、CSV インポートでした。MySQL では、1日以上かかる始末で・・・ 一部改良したプログラムは EC-CUBEコミュニティ(eccube-comu) にコミットしました。
http://svn.ec-cube.net/open_trac/changeset/17852
http://svn.ec-cube.net/open_trac/changeset/17880

それでも、実運用に耐える状態ではなくて、最終的に顧客サイトでは EC-CUBE を使用せずに直接インポートする運用にしましたけど^^; それだと、分単位で数十万件の商品マスタをインポートできるので、なかなか快適です。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

seasoftさま

パフォーマンス比較数値は参考になります。ありがとうございます。

ありがとうございます.
こういった具体的な数値がでるのは興味深いですね.

環境構築方法や, 使用したテストプログラムなど, よろしければ公開していただけませんでしょうか?

当方の環境(FreeBSD や Mac OS X)でも, 同様の方法で試してみたいですし, 他のユーザーからのフィードバックも期待できそうです.

商品数 15,000 点で、PostgreSQL と MySQL のパフォーマンス比較を実施しました。

→ パフォーマンス [EC-CUBE メモ]

PostgreSQL を使用したほうが MySQL よりも約1500倍速いという結果になりました。

EC-CUBE は PostgreSQL の方が向いているというのは、定説と認識してはいましたが、想像以上にパフォーマンスに差が生じました。MySQL に詳しい方、何かチェックポイントなどありますか?

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

> 僕も以前はMySQLを専ら使用していたので、PostgreSQLには抵抗がありました。
>
> しかし、nanasessさんからPostgreSQL8.3が良いという話をきいて、その速度の差のあまり、これまでの考えが吹っ飛んでしまいました。
> （この辺、とても安直な性格なので技術者向きじゃないなぁと反省しますね・・・）

そこで切り替えができるというは、変化の激しい昨今ではプラスだと思いますよ。
スキルとしても、選択肢が増えるわけですし。

以前は、
PostgreSQL … 高機能・低速
MySQL … 高速・低機能
という明確な住み分けがありましたが、今では似たり寄ったりで、選択が難しい場合も多いですね。

MySQL の強みは、安価なサーバでも利用できて、裾野が広いこという EC-CUBE のマーケティング面が大きい予感。
技術面では MyISAM を選択できることですかね。そういえば、EC-CUBE も一部 MyISAM のテーブルがありますね。

----------------
Seasoft
こちらでの投稿は、アイディア程度に留めさせていただいております。
個別案件の作業は有償で承っております。お気軽にご相談ください。

私の書き込みからずいぶんとレスが進んでいるようですね。

ちなみに私の移行手順ですが、
１．ポスグレのDBを２つ作成する。（本番用・テンポラリ）
２．別ディレクトリにEC-CUBEをインストール。テンポラリDBを使用。
３．２のEC-CUBEが正常に動作するのを確認して。
４．２のEC-CUBEからDB生成のみのsqlを作成。
５．本番用DBに４でテーブル作成
５．mysql版EC-CUBEのテーブルデータをCSVにてエクスポート。
６．本番用DBにテーブルごとにちまちまインポート。
（５、６を繰り返す）
｛このときのインポートでエラーが出れば、テーブルをカスタマイズしているはず(^^;なので、構造を変更｝
７．５からmtb_constantsのみsqlでエクスポート
８．７をインポート（CSVでのインポートがダブルクォーテーションがらみでエラーが出たため。）
９．install.php をポスグレ用に書き換え。
10．Smartyのキャッシュを全削除

こんな流れでしょうか。
何か問題が考えられれば教えて欲しいですｗ。

とにかく、今の環境での動作には非常に満足しています。
EC-CUBE 2.3.3
PHP 5.1.6
Postgresql 8.3.6
何より、カスタマイズ時の動作確認が早い！のが嬉しいですね。

僕も以前はMySQLを専ら使用していたので、PostgreSQLには抵抗がありました。

しかし、nanasessさんからPostgreSQL8.3が良いという話をきいて、その速度の差のあまり、これまでの考えが吹っ飛んでしまいました。
（この辺、とても安直な性格なので技術者向きじゃないなぁと反省しますね・・・）

MySQLでもPostgreSQLでも、tontonさんがおっしゃるようにそのDBに沿ったSQL文にチューニングするだけで、よっぽど大規模な案件でない限り、ほとんどの場合解決できそうな気がします。

これからはチューニングのスキルを磨きたいですね。

----------------
このコミュニティでの投稿はボランティアの範囲に留めさせていただいています。個別の相談やカスタマイズは有償にて承っておりますのでご相談下さい。

[url=http://www.eccube-school.jp/]EC-CUBE

mySQLからpostgreSQLへのデータ移行、やってみました。
残念ながら、私のサーバーのポスグレは、8.3系だったので、ちょっとモジュールなどは厳しいのかもしれませんが、通常使っていた機能の範囲では、いくつかのカスタマイズも含め、無事表示されました。

現状、注文処理などメインの処理は大丈夫そうです。

＊＊主な移行フロー＊＊

１）MYSQLのDBからphpMyAdminで、テーブルごとにCSVデータを書き出す。
２）（一応同じサーバ内に別環境をつくり）EC-CUBEをポスグレ使用でインストール
３）postgreSQL（以下PSQL）のDBのテーブル内のデータを全て空にする
４）テーブルごとに、先にMSQLからダウンロードしていたCSVデータをインポート（※カゴラボさんの携帯用コメント表示ソースをカスタマイズしていたので、この際にPSQLのdtb_productsにカラムを追加しておく）
５）ビューを調整。
・vw_product_class
・vw_products_allclass
・vw_products_allclass_detail
・vw_products_nonclass
の４つのビューに、カスタマイズで追加していた携帯用コメントカラム（comment7)をそれぞれ追加して生成しなおす

カスタマイズで増やしたDBのカラムの移行部分でちょっと手間が掛かりましたが、およそ上記作業で問題なかったです。


速度ですが、やはり速いです。
当初mySQLで運用し始めた頃よりダントツで早いです。
うちは、商品数もアクセス数もそれほど多くないので、こちらのスレッドで、SEASOFTさんが、教えてくださったコミュ版のMYSQLコードを使用した場合と比べると、MYSQLでもPSQLに移行したのとそれほど変わらないパフォーマンスが出ていたのでは？と思いました。

カスタマイズ関係は、MYSQLのほうがDBが触りやすいのでやりやすいです。MYSQLの速度に悩んでいる方は、一度DBの変更でなく、SQL文の変更で対応してみて、どうしても厳しかったらPSQLへ、くらいでいいのではないかと思いました。（個人感想ですので、環境によって違うと思いますが＊＾＾＊）

以上です。皆さん、良い情報をありがとうございました！
もう少しテストして、問題なければ、次回使用してみたいと思います。

PostgreSQL8.3からは、決済関係のモジュールを管理画面のオーナーズストアページからダウンロード→設定する際などにもエラーが生じることが多いみたいです。

http://svn.ec-cube.net/open_trac/ticket/417

上記はYammyさんがペイジェントモジュールを例にされていますが、ソフトバンクの決済やF-REGIなどでもまったく同様の箇所・理由で発生した記憶があります。


ちなみに、MySQLからPostgreSQLに移行する際の１つの方法（案？）としては以下のスレッドをご参考下さい（学校にも一応記事がありますけれど・・・）

http://xoops.ec-cube.net/modules/newbb/viewtopic.php?viewmode=flat&topic_id=2971&forum=2
http://www.eccube-school.jp/products/detail50.html
（コメントも参考）

上記は１系（MySQL運用）→2系（PostgreSQL運用）の例ですが、2系（MySQL）→2系（PostgreSQL）も基本的には同じです。
ただ、2系からはデータベーステーブルが増えているので、1系→2系のときよりは2系→2系のときのほうが、移行させたほうがいいテーブルの数が多くなると思いますので、記事で用意している移行シート（Excel形式）だけでは足りないと思います。


最近は、一番ネックになりそうな商品規格の部分と集計周りをどうにかもっと効率よく管理できないか考えています。商品規格の部分はPostgreSQLにすることでずいぶんと反応はいいですが、50×40位の組み合わせなどになると、ブラウザ上に表が全て表示されるまでに若干時間がかかってしまいます。しかも、その50×40でも実際は5組み合わせ程度しか利用してなかったりするので、在庫を変更しないといけない際なんかになかなか見つけにくい感じです・・・。

登録フローと修正時のフローを見直す必要があるかもしれないですね。


あと、集計周りは不都合が生じることがあって、一度集計済みで昨日よりも前の日は再集計しない設定になっているようです（2.2.0ベータで確認）。もし、昨日以前の受注情報に変更があった場合、集計上では再集計されません（つまり、実際の売り上げとズレてしまいます）。ポイント値引きなどがあった場合はもともと集計の対象になっておらず、ポイント値引き前の金額が集計されます。この不都合もなんとか解決しつつパフォーマンスを上げられる方法がないか模索中です。

----------------
このコミュニティでの投稿はボランティアの範囲に留めさせていただいています。個別の相談やカスタマイズは有償にて承っておりますのでご相談下さい。

[url=http://www.eccube-school.jp/]EC-CUBE