我正在嘗試設計我的流式應用程序的體系結構併爲該作業選擇正確的工具。對時間序列數據流執行查詢
這是它是如何工作目前： 
從「應用生產者」部分信息有(address_of_sensor, timestamp, content)元組的形式。
我已經在Kafka之前實現了所有功能，現在我遇到了設計中的重大缺陷。在「Spark Streaming」部分，整合的消息流被轉換成事件流。問題是大多數情況下的事件是複合的 - 由多個消息組成，這些消息在不同的傳感器上同時發生。
我不能依靠「到達卡夫卡的時間」作爲檢測「同時性」的手段。所以我必須先用Kafka對消息進行排序，然後再用Spark提取它們。或者更準確地說，可以查詢Kafka消息。
也許卡桑德拉是卡夫卡的合適替代品嗎？我有非常簡單的數據模型，只有兩種可能的查詢類型：按地址查詢和按時間戳查詢範圍。也許這是正確的選擇？
有人有任何Cassandra的吞吐量？
如果你想在你的時間序列上運行查詢，Cassandra可能是最適合的 - 它非常適合寫入，你可以爲你的系列構建'寬'行。您可以在寬行上製作切片，因此您可以僅使用一個查詢來選擇一些時間範圍。
另一方面，kafka可以被視爲原始數據流 - 您沒有查詢，只有最近生成的數據。爲了收集基於同一分區中某個鍵的數據，您必須仔細選擇該鍵。同一分區內的所有數據都按時間排序。
範圍查詢時間戳是cassandra的經典用例，如果您需要基於地址的查詢，那麼如果使用cassandra，則必須將它們作爲聚簇列。就cassandra througput而言，如果您可以投資於cassandra集羣的適當性能分析，您可以實現非常高的寫入吞吐量。但是我已經使用了SparkQL，Cassandra Driver和spark Cassandra連接器，它們並沒有提供高查詢吞吐速度，除非您擁有一個CPU配置較高的大型羣集，但對於小型數據集不適用。
卡夫卡不應該被用來作爲查詢的數據源，它更多的提交日誌
我應該清理卡桑德拉使用過的信息嗎？它也會影響性能。對於Kafka，AFAIK，由於基礎數據模型的原因，隊列中的數據量並不重要。 – mkurnikov
如果你清理使用的消息..它創建墓碑和墓碑在壓實期間創建高cpu使用..所以我不建議刪除數據或清除算術cassandra。 –
如果我創造了很多話題，其中話題=卡夫卡的地址？它會起作用嗎？然後，我可以對到達時間的「不正確」和「時間戳」的值進行一些假設，並放棄地址查詢。 – mkurnikov
@mkurnikov很多話題可能不是一個好主意。但是您可以爲您的數據創建主題並選擇地址字段作爲關鍵字。在這種情況下，具有相同地址的所有事件都轉到相同的分區並按時間排序。您甚至可以使用單個分區創建主題並將所有事件存儲在該分區中。在這種情況下，您可以獲得所有訂購的事件，但吞吐量會很差。 – leshkin