Nếu bạn sử dụng cơ sở dữ liệu chuỗi thời gian (timeseries db, ) làm nơi lưu trữ chính cho một trang web có số liệu thống kê, thì thay vì giải quyết vấn đề, bạn có thể phải đau đầu rất nhiều. Tôi đang làm việc trong một dự án sử dụng cơ sở dữ liệu như vậy và đôi khi InfluxDB, sẽ được thảo luận, đưa ra những điều hoàn toàn bất ngờ.
Từ chối trách nhiệm: Các vấn đề được liệt kê áp dụng cho InfluxDB phiên bản 1.7.4.
Tại sao chuỗi thời gian?
Dự án nhằm theo dõi các giao dịch trên các chuỗi khối khác nhau và hiển thị số liệu thống kê. Cụ thể, chúng tôi xem xét việc phát hành và đốt các đồng tiền ổn định (). Dựa trên các giao dịch này, bạn cần xây dựng biểu đồ và hiển thị bảng tóm tắt.
Trong khi phân tích các giao dịch, một ý tưởng đã nảy ra: sử dụng cơ sở dữ liệu chuỗi thời gian InfluxDB làm bộ lưu trữ chính. Giao dịch là các thời điểm và chúng rất phù hợp với mô hình chuỗi thời gian.
Các chức năng tổng hợp cũng trông rất tiện lợi - lý tưởng để xử lý các biểu đồ có thời gian dài. Người dùng cần có biểu đồ cho một năm và cơ sở dữ liệu chứa tập dữ liệu có khung thời gian là năm phút. Thật vô nghĩa khi gửi cho anh ấy tất cả một trăm nghìn điểm - ngoài việc xử lý lâu, chúng thậm chí sẽ không vừa với màn hình. Bạn có thể viết cách triển khai tăng khung thời gian của riêng mình hoặc sử dụng các hàm tổng hợp được tích hợp trong Influx. Với sự trợ giúp của họ, bạn có thể nhóm dữ liệu theo ngày và gửi 365 điểm cần thiết.
Có một chút khó hiểu là những cơ sở dữ liệu như vậy thường được sử dụng cho mục đích thu thập số liệu. Giám sát máy chủ, thiết bị iot, mọi thứ mà từ đó hàng triệu điểm có dạng “dòng chảy”: [<thời gian> - <giá trị số liệu>]. Nhưng nếu cơ sở dữ liệu hoạt động tốt với luồng dữ liệu lớn thì tại sao khối lượng nhỏ lại gây ra vấn đề? Với suy nghĩ này, chúng tôi đã đưa InfluxDB vào hoạt động.
Còn gì thuận tiện hơn trong InfluxDB
Ngoài các chức năng tổng hợp đã đề cập, còn có một điều tuyệt vời khác - truy vấn liên tục (). Đây là một bộ lập lịch được tích hợp trong cơ sở dữ liệu có thể xử lý dữ liệu theo lịch trình. Ví dụ: cứ sau 24 giờ, bạn có thể nhóm tất cả các bản ghi trong ngày, tính điểm trung bình và ghi một điểm mới vào một bảng khác mà không cần viết xe đạp của riêng mình.
Cũng có chính sách duy trì ()—thiết lập xóa dữ liệu sau một khoảng thời gian nhất định. Ví dụ: nó rất hữu ích khi bạn cần lưu trữ tải CPU trong một tuần bằng các phép đo mỗi giây một lần, nhưng trong khoảng cách vài tháng thì không cần độ chính xác như vậy. Trong tình huống như vậy, bạn có thể làm điều này:
- tạo một truy vấn liên tục để tổng hợp dữ liệu vào một bảng khác;
- đối với bảng đầu tiên, hãy xác định chính sách xóa các số liệu cũ hơn cùng tuần đó.
Và Influx sẽ giảm kích thước dữ liệu một cách độc lập và xóa những thứ không cần thiết.
Về dữ liệu được lưu trữ
Không có nhiều dữ liệu được lưu trữ: khoảng 70 nghìn giao dịch và một triệu điểm khác chứa thông tin thị trường. Thêm mục mới - không quá 3000 điểm mỗi ngày. Ngoài ra còn có các số liệu cho trang web, nhưng có rất ít dữ liệu ở đó và theo chính sách lưu giữ, chúng được lưu trữ không quá một tháng.
Vấn đề
Trong quá trình phát triển và thử nghiệm dịch vụ sau đó, ngày càng có nhiều vấn đề nghiêm trọng nảy sinh trong hoạt động của InfluxDB.
1. Xóa dữ liệu
Có một chuỗi dữ liệu với các giao dịch:
SELECT time, amount, block, symbol FROM transactions WHERE symbol='USDT'Kết quả:
Tôi đang gửi lệnh xóa dữ liệu:
DELETE FROM transactions WHERE symbol=’USDT’Tiếp theo tôi đưa ra yêu cầu nhận dữ liệu đã bị xóa. Và thay vì phản hồi trống, Influx trả về một phần dữ liệu cần xóa.
Tôi đang cố xóa toàn bộ bảng:
DROP MEASUREMENT transactionsTôi kiểm tra việc xóa bảng:
SHOW MEASUREMENTSTôi không thấy bảng trong danh sách nhưng truy vấn dữ liệu mới vẫn trả về cùng một nhóm giao dịch.
Sự cố chỉ xảy ra với tôi một lần vì trường hợp xóa là trường hợp cá biệt. Nhưng hành vi này của cơ sở dữ liệu rõ ràng không phù hợp với khuôn khổ hoạt động “đúng đắn”. Sau này tôi thấy nó mở trên github gần một năm trước về chủ đề này.
Do đó, việc xóa và sau đó khôi phục toàn bộ cơ sở dữ liệu đã giúp ích.
2. Số dấu phẩy động
Các phép tính toán khi sử dụng các hàm dựng sẵn trong InfluxDB có lỗi về độ chính xác. Không phải điều này có gì bất thường nhưng nó thật khó chịu.
Trong trường hợp của tôi, dữ liệu có thành phần tài chính và tôi muốn xử lý nó với độ chính xác cao. Vì điều này, chúng tôi dự định từ bỏ các truy vấn liên tục.
3. Không thể điều chỉnh các truy vấn liên tục theo các múi giờ khác nhau
Dịch vụ này có một bảng thống kê giao dịch hàng ngày. Đối với mỗi ngày, bạn cần nhóm tất cả các giao dịch trong ngày đó. Nhưng mỗi ngày của người dùng sẽ bắt đầu vào một thời điểm khác nhau và do đó, tập hợp các giao dịch sẽ khác nhau. Theo UTC thì có những ca mà bạn cần tổng hợp dữ liệu.
Trong InfluxDB, khi nhóm theo thời gian, bạn có thể chỉ định thêm một ca, ví dụ: theo giờ Moscow (UTC+3):
SELECT MEAN("supply") FROM transactions GROUP BY symbol, time(1d, 3h) fill(previous)Nhưng kết quả truy vấn sẽ không chính xác. Vì lý do nào đó, dữ liệu được nhóm theo ngày sẽ bắt đầu từ năm 1677 (InfluxDB chính thức hỗ trợ khoảng thời gian kể từ năm nay):
Để khắc phục sự cố này, chúng tôi tạm thời chuyển dịch vụ sang UTC+0.
4. Hiệu suất
Có nhiều điểm chuẩn trên Internet so sánh InfluxDB và các cơ sở dữ liệu khác. Thoạt nhìn, chúng trông giống như tài liệu tiếp thị, nhưng bây giờ tôi nghĩ chúng có phần nào đó đúng.
Tôi sẽ kể cho bạn nghe trường hợp của tôi.
Dịch vụ này cung cấp phương thức API trả về số liệu thống kê cho ngày cuối cùng. Khi thực hiện tính toán, phương thức này sẽ truy vấn cơ sở dữ liệu ba lần với các truy vấn sau:
SELECT * FROM coins_info WHERE time <= NOW() GROUP BY symbol ORDER BY time DESC LIMIT 1SELECT * FROM dominance_info ORDER BY time DESC LIMIT 1SELECT * FROM transactions WHERE time >= NOW() - 24h ORDER BY time DESCGiải trình:
- Trong yêu cầu đầu tiên, chúng tôi nhận được điểm cuối cùng cho mỗi đồng xu cùng với dữ liệu thị trường. Tám điểm cho tám xu trong trường hợp của tôi.
- Yêu cầu thứ hai nhận được một trong những điểm mới nhất.
- Người thứ ba yêu cầu danh sách các giao dịch trong XNUMX giờ qua; có thể có vài trăm giao dịch trong số đó.
Hãy để tôi làm rõ rằng InfluxDB tự động xây dựng chỉ mục dựa trên thẻ và thời gian, giúp tăng tốc độ truy vấn. Trong yêu cầu đầu tiên biểu tượng là một thẻ.
Tôi đã chạy thử nghiệm căng thẳng về phương pháp API này. Đối với 25 RPS, máy chủ đã thể hiện mức tải đầy đủ của sáu CPU:
Đồng thời, quy trình NodeJs hoàn toàn không cung cấp bất kỳ tải nào.
Tốc độ thực thi đã giảm 7-10 RPS: nếu một khách hàng có thể nhận được phản hồi sau 200 mili giây thì 10 khách hàng phải đợi một giây. 25 RPS là giới hạn mà độ ổn định phải chịu; 500 lỗi đã được trả lại cho khách hàng.
Với hiệu suất như vậy thì không thể sử dụng Influx trong dự án của chúng tôi. Hơn nữa: trong một dự án cần thể hiện việc giám sát cho nhiều khách hàng, các vấn đề tương tự có thể xuất hiện và máy chủ số liệu sẽ bị quá tải.
Đầu ra
Kết luận quan trọng nhất từ kinh nghiệm thu được là bạn không thể đưa một công nghệ chưa biết vào dự án nếu không có phân tích đầy đủ. Việc sàng lọc đơn giản các vấn đề mở trên github có thể cung cấp thông tin để tránh chọn InfluxDB làm kho lưu trữ dữ liệu chính.
InfluxDB lẽ ra phải phù hợp với các nhiệm vụ trong dự án của tôi, nhưng thực tế đã cho thấy, cơ sở dữ liệu này không đáp ứng được nhu cầu và có rất nhiều lỗi.
Bạn đã có thể tìm thấy phiên bản 2.0.0-beta trong kho dự án; chúng tôi chỉ có thể hy vọng rằng phiên bản thứ hai sẽ có những cải tiến đáng kể. Trong lúc chờ đợi, tôi sẽ nghiên cứu tài liệu của TimescaleDB.
Nguồn: www.habr.com