Bir arama hizmetinin kapasitesini tahmin edin ve yönetin

Belirli bir fiyatlandırma katmanında bir arama hizmeti ve kilitleme oluşturmadan önce kapasitenin nasıl çalıştığını ve iş yükü dalgalanmasına uyum sağlamak için çoğaltmaları ve bölümleri nasıl ayarlayabileceğinizi anlamak için birkaç dakikanızı yararlanın.

Azure Bilişsel Arama, kapasite çoğaltmaları ve bölümleri temel alır. Çoğaltmalar, arama altyapısının kopyalarıdır. Bölümler depolama birimleridir. Her yeni arama hizmeti her biri ile başlar, ancak iş yüklerini dalgalanmaya yetecek şekilde her bir kaynağı birbirinden bağımsız olarak ölçeklendirebilirsiniz. Kaynak ekleme işlemi faturalandırılabilir.

Kopyaların ve bölümlerin işleme hızı ve disk GÇ gibi fiziksel özellikleri hizmet katmanınagöre farklılık gösterir. Standart üzerinde sağladıysanız çoğaltmalar ve bölümler temel olanlardan daha hızlı ve daha büyük olur.

Kapasite değiştirme işlemi anlık değildir. Özellikle büyük miktarlarda veri içeren hizmetlerde, bölümleri komisyon veya kullanımdan kaldırmak bir saate kadar sürebilir.

Bir arama hizmetini ölçeklendirirken aşağıdaki araçlar ve yaklaşımlardan seçim yapabilirsiniz:

• Azure portalındaki
• Azure PowerShell
• Azure CLI
• Yönetim REST API'si

Kavramlar: ara birimler, çoğaltmalar, bölümler, parçalar

Kapasite, esnek yapılandırmaların desteklenmesi için temel bir parça mekanizması kullanılarak, bölüm ve çoğaltmaların birleşimlerinde ayrılabilecek arama birimlerinde ifade edilir:

Aşağıdaki diyagramda çoğaltmalar, bölümler, parçalar ve arama birimleri arasındaki ilişki gösterilmektedir. İki çoğaltma ve iki bölümden oluşan bir hizmette, tek bir dizinin dört arama birimi arasında nasıl yayıldığından bir örnek gösterir. Dört arama biriminin her biri, dizinin parçaları yalnızca yarısını depolar. Sol sütundaki arama birimleri ilk bölümden oluşan ilk parçayı depolarken, sağ sütundaki parçaların ikinci yarısını depolarken ikinci bölümden oluşan bir şekilde depolar. İki çoğaltma olduğundan, her bir dizin parçanın iki kopyası vardır. En üstteki satırdaki arama birimleri, ilk yinelemeyi kapsayan, alt satırdaki diğer bir kopyayı ikinci çoğaltmadan oluşan başka bir kopya depolarken bir kopya depolar.

Yukarıdaki diyagramda yalnızca bir örnek vardır. Birçok bölüm ve çoğaltma kombinasyonu, en fazla 36 toplam arama birimine kadar mümkündür.

Bilişsel Arama, parça yönetimi bir uygulama ayrıntısı ve yapılandırılamayan, ancak bir dizinin parçalı olduğunu bilmek, derecelendirme ve otomatik tamamlama davranışlarındaki zaman zaman anormallikleri anlamaya yardımcı olur:

• Sıralama bozukluileri: arama puanları önce parça düzeyinde hesaplanır ve sonra tek bir sonuç kümesine toplanır. Parça içeriğinin özelliklerine bağlı olarak, bir parçadaki eşleşmeler, başka bir parçadaki eşleşmelerle daha yüksek bir şekilde derecelendirilir. Arama sonuçlarındaki sayaç sezgisel derecelendirmeme bildirimini fark ederseniz büyük olasılıkla, özellikle de dizinler küçük olduğunda parçalama etkileri yüksektir. Puanları tüm dizinde küresel olarak hesaplamaseçeneğini belirleyerek bu derecelendirme bozuklukilerini önleyebilirsiniz, ancak bunu yapmak bir performans cezası olur.

• Otomatik tamamlama bozuklukları: kısmi olarak girilen bir terimin ilk birkaç karakterinin üzerinde eşleşme yapıldığında otomatik tamamlama sorguları, yazım içinde küçük sapmalar sağlayan benzer bir parametre kabul eder. Otomatik tamamlama için, belirsiz eşleştirme, geçerli parça içindeki koşullara göre kısıtlanmıştır. Örneğin, bir parça "Microsoft" ve kısmi "micor" terimi girilmişse, arama altyapısı bu parça içinde "Microsoft" ile eşleşir, ancak dizinin kalan bölümlerini tutan diğer parçalar üzerinde değildir.

Tahmine yaklaşıyoruz

Hizmetin kapasitesi ve maliyetleri, el ile çalışmaya devam ediyor. Katmanlar iki düzeyde sınırlar yapar: içerik (bir hizmetteki dizinlerin sayısı, örneğin, bir hizmet) ve depolama alanı. Her ikisini de göz önünde bulundurmanız önemlidir çünkü ilk ulaşılan sınır etkin limit.

Dizinlerin ve diğer nesnelerin sayısı genellikle iş ve mühendislik gereksinimlerine göre belirlenir. Örneğin, etkin geliştirme, test ve üretim için aynı dizinin birden fazla sürümüne sahip olabilirsiniz.

Depolama ihtiyaçları, oluşturmayı düşündüğünüz dizinlerin boyutuna göre belirlenir. Tahminlerle ilgili olarak sağlam bir buluşsal yöntem veya genellik yoktur. Bir dizinin boyutunu belirlemenin tek yolu derlemeamaçlıdır. Boyutu, içeri aktarılan verileri, metin analizini ve öneri araçları, filtrelemesini ve sıralamayı etkinleştirip etkinleştirmeyeceğinizi, dizin yapılandırmasını temel alır.

Tam metin arama için, birincil veri yapısı, kaynak verilerden farklı özelliklere sahip olan ters bir dizin yapısıdır. Ters bir dizin için boyut ve karmaşıklık, içeriğe göre belirlenir, bu, içinde yer alan veri miktarına göre değildir. Yüksek artıklığa sahip büyük bir veri kaynağı, yüksek oranda değişken içerik içeren küçük bir veri kümesinden daha küçük bir dizin oluşmasına neden olabilir. Bu nedenle, özgün veri kümesinin boyutuna bağlı olarak dizin boyutunu çıkarsmak nadiren mümkündür.

Dizin üzerindeki, filtreleri ve sıralamayı etkinleştirme gibi öznitelikler, depolama gereksinimlerini etkiler. Öneri araçları 'in kullanımı, depolama etkilerine da sahiptir. Daha fazla bilgi için bkz. öznitelikler ve dizin boyutu.

Ücretsiz katman ile tahmin edin

Kapasiteyi tahmin etmek için bir yaklaşım ücretsiz katmanla başlamadır. Ücretsiz hizmetin üç Dizin, 50 MB depolama alanı ve 2 dakikalık dizin oluşturma süresi sunduğunu unutmayın. Tahmini bir dizin boyutunu bu kısıtlamalarla tahmin etmek zor olabilir, ancak bunlar şu adımlardan biri:

• Ücretsiz bir hizmet oluşturun.

• Küçük, temsili bir veri kümesi hazırlayın.

• Bir dizin oluşturun ve verilerinizi yükleyin. Veri kümesi, Dizin oluşturucular tarafından desteklenen bir Azure veri kaynağında barındırılıyorsa, dizini oluşturmak ve yüklemek için portalda veri alma Sihirbazı 'nı kullanabilirsiniz. aksi takdirde, dizini oluşturmak ve verileri göndermek için REST ve postman veya Visual Studio Code kullanmanız gerekir. Gönderim modeli, verilerin, belgedeki alanların dizindeki alanlarla karşılık geldiği JSON belgeleri biçiminde olmasını gerektirir.

• Dizin hakkında boyut gibi bilgileri toplayın. Özellikler ve özniteliklerin depolama üzerinde bir etkisi vardır. Örneğin, öneri araçları (arama-yazma sorguları) ekleme, depolama gereksinimlerini artıracaktır.

  Aynı veri kümesini kullanarak, Depolama gereksinimlerinin nasıl değişeceğini görmek için, her bir alanda farklı özniteliklere sahip bir dizinin birden çok sürümünü oluşturmayı deneyebilirsiniz. daha fazla bilgi için bkz. temel dizin oluşturma içindeki "Depolama etkileri".

El ile kabaca bir tahmin sayesinde, bu miktarı iki dizin (geliştirme ve üretim) için bütçeye katmanızı ve ardından katmanınızı uygun şekilde seçmenizi sağlayabilirsiniz.

Faturalandırılabilir katman ile tahmin

Adanmış kaynaklar, geliştirme sırasında dizin miktarının, boyutunun ve sorgu birimlerinin daha gerçekçi tahminleri için daha büyük örnekleme ve işleme sürelerine uyum sağlayabilir. Bazı müşteriler, faturalandırılabilir bir katmanda doğrudan geçiş yaparken geliştirme projesi olarak yeniden değerlendirilir.

1. Alt katmanların ihtiyacınız olan dizin sayısını destekleyip desteklemediğini öğrenmek için Her katmandaki hizmet sınırlarını gözden geçirin . Temel, S1 ve S2 katmanlarında Dizin sınırları sırasıyla 15, 50 ve 200 ' dir. Depolama en iyi duruma getirilmiş katmanın, az sayıda çok büyük dizini destekleyecek şekilde tasarlandığından 10 dizin sınırı vardır.

2. Faturalanabilir katmanda bir hizmet oluşturun:

   • Tahmini yük hakkında emin değilseniz, temel veya S1 ' te düşük ' ı başlatın.
   • Test, büyük ölçekli dizin oluşturma ve sorgu yüklerini içeriyorsa, S2 veya hatta S3 ' da yüksek bir başlangıç yapın.
   • büyük miktarda veri dizinleniyor ve sorgu yükü görece düşükse, bir dahili iş uygulamasında olduğu gibi, en iyi duruma getirilmiş Depolama, L1 veya L2 ile başlayın.

3. Kaynak verilerin dizine nasıl çevrileceklerini belirlemek için bir ilk dizin oluşturma. Dizin boyutunu tahmin etmek için tek yol budur.

4. Portalda depolamayı, hizmet sınırlarını, sorgu hacmini ve gecikme süresini izleme. Portalda saniye başına sorgu sayısı, kısıtlanan sorgular ve arama gecikme süresi yer almaktadır. Bu değerlerin hepsi doğru katmanı seçtikten sonra karar vermede size yardımcı olabilir.

5. Yüksek kullanılabilirlik gerekirse veya yavaş sorgu performansıyla karşılıyorsanız çoğaltma ekleyin.

   Sorgu yüklerini karşılamak için kaç çoğaltmanın gerekli olduğuyla ilgili bir kılavuz yoktur. Sorgu performansı, sorgunun karmaşıklığına ve rakip iş yüklerine bağlıdır. Çoğaltma ekleme net bir şekilde daha iyi performansa neden olsa da sonuç kesinlikle doğrusal değildir: üç çoğaltma eklemek üç tane aktarım hızını garanti değildir. Çözümünüz için QPS tahmini konusunda rehberlik için bkz. Performans için ölçeklendirme veSorguları izleme.

Sorgu birimiyle ilgili dikkat edilmesi gerekenler

Saniye başına sorgu sayısı (QPS), performans ayarlama sırasında önemli bir ölçümdür, ancak genellikle yalnızca en başından yüksek sorgu hacmi beklediğinizde katmanda dikkate alınması gereken bir ölçümdür.

Standart katmanlar, çoğaltmalar ve bölümler arasında bir denge sağlar. Yük dengeleme için çoğaltmalar ekleyerek veya paralel işleme için bölümler ekleyerek sorgu geri dönüş sayısını artırabilirsiniz. Daha sonra hizmet sağlandıktan sonra performansı ayarlayabilirsiniz.

En başından itibaren yüksek sürdürülebilir sorgu birimleri bekliyorsanız, daha güçlü donanımlarla birlikte daha yüksek Standart katmanları göz önünde bulundurabilirsiniz. Daha sonra bölümleri ve çoğaltmaları çevrimdışı duruma getirin veya bu sorgu birimleri oluşmazsa daha düşük katmanlı bir hizmete geçebilirsiniz. Sorgu aktarım hızını hesaplama hakkında daha fazla bilgi için bkz. Azure Bilişsel Arama ve iyileştirme.

İyileştirilmiş Depolama katmanları büyük veri iş yükleri için yararlıdır ve sorgu gecikme süresi gereksinimlerinin daha az önemli olduğu genel olarak kullanılabilir dizin depolama alanını destekler. Yine de yük dengeleme için ek çoğaltmalar ve paralel işleme için ek bölümler kullanacağız. Daha sonra hizmet sağlandıktan sonra performansı ayarlayabilirsiniz.

Hizmet düzeyi sözleşmeler

Ücretsiz katman ve önizleme özellikleri, hizmet düzeyi sözleşmelerini (SLA) kapsamında değildir. Tüm faturalanabilir katmanlarda, hizmetiniz için yeterli yedeklilik sağlarken SLA'lar etkili olur. Sorgu (okuma) SLA'ları için iki veya daha fazla çoğaltmaya sahip olmak gerekir. Sorgu ve dizin oluşturma (okuma-yazma) SLA'ları için üç veya daha fazla çoğaltmanız gerekir. Bölüm sayısı SLA'ları etkilemez.

İpuçları planlaması için planlama

• Ölçümlerin sorgular etrafında derlemesine ve kullanım desenleri (iş saatleri içinde sorgular, yoğun olmayan saatlerde dizin oluşturma) çevresinde veri toplamasına izin verme. Hizmet sağlama kararlarını bildirmek için bu verileri kullanın. Saatlik veya günlük tempoda pratik değildir ancak bölümleri ve kaynakları sorgu birimlerinde planlı değişikliklere uyum sağlayacak şekilde dinamik olarak ayarlayabilirsiniz. Düzeyler eyleme geçerek işlem yapmak için yeterli süreye sahipse planlanmamış ancak sürekli değişiklikleri de karşılarsınız.

• Sağlamanın tek dezavantajı, gerçek gereksinimlerin tahminlerden fazla olduğu bir hizmeti yok etmek zorunda olabileceğini unutmayın. Hizmet kesintisi yaşanmaması için, daha yüksek bir katmanda yeni bir hizmet oluşturabilir ve tüm uygulama ve istekler yeni uç noktayı hedef alana kadar bu hizmeti yan yana çalıştırabilirsiniz.

Kapasite ne zaman ekli?

Başlangıçta, bir hizmete bir bölüm ve bir çoğaltmadan oluşan en düşük düzeyde kaynak ayrılır. Seçtiğiniz katman bölüm boyutunu ve hızını belirler ve her katman çeşitli senaryolara uygun bir dizi özellik etrafında iyileştirilmiştir. Daha yüksek bir uç katmanı seçerseniz, S1'e göre daha az bölüme ihtiyacınız olabilir. Otomatik olarak yönlendirilen test aracılığıyla yanıtlamak için ihtiyacınız olan sorulardan biri, daha büyük ve daha pahalı bir bölümün daha düşük katmanda sağlanan bir hizmette iki daha ucuz bölüme göre daha iyi performans gösterip sağlamay olmadığıdır.

Tek bir hizmet, tüm iş yüklerini (dizin oluşturma ve sorgular) işlemek için yeterli kaynaklara sahip olmalıdır. hiçbir iş yükü arka planda çalıştırnmaz. Sorgu isteklerinin doğal olarak daha az sıklıkta olduğu zamanlar için dizin oluşturma zamanlaması da zamanlanabilirsiniz, ancak hizmet aksi takdirde bir görevi diğerine göre önceliklendirmez. Buna ek olarak, hizmetler veya düğümler dahili olarak güncelleştirildiğinde belirli bir yedeklilik miktarı sorgu performansını düzgün hale gelir.

Kapasite eklip eklen karara varma konusunda bazı yönergeler şunlardır:

• Hizmet düzeyi sözleşmesi için yüksek kullanılabilirlik ölçütlerini karşılar
• HTTP 503 hatalarının sıklığı artıyor
• Büyük sorgu birimleri beklenir

Genel bir kural olarak, özellikle de hizmet işlemleri sorgu iş yüklerine yönelik sapmalar olduğunda, arama uygulamaları bölümlere göre daha fazla çoğaltmaya ihtiyaç gösterir. Her çoğaltma, dizininizin bir kopyasıdır ve hizmetin isteklerin yükünü birden çok kopyaya göre dengelemeye olanak sağlar. Bir dizinin tüm yük dengeleme ve çoğaltması Azure Bilişsel Arama tarafından yönetilir ve hizmetiniz için ayrılan çoğaltma sayısını herhangi bir zamanda değiştirebilirsiniz. Bir Standart arama hizmetine en fazla 12 çoğaltma ve Temel arama hizmetine 3 çoğaltma ayırabilirsiniz. Çoğaltma ayırma, çoğaltmadan Azure portal veya programlı seçeneklerden biri olabilir.

Gerçek zamanlıya yakın veri yenilemesi gerektiren arama uygulamalarının çoğaltmalardan orantılı olarak daha fazla bölüme ihtiyacı vardır. Bölüm ekleme, okuma/yazma işlemlerini daha fazla sayıda işlem kaynağına yalıtır. Ayrıca ek dizinleri ve belgeleri depolamak için size daha fazla disk alanı sağlar.

Son olarak, daha büyük dizinlerin sorguyu oluşturması daha uzun sürer. Bu nedenle, bölümlerde yapılan her artımlı artışın çoğaltmalarda daha küçük ama orantılı bir artış gerektirdiğini bulabilirsiniz. Sorgularınızı ve sorgu hacminizin karmaşıklığı, sorgu yürütmenin ne kadar hızlı geri çevrileceklerini dikkate alar.

Çoğaltmaları ve bölümleri ekleme veya azaltma

1. Hizmette oturum Azure portal ve arama hizmetini seçin.

2. Yeni Ayarlar altında, çoğaltmaları ve bölümleri değiştirmek için Ölçek sayfasını açın.

   Aşağıdaki ekran görüntüsünde, tek bir çoğaltma ve bölümle sağlanan Temel Standart'ın ekran görüntüsü. En alttaki formül, kaç arama biriminin kullanılıyor olduğunu gösterir (1). Birim fiyat 100 ABD doları (gerçek bir fiyat değil) ise, bu hizmeti çalıştırmanın aylık maliyeti ortalama 100 ABD doları olur.

   

3. Bölüm sayısını artırmak veya azaltmak için kaydırıcıyı kullanın. Kaydet’i seçin.

   Bu örnek ikinci bir çoğaltma ve bölüm ekler. Arama birimi sayısına dikkat: faturalama formülü, bölümlerle (2 x 2) çarpılarak çoğaltıldıkları için artık dört. Kapasiteyi iki katına çıkararak hizmeti çalıştırma maliyeti iki katına çıkar. Arama birimi maliyeti 100 ABD doları olsaydı yeni aylık fatura şimdi 400 ABD doları olurdu.

   Her katmanın birim başına geçerli maliyetleri için Fiyatlandırma sayfasını ziyaret edin.

   

4. Kaydetme işleminin ardından, eylemin başarılı olduğunu onaylamak için bildirimleri kontrol edin.

   

   Kapasite değişikliklerinin tamamlanması 15 dakika ile birkaç saat arasında sürebilir. İşlem başlatıldıktan ve çoğaltma ve bölüm ayarlamaları için gerçek zamanlı izleme yoktur. Ancak, değişiklikler devam ederken aşağıdaki ileti görünür durumda kalır.

   

Ölçek isteklerinin iş nasıl işli olduğu

Ölçek isteği alındından sonra arama hizmeti:

1. İsteğin geçerli olup olmadığını denetler.
2. Verileri ve sistem bilgilerini geri toplamaya başlar.
3. Hizmetin zaten sağlama durumda olup olmadığını denetler (şu anda çoğaltmaları veya bölümleri ekliyor veya ortadan kaldırıyor).
4. Sağlamayı başlatır.

Hizmetin boyutuna ve isteğin kapsamına bağlı olarak bir hizmetin ölçeklendirilemesi 15 dakika kadar kısa sürebilir veya bir saatten uzun sürebilir. Veri miktarına ve bölüm ve çoğaltma sayısına bağlı olarak yedekleme birkaç dakika sürebilir.

Yukarıdaki adımlar tamamen ardışık değildir. Örneğin sistem, güvenli bir şekilde sağlansa da sağlamayı başlatır ve bu da yedeklemenin sondası olur.

Ölçeklendirme sırasında oluşan hatalar

"Önceki bir isteği işlememiz nedeniyle şu anda hizmet güncelleştirme işlemlerine izin verilmiyor" hata iletisi, hizmet zaten önceki bir isteği işlemeye devam ettiyse ölçeğin aşağıya veya yukarı doğru ölçeklendirilen bir isteğin tekrarlamasına neden olur.

Sağlama durumunu doğrulamak için hizmet durumunu kontrol ederek bu hatayı giderin:

1. Hizmet durumunu almak REST API, Azure PowerShellveya Azure CLI'sini kullanın.
2. Get Service çağrısı
3. "provisioningState": "provisioning" yanıtını denetleme

Durum "Sağlama" ise isteğin tamamlandıktan sonra tamamlanır. Başka bir istek denenmeden önce durum "Başarılı" veya "Başarısız" olabilir. Yedekleme için bir durum yok. Yedekleme bir iç işlemdir ve bir ölçek alıştırması kesintisinde bir faktör olması pek olası değildir.

Bölüm ve çoğaltma birleşimleri

Temel hizmet, en fazla üç SUS sınırı için tam olarak bir bölüme ve en fazla üç çoğaltmaya sahip olabilir. Ayarlanabilir tek kaynak çoğaltmadır. Sorgularda yüksek kullanılabilirlik için en az iki çoğaltma gerekir.

Tüm Standart ve Depolama İyileştirilmiş arama hizmetleri, bu katmanlar için izin verilen 36 SU sınırına bağlı olarak aşağıdaki çoğaltma ve bölüm birleşimlerini varsayılabilir.

SUS, fiyatlandırma ve kapasite, Azure web sitesinde ayrıntılı olarak açıklanmıştır. Daha fazla bilgi için bkz. Fiyatlandırma Ayrıntıları.

Sonraki adımlar