ペタバイト級ClickHouseクラスタを5年間運用して分かったこと
I've operated petabyte-scale ClickHouse clusters for 5 years
TinybirdでClickHouseのペタバイト級クラスタを5年間運用してきた筆者が、その経験から得た教訓を共有。クラスタ構築は簡単でも維持が難しいとし、レプリカとシャードによるアーキテクチャ、クラウドストレージの限界、ゼロコピーレプリケーションの危険性、アップグレードの苦労とベストプラクティスを解説。特に、アップグレードをCI/CDパイプラインに組み込むまでに4年かかったことや、データ損失のリスクなど、実運用で直面する問題を率直に語る。
クラスタのセットアップは簡単だが、難しいのはそれを動かし続けることだ。
HNでの議論
51- zbentley
20k行/秒を超える負荷で、しかも人が変更をどんどんプッシュしてくるような場合、クラスタを管理し、人々が書こうとしているとんでもないクエリをチェックする専任の担当者が一人必要になるかもしれない。
これは以前の時代のDBA文化の利点だったと思う。DBAが特に必要だったのは、良いクエリを書くため（多くの場合、うまく機能するスキーマや振る舞いへとアプリケーションチームを導くために彼らと協力する必要があった）でも、データベースを保守するため（マネージドDBの登場でこの作業の多くは不要になった）でもない。むしろ、どのクエリやスキーマが存在してよいかを決めるゲートキーパー兼レートリミッターとして機能していたからだ。
そのモードでは、DBAはデータベースアクセス機能をラップする薄いマイクロサービスの、人間／プロセス版のような役割を果たしていた。大きな利点は、クエリの変更、スキーマ変更、アクセスパターンの変化の速度が制御され、本番投入前に人間がレビューして考える確率が高まることだった。またこのことは、とりあえずオーダーメイドのアクセスパターンに飛びつく前に、既存のスキーマやクエリアパターンでなんとかならないか試そうとする、エンドデータベースユーザー側の文化を育てることにもつながった。そうした文化は、たとえばスタートアップや、迅速で大規模なリファクタリングを旨とする組織には向かないが、DBの信頼性要件やクエリレート、データセットサイズが高い場合にはまさに求められるものだ。
ゲートキーパー的なチームがそのオーバーヘッドとコストに見合うかどうかは一概には言えない。状況次第だ。ただ、そのチームのコード版（前述の、DBアクセスやスキーマ変更をラップするだけのマイクロサービス）は […]
- dev_l1x_be
複雑なシステムには複雑な運用と問題がつきものだ。読み取りと書き込みのワークロードを分離し、読み取りクエリを部門ごと、あるいはユーザーごとに切り分けるのは、特にDuckDBのような技術を使えば、十分あり得る選択肢だと思う。
- walthamstow
余談だが、先週フラム対クリスタル・パレスの試合をつけようとして、今年はフラムのユニフォームにClickHouse、パレスにはTemporal AIが入っているのを見て固まってしまった。まさに自分の世界が衝突した瞬間だ。
- lucrbvi
®がやたら多いな。ClickHouse® Inc.が他社による名称の使用をどう扱っているのか気になる……OracleがJavaScriptに対してやったみたいなことになっていなければいいが。
- threecheese
私はテラバイト規模のClickHouseを運用している——ただし、MacBookでLangfuseを数か月動かしっぱなしにしたせいでだけど :)
でも真面目な話、ClickHouseはディスクスペースが本当に大好きだ。