SOLR aşağıdaki okudum

Question

performans ayarlama:

1. Ben kullanıyorsanız:

   http://wiki.apache.org/solr/SolrPerformanceFactors

   http://wiki.apache.org/solr/SolrCaching

   http://www.lucidimagination.com/content/scaling-lucene-and-solr

   Ve ben bir kaç şey hakkında sorularınız JVM seçeneği -XX:+UseCompressedStrings ne tür bir bellek tasarrufu sağlayabilir miyim? Basit bir örnek vermek gerekirse, 1 indeksli alan (string) ve omitNorms = true ve omitTf = true ile 1 depolanmış alan (string) varsa, indeks ve belge önbelleğinde ne tür bir tasarruf bekleyebilirim? Yaklaşık% 50 tahmin ediyorum ama belki bu çok iyimser.

2. Solr filtre önbelleği tam olarak ne zaman çalışıyor? Sadece AND ve birkaç OR ile basit bir sorgulama yapıyorum ve skorlara göre sıralıyorum, buna ihtiyacım var mı?
3. Belge önbelleğindeki tüm belgeleri önbelleğe almak istiyorsam, gereken alanı nasıl hesaplayabilirim? Yukarıdaki örneği kullanarak, 20M dokümanlarım varsa, sıkıştırılmış dizeleri kullanın ve depolanan alanın ortalama uzunluğu 25 karakterdir, temel olarak gerekli alan (25 bayt + small_admin_overhead) * 20M?
4. Tüm belgeler belge önbelleğinde bulunuyorsa, sorgu önbelleği ne kadar önemlidir?
5. Her belgeyi otomatik olarak doc önbelleğine yüklemek istiyorsam, *:*'un autowarm sorgusu yapacak mı?
6. Ölçekleme-lucene ve solr makalesi, FuzzyQuery'nin yavaş olduğunu söylüyor. Solr'un yazım denetimi özelliğini kullanıyorum, o zaman bulanık bir şekilde sağa doğru sorgulama yapıyorum (çünkü yazım denetimi aynı düzenleme mesafesini hesaplıyor)? Muhtemelen yazım denetimi ve bulanık sorgu her ikisi de eşit "yavaş" mı?
7. Dizeler için lucene alan önbelleğini açıklayan bölüm biraz kafa karıştırıcı. Gerekli boşluğun temel olarak indekslenmiş string alanının + bir tamsayı büyüklüğünün o alandaki benzersiz terimlerin sayısına eşit olduğunu doğru olarak okuyorum mu?
8. Son olarak, işlem hacmini en üst düzeye çıkarırken, OS disk önbelleği için yeterli alan bırakılmasıyla ilgili bir ifade vardır. “Her şeyden önce, büyük ölçekli bir dizin için, JVM'ye verdiğinizin ötesinde en az birkaç gigabayt RAM'e sahip olduğunuzdan emin olmanız en iyisidir.” Diyor. Yani bir 12GB hafıza makinem varsa (örnek olarak), OS'ye en az 2-3GB vermeliyim? İşletim sistemi tarafından gereken disk önbellek alanını, diskteki dizin boyutuna bakarak tahmin edebilir miyim?

Answer 1

1. Bundan emin olmanın tek yolu denemek. Bununla birlikte, Endekste çok az tasarruf beklerdim, çünkü indeks her seferinde bir kez gerçek dizeyi içerecek, geri kalanı da bu dizinin belgeler içindeki konumlarının verileridir. Endeksin büyük bir kısmı değiller.
2. Filtre önbellek yalnızca filtre sorgularını önbelleğe alır. Hassas kullanım durumunuz için kullanışlı olmayabilir, ancak çoğu bunları yararlı bulabilir. Örneğin, sonuçları ülkeye, dile, ürün türüne vb. Göre daraltma. Solr, sık sık kullanıyorsanız, bunun gibi şeyler için sorgu sonuçlarının yeniden hesaplanmasını engelleyebilir.
3. Gerçekçi olarak, bunu denemek ve bir profilerle ölçmek zorundasınız. EKSİKSİZ derinlemesine bilgi olmadan, kullanılan veri yapısı, başka bir şey saf SWAG'dır. Hesaplamanız, profil oluşturmayan herkes kadar iyidir.
4. Belge önbelleği, yalnızca sorguyu hesapladıktan sonra sonuçları oluştururken zaman kazandırır. Zamanınızın çoğunu sorguları hesaplarken geçirirseniz, belge önbelleği size iyi gelir. Sorgu önbelleği, yalnızca yeniden kullanılan sorgular için kullanışlıdır.Sorgularınızdan hiçbiri tekrar edilmezse, Sorgu önbelleğinizin tümünü saklamak için yeterince büyük olduğu varsayılırsa, Sorgu önbelleği kullanışsızdır (
5. ).

6-8 Pozitif değil.

Solr performans ayarlaması ile ilgili kendi deneyimlerimden, Solr'u, belgelerin depolanması için değil, sorgularla ilgilenmesi için terk etmelisiniz. Sorularınızın çoğu belgelerin yer açmasına odaklanır. Solr bir arama motoru, bir belge depolama deposu değil. Solr'un FAST olması ve en az bellek almasını istiyorsanız, o zaman tutması gereken tek şey arama amaçları için indeks bilgisidir. Dokümanların kendileri başka bir yerde saklanmalı, alınmalı ve sunulmalıdır. Tercihen bu iş için özel olarak optimize edilmiş sistemde. Solr belgenizde saklamanız gereken tek alan, belge depolama sisteminden alma için bir kimliktir.

Answer 2

Önbellekler Genelde

, önbelleğe alma performansını artırmak için iyi bir fikir gibi görünüyor, ama bu aynı zamanda sorunların bir yeri vardır:

• önbelleğe nesneler eski nesil gitmek muhtemeldir Toplamak için daha maliyetli olan çöp toplayıcı, eklemeleri ve tahliyeleri yönetmek için
• bazı ek yükleri ekler.

Ayrıca, önbelleğe alma, sorgularınızda kalıplar olmadıkça, arama gecikme sürenizi çok daha fazla geliştirmez. Aksine, trafiğinizin% 20'si birkaç sorgudan kaynaklanıyorsa, sorgu sonuçları önbelleği ilginç olabilir. Önbelleklerin yapılandırılması, sorgularınızı ve belgelerinizi çok iyi bilmenizi gerektirir. Yapmazsanız, muhtemelen önbelleğe almayı devre dışı bırakmanız gerekir.

Tüm önbellekleri devre dışı bıraksanız bile, OS G/Ç önbelleği sayesinde performans hala oldukça iyi olabilir. Pratik olarak, bir dosyanın aynı bölümünü tekrar tekrar okursanız, diskten sadece ilk kez ve sonra G/Ç önbelleğinden okunması muhtemeldir. Tüm önbelleklerin devre dışı bırakılması, JVM'ye daha az bellek vermenizi sağlar, böylece G/Ç önbelleği için daha fazla bellek olacaktır. Sisteminizde 12GB bellek varsa ve JVM'ye 2GB verirseniz, bu, G/Ç önbelleğinin dizininizin 10G'ını önbelleğe alabildiği anlamına gelir (bellek gerektiren diğer uygulamalara bağlı olarak).

Sana G/Ç cache vs uygulama düzeyinde cache hakkında daha fazla bilgi almak için bu okuma salık:

https://www.varnish-cache.org/trac/wiki/ArchitectNotes

http://antirez.com/post/what-is-wrong-with-2006-programming.html

Saha önbellek

büyüklüğü Bir dize için alan önbellek (bir dizi uzunluk tamsayıları dizisi) + (tüm benzersiz dize örnekleri için bir dizi) 'dir. Yani, bir S dizesi ile, ortalama S boyutunda N örneğine sahip bir dizininiz varsa ve dizininizde M belgeleri varsa, bu alanın alan önbelleğinin boyutu yaklaşık M * 4 + N * S olacaktır.

Alan önbellek çoğunlukla faset ve sıralama için kullanılır. Çok kısa dizeler bile (10 karakterden az) are more than 40 bytes, bu sayede, çok sayıda benzersiz değere sahip bir String alanına sıralarsanız ya da yüzerseniz Solr'un çok fazla bellek gerektirmesini bekleyebilirsiniz.

Bulanık Sorgu

FuzzyQuery is slow in Lucene 3.x, but much faster in Lucene 4.x.

Bu seçtiğiniz İmla uygulanmasına bağlıdır ama Solr 3.x yazım denetleyicisi bir ihtiyacı bu yüzden (adaylarını bulmak için N-Grams kullanır düşünüyorum adanmış dizin) ve daha sonra sadece adaylar üzerinde bu sette olan mesafeleri hesaplar, bu yüzden performans hala makul derecede iyidir.