のくす牧場
コンテンツ
牧場内検索
カウンタ
総計:127,062,729人
昨日:no data人
今日:
最近の注目
人気の最安値情報

    元スレMySQL 総合 Part24

    mysql覧 / PC版 /
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。
    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitter

    251 = :

    >>249

    コストの話も極論だよな。つうか、DBAなんてコスト部門でしかないわけでさ。
    効率化すればするほど自分たちのクビを締めることになるんだよ。

    だからMySQL使ってると、
    バージョンアップ毎に膨大な作業が発生してDBAのクビが繋がる、
    マッチポンプ ウマーって思うときもある。

    >>250

    そう。そのレベルでMySQL大規模有利っておかしい。
    JAVAならプーリング使えばいいし、LLでもpgpool使えばよかったわけだし。

    252 = :

    >>249
    > まぁ、元 MySQL のサポートエンジニアでその後は WEB系でしか働いてない人だししゃーないかな。


    キャリア戦略で「ダメな技術は誰もダメといわない。自分で見分けろ。」って書いてるけど、
    これってMySQLのことかと思ったw

    253 = :

    pgpool使っても接続数減るわけじゃないからな。
    あれはポスグレへの接続コスト削減とロードバランシングか主なメリット。
    それとも今のバージョンでは1コネクションで同時にクエリー発行できたりするの?

    254 = :

    よくわからんが接続コスト低けりゃそれでいいんじゃないの?
    スライドの主張についての話なら。

    接続数はMySQLもポスグレも変わらないだろ。カネ払ってスレッドプール入れるなら別だけど。

    接続数が多い場合、昔はポスグレもMySQLも遅かったよ。
    そんでポスグレのほうが並列実行性能がはやく向上した。
    InnoDBはずっと遅いままだった。

    255 = :

    昔に関して言えば、ポスグレはレプがなかったのと
    VACUUMのせいで避けるようになってしまってたな。
    レプがないのは、Web系では結構つらい印象(参照系がおおいので)

    大規模、小規模関係なく、プール(≠永続化)しない場合は
    スレッドベースである MySQL のほうが性能は稼げるかな。
    プールをはさむと管理、トラブル対応めんどいとかもあるし。

    256 = :

    >>255
    レプとVACUUMの問題が解決してから世界で一気に利用者増えたし
    そういうことなんだろうな

    台数が多いとプールはさんだ方が管理、トラブル対応は楽よ

    257 = :

    >>251

    > コストの話も極論だよな。つうか、DBAなんてコスト部門でしかないわけでさ。
    > 効率化すればするほど自分たちのクビを締めることになるんだよ。

    > だからMySQL使ってると、
    > バージョンアップ毎に膨大な作業が発生してDBAのクビが繋がる、
    > マッチポンプ ウマーって思うときもある

    要は、AWS で RDS(マネージドDB)使うのが当たり前になると、
    そういう仕事が少なくなるから、フルスタックエンジニアに成るか、
    スペシャリストになって AWS では満足しないような大規模なところで
    働くかしかなくなってくるよって書いてあるんだよね。

    AWS(RDS) なんてって思うっちゃうけど、利便性とか対障害性とか
    本当にローコストで使えてしまって、エンジニアとしてあれに対抗するの
    きちいって最近いつも思ってる。

    258 = :

    .>>256
    オラクルに問題があるだけじゃないの?

    259 = :

    >>256

    > レプとVACUUMの問題が解決してから世界で一気に利用者増えたし
    > そういうことなんだろうな
    多分最大の問題は Oracle だ。
    あのニュースが流れた時、ポスグレに移行するかほんとうに悩んだ。

    > 台数が多いとプールはさんだ方が管理、トラブル対応は楽よ
    プールがある方が性能は上がると思うんだけど、
    管理とかトラブルはどうなんだろ。
    接続先を増やすときとか、アプリのコードだけじゃなくて、
    プールの設定も追加しないとだめだよね?
    別のものを挟むとやっぱり面倒くさくない?

    260 = :

    同時接続数を制御下におけるのはでかいと思うよ

    基本アプリにはコネクションプールが接続先
    なので、DB台数が増えたときはコネクションプールの設定だけ

    261 = :

    >>255
    Linuxなら今やスレッド起動もプロセス起動もコストはほとんど変わりないけどね。
    2000年頃は確かに違ったけど、2005年頃には(カーネルバージョン忘れたけど)
    プロセス起動も軽快になったんだけどね。


    レプリケーションは確かにWEB系では必須だわな。
    ただし、非同期レプリケーションで参照分散つうのが大規模といわれてもなぁと思うわけだ。


    >>257
    >要は、AWS で RDS(マネージドDB)使うのが当たり前になると、
    >そういう仕事が少なくなるから、フルスタックエンジニアに成るか、
    >スペシャリストになって AWS では満足しないような大規模なところで
    >働くかしかなくなってくるよって書いてあるんだよね。

    それは一理あるんだけど、コスト+利便性でいえば集中型が最もよいけど
    世の中、かならず集中と分散を繰り返すじゃない?RDSの先に何がくるか考えてるよ、俺。


    スライド書いた人、ソニー、MySQL、DeNA、顔本らしいね。いく先々クラッシュしてるのが面白いと思った。
    そういう価値観で会社選んで、キャリア戦略なんつうスライド書いたんだなって。

    262 = :

    ポスグレはDBの機能として、
    ファイルシステムレベルでオンラインバックアップの取得が可能
    レプリカも全く止めずに作成可能

    これがいい

    264 = :

    何で急にストレージ側の機能が出てくるんだ。

    要するに出来ないんだろ。
    こいつの突っかかり方キモイな。

    265 = :

    TechCrunchにこんな事書かれちゃうのは仕方ないよね
    > PostgreSQLは、OracleがSun Microsystemsを買収してMySQLを手中にして以降、人気が増大している。
    > OracleはMySQLのオープンソースな側面に関心を示さなくなったため、メンテ放棄を恐れたユーザはPostgreSQLへの引越しを開始したのだ。

    これから日本は>>234に書いてあるような日本市場の特殊性が起きるわけだ

    266 = :

    >>264
    >こいつの突っかかり方キモイな

    こいつだなんて、自称ギーグの日本男児様をしらないのかw
    日本男児様のブログさえ読んでればトランザクションも知らないWEB野郎たちは幸せに暮らせるんだ。
    なにせ日本男児様はMySQLを完全無欠にみせてくれるからw

    267 = :

    postgresにhandlersocket的なものがあれば移るわ。

    268 = :

    >>267
    FDWのエクステンションつくればいいんでね?

    272 = :

    >>265

    > これから日本は>>234に書いてあるような日本市場の特殊性が起きるわけだ


    どうだろうねえ。
    新規プロダクトはポスグレも増えるだろうけど、
    すでにMySQL方言でガチガチにつくりこんだプロダクトはマリア一択だね。

    オープンソースのデファクトプロダクトの多くはMySQL依存が強烈だから。

    273 = :

    逆だろ、世界はpostgresにいくのに日本はmysqlのままってことよ

    274 = :

    mariaってinnodb使えなくて大丈夫なの?

    275 = :

    >>273

    いやいや、世界がポスグレに流れるのかって。

    もともとビジネスユースはOracle->ポスグレの流れはあった。ビジネスユースでMySQLなんて使いものにならないじゃない。
    まともにジョインもできない、コロコロ仕様がかわるし。

    WEB系はMySQLが強くて、オープンソースのプロダクトもMySQL依存が強い。
    MySQL独自SQLを使いまくってるプロダクトが多いから、いまさらポスグレに移植できないものも多いのが実情。

    どのプロダクトだってのは書かないけど、かなり多いよ。
    移植が失敗したプロダクトもいくつか知ってる。どれもその分野のデファクトでポスグレ未対応。
    DB詳しくない人たちが開発するから、MySQL独自機能をつかいまくって移植不可能なくらい
    複雑なコードになってたり、
    「PHPのDBO使ってるから移植できるっしょ」くらい軽いノリの開発者ばかりなんで
    移植の問題自体を認識されてないとか。

    DB屋とアプリ屋の溝はとても深いよ。

    276 = :

    >>274
    > mariaってinnodb使えなくて大丈夫なの?

    MariaDBはInnoDBバンドルされてるよ。
    InnoDBは一応オープンソースだし、Oracleが改造した機能をMariaDBも独自に取り込んでる。
    それとInnoDB互換のXtraDBもバンドルされてるし。

    277 = :

    Oracleに潰された

    278 = :

    >>276
    それでライセンスとかオラクルの存在とか大丈夫なの?

    mysqlから世界が逃げ出したのって、INNODBが買収されたとき始まったんよね

    279 = :

    xtradb作ったのは別の会社なんだよな。
    使ってみたいけどサーバースペックある程度無いとinnodbと性能変わらないんだっけ?

    280 = :

    >>279

    性能がどういういう奴にかぎって、ろくでもない馬鹿SQL走らせてるよなあ。
    ベンチマークばっかやってる奴とか。

    281 = :

    >>278

    だからオープンソースっていってるじゃん。
    マリアだってMySQLのフォークなんだし。
    自分たちでなんとかするのがオープンソース。

    282 = :

    >>281
    ライセンスやオラクルに対する見方が違うのがよくわかった

    283 = :

    >>276 XtraDBはGPLv2下のInnoDBをフォークして魔改造 したもので、ライセンスは勿論GPLv2。
    開発元はPercona。 5.5のXtraDBはMySQL 5.5から、5.6のXtraDBは MySQL 5.6からブランチしなおしてるから、
    Oracle がMySQL潰したら多分進化は止まる。
    進化は止ま るけど既存のフォークはGPLのまま影響を受けない ので、今あるところまでは問題なくXtraDB使える (これはInnoDBも一緒だが)

    http://www.percona.com/software/percona-xtradb

    XtraDBとInnoDBは共存できない。XtraDBが入って る環境でCREATE TABLE .. Engine= InnoDBってやる とXtraDBが使われる。 例外的に10.0.3~10.0.5くらいではInnoDBが入って いたけど、MariaDBでは5.3以来ずっとXtraDB。

    284 = :

    >>283

    maria5.5.32にstorage/innobaseとstorage/xtradbがあるんだけど、
    それでもCREATE TABLE .. Engine=InnoDBってやるとXtraDBになるの?
    だとすると、なんでソースがバンドルされてんだろ。

    285 = :

    >>284
    なんでか知らないけど昔から両方ある。
    Percona ServerのXtraDBはstorage/innobaseの下にしかないんだけどね。

    SHOW ENGINESをよく見ると、InnoDBの説明にXtraDBって書いてあって、どっちやねんてかんじだけど。

    287 = :

    タブレットにもいろいろあってだな・・・

    288 = :

    windowsのタブレットなら出来るんじゃない
    windows8がそのまま入ってるんでしょ?あれ
    タブレットに入れる意味はないと思うけどな

    290 = :

    ネットにつながるならVPSなりを借りて使うのが無難
    どう入れるのか知らんがarmでもmysqlは動くようなので入れようと思えば入れらるんじゃないか
    足りないパッケージは多そうだけど

    293 = :

    こっちで聞けと言われたので質問させてください
    mysql5系の質問です
    DBを作る時の「MyISAM」と「InnoDB」の違いがよくわかりません。
    ゴミでもわかりやすいように教えて頂けないでしょうか?

    294 = :

    >>293ですが解決しました

    296 = :

    以上ゴミがお伝えしました

    298 = :

    しないといけないってことはないけど、それでも実装はできるんじゃない?
    逆に値の列だけでどうにかしようとすると、先頭に"!!"をつけているものは非公開と判定するとか
    ユーザーが入力したものかどうかを確実に判断できるように実装しないとバグるけど

    299 = :

    作らないといけないっていうか、普通そう作るよね
    何が嫌なんだ?

    300 = :

    それか公開情報カラムを1つで作ることも出来るけどね
    そのカラムの数字が
    2の倍数なら名前公開
    3の倍数なら年齢公開
    5の倍数なら住所公開
    7の倍数ならプロフィール公開
    11の倍数なら出身校公開
    みたいに
    いや、普通はやらんが


    ←前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ→ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql一覧へ
    スレッド評価: スレッド評価について
    みんなの評価 :
    タグ : 追加: タグについて ※前スレ・次スレは、スレ番号だけ登録。駄スレにはタグつけず、スレ評価を。荒らしタグにはタグで対抗せず、タグ減点を。

    類似してるかもしれないスレッド


    トップメニューへ / →のくす牧場書庫について