Tech Table Log: 同期エンジニアの雑談・勉強ログ

Lon, Shinya

社会人7年目の同期ソフトウェアエンジニアの二人が、お互いの近況や気になる技術トピックをゆるく雑談しながら、リスナーと一緒に学ぶPodcastです。 隔週水曜の朝に配信しています。 Shinya: PostgreSQL エンジニア (X: https://x.com/ShinyaKato_ ) Lon: ソフトウェア / 機械学習 エンジニア お便りはこちらから: https://forms.gle/n1ft3Pjdeuk4qznS6 以下のプラットフォームで配信しています。 Spotify: https://x.gd/KGYhE Apple Podcasts: https://x.gd/A6dh7 Amazon Music: https://x.gd/qwgID YouTube Music: https://x.gd/f9AeY 本Podcastでの発言は全て出演者個人の見解であり、所属する組織とは一切関係がありません。 内容は可能な範囲で精査してお届けしていますが、誤りやお気づきの点があれば、上記の Google Form などからご指摘を頂けますと幸いです。

  1. 8月4日

    #38: 組み込みDB (DuckDB、Kùzu、LanceDB)の進化と調和

    『Designing Data-Intensive Applications』第2版でも引用されたブログ記事「Embedded databases (1): The harmony of DuckDB, Kùzu and LanceDB」を元に、次世代の組み込み型データベース(Embedded DB)の動向と特徴について解説します。 本編では、分析処理(OLAP)に特化した「DuckDB」、高度な接続性を持つグラフ構造に特化した「Kùzu」、画像・音声などの生データとベクトルを同居できる「LanceDB」の3つの組み込みDBを取り上げます。それぞれの技術的特徴(ベクトル化クエリ実行、ポインタベースジョイン、DiskANNに対応した独自フォーマットなど)を整理しつつ、インメモリ列指向フォーマット「Apache Arrow」を介して同一プロセス内で変換コストなく連携する「調和(Harmony)」の仕組みを読み解きます。また、PostgreSQLの各種拡張機能(pg_duckdb、Apache AGE、pgvectorなど)との比較や、買収・フォークを含めた各OSSプロジェクトの最新動向についても議論します。 組み込みデータベース (Embedded DB) / DuckDB / Kùzu / LanceDB / OLAP と ベクトル化クエリ実行 / グラフデータベース と Cypher / マルチモーダルとDiskANN / Apache Arrowによるゼロコピー連携 / PostgreSQL拡張機能 (pg_duckdb, Apache AGE, pgvector) / OSSの商業化とエコシステム 参考リンク The harmony of DuckDB, Kùzu and LanceDB, The Data Quarry⁠⁠DuckDB⁠⁠Kùzu⁠⁠LadybugDB⁠LanceDB⁠Lance⁠Apache Parquet⁠Apache Arrow⁠pg_duckdb⁠Apache AGE⁠pgvector⁠⁠pgvectorscale⁠pg_diskann⁠

  2. 7月7日

    #36: AI時代の開発エコシステムはどう変わる?Googleに学ぶソフトウェアエンジニアリングの転換点

    Google I/O 2026でのAdam Bender氏の講演「Software engineering at the tipping point」を元に、AIがソフトウェア開発のエコシステム全体に与える影響について議論します。 本編では、AIによってコード生成速度が10倍になった際に生じるシステム的な歪みについて解説します。コード量の爆発的な増加がもたらすコンパイル時間の長期化やバイナリサイズの肥大化、Gitなどバージョン管理システムの負荷増大、そして人間によるコードレビューが完全にボトルネックとなる問題を取り上げます。さらに、従来の「全テストパス」を前提としたリリースフローの限界や、コストが下がるほどトークン消費が増大していく「ジェボンズのパラドックス」について考えます。 これらへの対応策として、「AIは方向を示すものではなく、組織の強みも弱みも増幅させる増幅器(Amplifier)である」という原則を紹介します。計算リソースやトークン消費の把握、インテグレーションテストの拡充といった基礎の重要性に触れつつ、個別のコード(葉)だけでなくシステム全体(森)を俯瞰する視点が今後のエンジニアに求められることについて、実務における葛藤を交えながら議論します。 Google I/O / ソフトウェア生態学 / コード生成の高速化と副作用 / コンパイルとバイナリ肥大化 / コードレビューのボトルネック / CI/CDとテスト戦略 / ジェボンズのパラドックス / AIは増幅器 (Amplifier) 参考リンク Software engineering at the tipping point#8: AI時代における新たなデータシステムを考える -論文紹介-#17: AI時代に組織に求められる性質やソフトウェア開発プロセスとは?#26: 初の対面収録!書籍『AIエージェント 人類と協働する機械』を読んで考えるソフトウェアエンジニアリングの未来#31: システムや機能の「非推奨と廃止」はどう進める?Google/Kubernetes/SQL Server/PostgreSQLに学ぶコードの終活

  3. 6月9日

    #34: PostgreSQLのロック:アプリ開発の「はまりどころ」から内部実装まで(後編)

    PostgreSQLのロックの仕組みについて、データベース内部実装(SpinlockやLWLockなど)のディープな世界を深掘りする2回エピソードの後編です。 今回は、DBAやデータベース開発者、並行プログラミングに関心がある方向けに、PostgreSQLの内部的な排他制御を解説します。CPUのアトミック命令であるCAS (Compare-and-Swap) を前提知識として、WAL (Write-Ahead Logging)の書き込みなどで使われ競合時にスリープする「Lightweight Lock (LWLock)」と、スリープせずにCPUを回し続けてロック獲得を待つ「Spinlock」の仕組みや用途の違いを整理します。 さらに、Linux 7.0環境で話題になったPostgreSQLの性能劣化問題の真相に迫ります。カーネルのスケジューラ変更(プリエンプションの挙動変化)がSpinlockに与えた影響や、PostgreSQLコミッタが指摘する、Spinlockをfutexに置き換えることの構造的な難しさを紹介します。また、この性能劣化報告の根本的な原因が「Huge Pages」の未設定によるTLBミスとページテーブル探索のオーバーヘッドにあったことを挙げ、OS・CPUレベルの適切なパラメータ設定がいかに重要であるかを議論します。 PostgreSQL内部実装 / CAS命令 (Compare-and-Swap) / Lightweight Lock (LWLock) / Spinlock / WAL書き込み / Linux 7.0性能劣化問題 / プリエンプション / futex / Huge Pages / パラメータチューニング 参考リンク ⁠PostgreSQLのロックでハマりがちな挙動5選⁠⁠AWS Engineer Reports PostgreSQL Performance Halved By Linux 7.0, But A Fix May Not Be Easy⁠⁠I really dislike the use of spinlocks in postgres

番組について

社会人7年目の同期ソフトウェアエンジニアの二人が、お互いの近況や気になる技術トピックをゆるく雑談しながら、リスナーと一緒に学ぶPodcastです。 隔週水曜の朝に配信しています。 Shinya: PostgreSQL エンジニア (X: https://x.com/ShinyaKato_ ) Lon: ソフトウェア / 機械学習 エンジニア お便りはこちらから: https://forms.gle/n1ft3Pjdeuk4qznS6 以下のプラットフォームで配信しています。 Spotify: https://x.gd/KGYhE Apple Podcasts: https://x.gd/A6dh7 Amazon Music: https://x.gd/qwgID YouTube Music: https://x.gd/f9AeY 本Podcastでの発言は全て出演者個人の見解であり、所属する組織とは一切関係がありません。 内容は可能な範囲で精査してお届けしていますが、誤りやお気づきの点があれば、上記の Google Form などからご指摘を頂けますと幸いです。

その他のおすすめ