cơ sở dữ liệu tốt (noSQL?) Cho các phép đo vật lý

Question

Chúng tôi đang xây dựng một hệ thống đo lường mà cuối cùng sẽ bao gồm hàng nghìn trạm đo lường. Mỗi trạm sẽ tiết kiệm khoảng 500 triệu phép đo bao gồm 30 giá trị vô hướng trong suốt vòng đời của nó. Đây sẽ là giá trị nổi. Chúng tôi hiện đang tự hỏi cách lưu dữ liệu này trên mỗi trạm, xem xét chúng tôi sẽ xây dựng một ứng dụng web trên mỗi trạm sao cho

• chúng tôi muốn hình ảnh hóa dữ liệu trên nhiều lần (ví dụ: đo một tuần, tháng, năm)
• chúng ta cần phải xây dựng các đường trung bình so với các dữ liệu (ví dụ trung bình trong một tháng để hiển thị trong một đồ thị năm)
• cơ sở dữ liệu cần phải được kháng (cúp điện sụp đổ)
• chúng tôi chỉ làm viết và đọc, không có cập nhật hoặc xóa trên dữ liệu

ngoài ra, chúng tôi muốn có thêm một máy chủ có thể hiển thị dữ liệu của 1000 trạm đo lường. Đó sẽ là ~ 50TB dữ liệu trong 500 tỷ phép đo. Để truyền dữ liệu từ trạm đo đến máy chủ, tôi nghĩ rằng một số loại sao chép ở cấp cơ sở dữ liệu sẽ là một cách sạch sẽ và hiệu quả.

Bây giờ tôi tự hỏi nếu một giải pháp noSQL có thể tốt hơn so với mySQL cho các mục đích này. Đặc biệt là couchDB, Cassandra và có thể là các cửa hàng có giá trị quan trọng như Redis trông hấp dẫn đối với tôi. Cái nào trong số đó phù hợp với mô hình dữ liệu "chuỗi thời gian đo lường" tốt nhất theo ý kiến ​​của bạn? Còn những ưu điểm khác như an toàn va chạm và sao chép từ trạm đo đến máy chủ chính thì sao?

Answer 1

Tôi nghĩ CouchDB là một cơ sở dữ liệu tuyệt vời - nhưng khả năng xử lý dữ liệu lớn là vấn đề. Trọng tâm chính của CouchDB là sự đơn giản của sự phát triển và sao chép ngoại tuyến, không nhất thiết về hiệu suất hoặc khả năng mở rộng. Bản thân CouchDB không hỗ trợ phân vùng, do đó bạn sẽ bị giới hạn bởi kích thước nút tối đa trừ khi bạn sử dụng BigCouch hoặc tạo ra lược đồ phân vùng của riêng bạn.

Không có kẻ ngốc, Redis là cơ sở dữ liệu trong bộ nhớ. Việc lấy dữ liệu vào và ra RAM rất nhanh và hiệu quả. Nó có khả năng sử dụng đĩa để lưu trữ, nhưng nó không phải là khủng khiếp tốt ở đó. Thật tuyệt vời cho số lượng dữ liệu bị giới hạn thay đổi thường xuyên. Redis không có bản sao, nhưng không có bất kỳ hỗ trợ tích hợp cho phân vùng, do đó, một lần nữa, bạn sẽ ở trên của riêng bạn ở đây.

Bạn cũng đã đề cập Cassandra, điều mà tôi nghĩ là nhắm mục tiêu nhiều hơn cho trường hợp sử dụng của bạn. Cassandra rất thích hợp cho các cơ sở dữ liệu phát triển vô thời hạn, về cơ bản nó là trường hợp sử dụng ban đầu. Việc phân vùng và tính khả dụng được nướng để bạn không phải lo lắng về nó. Mô hình dữ liệu cũng linh hoạt hơn một chút so với cửa hàng khóa/giá trị trung bình, thêm thứ nguyên cột thứ hai và có thể chứa hàng triệu cột mỗi hàng. Điều này cho phép dữ liệu chuỗi thời gian được "khóa" thành các hàng bao gồm các phạm vi thời gian, chẳng hạn. Việc phân phối dữ liệu trên cụm (phân vùng) được thực hiện ở cấp hàng, do đó chỉ cần một nút để thực hiện các phép toán trong một hàng.

Hadoop cắm ngay vào Cassandra, với "trình điều khiển gốc" cho MapReduce, Pig và Hive, vì vậy nó có thể được sử dụng để tổng hợp dữ liệu đã thu thập và thực hiện trung bình hoạt động. Cách tốt nhất là định dạng dữ liệu xung quanh các truy vấn, vì vậy có thể muốn lưu trữ nhiều bản sao của dữ liệu dưới dạng "không chuẩn hóa", một cho mỗi loại truy vấn.

Check-out bài này về làm chuỗi thời gian trong Cassandra:

http://rubyscale.com/2011/basic-time-series-with-cassandra/

Answer 2

Đối với dữ liệu có cấu trúc cao của thiên nhiên này (chuỗi thời gian của vectơ float) Tôi có xu hướng né tránh cơ sở dữ liệu tất cả cùng nhau. Hầu hết các tính năng của một cơ sở dữ liệu không phải là rất thú vị; về cơ bản bạn không quan tâm đến những thứ như nguyên tử hay ngữ nghĩa giao dịch. Tính năng duy nhất mà là mong muốn là khả năng phục hồi khi gặp sự cố. Tuy nhiên, tính năng này dễ thực hiện khi bạn không cần phải hoàn tác một ghi (không có cập nhật/xóa), chỉ bằng cách thêm vào tệp. phục hồi sự cố rất đơn giản; mở một tệp mới có số sê-ri tăng dần trong tên tệp.

Định dạng hợp lý cho điều này là csv thuần tuý. sau mỗi phép đo được thực hiện, hãy gọi flush() trên cơ sở file. Lấy dữ liệu được sao chép trở lại máy chủ trung tâm là công việc được giải quyết một cách hiệu quả bởi rsync(1). Sau đó, bạn có thể nhập dữ liệu trong công cụ phân tích mà bạn chọn.

Answer 3

Tôi sẽ lúng túng ra khỏi tệp "csv" và "bản rõ". Đây là những thuận tiện khi bạn có khối lượng thấp và muốn bỏ qua các công cụ để xem nhanh dữ liệu hoặc thực hiện các thay đổi nhỏ cho dữ liệu.

Khi bạn đang nói về "50Tb" dữ liệu, điều đó khá nhiều. Nếu một mẹo đơn giản sẽ làm giảm điều đó bằng một hệ số hai, điều đó sẽ tự trả lại chi phí lưu trữ và chi phí băng thông.

Nếu các phép đo được thực hiện thường xuyên có nghĩa là thay vì lưu dấu thời gian với mọi phép đo, bạn lưu trữ thời gian bắt đầu và khoảng thời gian và chỉ lưu trữ các phép đo.

Tôi muốn định dạng tệp có tiêu đề nhỏ và sau đó chỉ là một loạt các phép đo dấu chấm động. Để ngăn các tệp thực sự thực sự lớn, hãy quyết định kích thước tệp tối đa. Nếu bạn khởi tạo tập tin bằng cách viết đầy đủ nó trước khi bắt đầu sử dụng tập tin, nó sẽ được phân bổ hoàn toàn trên đĩa vào lúc bạn bắt đầu sử dụng nó. Bây giờ bạn có thể mmap tập tin và thay đổi dữ liệu. Nếu mất điện khi bạn đang thay đổi dữ liệu, nó chỉ đơn giản là làm cho nó vào đĩa hoặc nó không.