これを投稿しに来た。RedkaのパフォーマンスがPostgres（とRedis）と比べてどうなるのか気になるな。編集: https://antonz.org/redka/#performance

そうそう、記事では「どうせDBは必要だし」って言ってるけど、キーの期限切れのために余計なcronジョブを設定して、さらにコードも増やしてる。YAGNIや依存関係を避けるのはわかるけど、これは本当に余計な手間だよね。Postgresにもキャッシュ機能があればいいのに。そうなるまでは、再発明するよりもRedisかmemcachedを使うつもり。

悪いわけじゃないけど、運用するシステムの数を減らすって感じかな。

いつかPostgresがタイムスタンプ列を期限切れ列としてマークできるようになることを期待してる。キャッシュ以外にも、セッショントークンやフィーチャーフラグ、バックグラウンドジョブ、レート制限、遅延削除（ソフト削除のバリエーション）など、いろんなことに役立つと思う。自動バキュームが定期的に期限切れの行を処理できるみたいだし、クエリプランナーが自動的に期限切れの行を除外する条件を追加して、期限切れの行が自動バキュームでクリーンアップされるまで見えないようにできるんじゃないかな。

キャッシュキーにTTLを設定できる機能は、キャッシュにとって重要な要素だよね。後から追加できるものじゃない。具体的にどんな課題があるの？少なくとも、DBエントリの一部として有効期限のタイムスタンプを保存することはできるよ。一般的なキャッシング戦略では、キャッシュが期限切れになる前に再検証することが含まれているし、再検証中に古いデータを返すのは全く珍しいことじゃないから。

これが僕のブログに載ってる理由があるんだ。これはどちらのツールの絶対的な速度を示すものじゃないし、ベンチマークもそのために設定されてない。ブログ記事ではRedisがもっとパフォーマンスを発揮できるって言ってるよ。

ブログやってる人の大半は、自分が何やってるか分かってないか、知ろうともしてないんだよね。悲しいことに、そういう人が会社に雇われて、ブログがあるからみんなその言うことを聞く。あの業界では本当にひどいことを見てきたよ。何人かは本当に詐欺師みたいなもんだ。

彼はPostgresが2コアをフルに使っていることを認めているけど、RedisはHTTPサーバーによってボトルネックになっているんだね。あなたの言いたいことは何なの？どちらかをさらに最適化できるってこと？まあ、そうだろうね。それは驚くべきことじゃないよ。レイテンシーだけでも、いくつかの横断的リクエストの範囲に入ってるし。RedisがPostgresよりも優れていることに驚いた？そんなことないと思うけど。じゃあ、問題は何なの？証明されている主なポイントは、パフォーマンスに関しては確かに収穫逓減があるってことだよ。キャッシュにアクセスする際に20msの余裕があるアプリケーションなら、永続データベースを使ったキャッシングも選択肢だよ。そういう事実に驚く人もいるみたいだけど、それは考える材料になるよね。

あなたの言いたいことが分からない。この結果は、すべてのパラメータが文書化されているから、Fはつかないよ。結論も間違ってないし、じゃあ問題は何なの？

ハッカーニュースにはハッカーが多すぎる！

25年前のドットコムバブルが崩壊した時のことを知らないかもしれないね。あの頃、私たちはベイエリアに留まるために、すごく苦労したんだ。すごいエンジニアたちが、ひどい仕事をしながら、サイドで「契約」してた話もあるよ。家でスタートアップを立ち上げたり、レンタルホスティングのスライスでやるなんて無理だった。ハードウェアは高かったし、何も簡単じゃなかった。今は、月10ドルで1000ユーザーを抱えるビジネスを立ち上げて成功できる時代だよ。これは実現可能で、簡単に構築できるビジネスモデルだと思う。でも、アマゾンの無限の請求書で2012年の価格で利益を上げるためにホスティングを選ぶつもりはない。固定費のホスティングがあるのに、そんなことはしないよ。私にとって、テクノロジーで面白いことは、FBやGoogle、ハイパースケーラーからは出てこない。AIやMLでもないしね。もう一つのKubernetesやKafka、Reactは必要ない（コンウェイの法則プロジェクトももういらない）。もっと面白い仕事は、限られた時間と予算で問題を解決している小さな2人や3人のチームで行われている。彼らの仕事は、クラウドフレアの最新の大規模Rustプロジェクトについてのエンジニアリングブログよりも、HNを読んでいるほとんどの人にとってはずっと適用可能だと思う。

すごいベンチマークが内部調整の中で消えてしまっていることが多いよね。運が良ければブログ記事が出るけど、作成者が結果を共有することに対してインセンティブがなかったり、雇用主から共有を discouraged されていたりすると、結果は日の目を見ないままになる。

主なポイントは、両者を完全にベンチマークして比較することじゃなくて、Postgresのキャッシュが実際に役立つくらい速いかどうかをざっくり把握することだったんだ。Redisとの比較は、あくまでその感覚を得るための補助的なもので、「堅実なベンチマーク」を装うものではなかったよ。

なんか、騒ぎすぎな気がする。

こういう風に提示されると、普通の読者はPostgresがRedisのパフォーマンスの2/3くらいだと思っちゃうよね。 もし読者が技術的な選択に興味があるなら、人気のユースケースのベンチマークくらいは読むだろうし、結論も知るはずだよね。 キャッシュに関しては、Redisの方がPostgresより速いのは間違いない。 キャッシュに期待される便利な機能、例えばTTLもついてるしね。 それに、ハードウェアやサービスのボトルネックもあったから、もっと良い数字が出せたはず。 じゃあ、キャッシュが必要ならみんなRedisを使うべきだよね？ でも、俺はやっぱりPostgresを使うかな。 ほとんどのプロジェクトにはデータベースが必要だし、別の依存関係を追加しなくて済むのは大きなメリットだよ。 もしキーが期限切れになってほしいなら、カラムを追加して、クロンジョブでそのキーをテーブルから削除するようにするよ。 スピードに関しては、7425リクエスト/秒ってまだまだ多いし、1日で5億リクエスト以上だよ。 しかも、10年前のハードウェアでノートPCのCPUを使ってるんだから。 これだけのスケールに達するプロジェクトは少ないし、もし達したらPostgresのインスタンスをアップグレードするか、必要ならRedisを立ち上げればいいしね。 キャッシュのインターフェースを持っておくことで、簡単にストレージを切り替えられるのは、まさにこの目的のために続けるつもりだよ。 最初の文にはちょっと異議があるかも（「…少なくとも俺のハードウェアと設定に関しては。」って付け加えようかな）けど、他は大体大丈夫そう。 普通の読者としては、だいたいこんな感じだよね：

• お、誰かの経験とデータポイントだ。これだけで自分の意見を決めるつもりはないけど、みんなが経験を共有してるのはいいことだね。
• どっちを使いたいにしても、ボトルネックやHTTPサーバーについても調べる必要があるかも、最初は気にしないかもしれないけど！
• そんなにチューニングに手をかけなくても、どちらのソリューションも大量のデータを処理できて、パフォーマンスも同じオーダーに収まってる。
• だから、普通の読者としては、カジュアルなユースケースには、簡単そうな方を選べばいいって感じかな。 もし本格的なベンチマークを読みたかったら、そういうのを探しに行くし（それも詳細が多すぎてカジュアルな読み物にはならないけど、要約だけだと結局多くを見逃しちゃうし）、自分でやるかもね。 これは普通のポップサイエンスの記事みたいなもので、特に問題はないけど、他のものを探してるなら別だけどね。 ボトルネックを排除する方法についてのフォローアップ記事があったら面白いかも！

完全に同意。Postgresは多くのユースケースに使えるパワーツールだよ。パフォーマンスを求めるなら、調整が必要だね。Postgresを調整せずに判断するのは、Postgresが遅いんじゃなくて、開発者がナイーブなだけだよ。

一方では君に同意するけど、もう一方ではデフォルトが重要だと思う。デフォルト設定のままで調整を試みないシステムをよく見るからね。デフォルトをベンチマークするのと、調整されたセットアップをベンチマークするのでは、測定するものが全然違うけど、どちらも重要だよ。

反対だね。大多数のソフトウェアはデフォルトで動いているから、こうやって比較するのは理にかなってる。

私は反対だな。調整なしのPostgresが、低レベルのハードウェアでも十分に速いことがわかったし、別のサービスを展開しないという利点もある。さらに、調整することはあまり関係ないと思う。デフォルトがユースケースに合っているなら、個人的な興味で調整したい場合を除いて、それは私の楽しみの時間の無駄か、クライアントの資金の無駄になるだけだよ。

「たった5分のLLMクエリやウェブ検索で、LLMの出力やあまり理解していないかもしれない設定をコピペするよりも、PGのデフォルトの方が信頼できると思う…」

まあ、そうかもしれないけど、少なくともこのケースでは、チューニングされていないPostgresでも多くの実際のユースケースにおいて速いキャッシュとして使えるってことがわかるね。

1. Redisには永続性がない。2. RedisはOOMキルされる。3. 画像に付属しているデフォルト設定を使った。4. そう、CPUを2つ与えた。Postgresをキャッシングに使った場合とRedisを使った場合のHTTPサーバーの挙動を比較したかったんだ。このベンチマークは、時には専用のKVストアが必要ないことを示すためだけにある。もしかしたら、これにPostgresを使うのがあなたのユースケースには十分かもしれない。プロダクション環境という用語は色々な意味があるかもしれない。もし毎秒何十万件のリクエストを処理しているなら、HAやスケーリング、専用の共有キャッシュなど、異なるアーキテクチャが必要になるだろう。でも、そんなに多くのアプリケーションはその境地に達しないし、しばしば消費者にサービスを提供するために必要以上のものを使ってしまう。だから、シンプルに保つことが大事だと言いたいんだ。

IDでの選択は速いよ。キャッシュとして使ってるのにIDでの選択をしてないなら、それはキャッシュじゃないね。

でもキャッシュとして使うのは、信頼性の面でちょっと心配だと思う。これまでにPostgresにデータを保存することが信頼性の面で懸念だと誰かが言うのを聞いたのは初めてだし、君がこの問題に関して重要な洞察を持っている唯一の人間だとは思えない。君の以前の信念が根拠のないものである可能性はないの？ > DBがかなり劣化する場面を何度も見てきた。これって漠然とした逸話で意味がないよ。具体的なシナリオはあるの？誰でも十分なミスをすれば、Redisでも「かなり劣化」させることができるからね。