0527NAME IS NULL2013/04/23(火) 10:33:15.71ID:vt4yysNy てか>>511=>>521何だろ? その他の人間と同一視なんかしてないわけだが。 0528NAME IS NULL2013/04/23(火) 10:43:27.49ID:??? にぎわってんな。 0529NAME IS NULL2013/04/23(火) 10:45:25.56ID:vt4yysNy 同じ奴がID出ないのいいことに他人のふりして書き込んでるだけだと思うよw このスレにそんなにROMがいたわけがない。 0530NAME IS NULL2013/04/23(火) 10:56:34.20ID:4twmmFxW>>527 誰に言ってるのかも、レスした理由も書いたじゃん。 もうメンドイから黙っとくわ。 0531NAME IS NULL2013/04/23(火) 12:51:31.64ID:??? Firebirdの仕様がゴミだってのはみんなわかって使ってると思うよ ただ納品後にDB変えるのは手間だから仕方なく使ってる 仕様に満足してるふりするのは他のDBと仕様を比較せずに使っちゃったせっかちさんだけ 0532NAME IS NULL2013/04/23(火) 14:12:31.63ID:???>>525 他の解釈だと最大2G行しか保持できないだろ 0533NAME IS NULL2013/04/23(火) 14:23:04.40ID:??? 海の水はどうしてですか? 0534NAME IS NULL2013/04/23(火) 18:43:01.69ID:???>>525 ほんとお前バカだな。いいかお前に分かりやすいように説明してやる。 仮にお前の心配してたこと(以下「心配事」という)が数千年後に現実化したとしよう。 そのときおまえの後任者がやることは、クライアントからのエラー報告に対して 「データに更新処理をかけるか前のリストアを戻してください」 というエラー時の通常対応(以下「通常対応」という)をするだけだ。 次に、その前提となる「心配事」について検討しよう。 ここでクライアントについて「通常対応」が必要になった場合は その「通常対応」がなされたときからさらに数千年は「心配事」が発生しないことになる。 なぜなら「通常対応」により「心配事」の種はリセットされるからである。 つまり、「心配事」が発生する条件は、数千年「通常対応」が起こらないということなのである。 そして、エントロピー増大の法則により有体物は必ず壊れるからこの条件が成就する確立は 限りなく0に近いのである。 0535NAME IS NULL2013/04/23(火) 20:31:15.97ID:??? 第三に、仮に1つのレコードに数億回の更新がかかり「心配事」が1年ほどで現実化したとしよう。 そのような異常な使われ方をしたHDDが正常でいられる可能性は著しく低いといわざるを得ない。 すなわち、そのような特殊環境ではHDDが壊れる前に「通常対応」が必要な確率は逆にかなり高いのである。 0536NAME IS NULL2013/04/24(水) 06:53:46.98ID:??? 第四に、やはり仮に1つのレコードに数億回の更新がかかり「心配事」が1年ほどで現実化するシステムが あるとすると、そのような過酷な使われ方に耐えられるハードは相当高性能であり、 「通常対応」も数秒、数分で終わるだろう。 つまり、そのような優秀なハードがそろっているなら、1日1回定期定期的に「通常対応」をしても弊害が 生じないのである。 0537NAME IS NULL2013/04/24(水) 07:32:45.58ID:??? 「仮に1つのレコードに数億回の更新」って、トランザクションIDの意味解っている? 0538NAME IS NULL2013/04/24(水) 07:51:59.39ID:???>>537 大意を把握できないなら黙っててください 0539NAME IS NULL2013/04/24(水) 07:55:38.98ID:??? ここでも馬鹿がフルボッコにされてんな ttp://tech.dir.groups.yahoo.com/group/firebird-support/message/112108 0540NAME IS NULL2013/04/24(水) 07:57:14.44ID:???>>537 逆にお前がKarol BieniaszewskiみたいにトランザクションIDを誤解してるに1ペリカ 0541NAME IS NULL2013/04/24(水) 08:41:07.22ID:???>>534 525じゃなくて悪いけど ・リストアをクライアントに任せられる恵まれた環境が前提の話 ・数億回の更新が異常な使われ方という認識 みんながみんなに当てはまらないんじゃない? 0542NAME IS NULL2013/04/24(水) 09:29:10.65ID:7oZx62k7>>541 そんなヘビーな環境一台でこなせるわけ無いじゃん。 だから普通はクラスタ化されてるわけで。。 で、クラスタ化されてればいくらでもメンテのタイミングは作れるわけで。
前提となる環境が空理空論。 0543NAME IS NULL2013/04/24(水) 10:00:38.79ID:???>>539 ここに書いた人は一秒間に200トランザクションあるから四ヶ月で越えちゃうどうしようって言ってるけどな 秒間何十tps、何百tps何て今のサーバスペックじゃごく普通レベル、というか場合によっては少ない方だが… 0544NAME IS NULL2013/04/24(水) 10:26:42.66ID:7oZx62k7>>543 何を根拠に普通って言ってるのかしらんけど 例えばTPC-Cで12000tpmcなんて環境は、なかなか縁のない環境だな。 I/O絡めてそんな数字出るハードもあんまり普通レベルとは言いがたいな。 0545NAME IS NULL2013/04/24(水) 10:38:30.85ID:??? 何で二桁も飛んでるんだよw 0546NAME IS NULL2013/04/24(水) 10:47:56.11ID:??? tpc-bだけどこれ4年前の資料な http://www.slideshare.net/tomneko/firebird250547NAME IS NULL2013/04/24(水) 10:55:40.88ID:7oZx62k7>>546 TPC-Bでも200tpsに届いてないじゃんw 0548NAME IS NULL2013/04/24(水) 10:56:15.39ID:7oZx62k7>>545 バカなのか 0549NAME IS NULL2013/04/24(水) 11:11:10.54ID:??? 4年前のサーバスペックだぜ? それに問題はtpcの指標じゃないし、別にtpc-bでもトランザクションであることには変わらない。 トランザクションの制限値に現実味があるかどうかだろ? 仮に秒間100だとしても248日後にはMAX到達。 まぁ認めたくないのはわかるがそろそろ無理があるぞお前。 0550NAME IS NULL2013/04/24(水) 11:23:05.11ID:7oZx62k7>>549 4年前のサーバーが今現在稼働してるのは普通レベルじゃないのか? しかも>>539は2011年のスレッドなわけだがw
で、CPU限界近くまでぶん回した上限値ギリギリでシステム設計するのが普通なのか?
つうかTPC-Bはアカンってお前の持ってきたスライドに書いてあるやん…
> まぁ認めたくないのはわかるがそろそろ無理があるぞお前。
お前がなw レスの全てが突っ込みどころだらけじゃん。
あとID出せよw 0551NAME IS NULL2013/04/24(水) 11:24:55.37ID:7oZx62k7 で、件のスレッドでは 「お前のシステムはそもそもトランザクションが必要なのか? FB使うのがおかしくね?」 と問われてるわけで、当然俺もそう思う。 0552NAME IS NULL2013/04/24(水) 15:21:54.82ID:??? ところで「ワインに育毛効果!」って田崎真也に喧嘩売ってね? 0553NAME IS NULL2013/04/24(水) 18:08:33.37ID:???>>551 な。ファイルにシリアルに書き込んでけばいいだけの話やんなw DB屋ってバカだよなw 0554NAME IS NULL2013/04/24(水) 18:09:16.74ID:??? 結論:心配性のバカはほっとけ 0555NAME IS NULL2013/04/25(木) 08:45:31.88ID:??? 普通のプログラマなら自作テーブルで低機能・高速性を求めるか DBエンジンで高機能・低速でいいかを最初に検討するはずだけどな。 何の考えもなしにDBエンジン使うとかエンジニアとしてのレベルが低いとしかいえん。 0556NAME IS NULL2013/04/26(金) 01:36:40.25ID:h+QfU+Fn 40億回でだめなら何回あればいいんだ 仕様、BUGがわかっていれば普通は回避策を考えるんだが DB変えるとか 0557NAME IS NULL2013/04/26(金) 10:40:47.00ID:??? もう許してやれよ。涙目だぞ、そいつ 0558NAME IS NULL2013/04/26(金) 18:04:12.38ID:??? DBファイルだけで10TBとかそういう大規模なのだろう 0559NAME IS NULL2013/05/02(木) 11:59:20.03ID:???>>556 Postgresならバキュームがあるから回数は1億でもいいと思うわ 問題は回数よりリセット方法が稚拙だってことだろうね 0560NAME IS NULL2013/05/02(木) 12:32:31.35ID:??? 意図的なのかどうか知らんが論点がぶれてる 俺は、20億では少ないとか十分とか、Firefoxがいいとか悪いとか、運用の仕方の話じゃなくて、 異様に少ないコミット回数を前提にしてそんなトランザクション回数事実上有り得ないとか決めつけてたから、現実に十分あり得るし、以外と簡単に越えるんだよって一貫して言ってたんだけどな。 0561NAME IS NULL2013/05/02(木) 14:03:29.94ID:??? それは理解してるよ、あとFirefox関係ないだろw で、現実的な解決策としてはPostgresのバキュームみたいなので DB止めずにリセットできればいいねって Accessとかだと最適化だったかな?最近触ってないから知らん 有り得ないとか決めつけてるやつは思考停止してるからほっとけよw 0562NAME IS NULL2013/05/02(木) 14:37:27.74ID:??? げ、自動補完でFirefoxになってた… あと一行につき20億、じゃないし。仕組み理解してればdbにつき、てことくらいわかると思うが。 0563NAME IS NULL2013/05/02(木) 14:45:37.57ID:??? 執念深いやつだなw あんだけ論破されてもまだぐにゃぐにゃ言ってんのかw 0564NAME IS NULL2013/05/02(木) 14:47:18.01ID:???>>560 てかお前は一体どいつだよw レス番書け。ID出せw 0565NAME IS NULL2013/05/03(金) 05:51:53.54ID:???>>560 OK。じゃあ具体的に議論しようや。
>異様に少ないコミット回数を前提にして ではその前提をまず明らかにしてもらおうか。
>現実に十分あり得るし、以外と簡単に越えるんだよ ではその現実を明らかにしてもらおうか。 0566NAME IS NULL2013/05/03(金) 05:55:36.69ID:???>>561 >有り得ないとか決めつけてるやつは思考停止してるからほっとけよw 「事実上ありえもしないことを「ありえる!論理的にはありえる!」と騒いでる奴は思考停止どころか心配性で絶対頭禿げてるからほっとけよw」の間違いだよね 0567NAME IS NULL2013/05/03(金) 06:01:53.66ID:??? 裁判では欠陥があると指摘する側に立証責任がある。 なのにここでFirefox?に欠陥があると騒いでる奴は、まるでその責任を果たしているとは思えない。 逆に欠陥はないという被告側に立証責任を負わせたうえ、しかも論破されてしまってるというのが現状。 0568NAME IS NULL2013/05/03(金) 06:11:16.59ID:??? しかも、原告側ではトランザクション開始さえすればトランザクションIDが増加するという誤った認識すらしている可能性が高い。 よって被告人は無罪。 0569NAME IS NULL2013/05/03(金) 07:14:33.07ID:??? Ann Harrison said,
Transactions that don't insert, update, or delete records are of no interest to anyone once they end. The long term value in transaction identifiers is only to identify record versions. 0570NAME IS NULL2013/05/03(金) 18:38:02.33ID:??? 問題あるある君の問題点