Database Design and Implementation を Go で実装した - goropikariの備忘録
DBMS をフルスクラッチで作る Database Design and Implementation: Second Edition1 を読みながら、この本で作る DBMS(SimpleDB) を Go で実装しました。始めてからちょうど5ヶ月くらいかかりました。 去年も DBMS を自作していましたが、当時は DBMS の理論を学ばずに「この SQL が投げられたときにこういう結果を返すにはこういう実装にすればとりあえずそれっぽい動きをしてくれそう」という感じに実装していて理論的なところは何も学んでいませんでしたが、今回はちゃんと本に沿って実装したので理論・実装を体系だって学べました。 Database Design and Implementation: Second Edition (Data-Centric Systems and Applications) (English E
トランザクションを考慮した実装について考える
はじめに アプリケーションレイヤーでトランザクションを考慮した実装をどのようにすればいいのか悩んでいる人が多いことに気がつきました。オニオンアーキテクチャ等でアプリケーションコードを関心ごとのレイヤーに分離するときに、トランザクションを開始するためのDBとのコネクションの作成をどのレイヤーで実施するのか悩んでいる人が多いそうです。 本記事ではDDD+オニオンアーキテクチャ+Repositoryパターンを使う前提で、私がよく使うトランザクションを考慮した実装について説明しようと思います。 トランザクションを考慮した実装 私はトランザクションを開始するためのDBとのコネクションの作成はUsecase層で実施します。 私がよく書く実装ではDDDでいうEntityを定義します。そしてRepositoryではEntityのCRUDのみ行うように実装し、Repositoryをトランザクション境界にしま
Goで解放したメモリが少しずつ戻ってくる現象 - knqyf263's blog
情報を発信する人のところに情報が集まることを日々実感しているので、Linuxのメモリ管理に特に詳しいわけではないのですが最近遭遇した問題について自分の理解を書いておきます。ざっと調べても同じことを書いている人を見つけられなかったので、公開には意義があると考えています。識者の方がフィードバックをくださると嬉しいです。 ※ AIの出力をベースに書いているのでいつもと少し文体が違います。 背景 要約 調査 再現の難しさ Goアプリケーションの調査 pprofによる分析 GCログの調査 Linuxの調査 Goランタイムの調査 GoのGCとTHP khugepagedの問題 Goランタイムにおける回避策 回避策の削除 max_ptes_noneのデフォルト値について MADV_NOHUGEPAGEをやめた理由 調査内容まとめ 解決策 検証 C言語 Go言語 まとめ 背景 Go言語で書かれたOSSのア
goのエラーをスタックトレースも含めて構造化ログで残したい - エムスリーテックブログ
こんにちは、エムスリーエンジニアリンググループの福林 (@fukubaya) です。 golangでずっと課題に思っていたエラーの処理について試行錯誤してみました。 イオンモール センソックシティは、カンボジアにある商業施設。本文には関係ありません。 エラー処理のベストプラクティスは？ ぼくがかんがえるエラー処理の要件 検討したパッケージ 構造化ログ パッケージの検討 pkg/errors cockroachdb/errors goark/errs go-errors/errors go-errors/errors がよさそう? pkg/errors や cockroachdb/errors は使えないのか ラップして使う errors.WithStack(err) と呼びたい slogで使う errors.Join() に対応したい まとめ We are hiring! エラー処理のベス
GitHub Actions 上での Go の Docker ビルドを高速化する
どうも GitHub Actions 上で Docker ビルドを行うと時間がかかるなぁと感じていました。 かなり軽量の Go の Web アプリケーションを Docker イメージにしてプッシュするプロセスなのですが、全体で 3 分ほどかかっています。 今回はその速度改善を行ったので、得た知見を記事にしたいと思います。 最終的に、ケース次第では以下のような結果を出すことができました。 ※ケース = go のソースコードのほんの一部を変更してワークフローを実行する。 go.mod など依存関係に変化はない。 go build: 60秒 → 1秒 docker/build-push-action ステップ: 2分30秒 → 30秒 ワークフロー: 3分 → 1分 前提 go build は Dockerfile のステップで行っており、イメージとして以下のような内容になっています。 FROM
自社サービスのバックエンドを Go から TypeScript へ切り替えるための整理
切り替える理由 自社の主力製品で利用している技術(WebRTC / WebTransport)がブラウザベースのため TypeScript を利用する Go を採用したのは sqlc が使いたかったという理由 sqlc-gen-typescript が出てきたのでもう Go を使う理由がなくなった 自社サービスチーム全員が Go にまったく興味が無い sqlc 自体は便利 そもそも自社に Go への興味がある人がいない 自社サービスの規模ではボトルネックになるのはデータベースであって言語ではない もしアプリでスケールが必要なときは Rust や Erlang/OTP に切り替えれば良い コネクションプールは PgBouncer を利用すればいい TypeScript からは 1 コネクション 1 接続で問題無い どうせフロントエンドでは TypeScript を書く 自社では React
Goにおけるjsonの扱い方を整理・考察してみた ~ データスキーマを添えて
この記事について この記事はGo Advent Calendar 2021 13日目の記事です。 記事のテーマはencoding/jsonパッケージにおけるjsonエンコード・デコードの扱い方についてです。 普段私は、 MarshalとUnmarshalってどっちがGo→jsonでどっちがjson→Goなんだっけ？ タグでマッピング規則をいじれるのはエンコードとデコードどっちだっけ？ 非公開フィールドってどういう扱いになるんだっけ？ などというところがうろ覚えでパッと出てこないので、この際なのでまとめてしまおうということで前半部分を書きました。 また記事後半では、私が今年読んだとある本の内容に基づいてGoでのjsonデコードが持つ性質を好き勝手に考察してみました。 25日に向けてちょうど折り返しの位置ですが特におもしろネタ要素はなく、普通に私の書きたいことをひたすら真面目に理屈っぽく書いて
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
https://x.com/matsuu/status/1832248678859600154?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/engineer_ryoma/status/1831897525890248862?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/matsuu/status/1829885875280626102?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/matsuu/status/1828792100764389787?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/ken5scal/status/1825678717852725315?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/gorilla0513/status/1824758499311751184?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/nwiizo/status/1821135786470699318?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/gorilla0513/status/1818794939758919814?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/ymotongpoo/status/1816745942240100863?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/moneyforwarddev/status/1800027188697460863?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/voluntas/status/1787074934466138468?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
https://x.com/poly_soft/status/1743918486135644482?s=12&t=suYC6B2IhN7jv0qU5zDxmQ
JavaScript is not available.