Şu anda coğrafi verilerimizin yeniden tasarlanması için çalışıyoruz. Onların evriminin şu ana kadar 20 yıldan uzun sürdüğünü söylemeliyim. Jeo uzamsal veri yönetiminde aşağıdaki temel özellikleri belirledik:
- eşzamanlı düzenleme
- veri bölümlerini okuma veya yazma izinleri
- verilere dayanan hizmetleri çalıştırırken güncellemeler (İşlemler ve ACID paradigması)
- iç ve dış şema (iç şemayı değiştirmek hizmetleri etkilememelidir)
- büyük miktarda veriyi (terabayt raster ve gigabayt vektör verisinin hundret'leri) saklama ve bunlara erişme yeteneği
- farklı katmanlar arasında veri tutarlılığı (her parsel bir bölgeye aittir)
Aşağıdaki yaklaşımları değerlendirdik, işte onlar hakkında söyleyebileceklerim:
ESRI Kurumsal Coğrafi Veri Tabanı(ArcGIS 10.1); daha önce sahip olduklarımızla (SDE) hemen hemen aynıydı, ancak işlemlerin üstesinden gelmek için genişleme özelliğine sahip. Ancak bu gerçekten bir Kurumsal Coğrafi Veri Tabanı değil, benim görüşüme göre SDE sadece bir çalışma grubunda bir coğrafi veri sunucusu olarak çalışıyor, insanların sabah 8:00 - 20:00 arasında çalıştığı ve daha sonra bakım işleri için çevrimdışı duruma getirebileceğiniz, işlem taahhüt (ESRI konuşmasında mutabakat ve postalama), çoğaltma, vb ... Bu verilerin üstüne hizmetler oluşturuyorsanız, çoğaltılmış bir üretim veritabanını (işin yapıldığı yerde) bir hazırlama veritabanını kullanmanız gerekir. Bu hemen hemen programlama / programlama ve konuşlandırma ile aynıdır. Zengin özellikli ESRI paketinin sunduğu özellikler oldukça hoş olsa da, esneklikten yoksundur (örneğin şema değişiklikleri veya insanlar çalışırken bakım işleri, örneğin dizin oluşturma).
Düz Dosyalar ve Sürüm Kontrol SistemiGit'i seçiyoruz (zaten bir GeoGit olduğunu bilmiyordum). Evet, arkadaşlarımdan bazıları ve ben de yazılım mühendisliğinden geliyorum. Hepsi çok basit olabilir. Sanırım bu onun sorunu: Bir araba üreten bir araba tamircisi gibi. Onun için bakımı basit olacak, ama aynı zamanda emin olmak için araba sürmek ve çirkin olmak da can sıkıcı olacak. Ayrıca bazı büyük dezavantajları olduğunu düşünüyorum: Sürüm 2 TeraByte (veya daha da fazla ikili) Rasterdataset nasıl kontrol edilir? Ve hangi formatta? Metin tabanlı formatlar (örneğin GML) kullanıyorsanız, vektör verileri kolayca sürüm kontrol edilebilir, ancak o zaman milyar satırlık bir veri kümesiyle çalışmak da zordur. Etkili bir kullanıcı izni yönetimi yapıp yapamayacağımızdan hala emin değilim çünkü herkesin her şeyi düzenlemesine ve hatta görüntülemesine izin verilmemesi gerekiyor. Ve aynı anda 4 kullanıcı tarafından yoğun olarak düzenlenmiş bir vektör veri kümesini nasıl birleştirirsiniz? En azından bunların hepsini etkin bir şekilde yapabilmek için gerçek bir bilgisayar bilimcisi / programcısı olmalısınız ... GIS kullanıcılarımız planlamacılar, anketörler, jeologlar vb. Programcılar gibi sürüm soylarını düşünmeleri ya da dallanmaları gerektiği gibi kullanmaları bir problemdir. Bununla birlikte, veri depolarını paylaşılan repolar olarak düşünmek ilginç bir fikirdir.
Basit bir konteyner olarak düz tabled veritabanı . Aynı SDE'nin yaptığı gibi, ancak SDE’de olmayan şeyler. Bakımı zor, çünkü aslında bir RDBMS'nin size sunduğu avantajlardan faydalanmıyorsunuz. Evet, sadece bir veritabanındaki her şeyi yüklemek çok basittir, ancak bu kesinlikle veri yönetimi değildir.
Bigdata ve NoSQL . Düz dosyalar ve düz masalarla aynı problemler. Bence web kullanımı için basit bir dosya sistemi API. Evet, web’de iyi çalışır ve evet, sadece belgelerinizi atmak kolaydır, ancak sanırım terabaytlık (muhtemelen raster) veriler üzerinde mekansal veri analizi yapmak istersem, seri hale getirilmemesine ve seri hale getirilmemesini istiyorum HTTP arayüzü üzerinden.
GÜNCELLEME 2018: İşte bir çok ivme yaratan birçok yeni şey. Birkaç isim:
- Bulut bloğu depolama ve HDFS
- Python / düzgün / Dask Yığını
Apache Spark
- Vektör verileri için GeoMesa / GeoWave
- Tarama verileri için GeoTrellis
ve daha fazlası
- Kapsamlı klasik veritabanı modellemesi(bir RDBMS ile). Asıl sorun, verileri herhangi bir yere bırakmanın zor olması ve gelecekteki her ihtiyaca uygun olmasını ummasıdır. Ancak bir veritabanında sağlam bir veri modeli (OSM de bunu da yaptı) belirlemek için bir miktar zaman koyarsanız, tüm avantajlarından faydalanabilirsiniz. Dağıtılmış işlemlerde verileri düzenleyebilir ve güncelleyebiliriz, aynı zamanda temel şemalarını da değiştirebiliriz; hizmetler yine de aynı verilerin dış şemalarına dayanır, bakımını yapabilir, tutarlılığını kontrol edebilir, izinleri verebilir ve izinleri reddedebiliriz, Çok büyük miktarlarda veriyi hala hızlı bir şekilde erişebildiğimiz halde depolayabiliyor, tarihî veri modellerini oluşturabiliyoruz ve şeffaf bir şekilde vb. tetikleyebiliyoruz. Sql sunucusunu kullandığımız için hala yerel bir raster türünden yoksun, ancak diğer veritabanı satıcıları bunu zaten öneriyor.
Bence ilişkisel veri tabanı modeli, son birkaç yıldaki (bundan önce BLOB Konteynerlerinin bulunduğu mekansal) mekansal veri türleri ile mekansal dünyada ayağa kalktığını ve hala veriyi saklamanın en esnek ve profesyonel şekli olduğunu düşünüyorum. Bu, VCS yaklaşımları veya NoSQL ile desteklenmemesi gerektiği anlamına gelmez, ancak bu yaklaşımların, profesyonel merkezi bir mekansal veri yönetimi biçiminden ziyade, kullanıcı gruplarında bir veri dağılımı biçimi olarak daha muhtemel olduğunu düşünüyorum. Ayrıca OSM, büyük miktarda veri ithal etmek (kalabalığın değil, Avusturya kaynaklı OSM verilerinin çoğu, kalabalık kaynaklı değil bir günde ithal edildi) ve fayans üretimi gibi, kalabalığın sağlayamadığı birçok görevi merkezileştirmiştir. İşbirlikçi (kalabalık kaynaklı) kısım gerçekten çok önemlidir, ancak işin sadece yarısıdır.
Sanırım bunun çoğunu yeniden ifade etmem ve daha fazla gerçek vermem gerekiyor. Bunun gibi bir soruyu birkaç saat içinde kapsamlı bir şekilde cevaplamak zor, önümüzdeki günlerde cevabımın kalitesini arttırmaya çalışacağım.