リクエストでポータルサイトに投げるような設計をした場合はその負荷にも注意が必要です。ポータルサイトがボトルネックになって計算結果が失われるという悲しいながらも割と起こる事故があります。ISUCONするはめにならないよう。*4*4:個人的にはこういう設計がそもそもダメなんじゃないかという気もします。メタデータを書くしょぼエンジニアリング最強なのでは??だけちょっと思うところがあったのでメモします。*1*2この主張には一理あり、ICFPCをやっているとそもそもの問題サイズが大きかったり、中間結果もビジュアライズのために取っておきたくなったり等の理由により、プログラムの出力が数MBから数十MBに膨れ上がることが稀によくあります。いうとき、序盤で雑に書かれたFlask製サーバなんかがスケーリングされずにアップロードを待ち受けていたりすると一瞬で死んでしまうため、そんな辛い思いをするくらいなら最初からrsyncとファイルI/Oで頑張ればいいじゃんと考えるのは自然な発想ではあります。JSONメタデータ戦法は検索性が致命的に悪い。例を挙げると、何かしらの検索をしたければ、全てのデータを舐めながらマッチするデータだけ拾ってくる必要があるため自明に遅いという点が1つ。検索したい軸が1つしかないという状況もまずあり得ず、こういうカスタムクエリが欲しいという要望が無限に飛んできて、似たような検索ロジックをコピペで量産した挙句に全部バグって死ぬことになります(断言)。......みたいなことを考えて、実際2016年はこの方針だったけど途中でスケールしなくなってMySQL建てたと記憶してるので、まあどうせみんなMySQL書けるし、大人なんだから自分の好きな言語でMySQLに繋ぐ方法くらい分かるでしょ(大嘘)という感じで思考停止でMySQL使う→MySQLの認証情報を配るのめんどいし、Webサーバを建てといてアップロードした解答を勝手にインデックスすると楽だよね、という感じで上記の記事に書いてあるようなシステムが出来上がったんだったと思います。いつの間にかISUCONが同時開催されます。勝手にコンテストの問題が増えるなんてお得ですね。やって読んでるとなんとなく分かると思うんですが、上の理屈には飛躍があります。ICFPCのポータルサイトはデータ解析基盤なので厳しいリアルタイム性が要求されることはほぼなく、新しい結果が届いてから反映されるまで2、3分のラグがあってもまあええやろという雰囲気であることがほとんどです。いうことは、アップロードを司る何かがインデックスを作る必要は特になく、各人が勝手にファイルをrsyncで所定の場所に置くようにして、それを適当なcronがMySQLなりElasticSearchなりに順次突っ込んでいけば良いのでは?ということを思いついたので記事を書きました。誰か試してみてください。*1:本当はコメント欄にもっと雑な版を書こうと思ったんだけど、なんかコメント欄が存在しなかった*2:と思ったら下の方にボタンがあるのをこれを書き終えてから見つけた。HDの画面内を動き回る...2018-07-25ICFPC2018ICFPC2018にチームmanarimoとして参加しました。マナリモとは何...2017-08-13ICFPC2017ICFPC2017にチームAdlersprungで参加しました。1月グリーンカード取得の記録2020年の目標2019年振り返り月別アーカイブ参加グループテクノロジーはてなブログをはじめよう!osa_kさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。