p RSS

変態たちと書いています

DIE BURIBUNKEN!!!

BURIBUNKEN muxtape!!!

あわせて読みたい

tracker

Archive

Jun
19th
Thu
permalink
I Will Derive! (via MindofMatthew)
permalink
ガーディアンでは新聞のことを、『死んだ木』(紙のこと)を使ったビジネスだ、と言う。
Jun
18th
Wed
permalink

同性愛者と異性愛者の男女をMRI検査した結果、研究者たちは、女性を好む人――異性愛者の男性と同性愛者の女性――は脳の右半球のほうが大きく、男性を好む人――異性愛者の女性と同性愛者の男性――は脳が左右対称であることを発見した。

問題となっているのは、同性愛が個人の選択によるものか、あるいは生物学的に不可避のものかという点だ。

ヨーロッパ最大の同性愛者関連ニュースサービスといわれる『Pink News』では、異なる性的指向を持つ男女について、生物学的に測定可能な違いを発見したとする最近の研究について、それらが暗に意味するところを単刀直入にこう述べている。

「これらの研究が意味するのは、同性愛者の男性の脳が、異性愛者の女性の脳と機能的に類似していること、そして、同性愛は道徳上の選択ではなく、生物学的な基質によるものだということだ」と、Jane Rochstad Lim氏は記している。

permalink
ゴム部屋 米国税関・国境警備局(CBP)の隔離室(通称「ゴム部屋」)

カリフォルニア州サンイシドロ この隔離室にはプライバシーなど存在しないという事実を、部屋の隅で目を引くカメラが伝えている。Ross氏に言わせれば、「権威」とは子どもの保育施設(この本でも取り上げられている)から連綿と続いているものだが、このような部屋は、権威が極限的な形を取ったものだという。 (via 「権力」と建築:世界の刑務所、写真ギャラリー(4/9) | WIRED VISION
)

ゴム部屋 米国税関・国境警備局(CBP)の隔離室(通称「ゴム部屋」)

カリフォルニア州サンイシドロ この隔離室にはプライバシーなど存在しないという事実を、部屋の隅で目を引くカメラが伝えている。Ross氏に言わせれば、「権威」とは子どもの保育施設(この本でも取り上げられている)から連綿と続いているものだが、このような部屋は、権威が極限的な形を取ったものだという。 (via 「権力」と建築:世界の刑務所、写真ギャラリー(4/9) | WIRED VISION

)

permalink
code_swarm - Python on Vimeo (via Vimeo)
Jun
17th
Tue
permalink
youpy:
(via isbsh)

youpy:

(via isbsh)
permalink
私が思うにメディアアートは、その大半が工学的には出来損ないのデバイスアートであったりするわけで、その「芸術と科学との間に位置づけられる独立した場所」が、実のところちゃちな技術でも通用する、非芸術家、非専門家の駆け込み寺として機能していた側面は否めない。言説の場が制作における技術と噛み合ず、現代思想かぶれの観念論の空転により、作品の持つ技術的側面に的確な価値判断が行われずにいたことは大きな問題だ。メディアアートの場合、技術的側面と芸術的側面は注意深く分離したうえで価値判断を行わねばならず、評論家が技術的知識をある程度押さえ、そこで何が試考されているのかを正確に判断する必要があった。しかし私は、技術的知識をある程度押さえて評論を行うことのできる、メディアアートを専門とした評論家やキュレーターがいたとは思っていない。

Inter Communication 最終号 (阪本 - Blog) (via takawo) (via repsychose) (via ancooo)

日本のイベントは海外のアーティスト呼ばないよね。海外のは他の国の人呼んで、本当に吐き気がする物や、弱者のアイデンティティが立ち向かってくるような物を展示させるのに。そのせいでどんどんレベル低くなってつまらない物が量産されてる。単にGUIの処理や造形の作り込みが手が込んでる綺麗な物だけ。

(via shokai)

permalink
shokai:

fialux:

(via isbsh)
ハイテンション

shokai:

fialux:

(via isbsh)

ハイテンション

permalink
『ナード』は、男の王道たるジョック、女の花道たるチアに対して、これら『メインストリーム』から外れた二流の者の至る道―平易には『敗者の受け皿』であるとしばしば捉えられる。
ジョックス対ナーズという対立の図式は、高校や大学などの学校社会のみならず、アメリカ合衆国の社会や文化を語るうえでの欠かせない要素であると言われる。例えば、政治を語るときにリベラル(左派)の多くがナードを出自とするということは無視できず、大衆文化を語るときにほぼ全ての文化人がナードを出自とするということは無視できない、などである。
Jun
13th
Fri
permalink
permalink
Jun
12th
Thu
permalink

MySQL 総合 Part13

838 :NAME IS NULL:2008/05/24(土) 02:02:00 ID:???
搭載物理メモリ48Gのサーバーで、大きな単一テーブル(80G程度)を上手く扱う方法って無いですか?
(そのテーブル対して、更新&参照&集計が頻繁に発生すします。)

my.conf-hugeを元にいろいろチューニングを試してみたんですが、
io-waitが100%に刺さったまま、ハングしたようになり困っています。

開発当初はoracle案件で、ありきたりのチューニングだけで、問題なく動作していたのですが、
クライアントの方針変更で、急にMySQLで開発することになり、非常に難儀しています。
(ちなみに案件規模は、楽天クラスの商品在庫管理です。)


839 :NAME IS NULL:2008/05/24(土) 02:15:08 ID:/LSToqrf
その規模になると、MySQLでは、どうやっても無理。パフォーマンスや安定性の面でもお薦めしない。
クラに泣き付いてでも、オラクルに戻してもらえ。


840 :NAME IS NULL:2008/05/24(土) 02:20:15 ID:???
単一tblって時点で何だかな~…
大規模すぎてMySQLの範疇じゃないだろ

841 :NAME IS NULL:2008/05/24(土) 02:36:57 ID:???
»839-840
ありがとうございます。でも、それは無理っぽいです。

クライアントのライバル会社が全社的にOpenOfficeを採用したとかで、新聞に載ったらしく、
クライアントの経営トップがそれに対抗して、バックエンドにオープンソース採用の方針を
打ち出したいらしく、私が土下座するくらいでは受け入れられそうにも無いです。

842 :NAME IS NULL:2008/05/24(土) 02:49:35 ID:/LSToqrf
かなり痛いトップだな。
コッド博士クラスの優秀なDB開発者を雇ってMySQLを改造してもらえ。


843 :NAME IS NULL:2008/05/24(土) 03:34:26 ID:VAruVHOx
バカ相手してても身体壊すだけだから辞めちゃえw

844 :NAME IS NULL:2008/05/24(土) 03:39:53 ID:???
»841
土下座て。
やるだけの事はやってちゃんと検証データとボトルネック、仕組み的に無理ですって事を踏まえた上で
それでもなんとかしろと言うならやりますが、紆余曲折、最悪こういう想定事態になりますが
よろしいですか?ってクライアントと折衝する人に言ってもらえばどうでしょうか。
自分の仕事は最低限筋の通った理屈を報告して折衝担当者に理解してもらうこと。
もちろん前向きにね。
自分の仕事を理解し、精一杯やるだけやってしっかりとこなした上で無理難題言う上司や客に必要以上の負担を強いられる道理はないでしょ?
ただその事を丁寧にビジネス用語で当たり障り無く表現して相手に理解、納得してもらうよう「伝える」努力は必要ですけど。

私もそこまでのデータの運用経験はないけど、微力ながら言わせてもらうと
■ハード面
・SASでRAID0+1 ファイバーチャネル使えるならそれに越したことはないけど。
=> ディスクの読み込み速度が上がって結果的にMySQLの更新・参照・集計早くなります。
=> バックアップできます。三世代管理くらいまではしたほうが幸せになれるかも。
=> RAIDはライトキャッシュとBBUのついているものを使用 なるべくキャッシュは多い方がいいです。
2GとかつけれるのもあるけどRAIDカード選びは慎重にね。
ディスクはシークタイムがあるから10000rpmのもので秒間16コミットしかできない
ライトキャッシュ積むといっぱいコミットできます

・レプリケーション
=> レプリケーションしているとは思うけど、なんとなくしてなさそうな節があるのでやって見て下さい。
スレーブサーバに参照を掛けるとスレーブの台数分だけ参照はバンバン早くなります。
ただし、マスターと完全同期ではないので入金処理等精度の必要な部分はマスターを使って下さい。
アプリケーション側でのスレーブ参照制御が面倒なら間にLVSでもなんでもいいからロードバランサー仕込むと吉

・memcacheサーバ
=> 80G程度ならサーバ10台以内で構築できると思う
更新はライトスルーでMySQLにも書いて単純参照はmemcacheからすると涙でるほど早い。
但しきちんと両方更新されたか確認、制御する仕組みは必要。

ソフト面に続く

845 :NAME IS NULL:2008/05/24(土) 04:32:39 ID:???
■ソフト面
・設計の見直し
=> 詳細知らないので絶対とは言えませんが、MySQL用にテーブル設計、運用設計見直した方がいいと思います。
単一テーブル80Gは異常に思えます。
同一テーブルを複数作って分割・分散したり非正規化してみたり。
内部の詳しい人に相談して下さい。詳細知らないと設計はできません。

・インデックスの見直し
=> 当然ですがインデックスの付け方と発行クエリでMySQLの速度は1000倍違うこともあります。
複合インデックス、プライマリ、単一ユニーク、複合ユニーク気を付けながらexplainしてチューニング。

・クエリの見直し
=> これもexplainしながらチューニング 色々調べてみてください。
=> 拡張インサート、INSERT IGNORE等を使うと便利な局面もあるかもしれません。
=> 集計は、トリガを使ってインサート時に集計値をインクリメントしたりすると負荷がさけれます。
=> DELETEは実行コストが高いので、削除フラグを付けて対応する。一日一回纏めてDELETE処理する等

・MyISAM、InnoDB
=> 参照はMyISAM、更新はInnoDB。
ライトスルー、レプリケーションと合わせて使えばパフォーマンス全然違います。
MyISAMはライトロックが有効かもしれません。デッドロックに気をつけて。

・コンパイル
=> MySQLはソースからICCでコンパイル。速いっす。

・文字コード
=> できればUTF-8。一番苦労しなくて済みます。MySQLの内部コードもUTF-8。

・チューニング
=> ケースバイケースなんでなんとも言えませんが
tmp_table_size
max_heap_table_size
は同じ値にしないとダメですよー
query_cacheをしてみてください
禁断のチューニング
innodb_support_xa = OFF
innodb_flush_method = O_DIRECT
sync_binlog = 0 
innodb_flush_log_at_trx_commit = 2 
innodbを使用している場合上記設定だとディスクIOがガンガン減るので更新負荷がガクンと下がります。
ただし、データの保存性は最悪。
予期せぬマシンダウンがあれば復旧できない場合もあります。

・専門のコンサル
=> 実現までの早さと質が必要ならMySQLに習熟してる会社にコンサル依頼するのが一番早いような気が・・・
KLABさんにでも頼んでみたら?とふと思いました。
私も規模が大きくなるに連れて運用に悩まされ、夢の中のトイレで自分のションベンの放物線を眺めている時でさえMySQLの事を
考えていた時期が三ヶ月ほどありました。
データもいっぱい壊しました。いっぱい怒られました。あぁ思い出したらトイレに行きたくなってきたのでこれくらいで。
Jun
10th
Tue
permalink
permalink
permalink