08/05/22 01:08:34
>>822 >>823 解決しました。ありがとうございます！！
827:824
08/05/22 01:09:18
>>825
レス有り難う御座います。
早速調べてみます。
828:NAME IS NULL
08/05/22 01:18:09
>>824
MySQLのみでうちがやるなら、IPはINET_ATON()で整数保管。
マスクは別フィールドに保管。
比較の際は、IPの整数をマスクサイズでビット演算して比較。
現状のテーブルのままやるのなら、文字列だからMySQLの
正規表現関数を使うのが速度的にも妥当では。
829:NAME IS NULL
08/05/22 02:19:27
みんな文字化け回避するためにカラムごとに文字コード設定してるの？
830:NAME IS NULL
08/05/22 08:19:01
URLﾘﾝｸ(mainichi.jp)
ネット証券会社が主催するＦＸ（外国為替証拠金）取引コンテストの発表会が２１日、都内で行われた。
コンテストに特別参加するグラビアアイドルの滝沢乃南さん、山本彩乃さん、折原みかさん、山口愛実さん、佐々木梨絵さん
の５人が顔をそろえ、シストレに挑戦する意気込みなどを語った。
同コンテストは、自分で作成したトレードソフトの機能を評価する「シストレソフト部門」と、
ＦＸ初心者でも安心の仮想マネーを使った取引を体験できる「トレード部門」で賞金総額２０００万円を争う。
シストレ優秀ソフトは、最高２０００万円までの範囲内で買い取りの可能性もあるという。登録受付は２２日から。
仮想取引は６月２日～０９年４月３０日までとなっている。
▼トレード部門
初期資産500万円で、デモ取引のトレード収益を競っていただきます。
URLﾘﾝｸ(www.click-sec.com)
URLﾘﾝｸ(www.fx-gp.com)
▼賞金総額
■社長特別賞（シストレソフト買取価格） 10,000,000円
●シストレソフト部門賞 1位300万円 2位100万円 3位50万円
●トレード部門賞 1位300万円 2位100万円 3位50万円
●前期MVP賞 50万円
●後期MVP賞 50万円
831:NAME IS NULL
08/05/22 12:15:32
>>824 >>828
PHP側でIPのチェックしたいならPrarのNet_IPv4
URLﾘﾝｸ(pear.php.net)
832:NAME IS NULL
08/05/22 12:26:36
PrarじゃなくてPearでした。
833:NAME IS NULL
08/05/22 19:08:36
varchar (n)の使用バイト数はn+1とのことですが、それなら
本来は100文字までのデータしか入力しないカラムでも
varchar(255)とtinytextの限界で作成しておいて、
アプリ側の入力チェックで100文字制限をするという方針はありでしょうか？
制限を100文字以上に拡張したくなったとき、アプリ側のチェックだけ直して
テーブルは変更する必要がなくていいのではないかと思うのですが。
834:NAME IS NULL
08/05/22 21:54:45
>>833の便乗質問ですが各データ型で使用するバイト長ってどこでわかりますか？
835:NAME IS NULL
08/05/23 01:26:43
>>834
URLﾘﾝｸ(dev.mysql.com)
>>833
別に自分のしたいようにすればいいんでね？(自分にとって、管理しやすいほう、扱いやすいほうで)
ただ、fixed formatでテーブル作成してるんなら、discには実際使ってない部分の領域も書き込まれるけどね。
836:834
08/05/23 01:41:31
>>835
ありがとうございます！助かりました
837:NAME IS NULL
08/05/23 21:38:08 Dt8inalF
SQＬ文だけで、半角カナを全角カナにする方法（関数）って、ありますでしょうか？
838:NAME IS NULL
08/05/24 02:02:00
搭載物理メモリ48Gのサーバーで、大きな単一テーブル（80G程度）を上手く扱う方法って無いですか？
（そのテーブル対して、更新＆参照＆集計が頻繁に発生すします。）
my.conf-hugeを元にいろいろチューニングを試してみたんですが、
io-waitが100%に刺さったまま、ハングしたようになり困っています。
開発当初はoracle案件で、ありきたりのチューニングだけで、問題なく動作していたのですが、
クライアントの方針変更で、急にMySQLで開発することになり、非常に難儀しています。
（ちなみに案件規模は、楽天クラスの商品在庫管理です。）
839:NAME IS NULL
08/05/24 02:15:08 /LSToqrf
その規模になると、MySQLでは、どうやっても無理。パフォーマンスや安定性の面でもお薦めしない。
クラに泣き付いてでも、オラクルに戻してもらえ。
840:NAME IS NULL
08/05/24 02:20:15
単一tblって時点で何だかな～…
大規模すぎてMySQLの範疇じゃないだろ
841:NAME IS NULL
08/05/24 02:36:57
>>839-840
ありがとうございます。でも、それは無理っぽいです。
クライアントのライバル会社が全社的にOpenOfficeを採用したとかで、新聞に載ったらしく、
クライアントの経営トップがそれに対抗して、バックエンドにオープンソース採用の方針を
打ち出したいらしく、私が土下座するくらいでは受け入れられそうにも無いです。
842:NAME IS NULL
08/05/24 02:49:35 /LSToqrf
かなり痛いトップだな。
コッド博士クラスの優秀なDB開発者を雇ってMySQLを改造してもらえ。
843:NAME IS NULL
08/05/24 03:34:26 VAruVHOx
バカ相手してても身体壊すだけだから辞めちゃえｗ
844:NAME IS NULL
08/05/24 03:39:53
>>841
土下座て。
やるだけの事はやってちゃんと検証データとボトルネック、仕組み的に無理ですって事を踏まえた上で
それでもなんとかしろと言うならやりますが、紆余曲折、最悪こういう想定事態になりますが
よろしいですか？ってクライアントと折衝する人に言ってもらえばどうでしょうか。
自分の仕事は最低限筋の通った理屈を報告して折衝担当者に理解してもらうこと。
もちろん前向きにね。
自分の仕事を理解し、精一杯やるだけやってしっかりとこなした上で無理難題言う上司や客に必要以上の負担を強いられる道理はないでしょ？
ただその事を丁寧にビジネス用語で当たり障り無く表現して相手に理解、納得してもらうよう「伝える」努力は必要ですけど。
私もそこまでのデータの運用経験はないけど、微力ながら言わせてもらうと
■ハード面
・SASでRAID0+1 ファイバーチャネル使えるならそれに越したことはないけど。
=> ディスクの読み込み速度が上がって結果的にMySQLの更新・参照・集計早くなります。
=> バックアップできます。三世代管理くらいまではしたほうが幸せになれるかも。
=> RAIDはライトキャッシュとBBUのついているものを使用 なるべくキャッシュは多い方がいいです。
2GとかつけれるのもあるけどRAIDカード選びは慎重にね。
ディスクはシークタイムがあるから10000rpmのもので秒間16コミットしかできない
ライトキャッシュ積むといっぱいコミットできます
・レプリケーション
=> レプリケーションしているとは思うけど、なんとなくしてなさそうな節があるのでやって見て下さい。
スレーブサーバに参照を掛けるとスレーブの台数分だけ参照はバンバン早くなります。
ただし、マスターと完全同期ではないので入金処理等精度の必要な部分はマスターを使って下さい。
アプリケーション側でのスレーブ参照制御が面倒なら間にLVSでもなんでもいいからロードバランサー仕込むと吉
・memcacheサーバ
=> 80G程度ならサーバ10台以内で構築できると思う
更新はライトスルーでMySQLにも書いて単純参照はmemcacheからすると涙でるほど早い。
但しきちんと両方更新されたか確認、制御する仕組みは必要。
ソフト面に続く
845:NAME IS NULL
08/05/24 04:32:39
■ソフト面
・設計の見直し
=> 詳細知らないので絶対とは言えませんが、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の事を
考えていた時期が三ヶ月ほどありました。
データもいっぱい壊しました。いっぱい怒られました。あぁ思い出したらトイレに行きたくなってきたのでこれくらいで。
846:NAME IS NULL
08/05/24 04:38:50
追記：あっSUNが買収してオープンソースでなくなるんじゃなかったっけ？