MySQL vs PostgreSQL Part2
■ このスレッドは過去ログ倉庫に格納されています
同じオープンソースRDBMSとしてのMySQLとPostgreSQLを語ろう。
どちらが良い・悪いの宗教論争ではなく、漏れたちユーザにとってのそれぞれの使い所を見出そう。
前スレ
MySQL vs PostgreSQL
http://pc8.2ch.net/test/read.cgi/db/1056943680/l50
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/
技術的には関係なく、経営上の理由で、
MySQLが勝手に潰れてPostgreSQLが勝利しそうな感じ MySQLの世界での普及度合は半端じゃないから
もし5.5で開発打ち止めになったとしても
MariaとかDrizzleなどの互換プロダクトがシェアを維持するんじゃないかな
Linuxとは状況が違うのはわかっているがRHL、FedoraからCentOSが出たみたいに、
結局FreeBSDは表舞台にでれなかった。
書いてる俺はポスグレ派
CentOSの意味解っていってるのか
あれはRHELからロゴ外してそのまま配布してるだけで互換プロダクトとかそんなレベルではない
本家が無くなったらCentOSも無くなる ついにオラクルがOpenSolaris潰しが始まった
近いうちにMySQLも同じようになりそうな予感 いやいやCentOSの話と違うくらいわかってる。
MySQLがクローズソースになってもMariaとDrizzleがあるって話だ。
ポスグレがこれからMySQLなみに普及するとは思えない。
DBなんてどうでもいいプログラマがMySQL互換DBがあるのにわざわざポスグレに移ると思うか。
世の中DBなんてどうでもいいだよ。動けば。そんで動いたらもういじりたくないんだよ。
MySQL互換DBは本家が存続しないと続かないだろ
本家をちょっと改造しただけなんだからw てかDBなんてどうでもいいのかMySQL互換DBじゃなきゃ駄目なのかはっきりしろよw 基本的に、本家が投げ捨てたものを引き継いで開発し続けるプロジェクトって
上手くいかないからなぁ。あと、MySQLの場合はコマーシャルライセンスが
あったのも大きかったわけだし。 >>516
誰がいつ互換DBの心配について書いた?
>>518
ふつうのユーザやプログラマはDBなんてどうでもいいわけ。
だから手間のかかんない互換DBでOKってことだよ
つうかMySQL使ってるほとんどの奴ってレベル低いだろ
ポスグレやオラクル覚えようなんて奴いねえよ。 レンタルサーバに設定済みのDB使うなら
PostgreSQLだろうがOracleだろうがどうでもよくね
今時ならフレームワークのマッパー使うだろうし
なんでMySQL互換である必要があるのかと >>520
他のレス全然読めないならいちいちレスすんなよ このスレ5年も生きてるけど、
けっきょく、どうなんだ 大規模だったらPostgreSQLの方がいいと思うけど
ぶっちゃけどっちでもいいレベルだと思う >>524
>大規模だったらPostgreSQLの方がいいと思うけど
kwsk MySQLのJOINの方式はレコード数が増えるとパフォーマンスが落ちる(Nested Loop Joinしかない)
あとMySQLのレプリケーションはマスタがおかしくなると終わり
(というか面倒でリカバリに時間が掛かる) MySQLはJOINしないで読み出しばっかやるシステムだと最強なんだけどなー >>528
それならKVS最強じゃね?memcached以外にもいろいろ選択肢がある。
あと、メモリにテーブルデータ全部のっければMySQLもPostgreSQLも速いよ。
つうことでJOINなし検索OnlyでもMySQLは最強じゃないよ。
MySQL使う理由って結局ノウハウだよね
KVSだとまだ耐障害性とか未知の部分があって、
こないだのmixiみたいになることもある。 単純にJOINなし検索専用ならノウハウなんていらんだろ
慣れ、惰性だよ。
MySQL使ってる連中の99%は惰性で使ってるだけ
ノウハウなんてない。このスレみてみ
http://www.mysql.gr.jp/mysqlml/mysql/msg/15364
全員書籍執筆者なのにまともにデータバックアップもリストアもできないんだぜ。
使えてる気になってるだけ。
うわこれはひどい
ただテクニカルライターって現場で引っ張りだこの人でも新しい何かを産み出す人でもなくて
暇な人がやってるという俺の認識からすると不思議なことではない。
わかりやすい文章を書くにはプログラミングと別の才能が必要だからそれはそれで尊敬するけど
大企業なんかでちゃんとしたインフラやってる人が書くってより
中小企業の経営者やフリーランスが書いてるイメージあるな 執筆者は2極化してるよ。
評価の高い本を書くひとは所属関係なく技術レベルも高い。
糞本しか書けないひとはそれなり。
>ただテクニカルライターって現場で引っ張りだこの人でも新しい何かを産み出す人でもなくて
>暇な人がやってるという俺の認識からすると不思議なことではない。
>中小企業の経営者やフリーランスが書いてるイメージあるな
MySQLの中の人(M信さんやO野さん)も暇な人?
そうじゃない人もいるとピックアップしても反論にならんよ
そりゃまともな執筆者もいるのは当たり前なんだし
反論するなら全書籍の執筆者を調べて
大多数は忙しくて技術も完璧ってソースにしないと >反論するなら全書籍の執筆者を調べて
>大多数は忙しくて技術も完璧ってソースにしないと
中学生の夏休みはおわっただろ。早くねないと遅刻するぞ。
つうか、全員まともor全員ダメ
って2択しかできないって、頭が不自由なゆとりだよな。
>執筆者は2極化してるよ。
これ正解。
1割のすごい連中、9割の普通の連中。
執筆依頼のないお前は糞。
>>539
依頼があるボクはすごいんだ自慢乙。
ところで、お前、恥垢臭のせいで周囲から生きる悪臭公害と言われているのに
気づいているか? あまりの臭いで自分の頭まで狂ってしまうぐらいの。
その狂った頭はもう手のつけようがないけど、臭いに迷惑している周囲のため
包茎ぐらいはどうにかしとけ。包茎は治る障害なんだから。 他の人が抱いているイメージ論に対して自分の基準で完全否定するのって小学生レベルだよな まちがった
540と541が絶句するほどひどいレス __
´ ` 、
/ ィ、 \
. / / ! //!、 ヽ
l l | /! /,ヽ.、 /イ |_,、、ハ
l ! | ナレ´ ヽ\ル ヽ! リ
! | |/ ニ=- -=ニ K
l ゝ | xxx ' xx | }
. ! {r∧ r-ー--ァ ノ'
. ! `ー-r、 `ー---' イi |
. ! | | フ`、ー_‐ 〔 \ー、
l ! / \ ` .|、 | ヽ _/ ̄二フ >>540
l i / \_」|oV i ヽ /〈 つノ)
/|.ノ{ ⌒ヽ、 ヽ r‐‐!/ \ / ヽ´イー'
./ .| | 、 ヽ ニ二} ヽo ̄ヽ >'ヽ /
IT業界にいてもSE,PGが天職だと思える人は5%もいない。
9割以上は凡庸なプログラマ。残り5%弱がPGに向いてない人。
執筆者が1割も優秀ならまだいい方なのかもしれない。
まあ1割も適当に言っただけで根拠はないと思うけど。
んで10年後のMySQLとPostgresのシェアってどうなってると思う?
日本では拮抗、世界ではMySQLっていう今の状況(で、いいんだよね?)は
変わらないと思う?いろいろ覚えるの面倒だから一個でいいんだけど 覚えるの面倒だから一個でいいと言う人は一つもマスターできない気がする 例えば俺はポスグレメインなんだが、buffer, work_mem, fsync, commit_delay, check_point_segmentとかの
パフォーマンスに直結するパラメータをどれくらいに設定するのかとか、ORを使うくらいなら二個のSELECTをJOINした方が
早いとか(今は治ったけど)、VACUUM FULLしてもREINDEXしないとINDEXが小さくならないとか、
複数のDBについてそういう細かい特性の違いまで覚えるのは無駄だと思うんだ。
まあOracleも結構勉強したけど、フリーの奴は一個でいいかなって
例えば俺は醤油メインなんだが、塩分濃度、こく、うまみとかの
味に直結する要素をどれくらい把握するのかとか、手仕込みの醤油を使うなら味が安定しているキッコーマン使った方が
うまいとか(今は小さい蔵も品質安定してるけど)、無添加の醤油は劣化が早いから早めに使わないと味が変わるとか、
複数の調味料についてそういう細かい特性の違いまで覚えるのは無駄だと思うんだ。
まあ味噌も結構勉強したけど、フリーの奴は一個でいいかなって
っていう料理人いないだろ 醤油と味噌は用途が違うんだから両方知らないと駄目だろ。
みんなポスグレとMySQL両方とも各バージョンでどんな
変更があったとか把握してんの?
調味料で例えるなら、醤油を作ってる蔵Aと蔵Bがあって、蔵Aは大豆の刈り取りから
醤油になるまでのタイムラグがこれくらいだから何月頃に使うのがおいしいとか、
そういう細かいところを各蔵ごとに浅く広く覚えるより、一番おいしい蔵どころを一社見つけて
そこの醤油の特性を深いところまで覚えた方がいいってことだろ?
なにがおかしいのかわからん 味噌味の煮物か醤油味の煮物か
味噌汁かけんちん汁か
味噌ラーメンか醤油ラーメンか
の違いって事だろ 例えで混乱するのはこれくらいにして、みんなポスグレとMySQLで大方の設定パラメータまで暗記して使ってるの?
どっちも浅くしか使ってないんじゃないの? WindowsとMacとLinuxどれも使うみたいな程度の話だろ
何をキレてるんだ
そもそも他のDBの特徴もちゃんと把握してないとPostgreSQLを客に薦めることもできないだろ
これはPostgreSQLの方が優れてるんです!とかいっても、客にこないだのMySQLのバージョンアップで
そこはMySQLの方が良くなったよね?みたいに突っ込まれたらお前の仕事は
設定までたどり着かずにそこで終わりだ。 つまりお前はバージョンアップ毎に大体どんなとこが変わったか、
自分が関わるプロダクトについては抑えてる訳ね。それには敵わんわ。
DB以外の部分でいっぱいいっぱいだもの。
別に切れてないし、周りがどうなのか純粋に質問したかっただけ。ありがとう 末端部分の製造と設定の仕事しか請け負わない奴ならともかく、
システム全体請け負うフリーランスなら
プロダクトの選定からメンテナンスまで仕事じゃね普通? >>559
つーか導入時点で競合製品の比較やるために調査しないか普通。
逐次全部暗記してるわけじゃなくて、必要なら他のプロダクトについても調査するだけの話だぞ。
積極的にチェックするのはメジャーバージョンアップの時くらいでいいんだし。
俺はポスグレしか知らないし、他のプロダクトのこと学ぶのは意味がないとか言う奴に仕事が来るとは思えん。 わかってる人に質問。
今や、PostgreSQLがMySQLに勝る
ところは、ライセンスのわかりやすさ
だけなの?
MySQLは5.1以降の性能向上が
かなりいいらしいけど。
MySQLがPostgreSQLに勝る点
(1)オフィシャルサポートby Oracleがある
(2)DB毎、テーブル毎のレプリケーションができる
(3)サポートされているシステムやソフトが多い
以上。
パフォーマンスは使いかた次第。CPUコアに対するスケーラビリティはまだPostgresの勝ち。
ただしベンチマークだけで評価するのは素人。アプリ次第でパフォーマンスなんてどうにでもなる。
MySQLはトリガ、ストアドプロシージャがまだまだ弱い。check制約も未サポート。MyISAMは外部キーも未サポート。
ただしこれらを使うか使わないかはあなた次第。
メジャーバージョン間の互換性はPostgresが高い、というかMySQLはマイナーバージョンですら
互換性なくすから実際に運用してみるとどうしようもないことがわかる。
SQLレベルでもころころ仕様がかわるから、アプリケーションまで含めたシステムのバージョンアップに
とてつもないコストがかかる。
>>526
にあるように、レプリケーション用のスレーブを準備するのが大変。バックアップ/リストア機能がとてつもなく貧弱。
これが運用上最大の欠点。
ファイルシステムのスナップショット機能を利用するしかない。あらかじめ準備してなかったり、古い環境で作業させられたりするとアウト。
MySQLはバグも多い。バグフィックスの数が膨大。
もともと開発の稚拙さが目立っていたが最近ではAlterTableでクラッシュするバグが1年以上放置されたりとひどい。
スラドに「PostgreSQLやSQLiteがMySQLの代用になるとか、天と地が逆さになってもありえない。」
とか書いてるキチガイがいるな >>570
あんな基地外シッタカ放置だろ。言っていることの
全てに突っ込みどころがありまくり。 ./見てないけどSQLiteはともかくDRBMSなんてどれも同じだろ殆ど
運用方法や方言が違うだけで SQLiteは両者と比べてどの辺の位置づけになりますか?
http://gro.cc/across/ MySQL 5.5 になって、CPUスケーラビリティは PostgreSQL に追いつきましたか?
5.1 までは酷い性能だったみたいですが。 5.1+InnoDB Pluginでも実はまだ負けてたんだけど
5.5ならPostgreSQLとほぼ互角だと思われる MySQL vs PostgreSQL の時代は終わり。
Oracle vs PostgreSQL が適当。 MySQLのライセンスがよくわからんのでちょっと教えてください(´д`;)
(というか、みなさんどうやってるんだろう・・・)
【ケース1】
店主AはサイトBからMySQLを使ったフリーのショッピングカートシステム(PHP)をダウンロード。
店主Aはショッピングカートシステム(PHP)のソースをちょこっと変更して(文言とかデザインとか設定とか)
店主AはレンタルサーバC(MySQL利用可)にそのシステムをインストール。
店主Aはネットショップをオープン。
【ケース2】
店主Dは個人Eにネットショップの開発、設置を依頼。
個人EはMySQLを用いたショッピングカートシステム(PHP)を開発。
個人Eは店主Dが契約したレンタルサーバF(MySQL利用可)にそのシステムをインストール。
店主Dはネットショップをオープン。
これらのケースはよくあるパターンだと思うけど、誰がライセンス料を払う義務があるの?
・サイトBは自由にダウンロードできる状態でソースを公開してるのでGPLですかね。
・店主Aはソースを変更した上でソース非公開(※)で使ってるのでOEM?
※ショッピングサイトで「このサイトのシステムをダウンロード」があるのはおかしいw
・個人EがOEMとするとお小遣い稼ぎ程度のちょっとしたプログラム作成依頼でも全部OEM?
・MySQLをインストールした上で自由にユーザーに使わせてるレンタルサーバ屋は
ライセンス料とは無関係? ■ このスレッドは過去ログ倉庫に格納されています