漢のコンピュータ道の開設間待ち

>>850
感覚的にはそれでいいと思う
Oracleでも速くなった経験がない＞インデックスマージ

varcharとtextの違いってなんですか？
両方とも最大格納文字数って65535ですよね？

>>854
マニュアル嫁
http://dev.mysql.com/doc/refman/5.1/ja/blob.html

>>853
Oracleにインデックスマージの機能ってあったっけ？

ＤＢのテーブル設計についてアドバイスをください。（長文失礼します）

SNSもどきのサイトを作っているのですが、
自分のマイページにお気に入りユーザーの行動を逐一通知する機能を作ろうと考えています。

例えば、お気に入りユーザーが「日記を書いた」「写真をアップした」「他の日記にコメントをつけた」等の
行動をとった場合に、自分のマイページに行動履歴が表示されるようにしたいのです。

その際、行動履歴のデータはどのように取得すべきなのでしょうか？


単純に、マイページを表示する度に必要な情報を各テーブルから取得れば実装は可能です。
具体的には、
全てのお気に入りユーザーについて
entryテーブル、pictureテーブル、commentテーブル、等、ユーザーのアクションに関連するテーブルから
データを引っ張ってきて新着順に表示する感じです。
ただ、お気に入りユーザーが増えたら物凄く重い処理になりそうです。。

もう一つの案としては、
行動履歴用のテーブルを別に用意して、
ユーザーが何かしらのアクションを起こした時に、本来のテーブルとは別に
行動履歴用のテーブルにもデータを保存するようにすれば
マイページを表示する際には一つのテーブルから検索するだけでよくなるので良さそうです。

どちらの方法が一般的なのでしょうか？
また違う方法あるのでしょうか？
facebookなどにもある機能なので理想的な実装方法がありそうなのですが
ネットで調べてもなかなか見つかりませんでした。

ＤＢ分散を始めてみようと思っています。
どのＤＢサーバにどれくらい負荷がかかっているかを
モニタリングするような仕組みはありますか？

WindowsのタスクマネージャーのＣＰＵ利用率みたいなグラフだとなお良いです。

>>859
自分なら後者。
おそらく大量のinsertがあるだろうから当然innodbで。

>>860

マニュアルを読み返してください。

サーバー側からの実行とクライアント側からの実行についての注意点が書かれています。

INSERTがある日突然遅くなった(数msだったのが数十秒に）んだけど
どんな可能性があるでしょうか。

状況としては
・INSERT ... ON DUPLICATE KEY UPDATEを使っている
・SELECTを使ったINSERTではない
・特定のテーブルへのINSERTだけが遅い
・そのテーブルをロックするクエリなんて無い
・トランザクションの途中なのに重い
　（commitで時間がかかるほうがまだ理解できる）

自分の知識で思いつく範囲では、ロックされてるとしか思えないので
やっぱりどっかでロックしてるのかなぁと思うのですが。

インデックスがいっぱい貼ってあるとか
mysqlcheckしてみるとか

インデックスは単項目のが３つあるけど
INSERTとはいえ事実上はUPDATEで、どのインデックス項目も更新しない
というときでも遅い…。
データもたかが4万行程度。

mysqlcheckは知らなかったのでちょっと調べてみます。

>>867
ふつうにハード障害を疑っちゃうなあ

>>867
他のテーブルがどうなってるかわからんが、インデックスの総量がメモリに収まらなくなってディスクアクセスが発生しちゃってるとか
メモリは十分に積んでるけど設定で使い切れてないとか

>>870
ひとまず目を通してみて
http://dev.mysql.com/doc/refman/5.1/ja/disaster-prevention.html

5.5になって、パフォーマンスが大幅に改善したらしいけど、
実際に使っていて、変わったっていう人いますか？

実際にどうなのかを聞いてみたい。

互換性がメタメタ

バックアップの考え方について教えてください。

バックアップ方法として、mysqldumpを忌み嫌う人が多いのは何故でしょうか？
データが膨大になると致命的になるのですか？

うちの会社のサービスはDBの総データ量がまだ１０ＧB程度なので
フルでバックアップとっても数分で終わります。
その間は確かに接続が困難になるのですが、週１で深夜３時とかなので問題ないと思っています。

ここら辺の考え方は間違っているのでしょうか？
会社にWebサービスのノウハウが無いため一般常識が欠落していそうで少し怖いのです。

>>876
大きな誤解があると思うけど、mysqldumpだと論理バックアップが取れるだけ。
だから、リカバリーしようとした時に、リカバリが正常に出来ない場合が多々発生する。
mysqldumpは緊急用であって、業務で使うのは論外。

何かの原因でDBが異常をきたした場合って
他のバックアップ方法でも影響を受けるように思うけど
>>877が業務で使ってる方法は何なの?

＞その間は確かに接続が困難になるのですが、週１で深夜３時とかなので問題ないと思っています。

mysqldumpしている間は、接続が困難になるって、
そもそも何？

接続が困難じゃなくて、単に落ちているってことでしょ。
サーバー落とすような運用がそもそもどうかと思うけど。

みなさんは保存ドライブに、もうSSDは使ってますか？
SSDだと実質オンメモリDBに近い代物になると考えて良いのかな。

今は、安価なMLCタイプでも総書き込み数700テラ持つとかで、
寿命的には100年かけても使い切るの無理レベルだし
そろそろ検討しても良いのかな、と思いまして。

SSDを使うことを検討するような高負荷のサイトなら、
いっそうClusterを使った方がスケールアウトがしやすいし、
速度も圧倒的に速いでしょ？

>>882
なるほど。　つまりSSDではレスポンスの改善は期待できないということでしょうか？

期待できないことないけど、実効の転送速度がSASと余り変わらない。
それに、SASに比べてSSDの信頼性は格段に低いから、そもそもサーバー向きじゃない。


それなら、まずRAID0+1で4台くらい並列でやってみることが先で、
それでも限界ならClusterかもね。

SSDの評価で転送速度て。本当に分かってんのかね

>>884
お前がとんでもないシッタカってことは理解してあげた。口から出まかせ
撒き散らされると迷惑だから、もう二度と湧いてこないこと。

>>876
リストアが遅い
一度リストアのテストしといたほうがいいよ

その著者名とか分類とかタグに別のフィールド
（たとえば分類コード）があって、そのフィールドも検索対象になるなら
そういうテーブル構造がいいんだろうけど、
名称だけしか必要ない（twitterのハッシュタグみたいな）んだったら
記事: id, body
著者: id, 記事_id, name
カテゴリ: id, 記事_id, name
タグ: id, 記事_id, name
でいいんじゃねえかなぁと思う昨今

>>889
その手もアリですね

>>890
了解です

>>893
うん。configureじゃなくなったようだ。
自分はどうやったっけな。インストールスクリプトがあったような。それはバイナリの場合か。

>>897
それって、comment は一意に決まる？