アカウント名:
パスワード:
64000件のデータで、もし無作為で1000件連続して解約データが含まれていたのであれば、解約率は99%越えてるはずです。なので元々解約者が多く含まれるようなデータなのか、解約者が並びやすい条件でソートしているのか、どちらかでしょう。
あくまで理論上の話だけど、これ、「3月で契約終了」のデータが多数あったと思うのです。そのうち、例えば2年契約とかで「同じ時期にスタートした契約がたまたま同じ時期に終了する」可能性は、そんなに低くないと思われます。それが千件並ぶのはよっぽどのことだと思うけど、ありえない確率とは思えないのです。
一応簡単に計算すると、1000件連続で解約者が並ぶ確率は、解約率が99%としても0.99^1000=0.000043これを64000件分のバッチ処理、1000件を64回まわす間に落ちる確率は0.002755で0.28%弱しかありません。たとえ「3月末契約終了」が多く解約率が99%だとしても、64000件の処理中に1000件連続する確率は0.28%で、実際には解約率はもっと低いはずなのでちょっと起こり得ないかな、と。なので、他のACの方が指摘しているような、1000件とかまとまった件数を契約している業者が解約したとか、そういうのが無いと厳しいかと。
単体で見れば低い確率でも、それを数十回と繰り返してきたわけで
千件以上一度に契約していた業者が契約終了したという可能性はあると思います。
消費税率の変更という大きい事象があったわけで、それに合わせて金額変更に伴う契約終了→新規契約が多数発生した可能性は考えられますね。
自動送金なんて使うのは電気ガス水道がほとんどですよね。となると、3月の卒業なんかで解約して4月度の送金でトラブったんでしょうね。
電気ガス水道は定額じゃないよ。
NHKの受信料か
前処理でデータをソートしてそうなので年とか店とか、何か大きな節目があったんじゃなかろうか。
あとは、「無限ループとデッドロックを排除する」号令のもと、試行回数の上限にそれっぽい値をハードコードしてたとかそんな感じじゃないかと妄想してみる
勘定系でソートってあり得ない気が。
素人考えですけど、接続先が揃っているといちいちコネクション張り直さなくていいとかないんですかね?
そういう場合、通常は
・全件読み込んで振り分け処理。接続先毎のデータファイル作成・それを1ファイルずつ順に処理
という風にします。ソートは、うかつにつくるとメモリ足りなくなったりするし、まじめに(件数が多い時には)マージソートするように実装すると、結局振り分けするよりコストが高くなるので。
全件処理だからソートする領域が取れないか、時間がもったいないかで、ベタでfetchしては処理してるんじゃないかと想像してみた。いや、条件がなければ多分契約順になるから、大雑把には年齢順になる=頭の方から歯抜けになっていくか…。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
UNIXはただ死んだだけでなく、本当にひどい臭いを放ち始めている -- あるソフトウェアエンジニア
面倒だから計算しないけど (スコア:4, 興味深い)
64000件のデータで、もし無作為で1000件連続して解約データが含まれていたのであれば、解約率は99%越えてるはずです。
なので元々解約者が多く含まれるようなデータなのか、解約者が並びやすい条件でソートしているのか、どちらかでしょう。
Re:面倒だから計算しないけど (スコア:2)
あくまで理論上の話だけど、
これ、「3月で契約終了」のデータが多数あったと思うのです。
そのうち、例えば2年契約とかで「同じ時期にスタートした契約がたまたま同じ時期に終了する」可能性は、そんなに低くないと思われます。
それが千件並ぶのはよっぽどのことだと思うけど、
ありえない確率とは思えないのです。
Re:面倒だから計算しないけど (スコア:4, 参考になる)
一応簡単に計算すると、1000件連続で解約者が並ぶ確率は、解約率が99%としても
0.99^1000=0.000043
これを64000件分のバッチ処理、1000件を64回まわす間に落ちる確率は0.002755で0.28%弱しかありません。
たとえ「3月末契約終了」が多く解約率が99%だとしても、64000件の処理中に1000件連続する確率は0.28%で、実際には解約率はもっと低いはずなのでちょっと起こり得ないかな、と。
なので、他のACの方が指摘しているような、1000件とかまとまった件数を契約している業者が解約したとか、そういうのが無いと厳しいかと。
Re:面倒だから計算しないけど (スコア:2)
Re: (スコア:0)
解約済みのデータまで引っこ抜いてくる処理自体が錯誤的。
Re: (スコア:0)
単体で見れば低い確率でも、それを数十回と繰り返してきたわけで
Re: (スコア:0)
千件以上一度に契約していた業者が契約終了したという可能性はあると思います。
Re: (スコア:0)
消費税率の変更という大きい事象があったわけで、それに合わせて金額変更に伴う契約終了→新規契約が多数発生した可能性は考えられますね。
Re: (スコア:0)
自動送金なんて使うのは電気ガス水道がほとんどですよね。
となると、3月の卒業なんかで解約して4月度の送金でトラブったんでしょうね。
Re:面倒だから計算しないけど (スコア:2)
Re: (スコア:0)
Re: (スコア:0)
電気ガス水道は定額じゃないよ。
Re: (スコア:0)
Re: (スコア:0)
NHKの受信料か
Re: (スコア:0)
前処理でデータをソートしてそうなので
年とか店とか、何か大きな節目があったんじゃなかろうか。
あとは、「無限ループとデッドロックを排除する」号令のもと、
試行回数の上限にそれっぽい値をハードコードしてたとか
そんな感じじゃないかと妄想してみる
Re: (スコア:0)
勘定系でソートってあり得ない気が。
Re: (スコア:0)
素人考えですけど、接続先が揃っているといちいちコネクション張り直さなくていいとかないんですかね?
Re:面倒だから計算しないけど (スコア:1)
そういう場合、通常は
・全件読み込んで振り分け処理。接続先毎のデータファイル作成
・それを1ファイルずつ順に処理
という風にします。
ソートは、うかつにつくるとメモリ足りなくなったりするし、
まじめに(件数が多い時には)マージソートするように実装すると、
結局振り分けするよりコストが高くなるので。
Re: (スコア:0)
全件処理だからソートする領域が取れないか、時間がもったいないかで、ベタでfetchしては処理してるんじゃないかと想像してみた。
いや、条件がなければ多分契約順になるから、大雑把には年齢順になる=頭の方から歯抜けになっていくか…。