2026年9月12日(土)掲載 4,282本日 28
HN17162

ペタバイト級のClickHouse運用で5年分学んだこと:教訓とベストプラクティスを共有します

I've operated petabyte-scale ClickHouse clusters for 5 years

adastral4日前

議論

11
0adastralスレ主1714日前

5年にわたりペタバイト規模のClickHouseクラスターを運用してきた経験から、その技術的な知見や運用上の注意点について共有します。大規模分散データ処理の最前線で何が起きたのか、トラブルシューティングやスケーリングの秘訣について議論しましょう。

1lucrbvi約10時間前

®(登録商標マーク)がやたら多いね。ClickHouse® Inc.が他社による自社名の使用に対してどう対応するのか気になるところ……。JavaScriptでやったOracleみたいなことにはならないでほしいけど。

2walthamstow約10時間前

余談だけど、先週フラム対クリスタル・パレス戦をつけたら、今年のフラムのユニフォームにClickHouseのロゴが入ってて、パレスにはTemporal AIのロゴがあって驚いたよ。自分の世界が交錯した瞬間だった。

3bradleyy約9時間前

AmazonがRDSとして提供してくれればいいのに。そうしたら人生がずっと楽になるんだけどな。

4zbentley約9時間前

秒間2万行を超えるロードや頻繁な変更がある場合、クラスター管理と、ユーザーが書くヤバいクエリの監視をするための専任担当が必要になるかもしれない。

昔のDBA文化のメリットってこれだったと思う。DBAが優れたクエリを書くのに不可欠だったというより(実際にはアプリケーションチームと協力して、効率的なスキーマや動作に導く必要が多かった)、DBAがどのようなクエリやスキーマが「許容されるか」の門番であり、レートリミッターとして機能していたことが重要だったんだ。

そのモードでは、DBAはデータベースアクセスをラップする軽量なマイクロサービスのような人間版・プロセス版として機能していた。大きなメリットは、クエリやスキーマ変更、アクセスパターンの変更速度が制御されており、本番環境に反映される前に人間が確認・検討する可能性が高かったこと。その結果、既存のスキーマやクエリパターンを工夫して活用しようとする文化がエンドユーザー側に醸成された。スタートアップや、プロレベルの迅速なリファクタリングを行うショップには向かない文化だけど、データベースの信頼性やクエリ率、データセットの規模が重要視される場面ではまさに求められるものだ。

門番チームがコストに見合うかどうかは一概には言えない。状況次第だよ。ただ、そういったチームをコード化したもの(DBアクセスやスキーマ変更をラップするだけの前述のマイクロサービス)は、コストに見合わないことが多いと思う。経験上、それらはユーザーコードから直接DBクライアントを使用する場合に比べて、信頼性とパフォーマンスの恩恵をほぼ確実に削いでしまう。

6yakkomajuri約8時間前

「ClickHouse®を扱うすべての企業がインジェスト(取り込み)で苦労している」

本当にその通り。「too many parts(パーツが多すぎる)」っていうのを見て、昔の辛い記憶がフラッシュバックしたよ。

(以前PostHogでCHへのインジェストを担当してたけど、今はもうやってない)

7threecheese約8時間前

テラバイト規模のClickHouseを運用してるよ。まあ、MacBookでLangfuseを数ヶ月動かしっぱなしにしてたからなんだけどね :)

冗談はさておき、ClickHouseって本当にディスク容量を食うよね。

8anguss約5時間前

数週間前、いわゆる「ソフトウェア工場」を特定するためにGitHubでコミット頻度の高いリポジトリを調べてたんだけど、ClickHouseを見てびっくりした。メインへのマージ速度が速すぎて、俺なら怖くて触れないな。1日50件以上のコミットとか、AI生成のIssueやトリアージが大量にあるし。自分で確認してみてよ https://github.com/clickhouse/clickhouse (https://github.com/clickhouse/clickhouse)

9dev_l1x_be約5時間前

複雑なシステムには複雑な運用と課題がつきものだ。DuckDBのような技術を使えば、読み取りと書き込みのワークロードを分離したり、部門やユーザー単位で読み取りクエリを分けることも十分に可能だと思う。