確かに。。。

SEASOFTさんのこちらのアドバイスを拝見して、コミュ版のソースに変更したら、結構な効果でスピードアップしました。（私の場合は、2.3.3なので、ファイルをそのまま入れ替えて使用できました。）

それだけでも、驚きでした。
商品数もアクセス数もまだそれほどはないのですが、あの遅さには、本当に困っていました；
実は、こないだサーバーダウンしたんですけど、ちょうど2箇所でEC-CUBEを触っていたときで、もしや自分のところのせい？？？と結構ビビってしまいました。（まあ、さすがにそこまでの負荷ではないだろうと思うのですけど･･･ちょうど負荷を掛けていたときに落ちたので、そのときは、本気でドキドキしました。）


ポスグレにしたら、そんなにも速度が上がるのであれば、移行してみたいですね〜。携帯サイトでは、PCで負担になるこの速度は、もうひどく致命的です；；；
mySQLから運用しながらポスグレに変更、というのもできるのでしょうか？

SQLでデータを書き出せばいいのかな。やってみようかな。。。

引用：

以前、mysql4系からpostgresql7系へ移行したことがあります。

どうせ移行するならpostgresql8系がおすすめですが
互換性で問題があったような気がします・・

運用しながらの移行は同一サーバにpostgreをインストールし
別ディレクトリにテスト用のEC-CUBEをインストールし検証後、
DBの切り替えで可能かと思います。

バックアップ必須です。

>x41様

ありがとうございます。
やってみようと思います！
使用しているサーバのポスグレのバージョン確認と設定をホスティング会社に依頼しました。

また、ちょっとやってみて、できた！とか？とか書き込みに来させていただきますね♪

＞どうせ移行するならpostgresql8系がおすすめですが
互換性で問題があったような気がします・・

なるほどです。この辺も注意してやってみます。(*^^*)

引用：

8.2 までは, ほとんど問題無いと思います.
8.3 からは, 大幅にパフォーマンスアップしていますが, データ型の制約が厳しくなったため, substring 関数を使用している箇所の修正が必要です.

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

下記で修正されていますね.
http://svn.ec-cube.net/open_trac/changeset/17204

この辺も PostgreSQL 8.3 絡みでしたね。
http://svn.ec-cube.net/open_trac/changeset/17719

当方の開発環境は PostgreSQL 8.3.3 がメインですが、EC-CUBEコミュニティ(eccube-comu) では、現状目立った障害は発生しなくなっています。

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

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

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へ、くらいでいいのではないかと思いました。（個人感想ですので、環境によって違うと思いますが＊＾＾＊）

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

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

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

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

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

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

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

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

ちなみに私の移行手順ですが、
１．ポスグレの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が良いという話をきいて、その速度の差のあまり、これまでの考えが吹っ飛んでしまいました。
> （この辺、とても安直な性格なので技術者向きじゃないなぁと反省しますね・・・）

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

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

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

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