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

    元スレ【この先一体】MySQL 総合 Part15【どうなるの】

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

    303 = :

    MySQL単体の問題みたいだけど、エラーも出ない、ログイン時間が掛かる
    というのは不思議ですね…

    305 = :

    >>302
    エラーログに何も出ていないなら、テーブルスペースフルとかでもないんだよね。
    単純に件数が増えて遅くなっているならexplainとかを使ってクエリの中身とか
    インデックスの張り方を工夫してみると良いと思う。ファイルソートになってる
    とか、インデックスを使えてない可能性もあるから。

    306 = :

    >>303-305
    アドバイスありがとうございます。
    explainなど試してみます。

    307 = :

    MySQL 5 を使い始めました。

    PostgreSQL には vacuum がありますが、
    MySQL には同様のものはありますか?

    308 = :

    そんなものはいらないない。

    309 = :

    >>308
    ありがと。すばらしい。

    310 = :

    あれ? 2chはファイルシステム有利とか言ってた約1名は逃げた?

    2chがDB使ってないのは、元々の仕様でそうなっていたからだろ?
    要するにDB管理の掲示板じゃなかったから。

    DB版掲示板の無料レンタルなんて当時ほぼ無いだろうが
    スレ内検索なんかにはDBの方が有利だな。CPUに負荷もかからんし。

    311 = :

    それで思い出したけど、カウンタの質問してた人は質問投げっ放しか。
    疑問は解けたのかな。

    312 = :

    >>310
    スレ内検索…

    313 = :

    ってゆうか2ちゃんってひろゆきが作ったんじゃないの?
    ひろゆきプログラマー?

    314 = :

    お手軽ででかいシステムだとファイルシステムがいい
    金かけまくってとことん突きつめるとDBになるがコストパフォーマンスが…

    315 = :

    >スレ内検索なんかにはDBの方が有利だな。CPUに負荷もかからんし。

    真性のヴァカ発見

    つかRDBMS覚えたて厨房はさっさと2chをMySQLで構築してみりゃいいじゃねーか。

    316 = :

    >>310
    本気でそう思っているなら運営板にでもいって鯖管理でもやらせてもらえば。

    UNIX板あたりの住人に「バカ発見」と言われるのがオチだろうけど。

    317 = :

    DBに入れると魔法の力で計算量が激減すると思ってるのかもね。
    元々の仕様がなんでそうなったのかとか、検索用のインデックスを
    張るコストとか、深く考えてないんじゃないかな。

    318 = :

    その理由は?

    319 = :

    >>314
    RDBMS相当の機能を自前で実装しようとすると、もっとお金が掛かるよ~

    2chの書き込みをわざわざSQLを使って格納するのは無駄だし、ACID特性も
    必要無いし、RDBMSを使う意味は無いよね。

    321 = :

    2chはファイルシステム管理だお

    技術要件が違うんだから適材適所

    322 = :

    ファイルシステム管理とか変だろ。
    ただのベタファイルだろ。

    323 = :

    たいていのブログもDBじゃね?
    ファイルで管理とか初心者すぎだろ

    324 = :

    そのベタファイルをファイルシステムで管理してるんだよ。
    ディレクトリとかキャッシュとかタイムスタンプとかアクセス権減とか、
    その他のメタデータとか、実装をきちんと理解していれば変ではない。

    325 = :

    ファイルでの管理の問題点は、ファイル内を検索する速度の速い遅いではなく
    同じディレクトリ内に大量のファイルを置くとそのファイルを探すのに時間がかかる事。

    326 = :

    >>319
    ?2chでもACID特性は重要だろ。
    でなきゃ同時に書き込みしたらレスが混じるとか、行数制限を越えた
    書き込みをした時にレスが半分だけ書かれるなどということが
    起きかねない。

    327 = :

    >>325
    板毎にディレクトリは分かれてると思うけど、読み書き可能なスレッドだけ
    なら大量というほどの事は無いでしょ。ファイル名のキャッシュもあるし。
    もしファイル数が問題なら、ある程度のスレッド数毎にディレクトリを
    分ければいいだけだし。

    >>326
    程度の問題だけど、2chはレスを書き込む度にいちいちfsync()しないと
    いけないサイトではないでしょ。永続性は限定的で十分。

    328 = :

    楽観的ロックという考え方もあるしな。

    329 = :

    あれ?>>310は(ry

    330 = :

    >>327
    なぜその文脈でfsyncだの永続性だのといった単語が出てくる?

    331 = :

    >>319
    だから、同等の機能はそもそもアキラメル

    332 = :

    ちなみにとことん突きつめると全データオンメモリとか
    そんなもんw

    333 = :

    >>327
    だからファイルで管理する場合ディレクトリを分けなきゃいけないって事でしょ

    334 = :

    スレ内検索は、全文検索だから
    転地インデックスにするか、grepみたいに全部見るしかないんじゃね?

    335 = :

    >>330
    理解出来なかったのならACIDのDについて調べてみよう。

    >>333
    2chのスレ数なら>>325の問題はそもそも気にしなくて良いという事。

    336 = :

    そういえば「したらば」もデータベースって聞いた事あるよ。

    337 = :

    掲示板にDBを使う主な理由はこのどちらかだけど、

    ・データを連携させて高度な機能を実現したい
    ・性能を多少犠牲にしても、データの管理を丸投げしたい

    「2ch」はどちらにも当て嵌まらないんだよね。

    338 = :

    >>336
    何処で聞いたんだ?したらばも2chとほぼ同じ仕掛けだったと思うが。
    まあ、今話しているのはスレッドの管理のことで、
    板自体の管理にDBを使ってる可能性は否定しない。
    2chブラウザの仕組みを知ってるならスレッドの管理にDBを使ってないのは明白だろ。

    339 = :

    2chがどうとか言う話になってるから便乗して質問したいのだが
    sennaってどうなの?
    仕組みがよく分からないのだが、効率よく分かち書きしてくれるって事?

    341 = :

    2ちゃんがデータベースだろうが何だろうがかまわないが
    FOX★がハゲすぎてるのが気になる

    342 = :

    InnoDBってどうやって読むのでしょうか?
    インノデービーで合ってます?

    MyISAMはマイアイサムで合ってますよね?

    344 = :

    猪野出武威

    345 = :

    えー、イノデブイとマイイサムなんですか‥‥。

    346 = :

    イノデービーとマイイザム

    347 = :

    http://www.youtube.com/watch?v=RpC1BMOZeAs

    0:37 で『インノディービー』って言ってるね。
    日本では『イノデービー』と呼んでる人が多いと思う。

    348 = :

    mysql+phpで、例えばmysqlに
    A123A456A789
    って文字が格納されてるローがあって、
    これからA456てのを削除して、A123A789を残したいってときには、
    まずselectして、そこのローをみて、str_replaceしてupdate set
    する方法しかないかな?
    sql文だけで便利なものありませんか

    349 = :

    と思って調べたらREPLACE関数ってのがあった
    お騒がせしました

    350 = :

    解決できずモヤモヤしてます。
    初心者すぎてめっちゃ恥ずかしいですが、よろしくお願いします。
    バージョンは 5.1.22-rc です。

    TESTテーブルにある、SUUJIというカラムの構造を変更する文を書いてみました。

    ALTER TABLE `TEST` CHANGE `SUUJI` `SUUJI` INT( 4 )

    INT型は4byte必要と知ったので、INT(4) としてはみたものの、INT(1)でもINT(5)でもエラーが出ません。
    INT(1)にしたあと、試しに数字を保存(999999.....と大きめな数を入力)してみたのですが
    通常の最大値2147483647まで保存可能なようです。
    INT( xx ) の指定には意味があるのでしょうか。そして、本来どう指定するのが正しいのでしょうか?


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

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


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