MySQL vs PostgreSQL Part2
■ このスレッドは過去ログ倉庫に格納されています
同じオープンソースRDBMSとしてのMySQLとPostgreSQLを語ろう。
どちらが良い・悪いの宗教論争ではなく、漏れたちユーザにとってのそれぞれの使い所を見出そう。
前スレ
MySQL vs PostgreSQL
http://pc8.2ch.net/test/read.cgi/db/1056943680/l50
>>409
ちゃんと Mickos の投稿も読んでるかな?
GPL 版を重視するのは変わらずで、GPL 版の周辺ソフトウェアに
GPL じゃないライセンスを採用するかもしれないという話だと
思うけど、これはオープンソースを活用しているビジネスモデル
としては普通の事じゃないかな。そこでは Netteza や InnoDB の
ケースが出てるよね。こういうモデルはオープンソース版があって
初めて成り立つ話であって、GPL 版を放置するという発想が
どうして出て来るのかが不思議だよ。 そんなに大規模じゃなきゃMySQLで十分要求を満たす。
OracleやSQL-Serverで大規模を先に経験すると、
MySQLのシンプルさに疑心暗鬼になって、Postgresを
選択する。あるいはMySQL<4.1のサブクエリシンドロームな
人たちもPostgresを選択する傾向にある気が巣。 Derbyとか知るとMySQLがシンプルとは思えないんだが。
これも以外に要求を満たすからなぁ。
社内インフラ程度(?)の規模なら問題なしだし。
はともかく、単にMySQL対応のアプリ使いたいときは普通にMySQL選択するし、
特に要望がなければPostgresかな。
規模がデカくなるとDB2とかの商用使うな。Oracleはマンドクセなので個人的には嫌い。 情報量としてはMySQLの方が多くなってる気がするんだが >>412
>>413
大規模じゃなきゃ使えるって、まじで言ってるの?
mixiもYahoo!もFacebookも、超大規模なところはみんなMySQLなんだが。
GoogleもMySQLですよ? あれはちょっと使い方が違うけど。 別に誰も「大規模だと使えない」なんて言ってないと思うが。
なにを言いたいのかちっともわからん。
# 規模がでかい時に商用使うのは機能的な問題より、なんかあった
# 時に客に説明しやすいからだろうと思う。 超絶的な瞬間最大アクセス(?)がおきるオリンピック公式サイトはDB2だったと思うが。
大規模で楽したいって意味と顧客に説明する時にOracleとかは根拠のない
安心感があるんだよ。w
つかGoogleみたいな博士級のエンジニアがいる会社と偽装派遣や孫受けに
丸投げするばかりの能無し自称IT企業の事情といっしょにすんなよ。
#現実的には9割は後者の会社が多いと思っている。 >>416
> 別に誰も「大規模だと使えない」なんて言ってないと思うが。
じゃあ、MySQLは大規模でも使える(実例も多い)って結論だな。
> つかGoogleみたいな博士級のエンジニアがいる会社と
Googleが異常なだけで、mixiなんかは全然いないよw
普通のエンジニア。 mixiはfedoraをドカドカ使う度胸は凄いと思うな。
根性無しと言うワケではないが、そこはRHELを使うトコだろ、って思うし。
確かにfedoraでもdebianでもカーネルパニックとかには遭遇した事ないけどサ。
まあ原因不明のOracleのインスタンス落ちを経験するとfedora+MySQLでも
たいして安定性は変わらんとは思う。
Postgresも7以前は商用に比べれば、不安はあるけど8以降は結構いい感はある。 >>418
>> 別に誰も「大規模だと使えない」なんて言ってないと思うが。
> じゃあ、MySQLは大規模でも使える(実例も多い)って結論だな。
お前、プログラマに向いてないから早めに足洗った方がいいぞ。
まあ、痛い目を見るのはお前さんだからどうでもいいけど。 >>419
mixiはCentOSじゃなかった?
> 確かにfedoraでもdebianでもカーネルパニックとかには遭遇した事ないけどサ。
ああいうとこはkernel入れ替えてるんじゃないかな。
>>420
おまえ、何の情報も持ってないんだなぁ...
>>422
> おまえ、何の情報も持ってないんだなぁ...
>>418 のアホさ加減を示すのにこれ以上なんか情報がいるのか?
もう十分だと思うけど。 何が十分なんだよ。
相手が泣き叫んで許しを請うまでひたすら続けろ。 他人を貶す前に己の貧しさを知れ!
聞き囓った様な話じゃなくて、
本質的な内容にしようぜ。 >>429
そう言いつつネタ出せないんだから、つまらんやつだなぁ。
じゃあなんかネタふるか。
Drizzleどうよ? 昔はSQLの制限考えるとMySQLはありえなかったけど
今はどっちでもいいな、むしろMySQLのがサポート広い?
でもPostgreSQLかなあ。 MySQLはライセンスがうるさそうってか、
GPLってみんなあんまり意識してなさそう
世界じゃMySQL(CMSに採用されすぎwww)
日本じゃPostgreSQL(MySQLに追いつかれる)
って感じ?かな?
今度テラレベルのシステムを作ることになりそうだ
PostgreSQLににしようか本気でまよっている >>435
PostgreSQLじゃVACUUMが追いつかない
製品選定前に前もって性能テストしたほうがいいよ >>434
サーバサイドに関して言えば GPL である事は殆ど問題にならないよ。
少なくとも GPL v2 までは意識する必要はあまり無い。
GPL はバイナリを入手した人に対してソースも入手可能にしないと
いけないというルールだけど、サーバプロダクトはバイナリを配布
するわけじゃないから、ソースも公開する必要は無い。 話を分かり易くする為に前提条件を付けて話題を限定しているのに、
狭い世間しか知らないってどんなだw >>442
その限定ってまさかデータベースサーバの範囲とか言う間抜けなことを
言ってるんじゃないよな? >>436
レスありがとう
データが大量になりそうなテーブルは、インサートオンリーなんだ
VACUUMが必要な仕組みは、イヤだなぁ、と感覚的には思ったんだが、
インサートがメインだから、テーブル指定でVACUUMすれば問題ないかなぁ。と楽観的に考えている
たしかに性能テストした方がいいね >>446
インサートオンリーのテーブルもVACUUMが必要って知ってた?
http://www.postgresql.jp/document/current/html/routine-vacuuming.html#VACUUM-FOR-WRAPAROUND
パーティション機能をつかってテーブル分割したり、
VACUUMかけるテーブルを日ごとにローテーションしたり
運用で工夫することになると思うよ。
技術的に不可能なわけじゃないから止めはしないけど、
がんばってね。
8.3ではVACUUM頻度が劇的に落ちているから、それほど神経質になる必要は
あまり無いと思うけどなぁ そもそも「テラレベルのシステム」って言う俺たちには知り様のない
システムの話だから、>>435 に性能テストしてもらうしかない。
Vacuum 以外に落とし穴がないわけじゃないし。 PostgresみたいなフリーRDBMSは運用周りのサポートが弱いからねぇ。
使いはじめは考慮しなければならない部分が少ないから逆に楽なんだけど。 >>435です
2^32≒20憶トランザクションごとにトランザクションIDが周回してしまうから
全テーブルVACUUM必要なことは知らなかった
Oracleで4テラくらいのつくったときは、特に問題なかったんだ
それが4年くらい前だった
それからソフトもハードも進化したから(750玉なんてあるし)
PostgreSQLやMySQLとかでもいけるんじゃないかと思ってさ
実証実験するだけで、金かかりそうだなぁ
>>449
>Vacuum 以外に落とし穴がないわけじゃないし。
バックアップ・復旧周りが実は恐れている > 2^32≒20憶トランザクション
2^32 は約 40億だし、>>447 のリンク先にもそう書いてあるんだが...。
> これを防ぐためには、すべてのデータベースにあるすべてのテーブルを
> 少なくとも20億トランザクションごとにバキュームする必要があります。
と混同したのかも知れないけど、もう少し落ち着いてドキュメントを読む
癖つけたほうがいいぞ。
> 実証実験するだけで、金かかりそうだなぁ
金もかけずににちゃんのアドバイスで荒波に立ち向かうと言うスリリング
な人生を選択してもいいと思うけど。(w >>451
それこそ素直にOracle使うような案件なんじゃ……。
世の中の案件の80%はMySQL/PostgreSQLで済むと思うけど、
これは残り20%の範疇のように思う。 あと、PostgreSQLは定期的にvacuum fullしないとSELECT性能が劣化するから注意。 業務の関係でこれからPHPを勉強することになりました。
それで今アマゾン等でPHPの書籍を探しているところです。
仕はでPHP&postgreSQLの組み合わせなのですが、アマゾンや書店で
見つかるのは大概PHP&MySQLの組み合わせのものばかりです。
MySQLとPostgreSQLの違い(PHPとの連携する上で)がまだわからないのですが、
MySQLのほうのやつを買ってもポスグレ案件で役立ちますか?
(PHP初心者ですみません) >>455
・貴方のレベルにもよる
文章から察するに1〜3年目くらいに見えます。
(違っていたら申し訳ない。)
他の言語を複数習得している(それぞれ1年以上経験ある)レベルか
他の言語もやったことあるが、マスターしているとは言えないレベルなのか
・新規なのか既存なのかで判断が異なる
新規案件でPHPで業務の基盤周りから組むのと
既存案件で、すでに基盤はしっかりしているのと
で、参考になる書籍はことなると思う
(PEARはつかっているかとか)
マンモス本でよいんじゃないでしょうか
今はPostgreSQLのことかいていないんでしたっけ? >>454
それは昔のバージョン
今はバキュムしなくてもほとんど劣化なし そっか。少なくとも 8.1 まではそうだったけど、その後改善されたのかな。 単純にオートvacuumしてくれるだけで、vacuumしなければ、フルスキャンが遅くなっていく点は変わってないんじゃね?
>>461
つ ttp://itpro.nikkeibp.co.jp/article/COLUMN/20070409/267852/ 今度、オラクルで作っているシステムの換装があるんだけど、
そのままオラクルでいくか、MySQLやPostgreSQLを使うか本気で
迷っています。
データベース構造としては、親子関係の2階層のテーブルが
全部で10個くらいなんだけど、データ数がべらぼう。
1億は余裕で超えます。
理由は、格納するものは使用しているユーザーの操作ログだからです。
1つのボタンを操作するだけで、さまざまなファイルやデータを触るから、
それで、何十レコードにもなってしまいます。
10億とか行ったら、さすがにオラクル以外の選択肢はないんでしょうか?
また、性能評価って言いますけど、入札前に高価な想定するH/Wを
購入してまで性能評価ってやります?
検索リアクションタイムに制限があるけど、それをどう担保しようかが
最大の悩み。
みなさんは、実機相当のシステムで、同じ環境でデータベースを何億
も入れて性能調査やってるのでしょうか?
特にコンサル業界の人に聞きたい。 MySQLは、テーブル1つに1ファイルですよね?
テーブルのレコードが多ければ、それだけ検索するたびに、
ファイルオープンが発生するから、MySQLは遅いんだ。
この認識あってる? ログなんか大して参照しないだろ
するとしても参照するデータとしないデータに偏りがあるだろ
期間か何かで切り分けろよ
そうすればどれでもいける そもそも、MySQLがこの先も生き残っているのかという問題が
MySQLはOracleに殺されそうだな NetBeansに対するEclipseのように、MySQLにも有料化したらPostgreSQLに流れるだけなので
存続させるために無料のライセンスは続けるんじゃないかな。
サポートのライセンスは今でも有料なんだし。 Orcaleの得意技の飼い殺しというのが今一番懸念されているわけで。 >>463
板違い,コンサルでもない...
マニアックすぎて鼻で笑われるとおもいますが、
作りと開発者の技量にもよると思うけど
商用DBだけどCache' と言うのがあります..
内部(M)言語ガリガリではなく、
SQLアクセスで1億以上はさばけてます..
それぞれのアプリの条件にもよるので軽くとは
言い切れませんが、
10億はテストした事ないけど...
動作にOracleほど高価なH/Wはいらないと思います。
性能調査する価値はあるかも...
いまさらMっていわれるのがおち..ですかね...
DB自体くせもあるし..
そりゃねぇ、いくらIMSがそこらのRDBMSより速いとは言ってもやっぱり「いまさらIMS」だしねぇ。
10億くらいならPostgresでもイケるし。 >>471
MySQLは何億くらいまで、いけるんでしょうか?
あと、質問があと先になりましたが、10億の単位は何でしょうか?
よろしくお願いします。
indexなしでレコード追加してくだけなら何十億でも平気だろうな
10億を細かく参照やら分析するんならRDBMSやめれと思う このスレ、死んでるやん?w
ちょっと調べてみたけど、機能的にもコスト的にもPostgreSQLの一人勝ちじゃん
MySQLは今までたくさんの人が使っていたっていう惰性で情報が多いのと
ほんのちょっぴりの軽さだけが売り
ちょっとでもGPLを逸脱すると商用ライセンス
PostgreSQLはほぼLinuxでしか使えてなかったのが
Windowsにも進出してトランザクションもありーので完全にタダ
みんなでPostgreSQLに移ろうぜ
俺はPostgreSQLに移るよ >ちょっと調べてみたけど、機能的にもコスト的にもPostgreSQLの一人勝ちじゃん
さすがに、「性能」までは言わないか。 PostgreSQLのシェアはもうちょっと上がってもいいと思ってる
MySQLだけは危険だ 手元で動かしていると、MySQLのほうが性能が良いのはCPU1個のときだけで、
2-4 個を越えるとPostgreSQLのほうが圧倒的に伸びが良いんだが。 そんなもん
MySQLが速いのはCPU1〜2個
CPU4〜8個はPostgreSQLが速い
それを超えるとOracleが圧倒的に速い >>485
へー。やっぱり想定しているハードウェアの規模が違うのかもね。
ただ、今や普通にCPUを買っても普通に4コアとかになることを考えると……? そこでMySQL InnoDB Pluginですよ MySQLはもう過去の遺物でいいだろ
人気に胡坐かいてた罰だ >>484
MySQLの場合、大規模案件では単一マシンの強化ではなくクラスタ化という方向だしね。
>>485
OracleはCPUの数でライセンス料が違ってくるだけあって、スケーラビリティあるよなぁ。 >>485
>>486
公平に書くとMySQLのCPUスケーラビリティはバージョンと
ストレージエンジンに依存するからそんな単純ではない。
MySQL5.1までは確かにCPUコア数に対するスケーラビリティは低かったが
5.0でもInnoDBなら4程度まではなんとかなっていた。
5.4からはgoogleパッチでInnoDBのスケーラビリティは16くらいかなり向上した。
先のMySQLカンファレンスでは5.5で32コアまでいくと報告されたらしい。
MyISAMのCPUスケーラビリティはあがらんだろうね。性能もInnoDBに負けていくようだ。
PostgreSQLは8.1と8.2で劇的にスケーラビリティ向上で8.1で16程度、
8.2で32程度になった。しかしここからは先は難しいそうだ。
Oracleはコア数でライセンスかかるから論外。リニアで性能向上しない限り
コストパフォーマンスは悪いってことになる。
貧乏人はスケールアップよりスケールアウトを目指すべし。 「公平に書くと」とあるのでツッコむが、MySQL 5.4 も 5.5 も GA としてはリリースされて
いないようなので、開発中のバージョンの性能を持ってきても、比較にならないんじゃないの?
バグもあるだろうし、バグを潰していく中で追加の排他制御が必要になるかもしれないし。 MySQLは正式版の5.1ですらまったく安定してないから。
http://pc11.2ch.net/test/read.cgi/db/1258928470/835-
ここで問題になってるバグは5.1.20で発覚したものらしいから正式版のバグじゃないが、
レスに5.1のバグフィックスが3500とか書いてある。
CPUのスケーラビリティはPostgreSQLが先に対応して、今MySQLが追いかけてる。
安定性については誰がどう考えてもピーーーー(自主規制)だろう。
この↓ベンチマークテストの結果ってどう読めばいいの?
http://www.thinkit.co.jp/cert/article/0603/10/5/3.htm
MySQL+MyISAMエンジンはトランザクション機能を持ってないから速い、ってことは
どういう場面で使えば有利になるの?
その一方で、PostgreSQLはどういう場面で使えば有利になるの?
教えてエロい人 Postgreの権限管理周りはクソ
最近になってようやく揃ってきたけど・・・
Database単位とかSchema単位で参照権限うまく管理できねーとか
笑うしかない
あと何でDB作る度にデフォでpublicに登録されるん?
アホなの? >>498
MySQLはどうなってるの? スレタイ読め。
> Database単位とかSchema単位で参照権限
やっと9.0で機能が入る予定。確かにめんどくさかった。
> あと何でDB作る度にデフォでpublicに登録
スキーマ修飾できるし、search_path を設定すればデフォルトも変更できる。
これに関しては PG に全く落ち度はないと思うぞ。 >>499
MySQLと比べて糞って言ってるつもりだが
書かないといかんのなら・・・すまなんだ
権限周りはMySQLだとDB>tableって階層がはっきりしててGRANTで簡単に管理できるけど
Postgreは9になってやっとDB毎の権限対応でしょ・・・
PGはユーザがロールに統合されたりそこらへんの管理でポリシーを感じないんだよね
ほかのDBでもそうだど権限確認してログインユーザなりロールなり作る訳だが
PGは細かいなら細かいで方向性を持たせたら使いやすいのにって感じ
後で設定できるからいいだろって問題でもないと思うんだよね。
publicっていってるのはGRANTとかで使うPUBLICのことね
デフォルトだとCREATE DATABASEした直後、ログイン権限のあるユーザなら
新規作成したDBに入れちゃうじゃん
それってどうなのってこと
PGは最近触り始めたので誤りがあったらごめんなさい 標準SQLではDBとテーブルの間にスキーマの概念があるのだが、MySQLには無い。
標準SQLではユーザとグループは、ロールとして統合された。ロールのほうが柔軟性が高いデザイン。
申し訳ないが、MySQLが「ふつう」だとは思わないほうが良いよ。
Postgres はこれまで手間を減らすような機能は提供してなかったものの、設計そのものはより「正しい」と言える。
ココから先は単に PG の使い方だが、
publicスキーマに関しては REVOKE ALL ON SCHEMA public FROM public; で権限は剥奪しておける。
ログインに関しては pg_hba.conf のほうで制御するようになっている。
ぱっと見「アホなの?」と思うようなことはさすがに開発者も気づいているだろうから、少しは調べてみると良い。 何でもかんでも調べもせずにデフォルトで使ってそれに文句言ってるのって滑稽ではある >>501
どちらかというと、MySQLのデータベース ≒ PostgreSQLのスキーマ と考えたほうがいいかも。
PostgreSQLでもスキーマのUSAGE権限は、その中に含まれるテーブルに引き継がれるから、
そこは >>500 が言っている動きに近いんじゃないだろうか。 最近はsqliteがおもちゃっぽくて好きだなぁ。
Cで書くと速くてびっくり。
もちろんPostgreSQLが一番だい! sqlite使ってると、いつもPostgreSQLの豊富な関数使いたくてしょうがないです... orz すいません いきなりmysqlにログインできなくなりました
以前も同じようにログインできなくなり、navicat liteを使って
いたのですがそちらにも接続できなくなりました
その時はOSの再インストールで解決したのですが再度同じようになりました
おそらくlocalhost3306に接続できてないのだとは思います
mysqlをアンインストールして再度インストールもしてみました
そうするとApply security settingsでエラーがでます
Error.Nr.1130 Host localhost is not alloowed to this MYSQL sever
設定などはいじってないのですがやはりOSを再度入れ直さないといけないのでしょうか?
長文失礼しました
何でもちゃんと原因調べて適切な対処を取るようにしないと
毎回再インストールするはめになるぞ、、てかもうなってるか やばいなあ
2ヶ月ほど外に出たのはジュース買いに出ただけだよ顔色とか真っ白 設定いじってないっつってもなぁ。
mysql.userテーブルが書き換わって、とあるユーザ@localhost に関するレコードが
無くなった/書き換わったんだと思うよ。
まあ、何にせよスレ違いっぽいな。
MySQL 総合 Part17
http://pc11.2ch.net/test/read.cgi/db/1258928470/
■ このスレッドは過去ログ倉庫に格納されています