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

    元スレMySQL 総合 Part18

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

    651 :

    >>637
    同意。
    バイナリをDBに格納するなんて基地外。
    コネクション長時間握られてあっという間に飽和するぞ。
    転送時間を考えるべし。

    654 = :

    ごめん リストアって書いてあったね
    リストアはどうやったの？

    662 = :

    どっちか知りたいなら試してみりゃいい。
    ただし、決まっているとは限らんけどな。

    663 = :

    >>662
    おっしゃるとおり。時間ができたら試してみます。
    べ、別に誰か既に試したなら教えてくれてもいいんだからねっ！

    664 = :

    試してみた。結果、待ちが終わった時間を取得。

    まぁ、ロックされてる情報にしたって最新のを取得してくれるんだから
    時間もそうなるよなぁ。

    666 = :

    肝心の出力処理の部分を書きなさい

    668 = :

    データベースの容量が大きくなってしまったので、
    ローカルで1行ずつ容量の削減をする作業をしています。
    容量は700MB、レコード数は約20万です。

    $i = file_get_contents('count.php');
    $j = 0;
    while(1){
    $r = db_query('SELECT id,description FROM entry ORDER BY id LIMIT '.$j.',1'); //mysqli関数を使った独自関数です
    if($r === FALSE){ die(); }
    db_query('INSERT INTO entry SET decription = "'.mb_substr($r[0]['description'],0,200,'UTF-8').'" WHERE id = "'.$r[0]['id'].'"');
    $i++;
    file_put_contents('count.php',$i);
    $j++;
    if($j==1000){break;} //ここの数字を変えて1度に処理する量を変える
    }
    db_query('OPTIMIZE TABLE entry');

    テーブルの容量が減れば減るほど、UPDATEやOPTIMIZEは早く終わるのではと思い、
    1000行ずつやってみているのですが、1回に数分かかり、200回もやらなくてはいけません。
    10000行やると1回に十数分かかり、だいたい15MBくらいの削減になるようです。

    そこで質問なのですが、どれくらいずつやるのが良いと思いますか？
    よろしくお願い致します。

    677 = :

    >>676
    クエリはすべて成功したと考えてよい。

    ちなみにこれも老婆心だとは思うけど
    UPDATEは更新対象が０行でも正常終了するから気をつけて。

    678 :

    >>647
    どなたか教えていただけると嬉しいです＞＜

    680 = :

    >>647,6
    ORDER BY rand()を利用すればできるかもしれないけど、全件走査になるだろうしな。
    件数が少ないならプログラム側でなんとかなるだろうし、件数が極端に多くなったらIDを
    乱数で発生させて適度に抜き出したほうがいいだろうし。

    乱数ソートはインデックスが効かないんだから、SQLでなんとかするよりもプログラム側で
    なんとかするほうがいいでないかの。

    681 = :

    >>647
    解決法は分からないんだけど・・・
    差し支えなければ、どういう用途で使用するのか教えてくれる？

    683 = :

    >>682
    とりあえず両者とも、クエリ発行直後の時点でechoなりログ吐くなりしてみたら？
    そこの時点で同じなら、その後の処理になにかあるんだろう。

    685 :

    最近データベースに画像を保存できると知りました。それで、テーブルの扱いについて質問です。

    例えば同じサービスに日記と料理レシピの紹介機能があってそれぞれ写真をUPできるとき、
    1）写真データは専用の写真テーブルに入れるべきでしょうか？
    2）それとも日記テーブルとレシピテーブルに写真用カラムを作って入れるべきですか？

    1）の場合、登録時も引き出し時にトランザクションの負荷が発生するし、
    2）の場合、ユーザごとの合計アップロード容量を算出する時手間です

    どうしたら良いでしょうか
    合計容量の算出なんて各ユーザの管理画面でしか不要だから2）が正解でしょうか
    それとも第3・第4のテーブルを使って効率的に実装する方法があるんでしょうか

    どういう風に作るとどんな面で利点がある、という形で意見貰えると嬉しいです
    初心者過ぎてDB設計の留意点などわからないので漠然とした質問になってすみません
    よろしくお願いします

    686 = :

    ユーザの立場を想像して言うと、一枚の写真を日記とレシピの両方に
    使いたい場合もあるだろうなぁ、とか思うんだな。

    687 = :

    >>685
    >1）の場合、登録時も引き出し時にトランザクションの負荷が発生するし、
    ここがわからん
    別テーブルにすると更新も読み出しも負荷が高くなるって意味？

    個人的には画像は無理にDBに入れんでも
    ファイルでいいんｼﾞｬﾏｲｶと思うが

    688 :

    >>686
    ありがとうございます。確かにそうですね～！
    「日記の記入と一緒に画像UP」の他に「既存の画像アーカイブから選んで日記に貼りつけ」の
    機能も必要ですね

    >>687
    あ、引き出し時はトランザクションいらないですね
    でもjoinが発生するんでしょうか
    ＞別テーブルにすると更新も読み出しも負荷が高くなるって意味？
    はい、トランザクションとかjoinとか、そういうものが少しでも発生しないように
    作った方が良いのかなと思いまして…

    画像を普通にファイルとして保存する場合、利用ファイル容量の計算難しくないですか？
    （PHP使ってるんですが…　任意のディレクトリ以下のファイル容量を
    再帰的に取得できる関数があるのかな～）
    DBに画像登録なら、ファイルサイズも保存出来るからSUMで一発解決かなーと思いました

    689 = :

    画像自体はファイルで、そのデータだけDBいれときゃいいようなー

    690 = :

    >トランザクションとかjoinとか、そういうものが少しでも発生しないように


    なんで瑣末な事をやたらと気にするのかね

    691 = :

    >>687
    少しでも負荷を軽くしたいのならファイルで扱ったほうがいいと思うけどな。そもそも画像データ
    そのものは検索対象にならないんだし。

    >画像を普通にファイルとして保存する場合、利用ファイル容量の計算難しくないですか？
    ファイル名と一緒にサイズも登録しておけばいいだけじゃないの。

    692 = 688 :

    >>689
    なんか初耳です。データだけってのはどういうことですか？
    ファイル容量のデータ（100kbとか）のこと？

    >>690
    大した負荷じゃないんですかね？
    トランザクションもjoinも最近おぼえたので「なんか大層なことをしてしまってる」ような
    気がしてるんですが。

    >>691
    ＞ファイル名と一緒にサイズも登録
    これは689さんの言ってることと一緒でしょうか？　そういうことですよね？
    容量計算用のテーブルにファイルサイズを入れる、と。なるほど…

    693 = :

    >>692
    >トランザクションもjoinも最近おぼえたので「なんか大層なことをしてしまってる」ような
    >気がしてるんですが。

    そりゃやらない場合よりはオーバーヘッドはあるよ。
    ただ、それらをなるべく使わないようになんてのは、RDBを使う旨みをなるべく捨てようと
    してるようなもんだわな。
    まあとことん高負荷なサービス運営しようと言うところなら、一部その旨みを捨ててでも
    システムへの負荷を下げるという技を使ってるかもしれないけど、こんなとこでこんなの
    聞いてる人が作るものなら、先々は分らんが当面はそういう話は関係無いでしょ。
    まずは実装の細かいとこでの効率なんかより、素直な設計のちゃんと動くものを作り
    上げることを考えた方がよろし。

    >データだけってのはどういうことですか？

    画像データは普通のバラのファイルとして格納しといて、
    そのファイルの情報(パス名とか)だけDBに入れておくってことだと思う。

    694 = 688 :

    >>693
    あーなるほど、わかりました！　ありがとうございました

    695 :

    画像はシステム的に破綻をきたしやすいよ。
    DBにいれると例えばWeb側から画像表示となった場合、
    （ローカルサーバにDBない前提だが）
    ネットワーク越しにMySQLのポートを長時間つかむことになる。
    ローカルでも同じことだけどね。
    データ量がテキストの比じゃないからね。
    俺も昔管理のしやすさを期待してそうしたけど大変なことになった。

    696 = :

    DBに入れて初回アクセス時に適当なディレクトリにコピーを作っておいて、二回目以降はそちらを参照。
    一定時間が過ぎたらディレクトリから削除。
    毎回DBから取得はキツいでしょ

    699 = :

    デカいデータを取り出すのが遅いとかそういう話してるんじゃないのか
    データURIスキーム使ってもそこは一緒じゃん


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

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

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