10/12/22 15:25:34
>>867
ふつうにハード障害を疑っちゃうなあ
872:NAME IS NULL
10/12/22 16:26:17
>>867
他のテーブルがどうなってるかわからんが、インデックスの総量がメモリに収まらなくなってディスクアクセスが発生しちゃってるとか
メモリは十分に積んでるけど設定で使い切れてないとか
873:NAME IS NULL
10/12/22 20:42:47
>>870
ひとまず目を通してみて
URLﾘﾝｸ(dev.mysql.com)
874:NAME IS NULL
10/12/23 16:25:26
5.5になって、パフォーマンスが大幅に改善したらしいけど、
実際に使っていて、変わったっていう人いますか？
実際にどうなのかを聞いてみたい。
875:NAME IS NULL
10/12/23 17:17:21
互換性がメタメタ
876:NAME IS NULL
10/12/23 18:23:01 YZc0Oqr1
バックアップの考え方について教えてください。
バックアップ方法として、mysqldumpを忌み嫌う人が多いのは何故でしょうか？
データが膨大になると致命的になるのですか？
うちの会社のサービスはDBの総データ量がまだ１０ＧB程度なので
フルでバックアップとっても数分で終わります。
その間は確かに接続が困難になるのですが、週１で深夜３時とかなので問題ないと思っています。
ここら辺の考え方は間違っているのでしょうか？
会社にWebサービスのノウハウが無いため一般常識が欠落していそうで少し怖いのです。
877:NAME IS NULL
10/12/23 18:39:39
>>876
大きな誤解があると思うけど、mysqldumpだと論理バックアップが取れるだけ。
だから、リカバリーしようとした時に、リカバリが正常に出来ない場合が多々発生する。
mysqldumpは緊急用であって、業務で使うのは論外。
878:NAME IS NULL
10/12/23 18:48:32
何かの原因でDBが異常をきたした場合って
他のバックアップ方法でも影響を受けるように思うけど
>>877が業務で使ってる方法は何なの?
879:NAME IS NULL
10/12/23 18:55:39
＞その間は確かに接続が困難になるのですが、週１で深夜３時とかなので問題ないと思っています。
880:NAME IS NULL
10/12/23 19:08:33
mysqldumpしている間は、接続が困難になるって、
そもそも何？
接続が困難じゃなくて、単に落ちているってことでしょ。
サーバー落とすような運用がそもそもどうかと思うけど。
881:NAME IS NULL
10/12/23 19:10:10
みなさんは保存ドライブに、もうSSDは使ってますか？
SSDだと実質オンメモリDBに近い代物になると考えて良いのかな。
今は、安価なMLCタイプでも総書き込み数700テラ持つとかで、
寿命的には100年かけても使い切るの無理レベルだし
そろそろ検討しても良いのかな、と思いまして。
882:NAME IS NULL
10/12/23 19:31:43
SSDを使うことを検討するような高負荷のサイトなら、
いっそうClusterを使った方がスケールアウトがしやすいし、
速度も圧倒的に速いでしょ？
883:881
10/12/23 20:53:47
>>882
なるほど。 つまりSSDではレスポンスの改善は期待できないということでしょうか？
884:NAME IS NULL
10/12/23 21:11:14
期待できないことないけど、実効の転送速度がSASと余り変わらない。
それに、SASに比べてSSDの信頼性は格段に低いから、そもそもサーバー向きじゃない。
それなら、まずRAID0+1で4台くらい並列でやってみることが先で、
それでも限界ならClusterかもね。
885:NAME IS NULL
10/12/23 22:02:38
SSDの評価で転送速度て。本当に分かってんのかね
886:NAME IS NULL
10/12/23 23:12:33
>>884
お前がとんでもないシッタカってことは理解してあげた。口から出まかせ
撒き散らされると迷惑だから、もう二度と湧いてこないこと。
887:NAME IS NULL
10/12/23 23:16:18
>>876
リストアが遅い
一度リストアのテストしといたほうがいいよ
888:NAME IS NULL
10/12/24 11:10:43 CmCii1Ay
記事が著者、カテゴリ、タグとそれぞれ多対多の関係になる場合次のどっちが使いやすい、パフォーマンスがいい、ですか（検索など）？
記事の分類が増えることはなく、著者はただの分類でログイン等は持ちません。
記事: id, body
著者: id, name
カテゴリ: id, name
タグ:id, name
著者関係: 著者id, 記事id
カテゴリ関係: カテゴリid, 記事id
タグ関係: タグid, 記事id
記事: id, body
taxo: id, name, type
taxo関係: taxoid, 記事id
※taxo.typeは著者、カテゴリ、タグのいずれか
889:NAME IS NULL
10/12/24 14:24:59
その著者名とか分類とかタグに別のフィールド
（たとえば分類コード）があって、そのフィールドも検索対象になるなら
そういうテーブル構造がいいんだろうけど、
名称だけしか必要ない（twitterのハッシュタグみたいな）んだったら
記事: id, body
著者: id, 記事_id, name
カテゴリ: id, 記事_id, name
タグ: id, 記事_id, name
でいいんじゃねえかなぁと思う昨今
890:NAME IS NULL
10/12/24 16:33:47
>>888
DB設計を語るスレ 3
ｽﾚﾘﾝｸ(db板)l50
891:NAME IS NULL
10/12/24 18:04:13
>>889
その手もアリですね
>>890
了解です