Tôi nên quản lý dữ liệu PostGIS Raster với các phép chiếu khác nhau như thế nào?


10

Tôi có một yêu cầu để lưu trữ và quản lý dữ liệu địa vật lý khảo cổ học được thu thập dưới dạng một mảng hình chữ nhật của các mẫu - một hình ảnh raster.

  • Mỗi raster thường sẽ có các mẫu dấu phẩy động 20x20 hoặc 30x30, thường được lấy mẫu ở các khoảng cách 1m.
  • Một khảo sát sẽ bao gồm một hoặc nhiều hình ảnh trong một vị trí nhất định.
  • Có thể hai cuộc khảo sát khác nhau có thể diễn ra ở các quốc gia khác nhau hoặc các khu vực sử dụng các phép chiếu khác nhau, nhưng mỗi cuộc khảo sát sẽ sử dụng một và chỉ một phép chiếu.
  • Họ không bao giờ có thể được xem cùng nhau, mỗi cuộc khảo sát thường sẽ tự ngồi.
  • Dữ liệu sẽ chỉ được truy cập bởi một giao diện người dùng tùy chỉnh, do đó sẽ không có người dùng nào có quyền kiểm soát trực tiếp thông qua psqlhoặc tương tự.
  • Mỗi mẫu cần được lưu trữ khi nó được thu thập, vì vậy tôi không thể chuyển hướng nó thành CRS chung như Web Mercator vì một mẫu cuối cùng có thể bao phủ nhiều hơn hoặc ít hơn diện tích so với dự báo ban đầu và việc phân tích sẽ cần được thực hiện trên dữ liệu.

Làm thế nào tôi nên lưu trữ dữ liệu tốt nhất trong cơ sở dữ liệu Raster PostGIS? Các tùy chọn tôi đã đưa ra là:

  1. Bỏ qua các ràng buộc SRID và lưu trữ tất cả dữ liệu trong một bảng, viết mã mặt trước của tôi để xử lý dữ liệu một cách nhất quán.
  2. Lưu trữ tất cả dữ liệu trong một bảng và viết lại ràng buộc SRID dưới dạng hợp chất của SRID và ID khảo sát.
  3. Thông qua kế thừa bảng, tạo một bảng mới cho mỗi SRID mới.
  4. Thông qua kế thừa bảng, tạo một bảng mới cho mỗi khảo sát.

1 và 2 phá vỡ một số phần tự động đẹp của PostGIS, nhưng sẽ bị ẩn trong mã mặt trước. Nhưng các truy vấn có thể sẽ mất nhiều thời gian hơn.

3 và 4 có thể kết thúc bằng sự bùng nổ của các bảng khiến việc quản lý các ràng buộc FK trở nên khó khăn hơn, v.v.

Trên thực tế, số lượng người quét trên mỗi khảo sát là từ 1 đến 100 hoặc nhiều hơn và số lượng khảo sát có thể sẽ chạy vào hàng trăm. Nhưng số lượng các dự báo riêng biệt có khả năng vẫn còn rất thấp, ủng hộ 3.

Câu trả lời:


7

Tôi đã suy nghĩ câu hỏi của bạn và cuối cùng đưa ra kết luận rằng tôi sẽ lưu trữ mỗi khảo sát vào cơ sở dữ liệu của riêng mình .

LƯU Ý : theo cơ sở dữ liệu Tôi có nghĩa là một cơ sở dữ liệu được tạo bên trong một cụm cơ sở dữ liệu postgres theo thuật ngữ postgres được đưa ra ở đây , không phải là một quy trình postgres hoàn toàn riêng biệt với người dùng của riêng nó, template1, v.v.

Trong khi điều này nghe có vẻ quá mức, trên thực tế, cung cấp một số lợi thế:

  • Khả năng quản lý: mỗi khảo sát chỉ có một bảng raster với srid của nó cho phép bạn tuân thủ càng nhiều càng tốt các tiêu chuẩn quản lý dữ liệu của postgis (ví dụ: không gây rối với bảng raster_columns hoặc FK hoặc ràng buộc. Tất cả các chức năng của postgis vẫn hoạt động như mong đợi)

  • tính đơn giản: miễn là bạn áp dụng và thực thi chiến lược đặt tên mạch lạc như: gọi mỗi db là tên srvy_ và sau đó sử dụng lại cùng tên (ví dụ như giám sát ) cho tất cả các bảng và cột raster. Nếu bạn rất quan tâm (tôi biết tôi sẽ ;-)) bạn cũng có thể thêm bảng siêu dữ liệu vào mỗi cơ sở dữ liệu mô tả loại dữ liệu nào được lưu trữ trong cơ sở dữ liệu đó, khi nó được cập nhật lần cuối, v.v. Viết kịch bản / truy vấn cấu trúc cơ sở dữ liệu với cách đặt tên mạch lạc như vậy sẽ dễ dàng (và dễ chịu).

  • nó hoạt động theo yêu cầu của bạn, miễn là mỗi khảo sát sử dụng srid riêng của nó

  • khả năng mở rộng: nó mở rộng quy mô vì bạn có thể di chuyển cơ sở dữ liệu (bằng cách phân bổ chúng trên các không gian bảng khác nhau ) vào các trục chính khác nhau (hoặc đĩa, pool, lun, tùy thuộc vào nhà cung cấp lưu trữ) để có thể song song I / O. Việc di chuyển các bảng từ cùng một cơ sở dữ liệu sang các đĩa khác nhau sẽ khó khăn hơn nhiều

  • bảo mật: bạn có thể cấp các quyền khác nhau cho các khảo sát khác nhau bằng cách khai thác bảo mật cơ sở dữ liệu (dưới dạng một lớp bổ sung ở trên ứng dụng)

  • đã kiểm tra: đã có báo cáo về việc xử lý hàng ngàn cơ sở dữ liệu trong một trường hợp duy nhất, xem phần này để tham khảo

  • [điều này phải được kiểm tra, tôi biết nó hoạt động cho hình học, không biết cho người quét] bạn vẫn có thể truy vấn (và chuyển đổi) tất cả các trình quét cùng một lúc bằng cách tạo các chế độ xem như sau:

create or replace view v_all_surveys_as_wgs84 as select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number1.rasterdata union all select ST_Transform(raster, 4326) as raster_wgs84 from srvy_number2.rasterdata [...]

Một lập luận có thể chống lại là thiết lập này rất phức tạp, nhưng tôi sẽ lập luận lại rằng việc sao chép lại rất đơn giản khi cơ sở dữ liệu đầu tiên được thiết lập và sau đó có thể được quản lý hoàn toàn trong kịch bản nếu áp dụng chính sách đặt tên thích hợp.


Cảm ơn unicoletti, tôi thích ý tưởng này khá nhiều! Những gì tôi có thể làm là có mỗi khảo sát trong một lược đồ riêng thay vì mỗi cơ sở dữ liệu vì kế hoạch cuối cùng là có các khách hàng khác nhau lưu trữ các khảo sát của họ trên một máy chủ trung tâm và vì vậy tôi có thể có một cơ sở dữ liệu riêng cho từng khách hàng. Nhưng dù bằng cách nào, nó chắc chắn đánh bại sự lộn xộn với các ràng buộc cột! Tôi không chắc chắn nếu có một giới hạn thực tế cho số lượng cơ sở dữ liệu, nhưng nó chỉ bị giới hạn bởi các giới hạn hệ thống tệp.
MerseyViking

Cảm ơn! Ý tôi là cơ sở dữ liệu = lược đồ không phải cơ sở dữ liệu = thể hiện. Các điều khoản là một chút ambiguos, tôi sẽ làm rõ câu trả lời của tôi.
unicoletti

Tôi cũng đã thêm một gợi ý về việc sử dụng không gian bảng để phân vùng dữ liệu trên các đĩa khác nhau.
unicoletti
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.