Tôi đang tạo một hệ thống thăm dò các thiết bị để lấy dữ liệu về các số liệu khác nhau, chẳng hạn như mức độ sử dụng CPU, mức độ sử dụng đĩa, nhiệt độ, v.v. (có thể) trong khoảng thời gian 5 phút sử dụng SNMP. Mục tiêu cuối cùng là cung cấp trực quan cho người dùng hệ thống dưới dạng biểu đồ chuỗi thời gian.

Tôi đã xem xét việc sử dụng RRDTool trong quá khứ, nhưng từ chối nó vì việc lưu trữ dữ liệu bị bắt vô thời hạn rất quan trọng đối với dự án của tôi và tôi muốn truy cập cao hơn và linh hoạt hơn vào dữ liệu đã chụp. Vì vậy, câu hỏi của tôi là thực sự:

Điều gì là tốt hơn, một cơ sở dữ liệu quan hệ (như MySQL hoặc PostgreSQL) hoặc cơ sở dữ liệu không liên quan hoặc NoQuery (như MongoDB hoặc Redis) liên quan đến hiệu suất khi truy vấn dữ liệu để lập biểu đồ.

Quan hệ

Đưa ra một cơ sở dữ liệu quan hệ, tôi sẽ sử dụng một data_instancesbảng, trong đó sẽ được lưu trữ mọi trường hợp dữ liệu được ghi lại cho mỗi số liệu được đo cho tất cả các thiết bị, với các trường sau:

Lĩnh vực: id fk_to_device fk_to_metric metric_value timestamp

Khi tôi muốn vẽ biểu đồ cho một số liệu cụ thể trên một thiết bị cụ thể, tôi phải truy vấn bảng số ít này để lọc các thiết bị khác và các số liệu khác được phân tích cho thiết bị này:

SELECT metric_value, timestamp FROM data_instances
    WHERE fk_to_device=1 AND fk_to_metric=2

Số lượng hàng trong bảng này sẽ là:

d * m_d * f * t

trong đó dsố lượng thiết bị , m_dlà số liệu tích lũy được ghi lại cho tất cả các thiết bị, flà tần suất mà dữ liệu được thăm dò và tlà tổng thời gian hệ thống thu thập dữ liệu.

Đối với người dùng ghi 10 số liệu cho 3 thiết bị cứ sau 5 phút trong một năm, chúng tôi sẽ chỉ có dưới 5 triệu hồ sơ.

Chỉ mục

Không có chỉ mục trên fk_to_devicevà fk_to_metricquét bảng mở rộng liên tục này sẽ mất quá nhiều thời gian. Vì vậy, lập chỉ mục các trường đã nói ở trên và cũng timestamp(để tạo biểu đồ với các khoảng thời gian được bản địa hóa) là một yêu cầu.

Không liên quan (NoQuery)

MongoDB có khái niệm về một bộ sưu tập , không giống như các bảng, chúng có thể được tạo lập trình mà không cần thiết lập. Với những điều này, tôi có thể phân vùng lưu trữ dữ liệu cho từng thiết bị hoặc thậm chí từng số liệu được ghi lại cho từng thiết bị.

Tôi không có kinh nghiệm với NoQuery và không biết liệu họ có cung cấp bất kỳ tính năng nâng cao hiệu suất truy vấn nào không, chẳng hạn như lập chỉ mục, tuy nhiên đoạn trước đề xuất thực hiện hầu hết các truy vấn quan hệ truyền thống trong cấu trúc mà dữ liệu được lưu trữ trong NoQuery.

Chưa quyết định

Một giải pháp quan hệ với việc lập chỉ mục chính xác sẽ giảm xuống một lần thu thập thông tin trong năm? Hoặc cấu trúc dựa trên bộ sưu tập của các cách tiếp cận NoQuery (phù hợp với mô hình tinh thần của dữ liệu được lưu trữ) mang lại lợi ích đáng chú ý?

Chắc chắn là quan hệ. Không giới hạn linh hoạt và mở rộng.

Hai điều chỉnh, cả về khái niệm và ứng dụng, tiếp theo là độ cao.

Điều chỉnh

1. Nó không phải là "lọc ra dữ liệu không cần thiết"; nó chỉ chọn dữ liệu cần thiết. Tất nhiên, có, nếu bạn có một Chỉ số để hỗ trợ các cột được xác định trong mệnh đề WHERE, thì nó rất nhanh và truy vấn không phụ thuộc vào kích thước của bảng (lấy 1.000 hàng từ bảng 16 tỷ hàng là tức thời) .

2. Bảng của bạn có một trở ngại nghiêm trọng. Theo mô tả của bạn, PK thực tế là (Thiết bị, Số liệu, DateTime). (Vui lòng không gọi nó là TimeStamp, có nghĩa là một cái gì đó khác, nhưng đó là một vấn đề nhỏ.) Tính duy nhất của hàng được xác định bởi:

      (Device, Metric, DateTime)
   

   • Các Idcột không có gì, nó là hoàn toàn và hoàn toàn không cần thiết.

     • Một Idcột không bao giờ là Khóa (các hàng trùng lặp, bị cấm trong cơ sở dữ liệu quan hệ, phải được ngăn chặn bằng các phương tiện khác).

     • Các Idcột đòi hỏi một Index bổ sung, mà rõ ràng là cản trở tốc độ của INSERT/DELETE, và thêm vào không gian đĩa được sử dụng.

     • Bạn có thể thoát khỏi nó. Xin vui lòng.

Độ cao

1. Bây giờ bạn đã loại bỏ trở ngại, bạn có thể không nhận ra nó, nhưng bảng của bạn ở dạng thứ sáu thông thường. Tốc độ rất cao, chỉ với một Chỉ số trên PK. Để hiểu, hãy đọc câu trả lời này từ Mẫu thứ sáu thông thường là gì? hướng trở đi.

   • (Tôi chỉ có một chỉ mục, không phải ba; trên Non-SQL, bạn có thể cần ba chỉ mục).

   • Tôi có cùng một bảng chính xác (tất nhiên không có Id"khóa"). Tôi có một cột bổ sung Server. Tôi hỗ trợ nhiều khách hàng từ xa.

     (Server, Device, Metric, DateTime)

   Bảng có thể được sử dụng để Xoay dữ liệu (nghĩa là Devicestrên đầu và Metricsbên dưới hoặc xoay vòng) bằng cách sử dụng chính xác cùng một mã SQL (có, chuyển đổi các ô). Tôi sử dụng bảng để dựng lên một loạt các biểu đồ và biểu đồ không giới hạn cho khách hàng về hiệu suất máy chủ của họ.

   • Giám sát mô hình dữ liệu thống kê .
     (Quá lớn cho nội tuyến; một số trình duyệt không thể tải nội tuyến; nhấp vào liên kết. Ngoài ra, đó là phiên bản demo lỗi thời, vì lý do rõ ràng, tôi không thể hiển thị cho bạn DM sản phẩm thương mại.)

   • Nó cho phép tôi tạo Biểu đồ như thế này , sáu lần nhấn phím sau khi nhận được tệp thống kê giám sát thô từ khách hàng, bằng cách sử dụng một lệnh CHỌN duy nhất . Chú ý kết hợp và kết hợp; Hệ điều hành và máy chủ trên cùng một biểu đồ; nhiều loại Pivots. Tất nhiên, không có giới hạn về số lượng ma trận thống kê, và do đó là các biểu đồ. (Được sử dụng với sự cho phép của khách hàng.)

   • Những độc giả không quen thuộc với Tiêu chuẩn mô hình hóa cơ sở dữ liệu quan hệ có thể thấy Ký hiệu IDEF1X hữu ích.

Một điều nữa

Cuối cùng nhưng không kém phần quan trọng, SQL là một tiêu chuẩn IEC / ISO / ANSI. Phần mềm miễn phí thực sự là Non-SQL; sử dụng thuật ngữ SQL là gian lận nếu họ không cung cấp Tiêu chuẩn. Họ có thể cung cấp "tính năng bổ sung", nhưng họ không có những điều cơ bản.

Tìm thấy rất thú vị các câu trả lời trên. Cố gắng thêm một vài cân nhắc ở đây.

1) lão hóa dữ liệu

Quản lý chuỗi thời gian thường cần tạo ra các chính sách lão hóa. Một kịch bản điển hình (ví dụ: CPU máy chủ giám sát) yêu cầu lưu trữ:

• Mẫu thô 1 giây trong một thời gian ngắn (ví dụ: trong 24 giờ)

• Mẫu tổng hợp chi tiết 5 phút trong một khoảng thời gian trung bình (ví dụ: 1 tuần)

• Chi tiết 1 giờ trong đó (ví dụ lên đến 1 năm)

Mặc dù các mô hình quan hệ có thể chắc chắn (công ty của tôi đã triển khai cơ sở dữ liệu tập trung lớn cho một số khách hàng lớn với hàng chục nghìn chuỗi dữ liệu) để quản lý nó một cách thích hợp, nhưng các cửa hàng dữ liệu mới bổ sung các chức năng thú vị sẽ được khám phá như:

• thanh lọc dữ liệu tự động (xem lệnh EXPIRE của Redis)

• tập hợp đa chiều (ví dụ: việc làm giảm bản đồ a-la-Splunk)

2) Bộ sưu tập thời gian thực

Thậm chí quan trọng hơn, một số kho lưu trữ dữ liệu không liên quan vốn đã được phân phối và cho phép thu thập dữ liệu thời gian thực (hoặc gần thời gian thực) hiệu quả hơn có thể là một vấn đề với RDBMS do việc tạo các điểm nóng (quản lý lập chỉ mục trong khi chèn vào một bàn duy nhất). Vấn đề này trong không gian RDBMS thường được giải quyết hoàn nguyên cho các thủ tục nhập hàng loạt (chúng tôi đã quản lý theo cách này trong quá khứ) trong khi các công nghệ không sql đã thành công trong việc thu thập và tổng hợp thời gian thực lớn (ví dụ như Splunk, đã đề cập trong các câu trả lời trước) .

Bảng của bạn có dữ liệu trong bảng duy nhất. Vì vậy, quan hệ vs không quan hệ không phải là câu hỏi. Về cơ bản bạn cần đọc rất nhiều dữ liệu tuần tự. Bây giờ nếu bạn có đủ RAM để lưu trữ dữ liệu trị giá một năm thì không có gì bằng sử dụng Redis / MongoDB, v.v.

Hầu hết các cơ sở dữ liệu NoQuery sẽ lưu trữ dữ liệu của bạn trên cùng một vị trí trên đĩa và ở dạng nén để tránh truy cập nhiều đĩa.

NoQuery thực hiện tương tự như việc tạo chỉ mục trên id thiết bị và id số liệu, nhưng theo cách riêng của nó. Với cơ sở dữ liệu ngay cả khi bạn làm điều này, chỉ mục và dữ liệu có thể ở những nơi khác nhau và sẽ có rất nhiều IO đĩa.

Các công cụ như Splunk đang sử dụng phụ trợ NoQuery để lưu trữ dữ liệu chuỗi thời gian và sau đó sử dụng bản đồ thu nhỏ để tạo tập hợp (có thể là những gì bạn muốn sau này). Vì vậy, theo tôi, sử dụng NoQuery là một tùy chọn vì mọi người đã thử nó cho các trường hợp sử dụng tương tự. Nhưng một triệu hàng sẽ mang cơ sở dữ liệu đến thu thập dữ liệu (có thể không, với phần cứng phù hợp và cấu hình phù hợp).

Tạo một tệp, đặt tên là 1_2.data. ý tưởng mệt mỏi? những gì bạn nhận được:

• Bạn tiết kiệm tới 50% dung lượng vì bạn không cần lặp lại giá trị fk_to_device và fk_to_metric cho mỗi điểm dữ liệu.
• Bạn tiết kiệm được nhiều không gian hơn vì bạn không cần bất kỳ chỉ số nào.
• Lưu các cặp (dấu thời gian, số liệu) vào tệp bằng cách nối thêm dữ liệu để bạn nhận được đơn đặt hàng theo dấu thời gian miễn phí. (giả sử rằng các nguồn của bạn không gửi dữ liệu đặt hàng cho một thiết bị)

=> Truy vấn theo dấu thời gian chạy nhanh đáng kinh ngạc vì bạn có thể sử dụng tìm kiếm nhị phân để tìm đúng vị trí trong tệp để đọc.

nếu bạn thích nó thậm chí còn được tối ưu hóa hơn nữa hãy bắt đầu nghĩ đến việc chia nhỏ các tệp của bạn như thế;

• 1_2_jan nóng2014.data
• 1_2_f / 22014.data
• 1_2_march2014.data

hoặc sử dụng kdb + từ http://kx.com vì họ làm tất cả điều này cho bạn :) định hướng theo cột là những gì có thể giúp bạn.

Có một giải pháp định hướng cột dựa trên đám mây xuất hiện, vì vậy bạn có thể muốn xem qua: http://timeseries.guru

Nếu bạn đang xem các gói GPL, RRDTool là một sản phẩm tốt để xem xét. Nó là một công cụ tốt để lưu trữ, trích xuất và vẽ đồ thị dữ liệu chuỗi thời gian. Ca sử dụng của bạn trông giống hệt như dữ liệu chuỗi thời gian.

Đây là vấn đề chúng tôi phải giải quyết tại ApiAxle. Chúng tôi đã viết một bài đăng trên blog về cách chúng tôi đã làm nó bằng Redis. Nó đã không ở ngoài đó rất lâu nhưng nó đã được chứng minh là có hiệu quả.

Tôi cũng đã sử dụng RRDTool cho một dự án khác rất tuyệt vời.

Tôi nghĩ rằng câu trả lời cho loại câu hỏi này chủ yếu nên xoay quanh cách thức Cơ sở dữ liệu của bạn sử dụng lưu trữ. Một số máy chủ Cơ sở dữ liệu sử dụng RAM và Đĩa, một số chỉ sử dụng RAM (tùy chọn Ổ đĩa để duy trì), v.v. Các giải pháp Cơ sở dữ liệu SQL phổ biến nhất là sử dụng bộ nhớ + lưu trữ đĩa và ghi dữ liệu theo bố cục Hàng (mọi dữ liệu được chèn đều được ghi giống nhau vị trí vật lý). Đối với các cửa hàng thời gian, trong hầu hết các trường hợp, khối lượng công việc là như sau: Khoảng thời gian chèn khối lượng tương đối thấp, trong khi các lần đọc là dựa trên cột (trong hầu hết các trường hợp bạn muốn đọc một phạm vi dữ liệu từ một cột cụ thể, đại diện cho một số liệu)

Tôi đã tìm thấy Cơ sở dữ liệu Cột (google nó, bạn sẽ thấy MonetDB, InfoBright, parAccel, v.v.) đang làm công việc tuyệt vời cho chuỗi thời gian.

Đối với câu hỏi của bạn, cá nhân tôi nghĩ là hơi không hợp lệ (vì tất cả các cuộc thảo luận sử dụng thuật ngữ lỗi NoQuery - IMO): Bạn có thể sử dụng máy chủ Cơ sở dữ liệu có thể nói chuyện SQL một mặt, giúp mọi người biết về SQL rất dễ dàng năm và ngôn ngữ này đã được hoàn thiện nhiều lần cho các truy vấn dữ liệu; nhưng vẫn sử dụng RAM, bộ nhớ cache CPU và đĩa theo cách định hướng theo cột, giúp giải pháp của bạn phù hợp nhất với Chuỗi thời gian

5 triệu hàng không là gì đối với dữ liệu xối xả ngày nay. Dự kiến ​​dữ liệu sẽ ở trong TB hoặc PB chỉ trong vài tháng. Tại thời điểm này RDBMS không mở rộng theo nhiệm vụ và chúng ta cần khả năng mở rộng tuyến tính của cơ sở dữ liệu NoSql. Hiệu suất sẽ đạt được cho phân vùng cột được sử dụng để lưu trữ dữ liệu, thêm nhiều cột và loại khái niệm ít hàng hơn để tăng hiệu suất. Tận dụng công việc TSDB mở được thực hiện trên HBASE hoặc MapR_DB, v.v.

Tôi phải đối mặt với các yêu cầu tương tự thường xuyên và gần đây đã bắt đầu sử dụng Zabbix để thu thập và lưu trữ loại dữ liệu này. Zabbix có khả năng vẽ đồ thị riêng, nhưng đủ dễ dàng để trích xuất dữ liệu ra khỏi cơ sở dữ liệu của Zabbix và xử lý dữ liệu theo cách bạn muốn. Nếu bạn chưa kiểm tra Zabbix, bạn có thể thấy xứng đáng với thời gian của mình để làm điều đó.

Bạn nên xem xét cơ sở dữ liệu chuỗi thời gian . Nó được tạo ra cho mục đích này.

Cơ sở dữ liệu chuỗi thời gian (TSDB) là một hệ thống phần mềm được tối ưu hóa để xử lý dữ liệu chuỗi thời gian, các mảng số được lập chỉ mục theo thời gian (datetime hoặc phạm vi datetime).

Ví dụ phổ biến về cơ sở dữ liệu chuỗi thời gian InfluxDB