攝入系統應該在哪裏出現？

我試圖設計一個物聯網系統，它將許多物聯網設備發送不同類型的傳感器數據到前端負載均衡服務器，然後將消息發送到攝取系統（目前認爲Google Cloud PubSub）。然後有消費者使用消息並將它們寫入不同的數據庫和表。每個傳感器數據類型都有自己的數據庫。攝入系統應該在哪裏出現？

扇出發生在哪裏？

之前發佈訂閱系統：如果前端做扇出，那麼它必須被縮放足夠大，有足夠的處理能力來看待每封郵件的內容找出將其發送結束這話題。然後，我將爲每個消息和每個主題的消費者分別設置一個主題。
AFTER pubsub系統：如果我只有一個主題，即前端只是將所有消息推送到任何類型的消息中，那麼需要縮放該主題的消費者以便能夠消費和處理每個消息以確定哪個數據庫寫信給。這也意味着這一個消費者代碼需要訪問所有的數據庫。
INSIDE pubsub系統：讓pubsub做扇出，以便即使發佈者只發布到一個主題，該主題也有多個訂閱（每個數據類型一個訂閱），並且每個消費者從他們自己的訂閱刪除所有消息，這些消息是它們要使用的數據類型。看起來卡夫卡可能是更好的用途。

來源

2017-08-01 gunit

＃3非常適合卡夫卡。有一個Kafka連接器或Google PubSub，所以你甚至可以同時使用PubSub消息並將其發送到Kafka主題（或反之），而無需任何編碼。請參閱https://github.com/GoogleCloudPlatform/pubsub/blob/master/kafka-connector/README.md –

對於通過的Pub/Sub您將IoT Core，也可以用來處理設備的連接，認證和監督得到更好的服務連接設備和路由數據。由於配置設備連接性更復雜，因此最好在服務器上扇出。現在你最好的選擇是讓消費者爲每個存儲寫入的Pub/Sub系統。如果你想分離消費者，你可以爲每個存儲擁有多個消費者，但你需要「丟棄」不需要的消息。 Dataflow可用於此Apache Beam I/O Transforms。

來源

2017-08-02 16:00:04

IoT Core處於私人測試版，我在一個月前註冊嘗試使用它。當你說「最好在服務器上展開扇形」時，你的意思是讓PubSub通過將多個主題扇出到多個訂閱來執行扇出？ – gunit

Public Beta即將推出。我想（如果我錯了，Emilio可以報出來），他正在談論讓Dataflow成爲粉絲。因此，所有設備都寫入相同的發佈/訂閱主題，然後Dataflow根據數據進行解析和抓取。例如，您可以爲有效負載添加一個「類型」鍵。Dataflow可以解析和管理委託給適當的數據庫。與管理多個主題或訂閱相比，系統可能不太重要。 – GabeWeiss

攝入系統應該在哪裏出現？

回答

相關問題