Lý lịch
Tôi có một mạng lưới khoảng 2000 cảm biến, mỗi cảm biến có khoảng 100 điểm dữ liệu mà chúng tôi thu thập trong khoảng thời gian 10 phút. Các điểm dữ liệu này thường là giá trị int, nhưng một số là chuỗi và float. Dữ liệu này nên được lưu trữ trong 90 ngày, nhiều hơn nếu có thể và vẫn hiệu quả.
Thiết kế cơ sở dữ liệu
Khi ban đầu được giao nhiệm vụ với dự án này, tôi đã viết một ứng dụng C # viết các tệp được phân tách bằng dấu phẩy cho mỗi cảm biến. Vào thời điểm đó không có nhiều, khi ai đó muốn xem xét các xu hướng, chúng tôi sẽ mở csv trong Excel và vẽ biểu đồ khi cần thiết.
Mọi thứ phát triển và chúng tôi chuyển sang cơ sở dữ liệu MySQL. Tôi đã tạo một bảng cho mỗi cảm biến (vâng tôi biết, rất nhiều bảng!); nó đã hoạt động tốt, nhưng nó có một số hạn chế. Với rất nhiều bảng, rõ ràng không thể viết một truy vấn sẽ tìm thấy dữ liệu trong số tất cả các cảm biến khi tìm kiếm một giá trị cụ thể.
Đối với phiên bản tiếp theo, tôi chuyển sang Microsoft SQL Server Express và đặt tất cả dữ liệu cảm biến vào một bảng lớn. Điều này cũng hoạt động và cho phép chúng tôi thực hiện các truy vấn để tìm giá trị trong số tất cả các cảm biến được quan tâm. Tuy nhiên, tôi đã chạy vào giới hạn 10 GB cho phiên bản Express và đã quyết định chuyển trở lại MySQL thay vì đầu tư vào SQL Server Standard.
Câu hỏi
Tôi hài lòng với hiệu suất và khả năng mở rộng của MySQL, nhưng không chắc chắn nếu tuân theo cách tiếp cận tất cả dữ liệu trong một bảng là tốt nhất. 10GB trong một bảng dường như đang yêu cầu một thiết kế khác. Tôi nên đề cập rằng nhu cầu truy vấn dữ liệu để vẽ đồ thị vẫn còn đó và tôi lo ngại rằng sẽ có vấn đề về hiệu năng đối với truy vấn mà đồ thị, ví dụ, dữ liệu nhiệt độ cho một cảm biến trong 90 ngày. (Nói cách khác, biểu đồ phải là thứ gì đó được sản xuất nhanh chóng, không cần chờ SQL sắp xếp qua hàng đống dữ liệu chỉ để cách ly cảm biến quan tâm.)
Tôi có nên chia bảng này theo một cách nào đó để tăng hiệu suất? Hoặc không phải là bất thường khi có một bàn lớn như vậy?
Tôi có các chỉ mục trên các cột Cảm biến và Dấu thời gian, đây là ranh giới xác định cho bất kỳ truy vấn nào. (tức là lấy dữ liệu cho cảm biến X từ thời điểm A đến thời điểm B).
Tôi đã đọc một chút về shending và phân vùng, nhưng không cảm thấy những điều đó là phù hợp trong trường hợp này.
Biên tập:
Dựa trên các nhận xét và câu trả lời cho đến nay, một số thông tin bổ sung có thể hữu ích:
Không lưu trữ không xác định: Hiện tại tôi không lưu trữ dữ liệu trong 90 ngày qua. Hàng ngày, tôi chạy một truy vấn loại bỏ dữ liệu cũ hơn 90 ngày. Nếu nó trở nên quan trọng trong tương lai, tôi sẽ lưu trữ nhiều hơn, nhưng bây giờ nó là đủ. Điều này giúp giữ kích thước trong kiểm tra và hiệu suất cao (er).
Loại động cơ: Việc triển khai MySQL ban đầu đã sử dụng MyISAM. Khi tạo các bảng lần này để triển khai mới (một bảng dữ liệu thay vì nhiều bảng), chúng đã được mặc định là InnoDB. Tôi không tin rằng tôi có một yêu cầu cho cái này hay cái khác.
Chuẩn hóa: Tất nhiên có các bảng khác ngoài bảng thu thập dữ liệu. Các bảng hỗ trợ này lưu trữ những thứ như thông tin mạng cho các cảm biến, thông tin đăng nhập cho người dùng, v.v. Không có gì nhiều để bình thường hóa (theo như tôi biết). Lý do bảng dữ liệu có rất nhiều cột là có nhiều biến từ mỗi cảm biến. (Nhiều nhiệt độ, mức ánh sáng, áp suất không khí, v.v.) Bình thường hóa với tôi có nghĩa là không có dữ liệu dư thừa hoặc các nhóm lặp lại. (Ít nhất là cho 1NF.) Đối với một cảm biến nhất định, việc lưu trữ tất cả các giá trị tại một thời điểm cụ thể yêu cầu một hàng dữ liệu và không có mối quan hệ 1: N nào liên quan ở đó (mà tôi thấy).
Tôi có thể tách bảng theo chức năng, tạo (ví dụ) tất cả các giá trị liên quan đến nhiệt độ trong một bảng và tất cả các giá trị liên quan đến áp suất không khí trong một bảng khác. Mặc dù điều này có thể cải thiện hiệu quả cho ai đó thực hiện truy vấn chỉ có nhiệt độ, tôi vẫn phải chèn tất cả dữ liệu cùng một lúc. Tuy nhiên, mức tăng hiệu quả có thể đáng giá cho các hoạt động CHỌN. Rõ ràng tôi sẽ tốt hơn khi tách bảng theo chiều dọc dựa trên tần suất người dùng yêu cầu dữ liệu. Có lẽ đây là tất cả những gì tôi nên làm. Tôi cho rằng khi đặt câu hỏi của tôi, tôi đang tìm kiếm xác nhận rằng làm điều này sẽ có giá trị.
Chỉnh sửa 2:
Sử dụng dữ liệu: Cuối cùng, phần lớn dữ liệu không bao giờ được xem xét hoặc cần thiết, bởi vì chúng tôi thường chỉ tập trung vào các mục có vấn đề. Nhưng trong nỗ lực tìm kiếm các vấn đề, chúng tôi sử dụng các công cụ khác nhau để tìm kiếm dữ liệu và xác định mục nào để phóng to.
Ví dụ: chúng tôi nhận thấy mối tương quan giữa giá trị sử dụng bộ nhớ (chương trình phần mềm độc quyền dành riêng cho khách hàng) và khởi động lại / sự cố. Một trong những điểm dữ liệu tôi thu thập liên quan đến việc sử dụng bộ nhớ này và tôi có thể xem dữ liệu lịch sử để cho thấy các thiết bị trở nên không ổn định sau khi vượt quá mức sử dụng bộ nhớ cụ thể. Hôm nay, đối với tập hợp con của các thiết bị chạy phần mềm này, tôi kiểm tra giá trị này và đưa ra lệnh khởi động lại nếu nó quá cao. Cho đến khi điều này được phát hiện, tôi không nghĩ việc thu thập dữ liệu này có giá trị.
Vì lý do này, tôi đã duy trì rằng khoảng 100 điểm dữ liệu được thu thập và lưu trữ, ngay cả khi giá trị có thể nghi ngờ. Nhưng trong việc sử dụng hàng ngày thông thường, người dùng thường kiểm tra có lẽ hàng tá các thông số này. Nếu người dùng quan tâm đến một khu vực địa lý cụ thể, anh ta có thể (sử dụng phần mềm) tạo biểu đồ hoặc bảng tính dữ liệu cho khoảng vài chục cảm biến. Không có gì lạ khi nhìn vào biểu đồ 30 ngày với hai hoặc ba đường kẻ ô hiển thị những thứ như nhiệt độ, áp suất không khí và mức độ ánh sáng. Làm điều này sẽ chạy một truy vấn tương tự như sau:
SELECT sensor_id, location, data_timestamp, temp1, air1, light1
FROM data
WHERE data_timestamp >= '2012-02-01'
AND sensor_id IN (1, 2, 3);(Trong phiên bản MySQL gốc, trong đó mỗi cảm biến có bảng riêng, ba truy vấn riêng sẽ được đưa ra, nhưng kết quả được kết hợp trong phần mềm để tạo biểu đồ.)
Bởi vì databảng chứa rất nhiều hàng (~ 10 triệu), mặc dù có các chỉ số trên idvà data_timestamp, hiệu suất kém hơn đáng kể so với kịch bản nhiều bảng (4500 hàng được trả về trong 9 giây so với chưa đến một giây với ví dụ này). Khả năng tìm cảm biến nào đáp ứng các tiêu chí nhất định thực tế bằng không trong lược đồ nhiều bảng và do đó, lý do để chuyển sang một bảng duy nhất.
Loại truy vấn này có thể được thực hiện bởi nhiều người dùng liên tiếp khi họ chọn các nhóm dữ liệu khác nhau và so sánh các biểu đồ từ mỗi kết quả. Có thể khá bực bội khi chờ gần 10 giây cho mỗi biểu đồ hoặc bảng tính.
Dữ liệu bị loại bỏ sau 90 ngày. Nó có thể được lưu trữ nhưng hiện tại nó không phải là một yêu cầu.
Hy vọng thông tin này sẽ giúp hiển thị đầy đủ hơn cách thức dữ liệu được sử dụng sau khi thu thập và lưu trữ.