Bộ dữ liệu không gian địa lý lớn (> 22 nghìn tỷ) với hiệu suất truy vấn đọc nhanh (<1s)

Tôi đang trong quá trình thiết kế một hệ thống mới cho một tập dữ liệu không gian địa lý lớn sẽ yêu cầu hiệu năng truy vấn đọc nhanh. Do đó, tôi muốn xem liệu có ai nghĩ là có thể hoặc có kinh nghiệm / lời khuyên về các DBMS phù hợp, cấu trúc dữ liệu hoặc các phương pháp thay thế để đạt được hiệu suất cần thiết trong tình huống sau:

Dữ liệu sẽ liên tục được sản xuất từ ​​dữ liệu radar vệ tinh được xử lý, có phạm vi phủ sóng toàn cầu. Dựa trên độ phân giải vệ tinh và vùng phủ sóng trên toàn cầu, tôi ước tính toàn bộ dữ liệu được thiết lập để tạo ra các giá trị tại 75 tỷ vị trí riêng biệt trên toàn cầu. Trong vòng đời của một vệ tinh, đầu ra sẽ tạo ra tới 300 giá trị tại mỗi vị trí này (do đó tổng số dữ liệu> 22 nghìn tỷ giá trị). Đây là cho một vệ tinh, và đã có một quỹ đạo thứ hai, với hai vệ tinh khác được lên kế hoạch trong vài năm mới. Vì vậy, sẽ có rất nhiều dữ liệu! Một mục dữ liệu duy nhất rất đơn giản và sẽ chỉ bao gồm (kinh độ, vĩ độ, giá trị), nhưng do số lượng mục tôi ước tính một vệ tinh duy nhất tạo ra tối đa 100TB.

Dữ liệu bằng văn bản không bao giờ cần cập nhật, vì nó sẽ chỉ phát triển khi việc mua lại vệ tinh mới được xử lý. Hiệu suất viết không quan trọng, nhưng hiệu suất đọc là rất quan trọng. Mục tiêu của dự án này là có thể trực quan hóa dữ liệu thông qua một giao diện đơn giản như một lớp trên bản đồ google, trong đó mỗi điểm có một giá trị màu dựa trên mức trung bình, độ dốc hoặc một số chức năng theo thời gian. (bản demo ở cuối bài).

Từ các yêu cầu này, cơ sở dữ liệu cần có khả năng mở rộng và chúng tôi có khả năng hướng tới các giải pháp đám mây. Hệ thống cần có khả năng xử lý các truy vấn không gian địa lý như "điểm gần (lat, lon)" và "điểm trong (hộp)" và có hiệu suất đọc <1s để xác định vị trí một điểm và đa giác có chứa tới 50.000 điểm (mặc dù lên đến 200.000 điểm sẽ thích hợp hơn).

Cho đến nay tôi có một bộ dữ liệu thử nghiệm gồm ~ 750 triệu mục dữ liệu tại 111 triệu vị trí. Tôi đã dùng thử một ví dụ postgres / postGIS, hoạt động tốt, nhưng không có khả năng ngăn chặn Tôi không làm điều này sẽ có thể đối phó khi dữ liệu phát triển. Tôi cũng đã dùng thử một ví dụ mongoDB, một lần nữa xuất hiện để OK xa và với shending, nó có thể đủ để mở rộng theo khối lượng dữ liệu. Gần đây tôi đã tìm hiểu một chút về elaticsearch, vì vậy mọi bình luận về điều này sẽ hữu ích vì nó mới đối với tôi.

Dưới đây là hình ảnh động nhanh về những gì chúng tôi muốn đạt được với bộ dữ liệu đầy đủ:

Gif này (từ bản dùng thử postgres của tôi) đang phục vụ (6x3) gạch raster được tính toán trước, mỗi viên chứa ~ 200.000 điểm và mất ~ 17 giây để tạo ra mỗi viên. Bằng cách nhấp vào một điểm, biểu đồ được tạo bằng cách kéo tất cả các giá trị lịch sử tại vị trí gần nhất trong <1s.

Xin lỗi cho bài viết dài, tất cả các ý kiến ​​/ lời khuyên đều được chào đón.

Bạn có thể phân chia theo vị trí. Phân vùng toàn cầu thành một lưới và có mỗi ô vuông trong lưới đó trên một máy chủ. Vì bạn đã đề cập đến đám mây, điều đó sẽ rất phù hợp với đám mây. Tất nhiên bạn sẽ cần phải hợp nhất thủ công các kết quả từ nhiều máy chủ.

Bằng cách đó bạn có thể sử dụng bất kỳ giải pháp cơ sở dữ liệu nào bạn thích. Nó không cần phải có khả năng tự mở rộng.

Các ô vuông riêng lẻ sẽ có lượng dữ liệu khác nhau. Bạn có thể sử dụng các máy có kích thước khác nhau cho chúng (vì đây là đám mây) hoặc bạn đặt nhiều mảnh nhỏ trên cùng một máy.

Lược đồ shending này rất phù hợp với loại truy vấn bạn thực hiện vì mỗi truy vấn sẽ chỉ cần chạm vào rất ít phân đoạn. Shending theo thời gian là tồi tệ hơn bởi vì tất cả các mảnh thời gian phải được chạm vào cho mỗi truy vấn. Shending ngẫu nhiên có cùng một vấn đề.

Tất cả trong tất cả điều này là một trường hợp shending dễ dàng vì mẫu truy vấn phù hợp với sơ đồ shending rất tốt.

Trên thực tế, tôi tự hỏi nếu bạn cần một cơ sở dữ liệu cho việc này. Có thể bạn có thể phân vùng toàn cầu thành các ô 1000x1000 hoặc nhỏ hơn và có một tệp phẳng trong bộ lưu trữ blob cho mỗi ô. Lưu trữ Blob không bận tâm đến blob 1M nào cả.

Thực hiện một truy vấn về mặt khái niệm là rất dễ dàng với sơ đồ lưu trữ này. Bạn cũng có thể lưu trữ dữ liệu theo nhiều độ phân giải lưới.

Làm thế nào cập nhật các truy vấn đọc của bạn cần phải được?

Bạn có thể phân vùng cơ sở dữ liệu theo thời gian nếu bản đồ chỉ cần hiển thị phép đo gần đây nhất. Điều này sẽ làm giảm tải truy vấn của bạn cho bản đồ.

Đối với lịch sử của một điểm nhất định, bạn có thể giữ một cửa hàng thứ hai bằng x và y hiển thị lịch sử. Điều này có thể được thực hiện với việc làm mới / cập nhật hàng đêm vì dữ liệu lịch sử sẽ không thay đổi.

Sau đó, bạn có thể tính toán trung bình trước ở độ phân giải thô hơn để tích hợp với bản đồ ở các mức thu phóng khác nhau. Điều này sẽ giảm số lượng điểm cần truy xuất cho các khu vực bản đồ lớn (thu nhỏ). Độ phân giải tốt hơn sẽ được sử dụng để phóng to hơn trong các bản đồ đang truy vấn các khu vực nhỏ hơn. Nếu bạn thực sự cần tăng tốc độ này, bạn có thể tính toán các ô như các đốm màu và diễn giải chúng trong ứng dụng của bạn.

Bởi vì những điều này sẽ liên quan đến việc tính toán lại thông tin tổng hợp, sẽ có một số độ trễ trong kết quả truy vấn. Tùy thuộc vào độ trễ chấp nhận được, bạn có thể sử dụng cách tiếp cận này để tối ưu hóa việc đọc của mình.

OK, vì vậy điểm của bạn cần được tính trung bình theo thời gian. Với tính toán này, tôi đoán các truy vấn thực tế của bạn giảm khá nhiều từ 22 nghìn tỷ mục vì các giá trị raster có thể được tính toán trước để truy vấn.

Có vẻ như có hai lớp truy vấn - một để hiểu vị trí nào nằm trong cửa sổ chế độ xem hiện tại và thứ hai để cung cấp số liệu thống kê mong muốn cho các điểm đó. Đề nghị của tôi là sử dụng các công cụ riêng biệt, chuyên biệt cho từng công cụ.

Tôi giả sử tất cả các phép đo liên quan đến cùng một bộ 75 tỷ điểm. Những lat / long này, một khi được thiết lập, do đó là tĩnh. Chúng có thể được nhóm lại, tổng hợp và lập chỉ mục với chi phí một lần. Do đó, tôi sẽ đề nghị shending theo vùng và mức thu phóng. Kích thước của mỗi phân đoạn sẽ được điều khiển bởi hiệu suất có thể đạt được từ mỗi phiên bản GIS.

GIS sẽ trả về một tập hợp các điểm được chuyển đến cơ sở dữ liệu chuỗi thời gian. Điều này giữ các giá trị đo và thực hiện tổng hợp. KDB là một trong những gì tôi biết. Nó nhắm mục tiêu giao dịch chứng khoán, sẽ có ít khóa hơn nhưng nhiều điểm dữ liệu trên mỗi khóa hơn so với kịch bản của bạn.

Sẽ có chi phí để chuyển các giá trị chính từ máy chủ GIS sang DB thời gian. Giả thuyết của tôi là chi phí này sẽ được trả lại bằng cách xử lý nhanh hơn trong DB thời gian dành riêng cho nhiệm vụ. Từ cách đặt câu hỏi, có vẻ như một trường hợp duy nhất sẽ không thể chứa tất cả dữ liệu nên một số lưu lượng máy chủ chéo dường như không thể tránh khỏi. Với tốc độ tương đối của các thành phần, có vẻ như việc gửi một bộ khóa đến một máy chủ từ xa có dữ liệu được lưu trong bộ nhớ cache sẽ nhanh hơn đọc dữ liệu từ đĩa cục bộ.

Nếu các phần tìm kiếm điểm và tính toán giá trị có thể cục bộ với nhau thì tất nhiên tôi sẽ mong phản hồi sẽ nhanh hơn. Hiểu biết (hạn chế) của tôi là việc tìm N hàng xóm gần nhất đến một điểm nhất định là một nhiệm vụ không hề nhỏ. Đây là lý do tại sao tôi đề nghị sử dụng phần mềm cụ thể để thực hiện nó. Nếu việc tìm kiếm điểm có thể được giảm xuống

where latitude between x1 and x2
and logitude between y1 and y2

sau đó phần đó có thể được xử lý bởi phần mềm lưu trữ giá trị và loại bỏ GIS khỏi kiến ​​trúc.

Tôi đã không thực hiện một hệ thống như vậy. Tôi thực sự chỉ nghĩ lớn tiếng ở đây. Ở quy mô petabyte không có giải pháp sẵn có. Tuy nhiên, có nhiều nhà cung cấp dữ liệu vệ tinh để vấn đề của bạn có thể xử lý được. Chúc may mắn.