主持人 > 博客 > 管理 > 使用 InfluxDB 時的憤怒、討價還價和抑鬱

使用 InfluxDB 時的憤怒、討價還價和抑鬱

使用 InfluxDB 時的憤怒、討價還價和抑鬱

如果您使用時間序列資料庫（timeseries db， 維基）作為具有統計數據的網站的主要存儲，那麼您可能會遇到很多麻煩，而不是解決問題。 我正在做一個使用這樣的資料庫的項目，有時將要討論的 InfluxDB 會帶來完全意想不到的驚喜。

免責聲明：列出的問題適用於 InfluxDB 版本 1.7.4。

為什麼是時間序列？

該項目旨在追蹤各種區塊鏈上的交易並顯示統計數據。 具體來說，我們來看看穩定幣的發行和燃燒（維基）。 基於這些交易，您需要建立圖表並顯示總計表。

在分析交易時，產生了一個想法：使用InfluxDB時序資料庫作為主儲存。 交易是時間點，它們非常適合時間序列模型。

聚合函數看起來也非常方便 - 非常適合處理長期圖表。 使用者需要一年的圖表，資料庫包含時間範圍為五分鐘的資料集。 向他發送全部十萬個點是沒有意義的——除了長時間的處理之外，它們甚至無法顯示在屏幕上。 您可以編寫自己的增加時間範圍的實現，或使用 Influx 中內建的聚合函數。 在他們的幫助下，您可以按天對資料進行分組並發送所需的 365 個點。

令人有點困惑的是，此類資料庫通常用於收集指標。 監控伺服器、物聯網設備以及數以百萬計的點「流動」的一切：[<時間> - <指標值>]。 但是，如果資料庫在大數據流下運作良好，那麼為什麼小數據流會導致問題呢？ 考慮到這一點，我們使用 InfluxDB 來工作。

InfluxDB還有什麼方便的地方

除了上面提到的聚合函數之外，還有一個很棒的東西 - 連續查詢 (DOC）。 這是內建於資料庫中的調度程序，可以按計劃處理資料。 例如，每 24 小時您可以將當天的所有記錄分組，計算平均值並在另一個表中記錄一個新點，而無需編寫自己的自行車。

也有 保留政策 (DOC)—設定一定時間後刪除資料。 例如，當您需要儲存一周的 CPU 負載並每秒測量一次，但在幾個月的距離內不需要這種精度時，它非常有用。 在這種情況下，您可以這樣做：

  1. 建立連續查詢以將資料聚合到另一個表中；
  2. 對於第一個表，定義刪除早於同一周的指標的策略。

而Influx會獨立減少資料的大小，刪除不必要的東西。

關於儲存的數據

儲存的資料不多：大約 70 萬筆交易和另外 3000 萬個帶有市場資訊的點。 新增條目 - 每天不超過 XNUMX 點。 該網站也有一些指標，但那裡的數據很少，而且根據保留政策，它們的儲存時間不超過一個月。

問題

在服務的開發和後續測試過程中，InfluxDB的運作出現了越來越多的關鍵問題。

1. 刪除數據

有一系列的交易數據：

SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'

其結果是：

使用 InfluxDB 時的憤怒、討價還價和抑鬱

我正在發送刪除資料的命令：

DELETE FROM transactions WHERE symbol=’USDT’

接下來我請求接收已刪除的資料。 Influx 傳回的不是空響應，而是應刪除的部分資料。

我正在嘗試刪除整個表：

DROP MEASUREMENT transactions

我檢查表刪除：

SHOW MEASUREMENTS

我在清單中沒有看到該表，但新的資料查詢仍然傳回相同的事務集。

這個問題只出現在我身上一次，因為刪除案例是一個孤立的案例。 但資料庫的這種行為顯然不符合「正確」操作的框架。 後來發現github上開放了 票 大約一年前關於這個話題。

因此，刪除然後恢復整個資料庫會有所幫助。

2. 浮點數

在 InfluxDB 中使用內建函數時的數學計算存在精度錯誤。 這並不是什麼不尋常的事情，但它是令人不愉快的。

就我而言，數據包含財務成分，我希望對其進行高精度處理。 因此，我們計劃放棄連續查詢。

3.連續查詢無法適配不同時區

該服務有一個包含每日交易統計數據的表。 對於每一天，您需要將當天的所有交易分組。 但每個用戶的一天將在不同的時間開始，因此交易集也會不同。 按 UTC 時間 是 37種變體 您需要匯總資料的班次。

在 InfluxDB 中，按時間分組時，您也可以指定班次，例如莫斯科時間 (UTC+3)：

SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)

但查詢結果會不正確。 由於某種原因，按天分組的數據會追溯到1677年（InfluxDB官方支持從今年開始的時間跨度）：

使用 InfluxDB 時的憤怒、討價還價和抑鬱

為了解決這個問題，我們暫時將服務切換到 UTC+0。

4. 性能

網路上有許多比較 InfluxDB 和其他資料庫的基準測試。 乍一看，它們看起來像是行銷材料，但現在我認為其中有一些道理。

我來告訴你我的情況。

該服務提供了一個 API 方法來傳回最後一天的統計資料。 執行計算時，此方法使用下列查詢查詢資料庫 XNUMX 次：

SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1

SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1

SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESC

解釋：

  1. 在第一個請求中，我們透過市場數據獲取每種代幣的最後分數。 就我而言，八個硬幣可以得到八個積分。
  2. 第二個請求獲取最新點之一。
  3. 第三個請求請求過去 XNUMX 小時內的交易清單；可能有數百個。

讓我澄清一下，InfluxDB會根據標籤和時間自動建立索引，從而加快查詢速度。 在第一個請求中 符號 是一個標籤。

我已經對此 API 方法進行了壓力測試。 對於 25 RPS，伺服器展示了 XNUMX 個 CPU 的滿載：

使用 InfluxDB 時的憤怒、討價還價和抑鬱

同時，NodeJs進程根本不提供任何負載。

執行速度已經下降了 7-10 RPS：如果一個客戶端可以在 200 毫秒內收到回應，那麼 10 個客戶端就必須等待一秒鐘。 25 RPS 是穩定性受到影響的極限；向客戶端回傳了 500 個錯誤。

有了這樣的效能，不可能在我們的專案中使用 Influx。 而且：在一個需要向很多客戶端示範監控的專案中，可能會出現類似的問題，而且指標伺服器會過載。

產量

從所獲得的經驗中得出的最重要的結論是，如果沒有充分的分析，就不能將未知的技術應用到專案中。 對 github 上的未解決問題進行簡單篩選可以提供信息，以避免選擇 InfluxDB 作為主要數據存儲。

InfluxDB 本來應該很適合我的專案的任務，但實踐表明，這個資料庫並不能滿足需求，而且有很多 bug。

您已經可以在專案儲存庫中找到版本 2.0.0-beta；我們只能希望第二個版本能夠有重大改進。 同時，我將去研究 TimescaleDB 文件。

來源： www.habr.com

添加評論