メインコンテンツまでスキップ
メインコンテンツまでスキップ

成功事例

このガイドは、コミュニティのミートアップから得られた知見のコレクションの一部です。より実践的なソリューションやインサイトについては、特定の問題でブラウズできます。 本番環境での問題のデバッグに関するヒントが必要ですか？ デバッグインサイトコミュニティガイドをチェックしてください。

これらの事例は、企業がClickHouseを使用して成功を収めた方法を示しています。中には従来のデータベースカテゴリに挑戦し、時には「間違った」ツールがまさに正しい解決策になることを証明するものもあります。

ClickHouseによるレートリミッター​

Craigslistがユーザーを保護するためにTier-1レート制限を追加する必要があるとき、彼らはすべてのエンジニアリングチームが直面する同じ決定に直面しました - 従来の知恵に従ってRedisを使用するか、何か異なるものを探るか。Craigslistで働くBrad Lhotskyは、Redisが標準の選択であることを知っていました - 実質的にすべてのレート制限のチュートリアルやオンラインの例は、良い理由でRedisを使用しています。レート制限操作のための豊富なプリミティブ、確立されたパターン、そして実績があります。しかし、Craigslistのレッドイス性能は教科書の例とは一致しませんでした。*「Redisの経験は映画で見たものとは異なります...私たちはRedisクラスターのノードを再起動し、フロントエンドで遅延のスパイクが発生するという多くの奇妙なメンテナンスの問題に直面しています。」*メンテナンスの簡潔さを重視する小さなチームにとって、これらの運用上の頭痛は本当の問題となっていました。

したがって、Bradがレート制限の要件にアプローチされたとき、彼は異なるアプローチを取りました。*「私は上司に『このアイデアについてどう思いますか？ ClickHouseで試してみることができるかもしれません。』と尋ねました。」このアイデアは風変わりでした - 通常はキャッシングレイヤの問題に対して分析データベースを使用すること - しかし、彼らの核心的要件に対処しました：オープンに失敗し、遅延ペナルティを課さず、小さなチームにとってメンテナンスが安全であること。このソリューションは、アクセスログがすでにKafkaを介してClickHouseに流れ込んでいる既存のインフラストラクチャを活用しました。別のRedisクラスターを維持する代わりに、アクセスログデータからリクエストパターンを分析し、既存のACL APIにレート制限ルールを注入できるようになりました。このアプローチはRedisよりもわずかに高い遅延を意味しましたが、「それはそのデータセットを事前に生成することにより少し不正行為をしている」*リアルタイム集約クエリを行わなくても、クエリは100ミリ秒未満で完了しました。

主な結果:

  • Redisインフラストラクチャに対する劇的な改善
  • 自動クリーンアップのための組み込みTTLによりメンテナンスオーバーヘッドが排除された
  • SQLの柔軟性により単純カウンターを超えた複雑なレート制限ルールが可能に
  • 別にインフラストラクチャを必要とせず、既存のデータパイプラインを活用

Customer analytics​

ServiceNowがモバイルアナリティクスプラットフォームをアップグレードする必要があるとき、彼らは単純な質問に直面しました：「動作しているものをなぜ置き換えるのですか？」 ServiceNowのAmir Vazaは、既存のシステムが信頼できることを知っていましたが、顧客の要求はその処理能力を超えていました。「既存の信頼できるモデルを置き換える動機は実際にはプロダクトの世界から来ている」とAmirは説明しました。 ServiceNowは、ウェブ、モバイル、チャットボットのソリューションの一部としてモバイルアナリティクスを提供していますが、顧客は事前集計データを超えた分析の柔軟性を求めていました。

彼らの前のシステムは、固定された次元：アプリケーション、アプリバージョン、プラットフォームで区分された事前集計データを持つ約30の異なるテーブルを使用していました。カスタムプロパティ（顧客が送信できるキーとバリューのペア）のために、それぞれのグループに対して別々のカウンターを作成しました。このアプローチはダッシュボードパフォーマンスを迅速にしましたが、大きな制限がありました。「これは迅速な価値の内訳には素晴らしいですが、制限は分析コンテキストの損失を引き起こす」とAmirは指摘しました。 顧客は複雑な顧客の旅の分析を行うことができず、「検索語句「research RSA token」で始まったセッションは何回か」を分析し、そのユーザーがその後に何をしたかを分析することができませんでした。事前集計された構造は、マルチステップ分析に必要な連続的なコンテキストを破壊し、すべての新しい分析次元は事前集計とストレージのためのエンジニアリング作業を必要としました。

したがって、制限が明確になると、ServiceNowはClickHouseに移行し、これらの事前計算の制約を完全に排除しました。すべての変数を事前に計算する代わりに、メタデータをデータポイントに分解し、すべてを直接ClickHouseに挿入しました。ClickHouseの非同期挿入キューを使用し、Amirはそれを*「実際に素晴らしい」と*呼び、データの取り込みを効率的に処理しました。このアプローチにより、顧客は自分自身のセグメントを作成し、任意の次元で自由にデータをスライスし、以前は不可能だった複雑な顧客の旅の分析を行うことができるようになりました。

主な結果:

  • 事前計算なしの任意の次元にわたる動的セグメンテーション
  • 複雑な顧客の旅の分析が可能に
  • 顧客は自身でセグメントを作成し、自由にデータをスライスできる
  • 新しい分析要件のエンジニアリングボトルネックが解消

ビデオソース​

これらの物語は、従来のデータベースの知恵に疑問を呈することで、分析データベースで可能なことを再定義する画期的なソリューションを導き出すことができることを示しています。