カサンドラと集計されたデータ

Question

私たちは、OLTPデータを保持する「レガシー」SQL Serverベースのアプリケーションを持っているが：OLTPデータ構造が

非常に複雑である

• それでも我々はのためのソースとしてそれを維持する必要がありますOLTP構造の上に
• レポートは
• だから、我々は準備し、実際の「OLAP」-views、たとえば、一日あたりの売上高を維持する非常に遅い報告し、各ビューは、実際にMS SQLデータベース内のテーブルである

主な問題：新しいビューが必要な場合、既存のすべてのOLTPデータをスキャンするのに多くの時間がかかります。

今、私たちは、カサンドラに移行したい、我々は同じ目標をachiveする同じアプローチを使用する必要がありますか：

• は、私たちはより良いスパーク/麒麟のようなツールを使用することが、彼らはこのようなことを行うことができてもいいですか？
• 何とかアプローチを変えることができますか？

Answer 1

あなたが探したい回答ではないかもしれません。しかし、私はちょうど私たちの経験をカッサンドラと集計したデータと共有したいと思います。私たちのプロジェクトでは、世界中のサーバーからデータを収集し、それに応じて集計を行う必要があります。メトリックの中には、サーバごと、地理的領域ごとなどのメッセージがあります。新しいデータが入ったら、バッチ処理を自動的に開始して集約を実行したり、複数のテーブル/ビューにデータを挿入したりします。さらに処理エンジンとしてapache-sparkを使用しています。さらに、具体的な使用例に基づいて、materialized view,secondary index,custom triggerなどのいくつかの概念を使用しています。データモデルを設計する際の重要な点の1つは、NFを忘れることです。基本的には、NoSQLでは一般的にこれを必要としません。

つまり、従来のデータベースからNoSQLデータベースへの移行は、最初は面倒だったかもしれません。しかし、最終的な結果は、パフォーマンスと可用性の点では非常に満足です。