11

Uygulamamızın bir bölümünü büyük bir veri kümesi (> 2000 varlığı) yüklemesi ve bu sette hesaplama yapması gerekiyor. Her varlığın boyutu yaklaşık 5 KB'dir. zamanın kendisi çok küçük hesaplama gerçekleştirmek için gerekli süre bizim ilk, naif, uygulama günüGAE datastore'dan büyük (> 2000) varlık miktarını 1 saniyeden daha kısa sürede nasıl alırsınız?

, darboğaz < (zaman (2000 varlıklar için ~ 40 saniye) bütün varlıkları yüklemek için gerekli gibi görünüyor 1 saniye).

Biz varlıklar alma hızlandırmak için çeşitli stratejiler denemişti: 2000 varlıklar için ~ 20 saniye:

  • Bölme birkaç paralel örneklerini içine alma isteği ve sonra sonucu birleştirilmesi.
  • Varlıkları, yerleşik bir arka uçta yerleştirilen bir bellek içi önbellekte saklamak: ~ 2000 öğesi için 5 saniye.

hesaplama dinamik olarak yazma anda on hesaplama yapıyor ve bizim durumumuzda çalışmıyor sonucu depolamak, bilgisayarlı gerekmektedir.

Bir saniyeden kısa bir süre içinde ~ 2000 öğeyi alabilmeyi umuyoruz. Bu GAE/J yeteneği içinde mi? Bu tür bir geri alma için uygulayabileceğimiz başka stratejiler var mı?

GÜNCELLEME: bizim kullanma durumu ve paralelizasyon sonucu hakkında ek bilgi sunmak:

  • Biz veri deposuna aynı türden birden fazla 200.000 varlıklara sahip ve operasyon alma salt yazılır.
  • 10 paralel çalışan örneğini denedik ve elde ettiğimiz tipik bir sonuç this pastebin'da görülebilir. Varlıkları ana örneğe geri aktarırken gereken serileştirme ve serileştirme işleminin performansı engelliyor gibi görünüyor.

GÜNCELLEME 2:

  1. en bunun iyi bir yatırım olmadığını bilmek analiz edilmesi gereken bir StockDerivative varlık var diyelim: Biz yapmaya çalışıyoruz ne bir örnek verilmesi ya da değil. Gerçekleştirilen analiz, hem harici (ör., Kullanıcının tercihi, piyasa koşulu) hem de dahili (yani, kuruluşun özelliklerinden) birçok faktöre dayanan ve tek bir "yatırım puanı" değeri çıkaran karmaşık hesaplamalar gerektirir.
  2. Kullanıcı, türevlerinin yatırım puanına göre sıralanmasını talep edebilir ve N-sayısında en yüksek sayıda türev ile sunulmasını isteyebilir.
+1

Kullanıcılara yönelik bir istek için neden bu kadar çok varlığı almanız gerekiyor? Gerçekte yaptığınız şey hakkında daha fazla bilgi verebilir misiniz? –

+0

Kullanıcıya, bazı giriş parametrelerine ve kullanıcı tanımlı bir işleve dayalı olarak en büyük karı veren bir varlık alt kümesi sunmamız gerekiyor. Kullanım durumumuzda, arama alanını yalnızca en iyi ~ 2000 varlık alt kümesine indirgeyebiliriz. –

+0

Peter'ın işaret ettiği gibi, tek bir kullanıcı sorgusu için bir bilgi verisi almaya çalışıyorsunuz. Bunu bir şekilde yeniden yapılandırmanız ve yaptıklarınız hakkında daha fazla bilgi vermeden, nasıl olduğunu söylemek zor. –

cevap

0

Sonunda, bir saniyeden küçük bir kez> 2000 öğeyi alabildiğimiz görünmüyor, bu yüzden orijinal soruda açıklandığı gibi arka uç örneğimize yerleştirilen bellek içi önbelleğe almayı kullanmak zorunda kalıyoruz . Birisi daha iyi bir cevapla geliyorsa veya bu sorun için daha iyi bir strateji/uygulama bulsaydık, kabul edilen cevabı değiştirir veya güncellerdim.

+0

Bu uzun zaman önceydi ve GAE o zamandan beri çok gelişti. O zamandan beri bunun için daha iyi bir çözüm buldun mu? Aynı performans darboğazına da vurduk. – shelll

+0

@shelll Maalesef, o anda bu konuyu yürüttüğüm şirket GAE'den uzaklaştı ve şimdi GAE'de hiçbir şey yapmayan başka bir şirkete taşındım, bu yüzden bunun için en iyi uygulama çözümünü bilmiyorum şu anda sorun. –

0

Bu çok ilginç, ama evet, olası & Iv görülen bazı aklı almaz sonuçlanır.

Aynı şeyi yapardım; harita-azaltma konsepti

Eğer kaç paralel örneğini kullandığınız konusunda daha fazla metrik vermeniz gerekiyorsa & neleri kullanırsınız?

Ayrıca, işlem başına veya alma & depolama alma içerir?

kaç elemanları size veri deposunda var? 4000? 10000? Nedeni, önceki isteğinizden önbelleğe alabilmenizdir.

Saygılarımızla

+0

Daha fazla bilgi içeren soru sorun. Gördüğünüz boggling sonuçlarının bir örneğini paylaşır mısınız? –

1

kullanın Memcache. Yeterli olacağının garantisini veremem, ama eğer yapmazsan muhtemelen başka bir platforma geçmek zorundasın.

+0

Uygulama motoru durumu sayfasına bakıldığında, memcache multi-get'in ~ 60 MB/sn'lik bir çıkışı vardır ve bir saniyenin sonunda 2000 varlıklarını @ 5KB'yi yükleyebilir. Ancak uygulamanızın memcache'yi yoğun olarak kullanan başka bir parçası var ve önbellek tahliyesinin sık olacağından bunun büyük bir yanlışlığa neden olacağından endişe ediyoruz. –

+0

Önbellek kotalarının ne olduğundan emin değilim (kesin bir sayı bulamadı), ancak maksimum varlık boyutu 1 MB olduğu için 10 MB'dan daha büyük olduğunu tahmin ediyorum; Bir getirme için maksimum boyut 32 MB'dir. Bu rakamlar göz önüne alındığında, bunun büyük olasılıkla 64 MB'den (* çok * muhafazakar olmaktan) daha az olduğu görülüyor. – Viruzzo

+0

Gönderilen ve alınan veriler için kota ayrıntıları panelindeki istatistikler gigabayt olarak bulunduğundan, tahminin bu veri ölçeği için sorun olmayacağını tahmin ediyorum. – Viruzzo

4

200.000 by 5kb 1GB'dir. , ürününü largest arka uç örneğinde bellekte saklayabilir veya birden çok örneğiniz olabilir. Bu, en hızlı çözümü olan olur - hiçbir şey hafızayı atmaz.

Eğer hesaplaması için her varlığın bütün 5kB gerekiyor mu? Hesaplamadan önce sorgulama yaparken tüm 200k varlıklara ihtiyacınız var mı? Sorgular tüm varlıklara mı dokunuyor?

Ayrıca BigQuery göz atın. İhtiyaçlarınıza uygun olabilir.

+0

Bu oldukça iyimser olurdu. :) 5KB, serileştirilmiş varlığın boyutudur, sönük nesne, bellekte bu miktarın birkaç katını alır. Testlerimize dayanarak, 1GB belleğe sahip bir B8 arka ucunun 40k varlıkları önbelleğe alabileceğini tahmin ediyoruz. Bellek içi önbellekten ~ 2000 öğeyi almak çok hızlıdır (~ 500 ms), ancak önbellekten arka uçtan gelen istekleri istenen örneğe göndermek birkaç saniye sürdü. Yalnızca varlığın çeşitli özelliklerine ihtiyacımız var, başlangıç ​​sorgumuz yüklenen varlıkların sayısını 200k'dan ~ 2k'a düşürdü ve sorgu türdeki tüm varlıklara uygulandı. –

0

Çözümümüz periyodik bir arka plan görevi varlıkları okuma ve bir json damla sonucu depolayarak içerir. Bu sayede 100 binden fazla satır hızla geri dönebiliriz. Tüm filtreleme ve sıralama, SlickGrid'in DataView modeli kullanılarak javascript ile yapılır. Birisi zaten yorumladı gibi

, MapReduce GAE gitmek yoludur. Ne yazık ki MapReduce için Java kütüphanesi benim için kırılmıştı, bu yüzden tüm okumayı yapmak için optimal olmayan bir görev kullanıyoruz ancak MapReduce'un yakın gelecekte (ve/veya Pipeline API'sine) girmesini planlıyoruz.

En son baktığımda, Blobstore öğesinin sıkıştırılmış varlıkları> 1MB döndürmediğini, böylece içeriği sıkıştırılmış bir varlıktan yüklediğimiz ve belleğe genişletdiğimiz için, bu şekilde son yükün gziplendiğini unutmayın. Bundan hoşlanmıyorum, gecikmeyi başlatıyor, umarım yakında GZIP ile sorunları düzeltirler!

İlgili konular