ktgohan

流石に「2000万件を確実に2秒」と言われると、純粋なDB技術の勝負になるので「俺にゃ無理」と素直に手を上げる。 その代わり 「確実ではないが2-3秒で良いなら、もっと安く＜誰でも同じように保守できる＞仕掛けの図を描いてあげるよ」と言える。 …自分しか保守できないシステムなんて残せない。

初期の系統動揺解析システムで同じような問題（上がってくるデータが当時としては多過ぎる）に物理増したが、所詮、ネットのほうはトランキング、データの方はバッファリング以外に妥当な解がないので、memcacheとKVSに吸わせます。

なんか元スレッド見たけど、…DBだけで考えてるみたい（しかも、限定されたハードで）。 …今じゃそんなやり方では業務しない（「なぜ2000万件必要か」から考える）し…。

2つ思いついた。 1.KVSに載せ変えておく 2.いつものmemcache で、100万件あたり0.3秒くらいで10多重、運がよければ2000万ｰ3000万件を2-3秒。

まあ今ならAWSだろうから、RedisとMongoDBで緩衝帯にして、ゆっくりDWSに配置すればいいんじゃないですかね （構成図を呼び出してざっくり考えた）

KVSやmemcache（Redisでも）の多重化の仕組みは、一番ベタな奴でいい。 2000万件と言っても、キーの段階で区分できるものは多い。 データが主キーで行く先を仕分け出来るように作ってあれば 「検索を開始した段階で、どのインスタンス（もしくはキャッシュ）を叩くかは分散できる」