Büyük miktarlardaki coğrafi verileri yönetme? [kapalı]

Jeo uzamsal verilerinizi nasıl yönetirsiniz? Yüzlerce veri kümesine yayılmış terabayt veriye sahibim ve projelerdeki etki alanı adına dayalı bir arşiv dizinine geri dönen projelerdeki sembolik bağlantıları kullanarak geçici bir çözümüm var. Bu çoğunlukla çalışır, ancak kendi sorunları vardır.

Ayrıca, herhangi birinin coğrafi verilerini bir revizyon kontrol sisteminde yönetip yönetmediğini de duymak istiyorum; Şu anda kodum ve küçük veri kümelerim için birini kullanıyorum, ancak tam veri kümeleri için kullanmıyorum.

Hisse senedi / bariz cevap, esri GeoPortal veya açık kaynak kodlu GeoNetwork uygulaması gibi bir meta veri sunucusu ile birlikte mekansal bir veritabanı (PostGIS, Oracle, SDE, MSSQL Spatial, vb.) Kullanmak olacağını düşünüyorum ve genel olarak bunun genel olduğunu düşünüyorum. en iyi çözüm. Bununla birlikte, büyük olasılıkla her zaman proje tabanlı anlık görüntüler / dallar / etiketlere ihtiyaç duyacaksınız. Daha gelişmiş veritabanlarından bazılarının bunları yönetme yöntemleri vardır, ancak bunlar genellikle kullanıcı / yönetimi kolay değildir.

Veritabanının dışında sakladığınız şeyler için (büyük resimler, proje tabanlı dosyalar) Anahtarın tutarlı bir adlandırma kuralına ve tekrar izlemenizi sağlayan bir meta veri kayıt defterine (bir elektronik tablo gibi düşük teknolojili bir şey) sahip olduğunu ve Düzgün bir şekilde yönetildiğinden emin olun. Örneğin, proje tabanlı dosyalar söz konusu olduğunda bu, kayıt yönetimi politikası gerektirdiğinde dosyaları silmek veya proje tamamlama sırasında merkezi depoya almak anlamına gelebilir.

Yine de bazı ilginç çözümler gördüm.

M.Ö. Çevre Bakanlığı, Arc / Info gruplarından bir şeyleri koştuğunda, gerçekten harika bir rsync tabanlı iki yönlü senkronizasyon süreci uygulandı. Merkezi kontrol altında olan eşler gece bölgelere itildi ve bölgesel veriler geri itildi. Bu blok seviyeli diferansiyel transfer 56k bağlantı üzerinden bile gerçekten iyi çalıştı. Oracle tabanlı öznitelik veritabanlarını çoğaltmak için benzer işlemler vardı, ancak genellikle çevirmeli ağ üzerinden çok iyi yaptıklarını sanmıyorum :)

Şu anki iş yerimde benzer bir melez çözüm kullanılıyor. Her veri kümesinin yetkili kopyası vardır (bazıları Oracle’da, diğerleri MapInfo’da, diğerleri kişisel coğrafi veritabanlarında) ve bunlar FME’yi kullanarak gece boyunca ETL’ler arasıdır. Burada bakım konusunda bazı büyük ana yükler var; Herhangi bir yeni veri seti oluşturma ve kurumsal görünürlük sağlama çabası olması gerekenden çok daha yüksektir. Bu ek yükü önlemek için birleştirme yöntemini bulmaya yönelik bir inceleme süreci içindeyiz.

Meta veri burada en önemli konudur. Meta veriler kim, ne zaman, niçin, kabul edilebilir bir meta veri kaydının nerede olduğunu yanıtlarsa .

Yalnızca birkaç GIS kullanıcısı olan (yaklaşık 30 civarında) büyük şirketlerde iş deneyimine sahip olmak, verileri, özel sürümleri ve izinleri kontrol etmek için büyük sorunlarımız oldu. Bunun bir tarafı kapsamlı veri dokümantasyonu (meta veriler) ile çözülebilir ve diğer problemler büyük olasılıkla PostGIS'in parladığı merkezi bir depo ile çözülür.

GeoNetwork, meta veri sorunlarını ele almak için iyi bir başlangıçtır. Merkezi depoyu çözmek daha karmaşıktır, çünkü veritabanını tasarlamak / sürdürmek için uzman bir kişi gerekebilir.

Karmaşık sorun, bu veri setleri ve meta verilerinde KG / KK'dan kimin sorumlu olacağıdır. Bilgisayar destekli süreçler harika çalışsa da, bu şirkette yaptığım iyi bir veri yöneticisi / veri bekçisi kadar titiz olamazlar. Şimdi sadece bir üst veriyi incelemek / işlemek ve bir DBMS'de merkezileşmemiş coğrafi verileri düzenlemek için birileri var.

Hiyerarşik olarak düzenlenmiş bir dosya sistemi kullandık: - coğrafi kapsam (ülke veya kıta) - veri sağlayıcı, lisans veren - alan / veri kümesi - tarih / sürüm

Bundan sonra, kaynak verileri (tedarikçiden aldığımız CD / DVD'deki formatta aynı şekilde) şirketimizde ürettiğimiz türetilmiş veri kümelerinden ayırma politikamız vardır.

Dosya sistemi müşteriden herhangi bir veriyi almayı gerçekten kolaylaştırır ve ayrıca fiziksel depolama açısından biraz esneklik sağlar - arşivlerimizi daha büyük, daha yavaş diskler üzerinde tutarız ve bunun için özel dosya sunucularımız (şeffaf bir şekilde hiyerarşiye bağlanır) daha sık kullanılan veri setleri.

Projelerde yönetimi kolaylaştırmak için sembolik bağlantılar kullanıyoruz. Vektörlerimizi bir veritabanında tutuyoruz (Oracle) ve müşteri başına en az bir veritabanı örneğinin (ve projeler için birkaç kullanıcı / şema) olmasını bir kural haline getiriyoruz. Bir veritabanında pek çok raster tutmadık, çünkü bir tanesinde bile fazla yer kaplama eğilimindeler. Ayrıca, veritabanı örneklerimizi olabildiğince hafif tutmayı seviyoruz.

Ve evet, her şeyi 'polislik' etmekten sorumlu birileri var, bu yüzden fazla dağınık kalmaz.

Şu an için bu kurulumla ilgili en büyük sorun, her şey hakkında daha iyi bir genel bakışa sahip olmamıza yardımcı olacak hoş bir kullanıcı arayüzünün olmaması ve bunların hepsine bir meta veri depolaması eklemeyi planlıyoruz. Hala burada seçeneklerimizi düşünüyoruz.

Kodumuz için sürüm kontrolü kullanıyoruz ve belgeler için kullandık, ancak sürüm kontrolü gerçekten büyük veri setleri için yapılmıyor, özellikle de çoğunlukla ikili dosyalarsa, bu yüzden bunu tavsiye etmem. , eğer GML ile veya metin benzeri bir şeyle uğraşıyorsanız (problemler, sunucu tarafında disk kullanımının yanı sıra büyük depoları kontrol ederken çökmesini bekleyen büyük giderler de içerir).

@ JasonBirch dediği gibi, sürüm kontrolü çok büyük bir konudur.

Ayrıca uygun bir iş akışının çok önemli olduğunu bulduk. Örneğin, saha verilerini topladığımızda, ana veri setine birleştirilmeden önce saha verilerinin QA'da olabileceği evreleme veritabanlarını kullanma eğilimindeyiz. Ne kadar verinin QA olması gerektiğine bağlı olarak, bu yine de bazı ek yükler yaratacaktır.

Ayrıca, henüz görmediyseniz , en azından veri modelleme konusunda söylediklerinin bazıları için Lars Brodersen'in Geo-iletişim ve bilgi tasarım e - kitaplarına göz atmanızı öneririm .

Diğerlerinin söylediği gibi tümüyle postgres yapın, ancak taşınabilir ve taşınmasını kolay tutmak istiyorsanız, SQLite + Spatialite uzantısını kullanmaya her zaman bakabilirsiniz.

Yönetim araçları açısından Postgres kullanımı kadar kolay değil, ancak QGis CAN herhangi bir sorun olmadan doğrudan bir spatialite etkin GIS Veri Tabanı ile konuşabilir.

Aslında yedekleme için SQLite + Spatialite kullanıyorum, PGSql örneğimi izleyen arka planda çalışan bir Windows hizmetim var ve GIS Verilerimi harici USB sürücülerinde bulunan çeşitli SQLite DB'lerine yansıtıyor.

PG ile bir ipucu daha, şemalar kullanın

Tanıdığım birçok insan her şeyi "genel" e bırakır ve onunla birlikte çalışır, ancak veritabanınızı doğru düzenlerseniz fark yaratır.

Örneğin, "Ordnance_Survey" veritabanımda VectormapDistrict VectormapLocal Topo50 LookupGrids CodePointWithPolygons CodePointOpen için şemalar var

tüm ilgili verileri sakladığım yerde.

Bu arada, geometri sütunları vb. Gibi meta veri tablolarının tümü Genel olarak yalnızca Canlı'da bulunur, Postgis uzantısı da yalnızca genel şemada etkinleştirilir, ancak kullanımdaki diğer tüm şemalardan erişilebilir.

Önceki gönderide bahsettiğimiz gibi, mekansal veri tabanı ve bir meta veri sunucusu her zamanki kurulumdur. Hatırlanması gereken en önemli şey 'tek beden herkese uymuyor' olduğunu düşünüyorum. Ne olursa olsun, Oracle, dosya sunucuları, SQL server'da en uygun verilere sahip olacaksınız. Tüm veri ihtiyaçlarını tek bir çözümde ayakkabı bağlamayı denedim ve genellikle başarısız oluyor.

Verilere uygun farklı çözümler kullanmayı ve onlar için plan yapmayı bekleyin. Geo-portal (meta veri sunucusu) gerçekten girdiği yer burasıdır.

Yukarıdaki 'George' ile aynı fikirdeyim, meta verilerin coğrafi verileri yönetmede büyük bir rol oynaması gerektiğine katılıyorum. Gerçekten herhangi bir dijital veride meta veriler kilit öneme sahiptir - dijital fotoğraf dosyalarını uygun meta veriler olmadan yönetmeye çalışan bir fotoğrafçıyı düşünün. Bir şeyi dini olarak etiketlerseniz ve verileri kullanabilecek iyi bir yazılıma sahipseniz hayat çok daha kolaylaşır. Şimdi 'coğrafi verileri yönetme' hakkındaki asıl soru oldukça geniştir - bu, depolanacak veri biçimleri, sözleşmelerin adlandırılması, veri kümeleri ve özelliklerin hiyerarşisi, rollerin ve ayrıcalıkların düzenlenmesi vb.

Mekansal veriler için depolama düzeni, onu nasıl sorgulamak istediğinize / onunla ne yapmak istediğinize bağlıdır. Aşağıda, göz önünde bulundurabileceğiniz bazı araçlar bulunmaktadır:

Postgres + PostGIS: Jeo uzamsal dizinleri ve hayal edebileceğiniz her türlü soruyu destekler. Terabayt veriyi yönetmek için sharding, sorgu optimizasyonu vb. Uygulamanız gerekir. Yazma yükünüz ağırsa bunu tavsiye etmem.

MongoDB: Bu büyük miktarda veriyi destekler. Basit depolama, geri alma ve sınırlı coğrafi sorgular için idealdir.

Dosya depolama: Eğer gerçekten sadece bir arşivleme sistemi kullanıyorsanız ve sorgulamak için verilerin sadece bir bölümünü kullanıyorsanız, verilerinizi dosya olarak saklamak ekonomik olabilir. Sürüm kontrolü gereksiniminiz bundan memnun olabilir.

Redis: Az miktarda “sıcak” veriyi sık sık erişmeniz gereken redis olarak saklamak için yukarıdaki seçeneklerden herhangi birini Redis Geo desteği ile birleştirebilirsiniz. Bunu önbelleğin olarak düşün.