元スレMySQL 総合 Part19

mysql覧

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで

852 = :

>>849
意味が分からないんだけど…DBに画像を格納するとどうしてレプリケーションが大変に？？

853 = :

いや、画像云々じゃなくて、仕事でやると大変ということ。

854 = :

>>841
http://www.bitscope.co.jp/tep/MySQL/quickMySQL.html#doc1_id458

このあたり読んでみたら。

855 = :

DBに画像保管とか、素人乙としかいいようがない設計

856 = :

>>855
あまり初心者をいじってやるなよ。かわいそうだろ。

858 = :

>>849>>855
クラスタ組んでいる場合なんかはDBMSに任せられる分逆に楽だと思うけどね。

859 = :

>>858
画像とかサイズあるから、大量にくるとレプリケーション遅延するっしょ。
スレイブの状態がバラバラになる可能性も出る。

860 = :

そりゃサイズ次第だな。
スレイブの状態がバラバラってのは意味がわからん。
MySQL ClusterはBLOBの一貫性に問題があるってこと？

861 = :

巨大データが届くと遅延が発生してバラバラって事でしょ
掲示板とかに書きこんだ文字がなかなか表示されなかったりね
バイナリデータに差異が起きるのでなく、時間的に差異が出る

862 = :

そういう現象が発生するとしたらクラスタとして成り立っていないことになるが…
MySQL Clusterにそういう問題があると言っている？
いずれにしても、画像を外出しにしたらその同期のところを全部自前で用意しなきゃ
ならんわけだよ。

863 = :

>>854 どうもありがとう。読んでみます。

864 = :

クラスタって何？

865 = :

>>862
あぁ MySQL Cluster ってオンメモリだけなお大臣ソリューションあったなｗ
一般的なレプリケーションの時の話ですね。

同期のところを自分で～ってのも多分HTTPサービスだろうからリバースプロキシ＋キャッシュとか、rsync でえっちらおっちらとか、そちらの手法も色々確立されてるし
画像をDBにつっこんで幸せな状況もあるし。
うちは両方やってるよ

866 = :

レプリケーションでもあんまり事情は変わらんと思うがなぁ。
画像は同期が取れていないことがあってもいいから通常レコードの
同期だけは早く終わらせたいとか、そういう暗黙の前提があるのかね。

867 = :

>>866
通常マスタは更新専用で読み出しはスレイブからになる。だから、スレイブの最新データがそれぞれ違うと大問題。
大手サイトのケーススタディみたいなの見るといいよ。
ほぼみんな同じ運用。
画像はDBとは別管理で、DBはレプリケーションで、マスタ・スレイブ。スレイブ増やして負荷分散。

最近はAmazonS3に画像などファイル預けるのがデフォになりつつあるもうな気もする。

868 = :

だからさ、DBと画像の同期ズレは許容すんのが前提なの？で、スレーブ間の同期は
そんだけシビアなの？
そもそも、スレーブ間の完全な同期が必要だったらレプリケーションでやっちゃダメじゃんｗ
それを、画像が含まれないなら無視できる範囲だからやっちゃえ、てなもんか。

870 = :

>>868
画像はそもそもDBとは別に管理するもんだ。DBスレイブには画像は置かない。
まぁ自分はそこまで大きなシステム触ったことないけど、静的ファイルの配信は負荷分散というより、冗長化による信頼性なんじゃないかな。
バックアップするだけで、レプリケーションするわけじゃないと思う。
詳しい人教えて。

871 = :

大学の卒業研究でMySQL、PHPを１年ほど使用してデータベースサーバを
の構築をした経験があり、実務経験がないのですが、転職ってできますかね？

現在大学４年なので新卒向けのサイトを見て就職するのが一般的なのですが
給料等の面から、同じ正社員であれば転職のほうが良いなぁと考えています。
お詳しい方教えてください。

872 = :

環境構築云々より何を作ったかが大事

873 = :

実務経験がないなら新卒以下の待遇だろうな

874 = :

>>871
その程度の人材なら二束三文で手に入るので別にどうでもいいし
それしかウリがないのなら むしろいらないんだけど

というのが正直な回答になるよね・・・申し訳ないけど

875 = :

素直に新卒枠で見ていった方が良さそうですね。
ありがとうございました。

876 = :

画像をDBへの話は、画像を入れるタイミングが
人によって想定がバラバラに見える。

多少の信頼性の低さを許容出来るような WEBサービスを
前提とした場合の話になってしまうが、
画像を管理者が更新する場合はスレーブの遅延は気にならないはず。
# 更新頻度が低く、画像を公開するタイミングをコントロールできる

画像アップロード掲示板みたいなユーザー更新で
画像が追加される場合は、頻度が多いので
遅延を許容して専用DB用意するなり、KVS なりに逃がすのが
いいんじゃなかろうか

ちなみに、うちの場合は「ユーザー更新のサービスはしてない」、
「画像の合計容量が数Gしかない」という条件なので、
一番性能が良いと考えて、WEB用サーバ自体にファイル同期してる。
# サーバは300台前後

877 = :

状況によって変わるから絶対の解は無いよね
画像が入ったテーブルのダンプがでかくて嫌とかもあるな

878 = :

バイナリファイルをダンプで出すこと出来ましたっけ？

879 = :

基本を分かってあえて崩す技使うのはあり得るが、それを初心者にいきなり教えるなっつーこと。
あえてそれやるレベルの人間がここで「４Ｇ越えたらテーブルを分割して対応しているの？」なんて
質問するわけないだろう？　だから、ここでの回答は一律「画像をDBに入れんな」　でいいんだよ

880 = :

DBとDB管理外のリソースに分ける方が基本なのかｗ
どうも常識が違うようだ。

881 = :

自分が今まで勉強のために見たすべてのケーススタディは、バイナリは別管理だった。

882 = :

テーブルのフィールドタイプがInnoDBで
全体のフィールドタイプがMyISAMになってることに気がついたんですが
このままでも問題ないでしょうか

883 = :

>>882
言ってることが良く解らん。

デフォのテーブルタイプがMyISAMと設定されてるけど、
いくつかInnoDBなテーブルも存在してしまってるってことか?

それは、もーまんたい。

884 = :

>>883
そのとーりです。
特に支障なく動いているようなのですが、
気持ち悪いので統一したほうがいいのかとおもって

885 = :

>>880
君どこで勉強したの？

886 = :

>>880
君の常識は怖いな。

887 = :

>>884
統一じゃなく、テーブルの使用目的に合わせて設定すべきだぞ。
MyISAMとInnoDBの違いとか勉強すべし。

888 = :

>>887
最近は、調べていくと、InnoDB一択にしか
ならなくない？
よっぽどでなければそれ以外の選択肢に
ほとんど意味がない感じがする。

889 = :

全文検索さえなければ

890 = :

>>847
DBとファイルシステムを深く知らない俺には無理だ。

891 = :

likeで実現できない検索機能は作らない。これでOK

892 = :

>>891
うんこだな

895 = :

MySQL5.5.8でテーブルの列名を変更したいのですが、

ABC.DEFのように列名に「.」が含まれているため上手く変更できません。

ALTER TABLE z09_96 CHANGE COLUMN ABC.DEF ABC_DEF;
などと入れると
"Incorrect table name 'ABC'"
といったエラーが出てしまいます。
.がテーブル指定の.と認識されていると思うのですが回避策は有りませんでしょうか。

896 = :

>>895
バックスラッシュで囲む。
mysql> ALTER TABLE z09_96 CHANGE COLUMN `ABC.DEF` ABC_DEF CHAR(10);
Query OK, 0 rows affected (0.09 sec)
Records: 0 Duplicates: 0 Warnings: 0

897 = :

>>896

書き方は合ってるけど、それはバックスラッシュじゃないよ。

899 = :

後で泣き見そうなカラム名だなや

900 = :

ここにのせるのに適当な名に変えてんでしょ？実際にそうだったらプログラマは泣くだろうけど w

前へ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 次へ / 要望・削除依頼は掲示板へ / 管理情報はtwitterで / mysql一覧へ

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

• MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
• MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
• MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
• MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
• MySQL 総合 Part17 (1001) - [94%] - 2010/6/10 20:47 ○
• MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
• MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
• MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
• MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
• MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
• MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
• MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
• MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
• MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○