nikezono.dev
この記事は データベース・システム系 Advent Calendar 2023 (opens in a new tab) の16日目の記事です． 深い意味はない この記事はポエムです．また，Redbookの6章 (opens in a new tab) や Peter Bailis のブログ (opens in a new tab) がほぼ同じ話をしているので，この記事を読むよりこちらを読まれたほうがより深い理解が得られます． TL;DR; Serializableという概念は便利．しかし，使われていない Serializableでなくとも要件が満たされるシステムが世の中には多い ワークロードによってはそもそも Weak Consistency でも Serializable と等価 それでも，Weak Consistency と Serializable の差分の定式化（すなわち，Ano
開発者が知るべきキャッシュ設計でよく遭遇する問題
はじめに 分散システムの設計および開発において、キャッシュはパフォーマンス向上のための非常に重要な要素です。頻繁にアクセスされるデータをキャッシュすることで、アクセス速度が遅いデータベースへのアクセスを削減し、データへの迅速なアクセスを可能にします。これにより、システムの全体的な効率とパフォーマンスが向上します。 しかし、キャッシュは慎重に設計しないとむしろパフォーマンス上のデメリットになるケースが存在します。 この記事ではよく遭遇するキャッシュ設計の問題とその回避策について解説します。 Cache penetration DBに存在しない値を検索したときに、DBから返された空の結果をキャッシュしない場合に発生するシナリオです。 このシナリオではDBに存在しない値を繰り返し検索することにより、その値がキャッシュされていないため検索ごとにDBへのアクセスが必要になってしまいます。 存在しない
CloudNative Days、クラウドネイティブ技術を学べるハンズオン教材をGitHubで一般公開
12月11日～12日に開催された「CloudNative Days Tokyo 2023」で『一日で学ぶクラウドネイティブ技術実践ハンズオン』の企画を担当したCloudNative Days Tokyo 2023 実行委員会は、同教材を12月8日にGitHub上で一般公開した。 『一日で学ぶクラウドネイティブ技術実践ハンズオン』は、Kubernetesやクラウドネイティブ技術に精通した実行委員会のメンバーにより、現在標準的に使用されているクラウドネイティブ技術を一通り学べるように設計されたハンズオン。 教材には準備用チャプター1つと10個の通常チャプターが含まれており、準備用チャプターで環境を構築した後、「Prometheus」「Grafana」「OpenTelemetry」「Argo CD」「Argo Rollouts」「Istio」「Cilium」「Hubble」の8つのクラウドネイテ
フィーチャーフラグAPIの標準化を目指す「OpenFeature」がCloud Native Computing Foundationのインキュベーティングプロジェクトに昇格
フィーチャーフラグAPIの標準化を目指す「OpenFeature」がCloud Native Computing Foundationのインキュベーティングプロジェクトに昇格 KubernetesやContainerdなどクラウドネイティブ関連ソフトウェアの開発をホストするなど、クラウドネイティブの普及や推進のための団体「Cloud Native Computing Foundation」（CNCF）は、フィーチャーフラグAPIの標準化を目指す「OpenFeature」がこれまでのサンドボックスプロジェクトから、新たにインキュベーティングプロジェクトに昇格したことを発表しました。 The CNCF TOC has voted to accept OpenFeature as a CNCF incubating project! Congratulations @OpenFeature ht
本当に効く！アンガーマネジメント！
俺は新入社員時代、上司との相性が悪くて毎晩社宅のゴミ箱を蹴っていたり、酒飲みまくって奇声を上げたり、上司との電話直後にスマホを遠投したりといった伝説を数多く持つ本物の奇行種なんだが。 そんな俺が精神科医に薦められてやったことでマジで聞いたことを教える。 会社のカウンセラーが言ってた「７秒耐えろ！無限に耐え続ければいつか収まる！」はマジで無駄だった。 １位 カルシウムの錠剤を飲む。 ２位 ７時間以上寝る ３位 バナナを食って太陽光を浴びる ４位 朝と晩に「俺がよくやっているのは俺が知っているので、理解する気のない他人に認められる必要は実はそんなにない」を１０回唱える ５位 仕事終わりに明日会社に来たら思い出すべきことを書き出してそのことは忘れて家に帰る ６位 酒とカフェインは元気の前借りなので用法を守る ７位 過ぎたことに考え始めたら「もう諦めろ。取り戻そうとするな」と唱える ８位 どうして
めんどくさい作業を改善できるようになるには - Konifar's ZATSU
めんどくさい作業にぶち当たった時、一気に改善してしまう人がいる。ガッと自動化したり仕組みそのものを変えたりしてしまうのだ。「めんどくさい」と心の中で思ったなら、その時スデに行動は終わっているのである。 たとえばコードレビューで都度同じ指摘をしだしたらLintとCIを整備したり、期限のリマインドを何度もしていたらリマインドそのものを自動化したり。CI/CDやBranch Protect Ruleを初期段階で整えるみたいな動きもそう。 こういう動きができる人とできない人の違いは、大きく次の4つの段階に分けられる。 1. めんどくさいと自覚できるか 1つめはスタンスの問題かもしれない。「もっとよくできないか？」「なぜこれをやってるんだっけ？」といった感じで今の運用を疑ってみるのが第一歩である。 よい状態を知っている方が当然自覚しやすいので、次の2とも密接に関係してくる。 2. めんどくさくない状
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
