私的良スレ書庫
不明な単語は2ch用語を / 要望・削除依頼は掲示板へ。不適切な画像報告もこちらへどうぞ。 / 管理情報はtwitterでログインするとレス評価できます。 登録ユーザには一部の画像が表示されますので、問題のある画像や記述を含むレスに「禁」ボタンを押してください。
元スレMySQL 総合 Part17

みんなの評価 : ○
レスフィルター : (試験中)
>>348
その聞き方じゃ「ある条件を外す」としか答えられないでしょう
その聞き方じゃ「ある条件を外す」としか答えられないでしょう
誰か聞いてくれよ
今開発している案件のDBが、MySQL-inodbからMySQL Cluster-ndbclusterにストレージエンジンが変更になったんだよ。
俺の構想では、MySQL-inodbをレプリケーションしてスレーブ作って、負荷分散させようと考えてたんだよ。
そしたら1次請の会社のSEが、MySQL Clusterを使うって方針に決まったから、MySQL Clusterについて調べろっていうんだよ。
自社でテスト環境作ってたら、データノードのプロセスが突然落ちる>そしてデータノードのプロセスが起動しなくなってDBをcreateしなおして、レストアしないといけないのよ。
後は、configのパラメータの中身が意味不明。開発者向けのスイッチかと思われるほどの無残さ。
joinが遅いとか、configを帰ると3時間ものローリングリスタート。時々落ちるおまけつき。
deleteで消した行の領域は、リスタートしないと開放されないとか…。
俺の感想だと糞DB。バグだらけ
これほんとに運用されているシステムで使われているのか?
誰か使ってるやついたらなんか教えてくれ?
今開発している案件のDBが、MySQL-inodbからMySQL Cluster-ndbclusterにストレージエンジンが変更になったんだよ。
俺の構想では、MySQL-inodbをレプリケーションしてスレーブ作って、負荷分散させようと考えてたんだよ。
そしたら1次請の会社のSEが、MySQL Clusterを使うって方針に決まったから、MySQL Clusterについて調べろっていうんだよ。
自社でテスト環境作ってたら、データノードのプロセスが突然落ちる>そしてデータノードのプロセスが起動しなくなってDBをcreateしなおして、レストアしないといけないのよ。
後は、configのパラメータの中身が意味不明。開発者向けのスイッチかと思われるほどの無残さ。
joinが遅いとか、configを帰ると3時間ものローリングリスタート。時々落ちるおまけつき。
deleteで消した行の領域は、リスタートしないと開放されないとか…。
俺の感想だと糞DB。バグだらけ
これほんとに運用されているシステムで使われているのか?
誰か使ってるやついたらなんか教えてくれ?
>>358
やっぱりそうだよね。
最初はOracleだったんだけど、予算的な問題で、MySQLレプリケーション
それで、どこかのコンサルの入れ知恵でMySQLCluster。
これほんとにバグだらけで運用どころか開発もできる気がしないわ。SUNとかにコンサル頼むと、製品版とコンサル料金で2000万ぐらいいくらしい。
素直にOracleの方がやすいんじゃないかと。
>>359
今の所まったく安定しないのよ。ほんとにできるの?
データノード追加する度にDBクラッシュしたり、ディスクテーブルにSELECTすると、めちゃくちゃ遅いし。
ノードが落ちてもトランザクションの保障すると書いてあるのに、接続切れるし。
公式のマニュアルは間違いが多いし、開発者のオナニーにつき合わされている感じがしすぎ。
今のところ、妥協レベルのデータベースであることは間違いなさそうだわ。枯れてきていい感じに使えるにはあと3年ぐらいの予感が。
これを使わされるユーザさん可愛そうだわ。
途中でデータ消えたらユーザ激怒で修羅場が用意に創造できる・・・。
やっぱりそうだよね。
最初はOracleだったんだけど、予算的な問題で、MySQLレプリケーション
それで、どこかのコンサルの入れ知恵でMySQLCluster。
これほんとにバグだらけで運用どころか開発もできる気がしないわ。SUNとかにコンサル頼むと、製品版とコンサル料金で2000万ぐらいいくらしい。
素直にOracleの方がやすいんじゃないかと。
>>359
今の所まったく安定しないのよ。ほんとにできるの?
データノード追加する度にDBクラッシュしたり、ディスクテーブルにSELECTすると、めちゃくちゃ遅いし。
ノードが落ちてもトランザクションの保障すると書いてあるのに、接続切れるし。
公式のマニュアルは間違いが多いし、開発者のオナニーにつき合わされている感じがしすぎ。
今のところ、妥協レベルのデータベースであることは間違いなさそうだわ。枯れてきていい感じに使えるにはあと3年ぐらいの予感が。
これを使わされるユーザさん可愛そうだわ。
途中でデータ消えたらユーザ激怒で修羅場が用意に創造できる・・・。
>>363
確かに、毎日、毎時、毎分が驚愕の事実の新発見なのは間違いないよ。
安定しているとはうらやましい。俺はこれが運用に耐えられないとPMを説得中なんだよ。
スケールアウトしない前提でONメモリデータベースのみ使う場合は安定してる感じなんだけど、スケールアウトのとか障害テストをするとホントだめだめ。
俺が今の理解している範囲では、MySQLCluster強烈なクセがあり、以下のルールを守らないと使い物にならない感じが。
・selectする際は必ず、pkeyを指定すること。しない古代のDB並に遅い。joinはもってのほか
・indexをふってもwhere句の指定がrangeだとまったく効果なしというか遅い。
・メモリテーブルに展開するデータは、基本selectとupdateを繰り返すデータ向き。
insert/deleteを繰り返す処理には確実に向いていない。
・ディスクテーブルはおまけ程度の機能。普通のinodb以下の性能になる。
・SQLノードを増やせば早くなる。
・データノード数を増やしても遅くなるか、今の処理性能を維持するぐらい。消して早くはならない。
・スケールアウトはできるけど、それによるデータベース破損のリスクがある(バグってる)。
・基本的にコンサルやサポートを受けて成立するものであって、素人がMySQLの延長線上にあるぐらいで使おうとすると火傷し、結局サポートに大金を支払うという事態になる。
確かに、毎日、毎時、毎分が驚愕の事実の新発見なのは間違いないよ。
安定しているとはうらやましい。俺はこれが運用に耐えられないとPMを説得中なんだよ。
スケールアウトしない前提でONメモリデータベースのみ使う場合は安定してる感じなんだけど、スケールアウトのとか障害テストをするとホントだめだめ。
俺が今の理解している範囲では、MySQLCluster強烈なクセがあり、以下のルールを守らないと使い物にならない感じが。
・selectする際は必ず、pkeyを指定すること。しない古代のDB並に遅い。joinはもってのほか
・indexをふってもwhere句の指定がrangeだとまったく効果なしというか遅い。
・メモリテーブルに展開するデータは、基本selectとupdateを繰り返すデータ向き。
insert/deleteを繰り返す処理には確実に向いていない。
・ディスクテーブルはおまけ程度の機能。普通のinodb以下の性能になる。
・SQLノードを増やせば早くなる。
・データノード数を増やしても遅くなるか、今の処理性能を維持するぐらい。消して早くはならない。
・スケールアウトはできるけど、それによるデータベース破損のリスクがある(バグってる)。
・基本的にコンサルやサポートを受けて成立するものであって、素人がMySQLの延長線上にあるぐらいで使おうとすると火傷し、結局サポートに大金を支払うという事態になる。
KVSの延長として使うものなんだろうなあ
Oracleに買収されて、TimestenとCoherenceという優秀な製品がある中で
MySQL Clusterの先行きは大変気になるところ
っていう線でPMと話してみたら?
Oracleに買収されて、TimestenとCoherenceという優秀な製品がある中で
MySQL Clusterの先行きは大変気になるところ
っていう線でPMと話してみたら?
すいません、教えてください
SELECT id,カナ,名称 FROM tbl WHERE 名称 LIKE あ% ORDER BY カナ
上記のような場合
カナにインデックスを定義するメリットありますか?
(名称にはインデックス無しの前提で)
SELECT id,カナ,名称 FROM tbl WHERE 名称 LIKE あ% ORDER BY カナ
上記のような場合
カナにインデックスを定義するメリットありますか?
(名称にはインデックス無しの前提で)
BIGINT 型のID という名のカラムがプライマリキーで、オートインクリメントのデータ構造を持つテーブルです、
レコードを削除し、追加した場合、ID は連続しないことは周知の通りなのですが
なんとか、1234・・・ という具合に連続的にID 追加する方法はないのでしょうか?
レコードを削除し、追加した場合、ID は連続しないことは周知の通りなのですが
なんとか、1234・・・ という具合に連続的にID 追加する方法はないのでしょうか?
http://dev.mysql.com/doc/refman/4.1/ja/grant.html
>注意: GRANT コマンドでデータベース名を指定する際、‘_’ および ‘%’ ワイルドカードを使用できます。
>データベース名の一部として、たとえば ‘_’ 文字を使用したい場合、GRANT コマンドでは
>GRANT ... ON `foo\_bar`.* TO ... などのように、'\_' として指定するようしてください。
>そうしないと、ワイルドカードパターンに一致する別のデータベースにもユーザがアクセスできるようになります。
らしいよ。
>注意: GRANT コマンドでデータベース名を指定する際、‘_’ および ‘%’ ワイルドカードを使用できます。
>データベース名の一部として、たとえば ‘_’ 文字を使用したい場合、GRANT コマンドでは
>GRANT ... ON `foo\_bar`.* TO ... などのように、'\_' として指定するようしてください。
>そうしないと、ワイルドカードパターンに一致する別のデータベースにもユーザがアクセスできるようになります。
らしいよ。
今、cakephpを使って開発してるんですけど、DBの負荷が上がってきたら
何らかの対策をしないといけないと思っています。
たとえばカウンターのスクリプトを他のユーザーに貸し出すサービスがあるとします。
その場合は
・ユーザーID 1000 の人は DB 1 を
・ユーザーID 1001 から 2000の人は DB2 を 使う
というように分ける という考え方で良いのでしょうか。
ご指導下さい。先輩方!
何らかの対策をしないといけないと思っています。
たとえばカウンターのスクリプトを他のユーザーに貸し出すサービスがあるとします。
その場合は
・ユーザーID 1000 の人は DB 1 を
・ユーザーID 1001 から 2000の人は DB2 を 使う
というように分ける という考え方で良いのでしょうか。
ご指導下さい。先輩方!
>>386
ありがとうございます・・・
えと、別PCでは何も触ることなく他のPCからQuery Browser等で覗く事ができたのですが
違うPCにまたMySQLにインスコして、違うPCから接続するとエラーになってしまうのですが・・・
MySQL側で何か設定があるのでしょうか?
ありがとうございます・・・
えと、別PCでは何も触ることなく他のPCからQuery Browser等で覗く事ができたのですが
違うPCにまたMySQLにインスコして、違うPCから接続するとエラーになってしまうのですが・・・
MySQL側で何か設定があるのでしょうか?
ひょっとしてこれでいけるのかなああ?
grant all privileges on *.* to root@'%' identidied by '1234' with grant option;
他のPCの権限のあれみたら%しかかいてないのあったからこれっぽいですね
grant all privileges on *.* to root@'%' identidied by '1234' with grant option;
他のPCの権限のあれみたら%しかかいてないのあったからこれっぽいですね
結局、>>386でいいんじゃねーか



類似してるかもしれないスレッド
- MySQL 総合 Part12 (1001) - [94%] - 2008/1/30 17:34 ○
- MySQL 総合 Part13 (996) - [94%] - 2008/6/10 21:02 ☆
- MySQL 総合 Part14 (1001) - [94%] - 2008/11/23 10:17 ☆
- MySQL 総合 Part15 (1001) - [94%] - 2009/4/20 12:15 ☆
- MySQL 総合 Part18 (986) - [94%] - 2011/1/17 15:46
- MySQL 総合 Part19 (982) - [94%] - 2011/6/9 2:33
- MySQL 総合 Part26 (860) - [89%] - 2023/2/2 9:30
- MySQL 総合 Part20 (995) - [89%] - 2011/10/17 4:48
- MySQL 総合 Part21 (1001) - [89%] - 2011/12/25 22:16
- MySQL 総合 Part22 (1001) - [89%] - 2012/7/10 16:45
- MySQL 総合 Part23 (992) - [89%] - 2013/8/11 17:00
- MySQL 総合 Part24 (1010) - [89%] - 2015/2/14 4:46
- MySQL 総合 Part25 (947) - [89%] - 2017/6/18 6:30
- MySQL vs PostgreSQL Part2 (941) - [31%] - 2022/5/26 1:30 ○
トップメニューへ / →のくす牧場書庫について