入れてシャーディングするというのをやっていた。切り替えるようにした。使っている箇所が面倒だったので、そこは3台に同じクエリを投げてからその結果をマージするようなコードを書いた。いま振り返るとちゃんと必要なキーだけ集めてクエリを投げるように直してもよかったな。削除やロギングの削除をやった。ラスト1時間で再起動試験と最終スコアの確定をやった。レギュレーションでは最後のスコアが使われることになっており、今回のベンチマークは同じコードで実行しても一割くらいスコアにぶれがあることがわかっていたので、ここまでのベストスコアが59万点だったため58万点以上が出たらそれを最終スコアにしようという風に決めてベンチマークを実行した。実際には再起動後のベンチマーク一発目で58万点が出たので、もう少し試したい気持ちもありつつも、最終的にはこのときのスコアのまま終えた。試して最初の帯域の問題を早くクリアできたのが大きかったかなと思う。ずれではまるのも意図せず回避できていた。(スコアはそこまで伸びなかったけど)。予選から3台のサーバを使う問題で、ベンチマーク対象を複数指定できるという新鮮な設定で楽しめました。ベンチマークもエンキューしたらすぐに実行されるような環境で体験がよかった。本選でもよいスコアを残したい。知らないのかが読みとれずにめんどくさいと思うことがよくある。しれないことが考慮されているということが伝わりやすい。結果を知って使ってるのかも気になる。使ってるならいいけど、そうは思えないようなコードをよく見る。書くのがめんどくさくてそうしているのかが読みとりにくい。アプリにおいて、テーブルの追加やカラムの追加は簡単なものの、カラムの削除やリネームは慎重に行う必要がある。アプリからそのカラムを参照してないとしても、いきなりカラムを削除するとエラーになる可能性が大いにある。スキーマキャッシュというものがあり、テーブルのカラム情報をモデルがキャッシュしているからだ。するときに参照される。エンジニアは多いと思う。機械的に全カラムを取得するためにスキーマキャッシュを利用しているため、このようなクエリが実行されてる中でカラムを削除したりリネームしたりすると、スキーマキャッシュをもとに並べらたカラムの一部が消えてしまうため、不正なクエリとなってエラーになってしまう。おいてカラムの削除やリネームは面倒なものになっている。オンラインスキーマ変更のやりにくさを解消するために追加された。元に戻してデプロイという流れになる。カラム情報を取得するところにモンキーパッチをあてて特定のカラムを隠すようにすればなんとかいける。メソッドをフックする。グローバルに一意という前提を置いている点に注意する必要がある。同じような効果が得られるので、あとは同じ流れでカラムの削除を進めることができる。アプリで実際に成功したのでまぁたぶんだいたいいけると思う。使ったほうがいいことは言うまでもない。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。