Lưu trữ lượng dữ liệu khổng lồ từ một mảng cảm biến


14

Tôi đã được giao nhiệm vụ triển khai một giải pháp (ứng dụng và db) để lưu trữ các mẫu dữ liệu từ một mảng cảm biến khổng lồ. Mảng hiện bao gồm khoảng 20.000 cảm biến, nhưng sẽ sớm phát triển, lên tới 100.000 cảm biến. Mỗi cảm biến gửi một mẫu dữ liệu cứ sau 10 giây và mỗi mẫu có kích thước 28 byte.

Làm các khoản tiền do đó dẫn đến:

  • 8640 mẫu mỗi cảm biến mỗi ngày
  • 242kB dữ liệu mỗi cảm biến mỗi ngày
  • 864 triệu mẫu mỗi ngày

Bây giờ tôi đã tự hỏi cách tốt nhất để lưu trữ / truy xuất dữ liệu là gì? Tôi đã "tham gia" dự án này sau khi phần mềm đã được chỉ định, vì vậy nó cần được triển khai trên Nền tảng Windows bằng SQL Server.

Giải pháp hiện tại trong đầu tôi là tạo một DB với hai bảng để lưu trữ các mẫu dữ liệu. Cái đầu tiên đóng vai trò là một loại chỉ mục thành cái thứ hai lưu trữ các mẫu đối chiếu trong trường nhị phân trên cơ sở mỗi ngày trên mỗi cảm biến:

Table 1:

  RecordID - BigInt - Identity
  SensorID - BigInt - Primary Key
  Date - DateTime - Primary Key (yyyy-mm-dd)

Table 2:

  RecordID - BigInt - Primary Key (from an insert into Table 1)
  Data - Binary 

Về cơ bản tôi sẽ viết các mẫu từ tất cả các cảm biến thành các tệp tạm thời (1 cho mỗi cảm biến). Vào cuối mỗi ngày, sau đó tôi sẽ tạo một mục trong Bảng 1, sử dụng RecordID được tạo và kết xuất tệp vào trường Dữ liệu trong Bảng 2.

Bằng cách này, tôi kết thúc với chỉ 100.000 mục vào bảng mỗi ngày, thay vì 864 triệu mục. Dữ liệu phải có sẵn trên mạng LAN hoặc mạng tốc độ cao, do đó, việc truy xuất dữ liệu cảm biến trên cơ sở cả ngày sẽ được chấp nhận.

Mặc dù tất cả dữ liệu phải được lưu trữ, nhưng hầu hết dữ liệu có thể sẽ không bao giờ được đọc. Vì vậy, số lượng đọc trên (các) bảng sẽ không nhiều hơn so với viết.

Tôi biết rằng tôi có thể thực hiện một cái gì đó bằng cách sử dụng hệ thống tệp bằng cách chỉ lưu trữ đường dẫn đến tệp dữ liệu, nhưng tôi đọc rằng SQL Server vượt trội so với NTFS trong khi các trường nhị phân của bạn ít hơn 256kB. (Một vùng màu xám tồn tại giữa 256kB và 1MB, trong khi NTFS vượt xa SQL Server về kích thước nhị phân> 1 MB).

Tôi cũng hơi cảnh giác khi lưu trữ dữ liệu từ 100.000 cảm biến vào các tệp của riêng mình mà không gây ra sự cố trong hệ thống tệp bằng cách có một lượng lớn tệp trong một thư mục hoặc bằng cách có cấu trúc cây phức tạp với một vài tệp trong mỗi thư mục, trong khi không thậm chí lấy phân mảnh tập tin vào tài khoản.

  1. Bất cứ ai có thể cung cấp cho tôi một số lời khuyên / ý kiến ​​thiết thực ở trên?

  2. Có những cạm bẫy rõ ràng mà tôi sẽ rơi vào?

  3. Dữ liệu mẫu không nén khá độc đáo. Một tệp 242 kB nén xuống khoảng 85kB. Tuy nhiên tôi có thể thực hiện một số loại nén ở cấp cơ sở dữ liệu để dữ liệu mẫu (cột) được nén tự động không?

  4. SQL Server rõ ràng là một lựa chọn sai cho dự án này?

  5. Thiết kế của hai bảng có phải là khôn ngoan không, hay tôi có thể kết hợp nó thành một bảng duy nhất vẫn sẽ là "biểu diễn" như hai bảng không?


5
SQL Server không hỗ trợ nén cấp hàng và cấp bảng cho những thứ như thế này.
JNK

2
Vì chỉ có 1 mục / cảm biến / ngày, bạn có cần Bảng 1 không?
GalacticJello

2
Bạn dự định làm gì với dữ liệu này, một khi nó có trong cơ sở dữ liệu? Tôi không thể tưởng tượng được việc có thể tổng hợp dữ liệu cảm biến ở định dạng nhị phân, ít nhất là không dễ dàng hoặc nhanh chóng ở các cấp độ đó.
datagod

1
100.000 cảm biến X 10 mẫu mỗi giây X 28Bytes mỗi mẫu x 24 giờ mỗi ngày = 2.2TB mỗi ngày. Đó là rất nhiều để đặt vào hai bảng.
datagod

2
@AlexKuznetsov: Tôi đã tự hỏi về sự lựa chọn Máy chủ SQL, nhưng họ là đối tác vàng của Microsoft, vì vậy tôi đoán đó là lý do chính.
Oliver

Câu trả lời:


12

Vâng, có một cạm bẫy khá lớn mà bạn sẽ gặp phải khá nhanh chóng, và đó là với quy mô và bảo trì của các bảng. Bạn đang đi đúng hướng bằng cách nói rằng bạn muốn đưa dữ liệu của mình vào một bảng tạm thời hàng ngày, sau đó di chuyển nó vào bảng cố định của bạn, nhưng bạn sẽ sớm gặp rắc rối với sơ đồ này.

Ví dụ: giả sử bạn muốn "tung ra" giá trị dữ liệu của tháng cũ nhất sau hai năm. Trong thiết kế của bạn, bạn sẽ phải đưa ra một tuyên bố XÓA đối với bảng lớn, lớn của bạn. Điều này có thể sẽ hơi chậm, tùy thuộc vào số lượng chỉ mục bạn có. Ngoài ra, nó sẽ gây ra sự phân mảnh chỉ mục và cách duy nhất để khắc phục đó là xây dựng lại hoặc sắp xếp lại các chỉ mục trên bảng rất lớn này cũng sẽ gây ra vấn đề về hiệu suất. Có một loạt các vấn đề khác với một thiết kế loại bảng lớn. Ví dụ: với một bảng lớn, một bảng, bạn không thể thực hiện sao lưu dựa trên FILEGROUP , điều đó có nghĩa là nếu bạn muốn sao lưu toàn bộ cơ sở dữ liệu của mình, nó sẽ LỚN và sẽ mất nhiều thời gian để hoàn thành.

Giải pháp là gì? Phân vùng bảng. Đọc về điều này sâu, ở càng nhiều nơi càng tốt. Về cơ bản, phân vùng cho phép bạn phân chia dữ liệu của mình thành "các bảng trong bảng" - mỗi phân vùng chia sẻ cùng một lược đồ và được truy cập thông qua đối tượng bảng, nhưng có thể được lập chỉ mục và duy trì khác nhau. Các phân vùng về cơ bản là các bảng, được cắt bởi một số khóa hữu ích. Trong trường hợp của bạn, nó có thể sẽ là ngày. Chúng có thể được loại bỏ giống như các bảng (và nhanh như), điều đó có nghĩa là nếu bạn phân vùng các bảng dữ liệu lớn theo ngày, bạn có thể bỏ các phân vùng cũ ngay lập tức, không ảnh hưởng xấu đến các chỉ mục trên bất kỳ phân vùng nào khác. Bạn có thể đặt các phân vùng trên các nhóm fileg khác nhau, điều đó có nghĩa là các phân vùng cũ hơn có thể được gỡ bỏ hoặc chuyển sang lưu trữ hàng hóa rẻ hơn nếu nó không được sử dụng phổ biến. Cuối cùng nhưng không kém phần quan trọng, trong SQL 2012 bạn 'trên các phân vùng cũ hơn, chỉ đọc của bạn , trong khi có một lược đồ lập chỉ mục hướng chèn khác, nhiều hơn trên phân vùng hoạt động nơi bạn đang chèn tất cả dữ liệu cảm biến của mình.

Hi vọng điêu nay co ich. Bạn có một lượng lớn nghiên cứu để thực hiện liên quan đến các sơ đồ phân vùng và phân vùng, nhưng hy vọng bây giờ bạn biết hướng bạn cần tìm.

PS: Ồ, và tôi đã quên danh sách câu hỏi của bạn ... Trả lời 1, 2 và 5. Xem ở trên. Trả lời 3: Trong SQL Server, bạn có thể nén trên một phân vùng theo cơ sở phân vùng, vì vậy hãy nén mạnh các phân vùng cũ hơn bằng cách sử dụng nén PAGE. Nhưng tôi tin rằng các loại dữ liệu lớn ngoài hàng của bạn sẽ không bị nén nếu bạn làm điều này - một lần nữa, bạn có thể muốn giảm bớt vấn đề này bằng cách bình thường hóa các giá trị cảm biến của bạn. Trả lời 4: Hoàn toàn không, nhưng nếu tất cả những gì bạn muốn làm là lưu trữ dữ liệu tĩnh theo ngày và không bao giờ tìm kiếm trên bất kỳ cách nào khác, các tệp phẳng được nén có thể là một cách dễ dàng hơn nhiều.

PPS: Ồ, và một điều nữa. Bạn không cần giải pháp hai bàn của mình để thực hiện tất cả công việc này. Dữ liệu cảm biến nhị phân lớn phải là loại VARBINARY (MAX) vì các giá trị của nó có thể được lưu trữ " ngoài hàng " nhưng vẫn là một cột trong một bảng duy nhất (xem tài liệu sp_tableoption ). Tuy nhiên, bạn có thể muốn xem xét việc bình thường hóa một số dữ liệu cảm biến của mình khỏi dữ liệu nhị phân bạn có trong bảng vì cơ sở dữ liệu của bạn sẽ không tốt cho việc vượt quá thời gian truy xuất dữ liệu cảm biến nếu bạn không.


Thông tin tuyệt vời, cảm ơn. Tôi không hoàn toàn chắc chắn ý của bạn với "bình thường hóa" trong trường hợp này. Tôi giả sử rằng bạn có nghĩa là tôi nên trích xuất một số trường hữu ích hơn trong các khối dữ liệu và lưu trữ chúng trong các cột riêng của chúng. Nếu vậy, lý do ban đầu tôi không muốn làm điều này là vì điều đó có nghĩa là tôi sẽ kết thúc với 864 triệu hàng mỗi ngày. Đối chiếu mọi thứ và lưu trữ nó trong một khối có nghĩa là chỉ 100.000 hàng mỗi ngày. Đây có phải là cách tốt hơn không ?
Oliver

1
Nếu bạn đang sử dụng một cơ sở dữ liệu, thì đúng, đó chính xác là điều tôi muốn nói. 864 triệu hàng mỗi ngày có thể được xử lý hiệu quả nếu bạn có phần cứng, sơ đồ lập chỉ mục và sơ đồ phân vùng phù hợp để làm cho nó hoạt động. Tất cả phụ thuộc vào yêu cầu của bạn thực sự là gì và tại sao bạn lưu trữ tất cả các dữ liệu này. Nếu nó chỉ dành cho mục đích lưu trữ, thì cột nhị phân vẫn ổn. Nếu bạn muốn trích xuất giá trị doanh nghiệp từ nó bằng SQL Server, thì đó là một câu chuyện hoàn toàn khác.
Dave Markle

0

Hãy xem xét một giải pháp Hadoop. 2 Tb / ngày tăng lên nhanh chóng. Cũng xem xét việc ghi nhật ký chỉ các bản ghi delta, tức là một giá trị nội bộ, và sau đó chỉ khi thay đổi xảy ra.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.