この記事はデータベース・システム系 Advent Calendar 2023の3日目の記事である。昨日の記事も僕でした。 間接参照を巨大仮想メモリで飲み込む メインメモリはハードディスクやSSDより容量が小さく、この問題は当面は解決の目処が立たない。 そもそも今のDRAMより速くて安くて大きいストレージが仮に発明されてもそれがDRAMに取って代わるメインメモリの立ち位置になるだけであってその下のレイヤーには依然としてそのメインメモリより安くて大きなストレージが置かれる事になる。大局的な観点ではストレージの階層構造とは経済活動の鏡像でもある。 バッファプール さて、耳にタコができるほど繰り返しているが現代のデータベースはディスクなどの永続ストレージにデータの本尊が保存され、メインメモリはそれに対する読み書きを高速化するためのデータ一時置き場としての役割を担当している。 代表的なRDBMSは3

AIに描いてもらったストレージで作ったレース会場 はじめに この記事はデータベース・システム系 Advent Calendar 2023の一日目の投稿である。今年読んだ論文（今年書かれた論文とは限らない）の中で驚きや納得があって良かったなぁと思った論文をいくつか紹介していきたいと思う。 論文の本文そのものは機械翻訳なりチャットAIなりに叩き込めば誰でも内容の抽出はできるので、こちらのブログ内では何故これが良いと思ったかについて僕の主観に基づいて書いていく。僕の解釈が厳密に正しいことは一切保障しないし、気になって読んでみたら全然内容違うやんけ！と驚くところまでがセットくらいの気軽なつもりで読んで欲しい。 最初に紹介する論文は「When Database Meets New Storage Devices: Understanding and Exposing Performance Mism

「禅とオートバイ修理技術」これら2つの間にどのように関係があるのかまるで見当が付かず、タイトルだけ聞くとキワモノのようだがWikipediaによるとアメリカでは一番良く売れた哲学書とされている。 海外のエンジニアのブログを読み漁っていた時にオススメされていたのでKindleで買って読んだのだが想像以上に良かったのでメモを残したい。と言ってもwikipediaで説明されている内容を改めて説明しても面白くないのでソフトウェアエンジニアとして響いた部分を引用して僕の感じた事を書き連ねていく。 大都市の重工業地帯に一歩でも足を踏み入れてみれば、そこにはその全てが存在している。テクノロジーである。正面には有刺鉄線を施した高い塀が立ちはだかり、門は常に閉ざされ、「立入禁止」の札が掛かっている。そしてその向こうの薄汚れた大気の中には、金属や煉瓦で造られた醜い建物が立っている。その目的は不明であり、またそ

リングバッファのイメージ図 1. リングバッファとは何か 機能的にはFirst In First Out (FIFO)とも呼ばれるキューの一種であるが、リング状にバッファを置いてそれの中でReadとWriteのインデックスがグルグルと回る構造をとる事によって容量に上限ができることと引き換えに高速な読み書き速度を得たものである。キューを単に実装するだけなら山ほど方法があって線形リストを使ってもいいしスタックを2つ使っても原理的には可能だ。その中でもリングバッファを用いた方法の利点はひとえに性能の高さでありメモリ確保などを行わないお陰でシステム系の様々な場所で使われている。 これの実装自体は情報系の大学生の演習レベルの難度であるが少し奥が深い。まずリングバッファのスタンダードなインタフェースと実装は以下のようなものである。 class RingBuffer { public: explicit

前回のブログから90日以上経ってしまったので広告が載ってしまったから短文でもアウトプットしておく。 プログラマとして仕事をしているとコードと向き合っている時間の9割以上は既存のコードを読んでいる、だから読みやすさは重要である、という言説は耳にタコができるほど誰もが言っている。 仕事で書かれるコードが誰のレビューも通ること無くマージされている現場は凄惨だが、自分より明らかに経験を積んだ人たちが何度もレビューを重ねたコードが読みやすいかというとそうとは限らない。良いコードが守るべきルールをすべて守っていても不可解なコードはあるし、どんなに読みやすいコードでも数千行の規模になってくるとやはり脳内からこぼれて一度に覚えておける範囲からはみ出る。 変数名や関数名をわかりやすくするとか不必要な技巧を凝らさないとかわかりやすい設計にするとか主観的な事を偉そうに語る本は山ほどあり、それらの本を崇める事は悪

TL;DR 正しく設計するとキャパシティは常にカツカツになる これはpyspaアドベントカレンダーの8日目の記事です。前日はShibukawaさんです。 世はクラウド時代、ソフトウェアはひとたび作られたら何億回実行されても摩耗するものではないので、どんな間抜けなロジックであろうと動く以上は別のどこかで瑕疵が出てくるまで使い倒されるのは日常茶飯事である。 サービスを負荷の前提の上に定義する クラウドより前の時代においてサービスを支えるマシンは「ロードアベレージが1.0を超えてなければとりあえずOK、超えたらマシンを増やして負荷を分散する」というノリのベストプラクティスがよく言われていたがそれはサーバ資源の確保にそれなりに時間がかかる時代の常識であって、クラウド時代でサーバは分単位で確保できるようになった。 クラウドの利点としてその即時的なスケーラビリティが常套句として使われて久しいが、これは

blog.j5ik2o.me 値オブジェクトはドメイン固有型の一種です。なので、不変と等価判定だけではなく、なにかしらのドメイン固有の不変条件(invariant)を維持する責任があると考えます(もちろん型として切り出すわけですからその投資に見合うだけの見返りがないといけません)。 違う。値オブジェクトとはID以外で等価判定をするオブジェクトの事であって、RubyのHash、Pythonのdict、C++のstd::unordered_setすらも値によって等価判定を行うのでこれらは値オブジェクトであるがドメイン固有型ではない。RubyでHashに入れて渡されたユーザ入力値をValidationしてドメイン固有型に詰め直すのはもちろん必要ならやれば良いが、Hashクラスそのものにモンキーパッチなり特異クラスなりを行って不変条件を維持する責任を負った自分専用Hashを作って普通のHashクラ

Value Objectとは何であるか? マーチン・ファウラーのPatterns of Enterprise Application Architecture(PofEAA)やエヴァンス・エリックのDomain Driven Design: Tackling Complexity in the Heart of Software(DDD)が原典であるが、PofEAAではこう切り出している。 When programming, I often find it's useful to represent things as a compound. プログラミング時は物をcompound(合成物)として表現すると便利なことがしばしばある。 例えば2次元空間上での座標のように複数のメンバ(属性)を持つ物は便利である、と。しかしそれらを比較する方法は一意ではない、そこで Objects that a

TL;DR 並行処理を実装する人のこれからのスタンダードになる一冊。買い。 並行プログラミング入門 ―Rust、C、アセンブリによる実装からのアプローチ 作者:高野 祐輝 オライリージャパン Amazon 買ったら思いの外早く届いたのでパラパラと読み始めたら一気に読み終えてしまった。 総評 敢えて雑な喩え方をするなら The Art of Multiprocessor Programming (通称TAoMP本) の内容を薄めてRustやアセンブラや計算モデルを足したような本だった。 日本語の書籍としてはかなり珍しくWait-Free, Lock-Free, Obstruction-Freeの違いなどを適切に論じており、TTAS Lock, MCS Lock, TL2といった日本語では希少な情報が書かれているレアな本である。これらに付いて論じている日本語の本は知る限り (TAoMP本と昔僕

買った戸建てに付けた表札、住所はぼかした プロローグ 新型コロナが世間を騒がせ始めて以来ずっと在宅勤務をしている。 転職に伴って会社近くに引っ越したので通勤のドアtoドアで30分台を叩き出していた好立地はその活躍の機会をすっかり失った一方で、妥協した40平米の部屋の狭さと1LDK+Sの間取りが巣ごもり子育て核家族を襲った。 外で遊び足りない娘は泣き、広がった活動範囲で家中の物を無秩序に引っ掻き回すので必然的に触られたくないものは高いところに置くことになり、立体的に活用される事になった1LDKの空間は生活の難度を高めジワジワと真綿で首を締めるような状況が続いた。 住んでいたマンションは駅に近いのは良いが作りは古く、冬には窓枠が結露しカビが発生する。窓から降りる冷気はそのまま壁や床にすら結露を起こし室内はカビに見舞われた。それとの因果関係は不明だが冬場の慢性的な体調不良が家庭内の治安を更に悪化

最終退社時の自分の机 2012年に修士卒からの新卒でNTT研究所に入り、6年間お世話になりました。 研究所では同期や先輩や後輩や上司に恵まれ、存分に書籍や論文を読んで勉強して力を蓄えたり、対外的な発表の場にも恵まれ外ではできないような体験をすることができました。 ありがとうございました。 入社当時に作られたtogetterを見返すと togetter.com togetter.com まるで昨日のように感じられる。 NTT社内で僕が何をやっていたかについては言える物は軒並みアウトプットされているのでわざわざここでは触れない。 NTT研究所について NTT研究所を客観的に見た時にどうかを書いていく とにかく人に恵まれている。採用の倍率が高いのもあって潤沢な学生エントリーからよりすぐりのエリートが謎の力でポテンシャルを見極められて採用されている。同期を見てひと目ですごい奴も居れば、一見してわか

TL;DR 分散システムにおいてキューを導入する場合、本当にキューが必要なのか再考すべき。そこが地獄の入り口だから。 システムの抽象 コンピュータの世界は、本来は0と1の信号の羅列が飛び交う無機質なものである。でも人類は信号だけですべてを語らず、様々な喩えを定義してきた。それはデスクトップ・ウィンドウ・マウスカーソルといったグラフィカルな表現に留まらず、パケットやカプセル化といった用語にロック・キュー・リスト・木などのアルゴリズムやデータ構造の世界にも自然に溶け込んでいる。これらはすべて人間の理解を助けるための喩え話に過ぎず、この喩えこそが人間のより直感的な理解をもたらす一方で、発想の制約を生み出してきた。 人間が大きなシステムを作るときも何らかの喩えを用いてシステム全体を整理する。アーキテクチャの「ポンチ絵」を描いて情報共有をするのは企業に勤めていれば経験した人も多いだろう。パワーポイン

8/10のNTT Tech Conference #2 にて発表の時間をもらってこのタイトルで喋ってきた ntt-developers.github.io 発表が決まるまで これはNTTグループ内のソフトウェア・ネットワーク系技術者が集まるコミュニティで、誰が発表者になれるかは投稿されたProposalに対するコミュニティ内での投票によって選考される。 何を話したいか自分の中でも固まりきっていなかった上に、主催者の話をロクに聞いていなかった自分は小さい部屋で僕のことを知る人しか集まらない不人気セッションを勝手に想像しており、abstractを書く欄に「実世界で使われている分散システムを構成する際に理解してほしい議論についてkumagiが一人で滔々と語る。」という漠然とした説明を書いた。初心者にこそ聴いて欲しいという身勝手な理由でレベル設定をBeginnerにし、自己紹介欄に至っては本当は経