Hızlı (<1s) okuma sorgusu performansına sahip büyük (> 22 trilyon öğe) coğrafi mekansal veri kümesi

Hızlı okuma sorgusu performansı gerektiren büyük bir coğrafi veri kümesi için yeni bir sistem tasarlama sürecindeyim. Bu nedenle, herkesin aşağıdaki durumda gerekli performansı elde etmek için uygun DBMS'ler, veri yapısı veya alternatif yöntemler hakkında mümkün / uygun olduğunu düşünüp düşünmediğini görmek istiyorum:

Veriler, küresel kapsama sahip olacak olan işlenmiş uydu radar verilerinden sürekli olarak üretilecektir. Dünyanın uydu çözünürlüğü ve arazi kapsamına dayanarak, dünyadaki 75 milyar ayrı yerde değer üretmek için tüm veri setini tahmin ediyorum. Tek bir uydunun ömrü boyunca, çıkış bu konumların her birinde 300'e kadar değer üretecektir (bu nedenle toplam veri kümesi> 22 trilyon değer). Bu bir uydu içindir ve yörüngede bir saniye vardır, yeni iki yılda başka bir iki planlanmıştır. Yani çok fazla veri olacak! Tek bir veri öğesi çok basittir ve yalnızca (boylam, enlem, değer) oluşur, ancak öğe sayısı nedeniyle 100 TB'a kadar üretecek tek bir uydu tahmin ediyorum.

Yazılı verilerin asla güncellenmesi gerekmemelidir, çünkü yalnızca yeni uydu alımları işlendikçe büyüyecektir. Yazma performansı önemli değildir, ancak okuma performansı çok önemlidir. Bu projenin amacı, her bir noktanın ortalama, gradyan veya zaman içindeki bazı işlevlerine göre renkli bir değere sahip olduğu google haritaları üzerinde bir katman gibi basit bir arayüz aracılığıyla verileri görselleştirmektir. (gönderinin sonunda demo).

Bu gereksinimlerden, veritabanının ölçeklenebilir olması gerekir ve muhtemelen bulut çözümlerine bakacağız. Sistem, "yakın (lat, lon)" ve "(kutu) içindeki noktalar" gibi coğrafi uzamsal sorgularla başa çıkabilmeli ve tek bir noktayı bulmak için <1'lerin okuma performansına ve en fazla 50.000 puan (200.000 puana kadar tercih edilebilir).

Şimdiye kadar 111 milyon yerde ~ 750 milyon veri öğesi test veri setim var. Tamam olan bir postgres / postGIS örneğini denedim, ancak parçalanma olasılığı olmadan bu veri büyüdükçe başa çıkabilecektir. ve parçalama ile veri hacmi ile ölçeklendirme yeterli olabilir. Kısa bir süre önce elasticsearch hakkında biraz bilgi edindim, bu yüzden bu konuda herhangi bir yorum benim için yeni olduğu için yararlı olacaktır.

İşte tam veri seti ile elde etmek istediğimiz şeyin hızlı bir animasyonu:

Bu gif (postgres denememden), her biri ~ 200.000 puan içeren ve her birini oluşturmak için ~ 17s alan önceden hesaplanmış raster döşemelerine (6x3) hizmet ediyor. Bir noktayı tıklatarak, grafik tüm tarihi değerleri <1'lerde en yakın konumda çekerek yapılır.

Uzun yazı için özür dileriz, tüm yorum / tavsiye bekliyoruz.

Yere göre parçalayabilirsiniz. Dünyayı bir ızgaraya bölün ve bu karedeki her kareyi bir sunucuda bulundurun. Buluttan bahsettiğinizden bu, bulut için çok uygun olacaktır. Tabii ki sonuçları birden çok sunucudan manuel olarak birleştirmeniz gerekecek.

Bu şekilde istediğiniz herhangi bir veritabanı çözümünü kullanabilirsiniz. Kendi kendine ölçeklenebilir olması gerekmez.

Tek tek kareler farklı miktarlarda verilere sahip olacaktır. Onlar için farklı boyutta makineler kullanabilirsiniz (bu bulut olduğu için) veya aynı makineye birden fazla küçük parça koyabilirsiniz.

Bu gölgeleme şeması, gerçekleştirdiğiniz sorgu türleri için mükemmeldir çünkü her bir sorgunun yalnızca çok az sayıda parçaya dokunması gerekir. Her sorgu için tüm zaman parçalarına dokunulması gerektiğinden zamana göre parçalanma daha kötüdür. Rastgele parçalama aynı soruna sahiptir.

Sonuç olarak bu, sorgu kalıbı parçalama şemasına çok iyi uyduğu için kolay bir parçalama durumudur.

Aslında, bunun için bir veritabanına ihtiyacınız olup olmadığını merak ediyorum. Belki dünyayı 1000x1000 veya daha küçük karolara bölebilir ve her karo için blob deposunda bir düz dosyaya sahip olabilirsiniz. Blob depolama 1M blobları hiç umursamıyor.

Bu depolama şeması ile bir sorgu yürütmek kavramsal olarak çok kolaydır. Verileri birden çok ızgara çözünürlüğünde de yedek olarak saklayabilirsiniz.

Okuma sorgularınızın ne kadar güncel olması gerekir?

Haritanın yalnızca en son ölçümü göstermesi gerekiyorsa veritabanını zamana göre bölümleyebilirsiniz. Bu, harita için sorgu yükünüzü azaltır.

Belirli bir noktanın geçmişi için, geçmişi gösteren x ve y ile ikinci bir mağaza tutabilirsiniz. Bu, geçmiş veriler değişmeyeceğinden gece yenileme / güncelleme ile yapılabilir.

Ardından, farklı zum düzeylerindeki haritalarla entegrasyon için ortalamaları daha kaba çözünürlüklerde önceden hesaplayabilirsiniz. Bu, büyük harita alanları için alınacak nokta sayısını azaltacaktır (uzaklaştırma). Daha küçük alanları sorgulayan daha yakınlaştırılmış haritalarda daha ince çözünürlükler kullanılır. Bunu gerçekten hızlandırmanız gerekiyorsa, fayansları lekeler olarak hesaplayabilir ve uygulamanızda yorumlayabilirsiniz.

Bunlar, toplu bilgilerin yeniden hesaplanmasını içereceğinden, sorgu sonuçlarında bir miktar gecikme olabilir. Ne kadar gecikmenin kabul edilebilir olduğuna bağlı olarak, okumalarınızı optimize etmek için bu tür bir yaklaşımı kullanabilirsiniz.

Tamam, puanlarınızın zaman içinde ortalamaları hesaplanması gerekir. Bu hesaplama ile, raster değerleri sorgulama için önceden hesaplanabildiğinden, gerçek sorgularınız 22 trilyon maddeden oldukça fazla düşüyor.

İki sorgu sınıfı var gibi görünüyor - biri geçerli görünüm penceresinde hangi konumların bulunduğunu anlamak ve diğeri bu noktalar için istenen istatistiği sağlamak için. Benim önerim, her biri için ayrı, özel araçlar kullanmaktır.

Tüm ölçümlerin aynı 75Bn nokta kümesiyle ilgili olduğunu varsayıyorum. Bu lat / longs, bir kez oluşturulduktan sonra statiktir. Bir kerelik maliyetle gruplanabilir, toplanabilir ve dizine eklenebilir. Bu nedenle bölgeye ve yakınlaştırma düzeyine göre parçalanmayı öneriyorum. Her bir kırığın boyutu, her bir GIS örneğinden elde edilebilecek performans tarafından yönlendirilecektir.

CBS, bir zaman serisi veritabanına iletilen bir dizi nokta döndürür. Bu, ölçülen değerleri tutar ve agregaları gerçekleştirir. KDB farkında olduğum biri. Senaryonuzdan daha az anahtar ancak anahtar başına daha fazla veri noktasına sahip olacak menkul kıymet alım satımını hedefler.

Anahtar değerlerin GIS sunucusundan timeseries DB'sine aktarılmasının bir maliyeti olacaktır. Benim hipotezim, bu maliyetin göreve özgü zaman çizelgeleri veri tabanındaki daha hızlı işleme ile geri ödeneceği yönündedir. Sorunun ifadesine göre, tek bir örnek tüm verileri tutamayacak gibi görünüyor, bu nedenle bazı sunucular arası trafik kaçınılmaz görünüyor. Bileşenlerin göreceli hızı göz önüne alındığında, uzak bir sunucuya önbelleğe alınmış verileri olan bir anahtar kümesi göndermek, verileri yerel diskten okumaktan daha hızlı olacaktır.

Nokta bulma ve değer hesaplama parçaları birbirlerine yerel olabilirse, elbette yanıtın daha hızlı olmasını beklerdim. (Sınırlı) anlayışım, belirli bir noktaya en yakın N komşusunu bulmak önemsiz bir görevdir. Bu yüzden onu gerçekleştirmek için belirli bir yazılım kullanmayı önerdim. Nokta bulma şuna indirgenebilirse:

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

bu kısım değer depolama yazılımı tarafından ele alınabilir ve CBS mimariden kaldırılabilir.

Ben böyle bir sistem kurmadım. Gerçekten burada yüksek sesle düşünüyorum. Petabyte ölçeğinde hazır çözüm yoktur. Bununla birlikte, birçok uydu veri sağlayıcısı vardır, böylece sorununuz izlenebilir. İyi şanslar.