Fayansların Önbellek Hızını Artırma (TileStache)


13

Ben TileStache kullanarak vektör fayans hizmet , istediğim gibi her şeyi ayarladım. Verilerim Postgres'te saklanır ve GeoJSON döşemelerini sunmak için VecTiles sağlayıcısını kullanıyorum .

Karoların daha hızlı hizmet vermesi için tüm karolarımı önbelleğe almak istiyorum. Önbelleğimi tohumlamak için tilestache-seed.py kullanıyorum . Ben koşuyorum tilestache-tohum birçok makineye. Tilestache-tohumu zum seviyesi 13'e kadar gerçekten iyi çalıştı, ancak bundan sonra fayansları önbelleğe almak çok uzun sürüyor. Sadece Zoom Level 16 için önbelleğe alınacak 5023772 kutucuğum var ve her makinede günde sadece 100k-200k kutucuk alıyorum.

Döşemelerimin önbelleğini nasıl daha hızlı hale getirebilirim ? Tilestache-seed.py ' i ince ayarlamanın ve daha hızlı tohum yapmanın bir yolu var mı ?

Güncelleme: Tablolarımda (geometri sütununda ve verileri nereye cümlede filtrelemek için kullanılan sütunlarda) uzamsal dizinler oluşturmayı denedim ve döşeme hızında hala önemli bir artış görmedim. Bu hızda sadece Zoom 17 beni bir ay alacak ve bu süre sadece Zoom 21'e doğru hareket ettikçe katlanarak artacak

Güncelleme 2: Gerçekleştirilmiş görünümler de yapmayı denedim ve performansta fark edilebilir bir değişiklik yok, bu nedenle veritabanını optimize etmek çalışmıyor. Tilestache-seed.py'nin kendisini optimize etmem veya karoları önbelleğe almanın yeni bir yolunu geliştirmem gerektiğini düşünüyorum.

Donanım Bilgisi Önbellekleme işlemlerini 8 farklı bilgisayarda yürütüyorum, bunlardan biri 32 gb ram ile i7, diğeri 4 gb ram ile i3 ama her ikisi de bana neredeyse aynı önbellek hızını veriyor (günde yaklaşık 100k fayans)

Yanıtlar:


5

15'ten büyük zoom için, ilgi alanınızı daha küçük alanlara ayırırsanız (Sınırlayıcı kutu), tek bir makinede birden çok işlem çalıştırarak bunları daha kısa sürede önbelleğe alabileceğinizi söyleyebilirim.

Örneğin, bir makinede zoom 16 (50.000,00 kutucuğa sahip) çalıştırıyorsunuz ve ortalama taş önbellek hızınıza göre, bu işlem yaklaşık 40-50 gün içinde tamamlanacak. Bu karoları ikiye böldüğünüzü ve aynı anda makinede çalıştırdığınızı söyleyelim, o zaman 20-25 gün içinde önbellekleyebileceksiniz çünkü fayans kesme tohumlama işlemi tek bir karo önbellekleme işlemi için işlemcinizin sadece yüzde 30'unu kullanıyor ve biliyorum çünkü ben bir kez aynı sorunu var ve bazı extant kadar bu benim sorunum çözüldü.

Bir makinede veya birden çok işlemde tek bir işlem çalıştırıyorsanız, döşemenin önbellekleme hızını etkilemez, ancak CPU kullanımı artar.

Umarım bu sana yardımcı olmuştur.


Şimdiye kadar yapılacak en iyi şey gibi görünüyor, bunu denemek ve ne olacağını kontrol edeceğim.
Hasan Mustafa

Bu şimdiye kadar bulduğum en iyi çözüm olsa da, onun ideal değil (yeterince tilestache-seed.py finetune isterdi) yeterince iyi çalışıyor.
Hasan Mustafa

2

Varsayılan olarak shp2pgsql dizin oluşturmaz. Sen geçmesi gerekiyor -Ibir kayma dizin oluşturmak yapmak. http://postgis.net/docs/manual-1.3/ch04.html#id435762

\d tablenamePsql içinde çalışarak tablonuzun bir indeksi olup olmadığını kontrol edin . Dizin listesinde "gist" (farklı bir dizin seçmediğiniz sürece) ve geometri sütun adınızı içeren bir satır olmalıdır.

Siz de aslında ardına ekleyebilir, bkz http://postgis.net/docs/manual-1.3/ch03.html#id434676 (lossiness korkutmak size hakkında not izin vermeyin):

CREATE INDEX [indexname] ON [tablename] USING GIST ( [geometrycolumn] );

Muhtemelen sorgularınızda uzamsal olmayan sütunlar kullandığınızdan, genellikle arama için kullanılan her sütun için dizinler oluşturmak istersiniz. Örneğin aşağıdaki gibi bir sorgu varsa SELECT * FROM roads WHERE priority = 3;o zaman prioritykullanılan ve onunla olacak önemli ölçüde hız-up işler için bir dizin ekliyor:

CREATE INDEX idx_roads_priority ON roads(priority);.


Postgres eklentisi "PostGIS Shapefile ve DBF yükleyici" kullandım, bir dizin yarattı: CREATE INDEX scale_geom_idx ON scale USING gist (geom). , otomatik olarak şekil dosyalarımı içe aktardığımda. Ek dizinler oluşturmalı mıyım?
Hasan Mustafa

Çok satır var mı? Vektör kutucuğu oluşturma işleminiz diğer özelliklere (örn. Verilerin alt seçimleri) bağlı mı?
bugmenot123

Her ikisi için de evet, bazı tablolarda satır bir sürü var, POI tablo yaklaşık 975k satır ve Postgres içine almadan önce benim yol shapefile 8.5gb oldu. Yakınlaştırma düzeylerine göre verileri filtrelemek için sorgular kullanıyorum: "10": "SELECT wkb_geometry AS geometri , öncelik, ad, yol_DÜZENİ yollardan NEREDE öncelik IN (5,4,3)" Bu yollara dönmek için kullandığım bir sorgu zoom seviyesi 10
Hasan Mustafa

Sonra bir WHERE yan tümcesinde kullandığınız her sütun üzerinde bir dizin oluşturun. Gerekirse çok sütunlu dizinler de oluşturabilirsiniz.
bugmenot123

Bunu nasıl yapabilirim, indeksleri hangi temelde yapmalıyım?
Hasan Mustafa

1

Standart bir sorgu kullanıyorsanız denemeniz gereken başka bir şey de sorgudan materyalleştirilmiş bir görünüm oluşturmak ve karolarınızı bundan oluşturmaktır: http://www.postgresql.org/docs/9.3/static/sql-creatematerializedview.html

Bunun ne yapacağını sorguyu saklayan bir tablo haline getirebilirsiniz (böylece ileride potansiyel olarak güncelleyebilirsiniz). Alt MV'lerde uzamsal indekslerin bulunduğundan emin olun ve sonra mümkün olduğunca hızlı olacaksınız.

Ne olabilir ki, uzamsal bir dizininiz var, ancak o zaman verilerin sadece bir kısmını seçiyorsunuz, yani artık uzamsal dizini kullanmıyorsunuz ...


Fayanslarımı yapmak için sorguladığım 11 farklı tablo var, bu 11 materyalize görünüm yapmak zorunda kalacağım anlamına mı geliyor? Sorgularım da Zoom Seviyelerine göre değişiyor.
Hasan Mustafa

Yeterince hızlı değilse, belki de en yavaş seçim ifadelerinin görünümlerini geliştirmek onu geliştirebilir. Gerekirse, birden çok tablo da dahil olmak üzere herhangi bir select deyiminin bir MV'sini yapabileceğinizi unutmayın.
Alex Leith

Tüm sorgularıma dayanarak tek bir MV yaparsam bu işe yarayacak mı?
Hasan Mustafa

Bunu yapamazsın. En yavaş sorgunuz için, belki de tek bir yakınlaştırma düzeyi için bir tane yapın ve i'yi daha hızlı yapıp yapmadığını görün.
Alex Leith

1
Peki bu durumda veritabanı optimize yardımcı olmaz. Daha derine bak.
Alex Leith
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.