Quản lý số lượng lớn dữ liệu không gian địa lý? [đóng cửa]

Làm thế nào để bạn quản lý dữ liệu không gian địa lý của bạn? Tôi có hàng terabyte dữ liệu trải rộng trên hàng trăm bộ dữ liệu và có một giải pháp đặc biệt sử dụng các liên kết tượng trưng trong các dự án liên kết trở lại thư mục lưu trữ dựa trên tên miền cho mỗi tập dữ liệu. Điều này hoạt động chủ yếu, nhưng có vấn đề riêng của nó.

Tôi cũng rất muốn nghe nếu có ai quản lý dữ liệu không gian địa lý của họ trong một hệ thống kiểm soát sửa đổi; Tôi hiện đang sử dụng một cho mã của tôi và các bộ dữ liệu nhỏ, nhưng không phải cho các bộ dữ liệu đầy đủ.

Tôi nghĩ rằng câu trả lời rõ ràng / chứng khoán sẽ là sử dụng cơ sở dữ liệu không gian (PostGIS, Oracle, SDE, MSSQL Spatial, v.v.) kết hợp với máy chủ siêu dữ liệu như GeoPortal của esri hoặc ứng dụng GeoNetwork nguồn mở và nói chung tôi nghĩ rằng điều này nói chung giải pháp tốt nhất. Tuy nhiên, bạn có thể luôn có nhu cầu về ảnh chụp nhanh / chi nhánh / thẻ dựa trên dự án. Một số cơ sở dữ liệu nâng cao hơn có cách quản lý những cơ sở dữ liệu này, nhưng nhìn chung chúng không dễ sử dụng / quản lý.

Đối với những thứ bạn lưu trữ bên ngoài cơ sở dữ liệu (hình ảnh lớn, tệp dựa trên dự án) Tôi nghĩ rằng điều quan trọng là phải có quy ước đặt tên nhất quán và một lần nữa đăng ký siêu dữ liệu (ngay cả thứ gì đó công nghệ thấp như bảng tính) cho phép bạn theo dõi chúng và đảm bảo rằng chúng được quản lý đúng cách. Ví dụ, trong trường hợp các tệp dựa trên dự án, điều này có thể có nghĩa là xóa chúng khi chính sách quản lý hồ sơ ra lệnh, hoặc đưa chúng vào kho lưu trữ trung tâm khi hoàn thành dự án.

Tôi đã thấy một số giải pháp thú vị mặc dù ...

Quay lại khi Bộ Môi trường BC đang điều hành các trang bìa Arc / Info, họ đã có một quy trình đồng bộ hóa hai chiều dựa trên rsync thực sự thú vị. Các trang trải nằm dưới sự kiểm soát trung tâm đã được đẩy ra các khu vực hàng đêm và dữ liệu khu vực được đẩy lùi vào. Việc chuyển đổi vi sai cấp khối này hoạt động rất tốt, thậm chí hơn 56k liên kết. Có các quy trình tương tự để sao chép cơ sở dữ liệu thuộc tính dựa trên Oracle, nhưng tôi không nghĩ rằng chúng thường hoạt động quá tốt so với quay số :)

Nơi làm việc hiện tại của tôi sử dụng một giải pháp lai tương tự. Mỗi tập dữ liệu có bản sao có thẩm quyền của nó (một số trong Oracle, một số khác trong MapInfo, một số khác trong cơ sở dữ liệu địa lý cá nhân) và đây là những bản sao chéo hàng đêm sử dụng FME. Có một số chi phí khá lớn ở đây khi nói đến bảo trì; nỗ lực tạo ra bất kỳ tập dữ liệu mới nào và đảm bảo khả năng hiển thị của tổ chức cao hơn đáng kể so với mức cần thiết. Chúng tôi đang trong quá trình đánh giá nhằm tìm cách hợp nhất để tránh chi phí này.

Metadata là vấn đề quan trọng nhất ở đây. Nếu siêu dữ liệu trả lời ai, khi nào, tại sao, nơi đó là bản ghi siêu dữ liệu có thể chấp nhận.

Có kinh nghiệm làm việc trong các công ty lớn chỉ với một vài người dùng GIS (khoảng 30), chúng tôi gặp vấn đề lớn để kiểm soát dữ liệu, các phiên bản đặc biệt và quyền. Một mặt của vấn đề này có thể được giải quyết bằng tài liệu dữ liệu mở rộng (siêu dữ liệu) và các vấn đề khác rất có thể được giải quyết với một kho lưu trữ trung tâm, trong đó PostGIS tỏa sáng.

GeoNetwork là một khởi đầu tốt để xử lý các vấn đề siêu dữ liệu. Việc giải quyết kho lưu trữ trung tâm phức tạp hơn, bởi vì có thể cần một người chuyên môn để thiết kế / bảo trì cơ sở dữ liệu.

Vấn đề phức tạp là ai sẽ chịu trách nhiệm về QA / QC các bộ dữ liệu này và siêu dữ liệu của chúng. Mặc dù các quy trình điều khiển bằng máy tính hoạt động rất tốt nhưng chúng không thể nghiêm ngặt như một trình quản lý dữ liệu / người giữ dữ liệu tốt, được thực hiện trong công ty này mà tôi đã làm việc. Bây giờ có một người duy nhất ở đó để xem xét / cam kết siêu dữ liệu và sắp xếp dữ liệu không gian địa lý không tập trung trong DBMS.

Chúng tôi đã sử dụng một hệ thống tệp được sắp xếp theo thứ bậc theo: - phạm vi địa lý (quốc gia hoặc lục địa) - nhà cung cấp dữ liệu, người cấp phép - tên miền / tập dữ liệu - ngày / phiên bản

Sau đó, chúng tôi có chính sách tách dữ liệu nguồn (ở cùng định dạng trên bất kỳ CD / DVD nào chúng tôi nhận được từ nhà cung cấp) khỏi mọi bộ dữ liệu có nguồn gốc mà chúng tôi sản xuất trong công ty.

Hệ thống tệp giúp dễ dàng lấy bất kỳ dữ liệu nào từ khách hàng và cũng cho phép linh hoạt về lưu trữ vật lý - chúng tôi lưu trữ trên các đĩa lớn hơn, chậm hơn và chúng tôi có các máy chủ tệp đặc biệt (được liên kết trong hệ thống phân cấp) các bộ dữ liệu được sử dụng thường xuyên hơn.

Để tạo điều kiện quản lý trong các dự án, chúng tôi sử dụng các liên kết tượng trưng. Chúng tôi giữ các vectơ của mình trong cơ sở dữ liệu (Oracle) và chúng tôi đặt quy tắc để có ít nhất một phiên bản cơ sở dữ liệu cho mỗi khách hàng (và một số người dùng / lược đồ cho các dự án). Tuy nhiên, chúng tôi đã không lưu giữ nhiều trình quét trong cơ sở dữ liệu vì chúng có xu hướng chiếm quá nhiều không gian ngay cả bên ngoài. Ngoài ra, chúng tôi muốn giữ cho các trường hợp cơ sở dữ liệu của chúng tôi càng nhẹ càng tốt.

Và vâng, chúng tôi có một người chịu trách nhiệm "kiểm soát" toàn bộ mọi thứ để nó không trở nên quá lộn xộn.

Vấn đề lớn nhất mà chúng tôi gặp phải với thiết lập này hiện tại là thiếu giao diện người dùng đẹp sẽ giúp chúng tôi có cái nhìn tổng quan hơn về toàn bộ vấn đề và chúng tôi đã lên kế hoạch bao gồm một bộ lưu trữ siêu dữ liệu lên trên tất cả. Chúng tôi vẫn đang xem xét các lựa chọn của chúng tôi ở đây.

Chúng tôi đang sử dụng kiểm soát phiên bản cho mã của chúng tôi và chúng tôi đã sử dụng nó cho các tài liệu, nhưng hóa ra việc kiểm soát phiên bản không thực sự được tạo cho các bộ dữ liệu lớn, đặc biệt nếu chúng chủ yếu là các tệp nhị phân, vì vậy tôi không khuyến nghị rằng , ngoại trừ nếu bạn đang xử lý GML hoặc một cái gì đó tương tự như văn bản (các vấn đề bao gồm chi phí rất lớn đối với việc sử dụng đĩa phía máy chủ cũng như các máy khách gặp sự cố khi kiểm tra kho lưu trữ lớn).

Như @JasonBirch đã nói, kiểm soát phiên bản là một vấn đề rất lớn.

Ngoài ra, chúng tôi thấy rằng một quy trình làm việc phù hợp là vô cùng quan trọng. Ví dụ: khi chúng tôi thu thập dữ liệu trường, chúng tôi có xu hướng sử dụng cơ sở dữ liệu theo giai đoạn trong đó dữ liệu trường có thể là QA trước khi được hợp nhất vào tập dữ liệu chính. Tùy thuộc vào lượng dữ liệu cần QA, điều này sẽ luôn tạo ra một số chi phí.

Ngoài ra, nếu bạn chưa thấy nó, tôi khuyên bạn nên xem cuốn ebook Thiết kế thông tin và truyền thông địa lý của Lars Broderen, ít nhất là đối với một số điều ông nói về mô hình hóa dữ liệu.

Postgres tất cả các cách như những người khác đã nói, tuy nhiên nếu bạn muốn giữ cho nó di động và dễ dàng di chuyển, thì bạn luôn có thể xem xét bằng cách sử dụng SQLite + tiện ích mở rộng Spatialite.

Không dễ sử dụng như Postgres về các công cụ quản lý, nhưng QGis CÓ THỂ nói chuyện trực tiếp với Cơ sở dữ liệu GIS được kích hoạt không gian mà không gặp vấn đề gì.

Tôi thực sự sử dụng SQLite + Spatialite để sao lưu, tôi có một dịch vụ windows chạy ở chế độ nền (Được viết tùy chỉnh) theo dõi phiên bản PGSql của tôi và phản chiếu Dữ liệu GIS của tôi vào các SQL SQL khác nhau nằm trên các ổ USB ngoài.

Thêm một mẹo với PG nữa, hãy sử dụng lược đồ

Nhiều người tôi biết chỉ cần bỏ mọi thứ vào "công khai" và được thực hiện với nó, nhưng nếu bạn tổ chức cơ sở dữ liệu của mình một cách chính xác, nó sẽ tạo ra thế giới khác biệt.

Ví dụ: cơ sở dữ liệu "Ordnance_Survey" của tôi có các lược đồ cho VectormapDistrict VectormapLocal Topo50 Tra cứuGrids CodePointWithPolygons CodePointOpen

nơi tôi giữ tất cả các dữ liệu liên quan.

Trong khi đó, các bảng siêu dữ liệu, như các cột hình học, v.v., tất cả chỉ tồn tại ở chế độ Công khai, tiện ích mở rộng Postgis cũng chỉ được bật trên lược đồ công khai, nhưng có thể truy cập được từ tất cả các lược đồ khác đang sử dụng.

Như bài viết trước đã đề cập, DB không gian và máy chủ siêu dữ liệu là thiết lập thông thường. Tôi nghĩ một điều quan trọng cần nhớ là "một kích thước không phù hợp với tất cả". Bạn sẽ kết thúc với dữ liệu phù hợp nhất với Oracle, máy chủ tệp, máy chủ SQL, bất cứ điều gì. Tôi đã thử đánh giày tất cả các nhu cầu dữ liệu vào một giải pháp và nó thường thất bại.

Dự kiến ​​sẽ sử dụng các giải pháp khác nhau phù hợp với dữ liệu và lập kế hoạch cho chúng. Đây là nơi mà cổng thông tin địa lý (máy chủ siêu dữ liệu) thực sự xuất hiện.

Tôi phải đồng ý với 'George' ở trên rằng siêu dữ liệu sẽ đóng một vai trò lớn trong việc quản lý dữ liệu không gian địa lý. Thực sự với bất kỳ dữ liệu kỹ thuật số nào, siêu dữ liệu là chìa khóa - hãy nghĩ đến một nhiếp ảnh gia cố gắng quản lý các tệp ảnh kỹ thuật số của mình với siêu dữ liệu phù hợp. Cuộc sống trở nên dễ dàng hơn rất nhiều nếu bạn gắn thẻ mọi thứ một cách tôn giáo và có phần mềm tốt có thể sử dụng dữ liệu. Bây giờ câu hỏi ban đầu về 'quản lý dữ liệu không gian địa lý' khá rộng - đây có thể là các định dạng dữ liệu để lưu trữ, đặt tên theo quy ước, phân cấp các bộ dữ liệu và tính năng, chỉnh sửa vai trò và đặc quyền, v.v.

Mẫu lưu trữ cho dữ liệu không gian địa lý phụ thuộc vào cách bạn muốn truy vấn nó / những gì bạn muốn làm với nó. Sau đây là một số công cụ mà bạn có thể xem xét:

Postgres + PostGIS: Hỗ trợ các chỉ mục không gian địa lý và tất cả các loại truy vấn bạn có thể tưởng tượng. Để quản lý terabyte dữ liệu của bạn, bạn sẽ cần áp dụng shending, tối ưu hóa truy vấn, v.v ... Nếu tải ghi của bạn quá nặng thì tôi không khuyến nghị điều này.

MongoDB: Điều này hỗ trợ một lượng lớn dữ liệu. Tuyệt vời cho lưu trữ đơn giản, truy xuất và truy vấn không gian địa lý hạn chế.

Lưu trữ tệp: Nếu bạn thực sự chỉ là một hệ thống lưu trữ và chỉ sử dụng một phần dữ liệu để truy vấn thì việc lưu trữ dữ liệu của bạn dưới dạng tệp có thể là kinh tế. Yêu cầu kiểm soát phiên bản của bạn có thể được thỏa mãn với điều này.

Redis: Bạn có thể kết hợp bất kỳ tùy chọn nào ở trên với hỗ trợ Redis Geo để lưu trữ một lượng nhỏ dữ liệu 'nóng' trong redis mà bạn cần truy cập thường xuyên. Hãy nghĩ về điều này như bộ nhớ cache của bạn.