データベースの授業で作ったwrite-ahead logging付きの小さなkey-valueストア
共有者はAmazonの新卒選考ループでまさにこのプロジェクトを話し、その後内定を獲得しました。
この面接を練習する
実際の深掘り4問 · うち難問1 · 約12分
各質問に自分で答えると、本人の実際の答えが見られます。
本人はこう語った
システム系の授業でシングルノードのkey-valueストアを作りました。どこで壊れるかを正直に話したことで、耐久性のトレードオフをめぐる30分の議論に発展しました。
全文を読む
学部のデータベースの授業の最終課題でした。課題はJavaで永続化するkey-valueストアを作ることで、採点基準ではクラッシュリカバリが重視されていました。write-ahead logの部分は私が自分で担当し、B-treeインデックスとCLIはチームメイト2人が受け持ちました。私のパートは、put/deleteをインメモリのmapに反映する前にログファイルへ追記し、起動時にログをリプレイするというものです。fsyncもきちんと動かして、書き込み途中にkill -9されてもコミット済みのデータが失われないようにしました。破綻したのはここからで、コンパクションもチェックポイント処理も書かなかったのでログは際限なく伸び続け、ログが大きくなると再起動が遅くなりました。期間は2週間ほどしかなかったので、チェックポイント処理は切り捨てて、READMEに既知の制限として明記しただけです。実際のユーザーに使われたことは一度もなく、採点されてそれで終わりでした。面接ではまずその前提から入り、「これは授業の課題で、私が担当したのはこの部分です」と言ってから、データが永続化されるまでの経路を順に説明しました。面接官はfsyncの最中にマシンが落ちたらどうなるかをしつこく突いてきて、対応済みのふりをするのではなく、torn write(書き込みの分断)についてその場で推論するしかありませんでした。
実際に聞かれた質問
putで何が起きるか、呼び出しからデータが永続化されるまでを正確に説明してください。
普通ログレコードの書き込み途中でプロセスがクラッシュしたらどうなりますか?
難しいどの部分があなたので、どの部分がチームメイトのものでしたか?
易しい今の知識があるなら、まず何を変えますか?
普通