MongoDB'de Veri Geçişini Optimize Edin: Hız ve Ölçeklenebilirlik için Yeniden Paylaşım Teknikleri

2 TB'lık bir koleksiyonu parçalamanız ve verileri 24 saatten kısa bir sürede tüm parçalarınıza dağıtmanız mı gerekiyor? Veri geçişinizi hızlandırmak için yeniden parçalamadan yararlanın!

Bu yazıda, verileri kümenizdeki parçalar arasında hızlı bir şekilde yaymak için yeniden parçalamayı kullanan "yeniden parçaya" adı verilen bir tekniği ele alacağız.

Üzerinden geçeceğiz:

1. Geçiş öncesi ve sırasında dikkat edilmesi gerekenler.
2. Daha hızlı veri geçişi nasıl başlatılır, izlenir ve iptal edilir.

Parçalama konusunda yeniyseniz veya MongoDB'nin yatay ölçeklenebilirliği nasıl sağladığı konusunda bilgilerinizi tazelemek istiyorsanız lütfen şuraya göz atın: MongoDB kılavuzu .

İçindekiler

• Arka plan
• Parçadan parçaya geçişin faydaları nelerdir?
• Reshard'dan shard'a ne zaman kullanmalıyım?
• Ne zaman parçadan parçaya kullanmamalıyım?
• Parçadan parçaya geçişin önkoşulları nelerdir?
• Parçadan parçaya tekniğine genel bakış
• Parçadan parçaya örnek
• SSS

Arka plan

Bir koleksiyon başlangıçta çok parçalı bir kümede parçalandığında, dengeleyici, koleksiyonu parçalar arasında eşit şekilde dağıtmak için verileri yakın zamanda parçalanan koleksiyonu tutan parçadan kümedeki diğer parçalara taşımaya başlar. Dengeleyici verileri taşırken, kaç koleksiyonun taşınması gerektiğine bakılmaksızın bir parça aynı anda yalnızca bir taşıma işlemine katılabilir. Bu, 3 parçalı bir kümede aynı anda yalnızca iki parçanın aralarında veri taşıyabileceği anlamına gelir. Yeniden parçalama, dahili yürütme farklılıkları nedeniyle aynı sınırlamaları paylaşmaz.

Yeniden parçalama tüm verileri yeniden yazmak olduğundan, verileri kümedeki tüm parçalar boyunca paralel olarak yazabilir, böylece verimi artırır ve dengeleyicinin başarabileceğine göre verileri parçalar arasında geçirme süresini büyük ölçüde azaltır. Resharding, mevcut koleksiyonunuzu uygulamanızın kullanımına açık tutarken, her bir parçanın arka planında yeni bir parça anahtarıyla yeni bir koleksiyon oluşturur. Tüm belgeler yeni koleksiyona kopyalandıktan sonra geçiş gerçekleşir. Eski parça anahtarına sahip mevcut koleksiyon, yeniden parçalama işlemiyle oluşturulan yeni koleksiyon lehine bırakılır.

Parçadan parçaya geçişin faydaları nelerdir?

İlk olarak, çok daha hızlı! Bir müşteri, yeniden parçalamadan yararlanarak 3,5 TB'lık koleksiyonunu 22,5 saat içinde parçalayıp 4 parçaya dağıtabildi. Dengeleyicinin varsayılan yığın geçiş yöntemine bırakılsaydı aynı süreç 30 gün sürerdi.

İkincisi, iş yükünüzü minimum düzeyde etkiler! Dengeleyici verileri aktardıktan sonra, adı verilen bir temizleme işlemi gerçekleştirmesi gerekir. aralık silme yalnızca bir parça her belirli belgeye sahip olabileceğinden, verileri bağışlayan parça üzerinde. Aralık silme, kümenizin performansını etkileyebilecek, G/Ç yoğun bir işlemdir. Yeniden parçalamanın, yeni parça anahtarıyla yeni koleksiyona geçtikten sonra eski koleksiyonun bir kısmını gerçekleştirdiği için aralık silme işlemi yapmasına gerek yoktur.

Üçüncüsü, disk alanınızı otomatik olarak geri kazanırsınız! Eski koleksiyonu bırakarak herhangi bir koleksiyon tarafından kullanılacak depolama alanını, aşağıdaki gibi bir işlem yürütmeye gerek kalmadan serbest bırakır. kompakt . Bu, istenirse operasyondan sonra depolamanın ölçeğini daha hızlı ve kolay bir şekilde azaltabileceğiniz anlamına gelir.

Örneğin bir müşteri, en büyük koleksiyonunun yeniden parçalama işlemi tamamlanmadan önce shard0'da yaklaşık 2,8 TB tüketiyordu.

Yeniden parçalama bittiğinde 1,9 TB depolama alanı hemen iade edildi! 2,7 TB depolama alanı tüketmekten 873 GB depolama alanına geçtiler.

Reshard'dan shard'a ne zaman kullanmalıyım?

Cevap: Başlangıçta herhangi bir boyuttaki bir koleksiyonu herhangi bir sayıda parçaya böldüğünüzde.

Dengelemenin daha hızlı olabileceği (örn. 100 GB'tan az) bazı senaryolar vardır, ancak yine de aralığın silinmesini ve kompakt veya ilk senkronizasyon yoluyla depolama alanının geri kazanılmasını hesaba katmanız gerekir. Bu nedenle kapasiteniz varsa, parçalamak istediğiniz koleksiyon ne kadar büyük olursa olsun parçadan parçaya yapmanızı öneririz.

Ne zaman parçadan parçaya kullanmamalıyım?

Aşağıdaki durumlarda parçadan parçaya taktiğini kullanmamalısınız:

• Uygulamanız, yeniden parçalanan koleksiyona geçişe izin vermek için iki saniye boyunca yazma engellemesine tolerans gösteremez.

  • Yeniden parçalanan koleksiyon için yazma süresi bloke edilebilir, varsayılan olarak iki saniyedir, engelleme süresini değiştirebilen yapılandırılabilir bir parametre vardır.

    
    

• Koleksiyonunuz bir zaman serisi koleksiyonudur
  • Bir zaman serisi koleksiyonunu yeniden parçalamaya çalışırsanız, zaman serisi koleksiyonunu yeniden parçalamanın desteklenmediğini belirten bir hata mesajı alırsınız.

Yukarıda listelenen senaryolar için, bir koleksiyonu parçalamak ve dengeleyicinin verileri taşımasına izin vermek gibi geleneksel yöntemi kullanın.

Parçadan parçaya geçişin önkoşulları nelerdir?

1. MongoDB 5.0 veya üstünü çalıştıran bir MongoDB kümesi

   1. MongoDB 5.0 veya 6.0 çalıştırıyorsanız kümenizin 5.0.14 veya 6.0.3'ten büyük bir yama sürümü çalıştırdığından emin olun

2. Koleksiyonunuz için uygun bir parça anahtarı seçmelisiniz.

3. Hem geçici parça anahtarını hem de istenen parça anahtarını desteklemek için gereken dizinleri oluşturun.

4. Ayrıca, veri taşıma hızlarını artırmak için yeniden parçalamayı kullanacağınız için lütfen aşağıdakiler hakkında bilgi edinin: yeniden sertleştirme gereksinimleri ve sınırlamaları .

Yeniden parçalama işlemini başarıyla yürütmek için kümenizin aşağıdakilere sahip olması gerekir:

• Her bir parçada mevcut olan parça başına koleksiyon boyutunun 2,2 katı.
  • Örneğin, 1 TB'lık bir koleksiyonu 4 parçaya dağıtıyorsanız, parçalanmış koleksiyonun boyutu 4 parçaya dağıtıldığında parça başına 250 GB olur. Her bir parçada minimum 550 GB kullanılabilir depolama alanına sahip olmak istiyorsunuz.
• G/Ç kapasitesi %50'nin altında
• CPU kullanımı %80'in altında

Kümesi yeniden parçalamayı yürütmek için depolama, G/Ç ve CPU gereksinimlerini karşılamayan Atlas kullanan müşteriler, geçici olarak kolayca kümelerini ölçeklendirin ve/veya depolama alanını özelleştir Başarılı bir yeniden parçalama işlemine izin vermek için kümelerinin kaynaklarını artırmak. Operasyon tamamlandıktan sonra normale dönebilirler.

Parçadan parçaya tekniğine genel bakış

Parçadan parçaya işlemi gerçekleştirmek için çok basit iki adım vardır:

1. Parçayı Geçici Bir Parça Anahtarına Dönüştürme
2. İstediğiniz Parça Anahtarını Yeniden Parçalayın

Neden önce geçici bir parça anahtarını parçalayayım ve bu uygulamama zarar vermez mi?

Açıklayalım!

Birinci adım: geçici bir parça anahtarıyla parçalama

Şu anda yeniden parçalama, aynı parça anahtarına yeniden parçalamayı desteklememektedir (zaten istediğiniz durumda olduğunuz için "işlem dışı" olarak başarılı olacaktır). Bu sınırlamayı aşmak için yeniden parçalama tekniği, istenen parça anahtarından farklı bir geçici parça anahtarına kasıtlı olarak parçalamayı gerektirir. MongoDB'nin hem aralık parçalamayı hem de karma parçalamayı desteklemesi nedeniyle, geçici parça anahtarı, koleksiyonunuz için seçtiğiniz istenen parça anahtarından çok az değiştirilebilir.

Geçici parça anahtarı, parça anahtarı alanlarınızdan yalnızca biri için farklı bir bölümleme stratejisi seçmelidir. Sorgunun parça anahtarını içermesini gerektiren updateOne(), updateMany(), deleteOne() vb. gibi belirli sorgulara yönelik sınırlamalar nedeniyle, farklı bir bölümleme stratejisi kullanacaksınız. MongoDB, bölümleme stratejilerini yalnızca verilerinizi kümenizdeki parçalar arasında nasıl dağıtacağınızı belirlemenin bir yolu olarak kullanır ve belgedeki değerleri değiştirmez. Bu, uygulamanızın her iki bölümleme stratejisinde de parça anahtarı gerektiren bir updateOne veya başka bir sorguyu kullanabileceği anlamına gelir.

Örneğin, koleksiyonunuz için seçtiğiniz parça anahtarı şuysa:

 {"_id": "hashed"}

Koleksiyonunuz için başlangıçta kullanacağınız geçici parça anahtarı şöyle olmalıdır:

 {"_id": 1}

Bileşik parça anahtarları için, geçici parça anahtarı için istediğiniz parça anahtarının önekini kullanabilirsiniz. Örneğin, koleksiyonunuz için seçtiğiniz parça anahtarı şuysa:

 { launch_vehicle: 1, payload: 1}

Geçici parça anahtarınız şöyle olmalıdır:

 { launch_vehicle: 1}

Yeniden parçalama taktiği, koleksiyonun geçici parça anahtarıyla ilk parçalanması tamamlandıktan sonra uzun vadede kullanacağınız parça anahtarının neredeyse anında yeniden parçalanmasını gerektirir. Bu, yeniden paylaşım işlemi yürütülürken verilerin %99'undan fazlasını tek bir parçada tutar ve yayın sorgularının etkisini önemli ölçüde azaltır.

Yeniden parçalama işlemi yürütülürken, geçici ve istediğiniz parça anahtarınız için her iki dizini de oluşturacağınızdan, istediğiniz parça anahtarını kullanan sorgular, koleksiyonunuz geçici olarak bölümlenirken istenen parça anahtarı için dizinden yararlanabilecekleri için performanslı olacaktır. geçici parça anahtarınız tarafından.

İkinci adım: İstediğiniz parça anahtarını yeniden parçalayın

İkinci adım, yeniden parçalamanın sizin yararınıza nasıl çalıştığına dair bir yan etkiden yararlanmanız dışında normal bir yeniden parçalama işlemi yürütmektir.

Resharding'in dört ana aşaması vardır:

• Başlatma - yeniden parçalamaya tabi tutulan koleksiyon örneklenir ve yeni parça anahtarına dayalı olarak yeni bir veri dağıtımı belirlenir.

  
  

• Dizin - yeniden parçalama işlemi, yeni parça anahtarını temel alarak tüm parçalar üzerinde yeni bir boş, geçici parçalanmış koleksiyon oluşturur ve mevcut koleksiyonu destekleyen parça olmayan anahtar dizinleri de dahil olmak üzere dizinleri oluşturur.

  
  

• Klonla, Yakala ve Uygula - belgeler yeni parça anahtarına göre parçalara klonlanır ve yeniden parçalama işlemi yürütülürken belgelerde yapılan tüm değişiklikler uygulanır.

  
  

• Taahhüt - geçici koleksiyon yeniden adlandırılır ve yeniden parçalanan koleksiyonun yerini alır ve artık eski koleksiyon bırakılır.

Yukarıdaki aşamaları inceledikten sonra, hızlı veri taşımanın, işlem tamamlandıktan sonra parçalarınıza eşit olarak dağıtılan parçalı bir koleksiyonun ve tek seferde boş depolama alanının avantajlarından nasıl yararlanacağınızı görebilirsiniz.

Yeniden parçalama işlemi tamamlandıktan sonra, geçici parça anahtarı dizinini düşürmek ve kümenizi ve/veya depolama alanınızı kararlı durum ihtiyaçlarınıza uyacak şekilde ölçeklendirmek gibi temizleme işlemlerini gerçekleştirebilirsiniz.

Parçadan parçaya örnek

Diyelim ki ticari uçakları takip edecek ve böylece uçuşlarının ertelenmesi ihtimali varsa müşterilerin bilgilendirilebilmesini sağlayacak bir uygulama üzerinde çalıştığınızı varsayalım. Uygulamanızın sorgu modellerini incelediniz ve hangi özelliklerin iyi bir parça anahtarına katkıda bulunduğunu incelediniz.

Koleksiyonunuz için seçtiğiniz parça anahtarı:

 { airline: 1, flight_number: 1, date: "hashed" }

Parça anahtarı belirlendiğinde, yeniden parçalama işlemini yürütmek için önkoşulları kontrol etmeye başlayabilirsiniz. Öncelikle geçici parça anahtarınızı oluşturursunuz. Daha önce de belirtildiği gibi, geçici parça anahtarınızın, istenen parça anahtarının çok az değiştirilmiş bir versiyonu olmasını istiyorsunuz.

Yani seçtiğiniz geçici parça anahtarı:

 { airline: 1, flight_number: 1 }

Daha sonra, hem geçici hem de son parça anahtarlarını destekleyecek dizinleri oluşturursunuz.

Dizinler db.collection.createIndex() veya db.collection.createIndexes() aracılığıyla Mongo kabuğu kullanılarak oluşturulabilir.

İstenilen parça anahtarı bileşik bir parça anahtarı olduğundan db.collection.createIndexes() aracılığıyla yalnızca bir dizin oluşturmanız gerekir:

 db.flight_tracker.createIndex( { "airline": 1, "flight_number": 1, date: "hashed" } )

Dizin yapıları mongo kabuğu kullanılarak aşağıdaki komutla izlenebilir:

 db.adminCommand({ currentOp: true, $or: [ { op: "command", "command.createIndexes": { $exists: true } }, { op: "none", "msg" : /^Index Build/ } ] })

MongoDB kümeniz Atlas'ta konuşlandırıldıysa, kümenizin yeterli boş depolama alanına ek olarak yeniden parçalama işlemini yürütmek için CPU ve G/Ç boşluk payına sahip olduğunu size bildiren mevcut ölçümleri kolayca incelemek için Atlas kullanıcı arayüzünü kullanabilirsiniz.

Yeterli depolama alanı veya G/Ç boşluğu yoksa depolamayı ölçeklendirebilirsiniz. CPU boşluğunun olmaması durumunda kümeyi ölçeklendirebilirsiniz. Atlas kullanıcı arayüzü aracılığıyla hem depolamayı hem de kümeyi ölçeklendirmek kolayca yapılabilir.

Küme yapılandırmasına erişim basittir ve grup için dağıtılan tüm kümeleri görüntüleyen grubunuzun genel bakış ekranından yapılabilir.

Tüm önkoşullar karşılandığında, yeniden parçalama sürecinin ilk bölümünü, yani koleksiyonun geçici parça anahtarıyla parçalanmasını başlatabilirsiniz.

Daha sonra koleksiyonu parçalamak için Mongo kabuğunu ve sh.shardCollection() komutunu kullanabilirsiniz:

 sh.shardCollection("main.flight_tracker", { airline: 1, flight_number: 1 })

sh.shardCollection() tamamlandığında bir belge döndürecektir; işlem başarılıysa ok alanı 1 değerine sahip olacaktır.

 { collectionsharded: 'main.flight_tracker', ok: 1, '$clusterTime': { clusterTime: Timestamp({ t: 1684160896, i: 25 }), signature: { hash: Binary(Buffer.from("7cb424a56cacd56e47bf155bc036e4a4da4ad6b6", "hex"), 0), keyId: Long("7233411438331559942") } }, operationTime: Timestamp({ t: 1684160896, i: 21 }) }

Koleksiyon parçalandıktan sonra kümedeki her parçaya bir parçanın taşınmasını bekleyin. Mongo kabuğundaki sh.status() aracılığıyla her parçanın bir öbeği olup olmadığını kontrol edebilirsiniz:

 sh.status()

Koleksiyonunuzu istediğiniz parça anahtarına yeniden parçalamak için mongo kabuğunda sh.reshardCollection() işlevini kullanın:

 sh.reshardCollection("main.flight_tracker", { airline: 1, flight_number: 1, date: "hashed" })

Mongo kabuğunda sh.status() komutunu çalıştırırsanız, çıktıda yeni koleksiyonun adının biçimi <db_name>.system.resharding.<UUID> olan yeni bir koleksiyon göreceksiniz. Bu, yeniden parçalamanın verileri istediğiniz parça anahtarına göre oluşturup dağıttığı koleksiyondur

Flight_tracker koleksiyonuna yönelik yeniden parçalama işleminin durumunu izlemek için aşağıdaki komutu kullanabilirsiniz

 db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "main.flight_tracker" } } ])

Komutun çıktısı, kalanOperationTimeEstimatedSecs alanı aracılığıyla yeniden parçalama işleminin o anda hangi aşamada yürütüldüğünü ve tahmini tamamlanma süresini size bildirecektir. Yeniden paylaşımın tahmini tamamlanma süresinin kötümser olduğunu ve yeniden paylaşım işlemlerinin bildirilenden önemli ölçüde daha az zaman aldığını lütfen unutmayın!

Her bir parçanın veri boyutu, yeniden parçalanan koleksiyonun boyutunun kümedeki parça sayısına bölünmesiyle arttığında, yeniden parçalama işlemi tamamlanmaya yaklaşmalıdır. Örneğin, 4 parçaya yeniden dağıtılan 1 TB'lık bir koleksiyon, her parça 250 GB yazdığında yeniden parçalama işleminin tamamlanması gerekir (parçaya eklenen, güncellenen veya silinen diğer veriler hesaba katılmaz).

Kümeniz Atlas'ta dağıtıldıysa, kümenin Metrikler sekmesini kullanarak Atlas kullanıcı arayüzü aracılığıyla yeniden parçalama işleminin ilerlemesini de izleyebilirsiniz.

• MongoDB 6.0 ve üstünü çalıştıran Atlas kümeleri için, parça veri boyutu görüntüleme seçeneğini kullanabilir ve ardından <db_name>.system.resharding.<UUID> sözdizimine sahip bir koleksiyon seçebilirsiniz. Bu görünüm, geçici koleksiyonu izole eder ve yalnızca yeni koleksiyonun veri boyutu artışını görüntüler.

  
  

• MongoDB 5.0 çalıştıran Atlas kümeleri için db mantıksal veri boyutu görüntüleme seçeneğini kullanabilirsiniz. Bu görünüm, koleksiyon düzeyinde izolasyona izin vermez.

  
  

Yeniden paylaşım yürütülürken öncelikli olarak izlemeniz gereken kümedeki üç ölçüm şunlardır:

• Kullanılabilir Depolama - kullanılabilir depolama alanının tamamını tüketmek küme kararsızlığına neden olabilir
• CPU Kullanımı - yüksek CPU kullanımı küme performansının düşmesine neden olabilir
• G/Ç Kullanımı - Kapasitenizin üzerinde G/Ç kullanımı küme performansının düşmesine yol açabilir

Yeniden parçalamanın kümenizi olumsuz yönde etkileyeceğinden endişeleniyorsanız , aşağıdaki komutu kullanarak yeniden parçalama işlemini, sürecin taahhüt kısmına ulaşmadan önce anında iptal edebilirsiniz:

 sh.abortReshardCollection("main.flight_tracker")

Yeniden parçalama işlemi sona erdiğinde, işlemin başarılı olup olmadığı, çağrıyı yapan istemciye geri dönecektir.

Yeniden parçalama uzun süren bir işlem olduğundan ve Mongo kabuk oturumunu kapatmış olabileceğiniz için, ayrıntıları istiyorsanız yeniden parçalama izleme toplamasını kullanarak veya geçici olup olmadığını görmek için __ sh.status() __ kullanarak parçalama işleminin hala yürütülüp yürütülmediğini kontrol edebilirsiniz. çıktıda koleksiyon hala mevcut. Yeniden parçalama toplaması hiçbir şey döndürmezse veya sh.status() çıktısında artık geçici bir koleksiyon görmüyorsanız, yeniden parçalama işlemi sona ermiştir.

İşlemin başarılı olup olmadığını belirlemek için db.collection.getShardDistribution kullanabilirsiniz:

 db.flight_tracker.getShardDistribution()

Yeniden parçalama başarıyla tamamlandıysa, dağıtımın parçalar arasında eşit olduğu bir çıktı görmelisiniz.

• MongoDB 6.0 ve daha yüksek eşitlik, parça başına veri boyutuna göre belirlenir; dolayısıyla db.collection.getShardDistribution çıktısında her parça üzerinde neredeyse eşit miktarda veri görmelisiniz.

  
  

• MongoDB 5.0 için eşitlik, parça başına parça sayısına göre belirlenir, dolayısıyla db.collection.getShardDistribution çıktısında her parçada eşit sayıda parça görmelisiniz.

Kümeniz Atlas'ta dağıtıldıysa, yeniden parçalama işleminin başarılı olup olmadığını belirlemek için Metrikler sekmesi aracılığıyla Atlas kullanıcı arayüzünü kullanabilirsiniz.

• MongoDB 6.0 ve üzerini çalıştıran Atlas kümeleri için parça veri boyutu görüntüleme seçeneğini kullanabilir ve ardından yeniden parçalama yapılan koleksiyonunuzu seçebilirsiniz. Görüntülenen parça başına eşit miktarda veri görmelisiniz.

  
  

• MongoDB 5.0 çalıştıran Atlas kümeleri için parçaları görüntüleme seçeneğini kullanabilir ve ardından yeniden parçalama işlemine tabi tutulan koleksiyonunuzu seçebilirsiniz. Kümenizdeki tüm parçalarda neredeyse eşit sayıda parçanın görüntülendiğini görmelisiniz.

  
  

Hem parça veri boyutu hem de parça sayısı için Atlas Kullanıcı Arayüzü, <db_name>.system.resharding.<UUID> yeniden adlandırmadan ve eskisini bırakmadan önce geçici olarak eski parça anahtarıyla koleksiyon.

Yeniden parçalama iptal edilirse db.collection.getShardDistribution çıktısı muhtemelen koleksiyonun başlangıçta parçalandığı parçadaki verilerin çoğunu gösterecektir. Yeniden parçalamayla iptaller nadirdir ve büyük olasılıkla yeniden parçalamanın koleksiyon geçişini 2 saniye veya daha kısa sürede gerçekleştirememesi nedeniyledir.

Durum böyleyse, yeniden parçalamanın başlangıcını, kümeniz için trafiğin daha düşük olduğu bir dönemde işlemeye çalışacak şekilde zamanlamanızı öneririz.

Yeniden parçalama işlemi tamamlandıktan sonra, geçici parça anahtarı dizinini düşürmek ve kümenizi ve/veya depolama alanınızı kararlı durum ihtiyaçlarınıza uyacak şekilde ölçeklendirmek gibi temizleme işlemlerini gerçekleştirebilirsiniz.

SSS

1. Parçadan parçaya geçiş ne kadar sürer?

   
   

   • Bu, koleksiyonunuzun boyutuna, koleksiyonunuz için dizinlerin sayısına ve boyutuna ve kümenizdeki parça sayısına bağlıdır, ancak 48'de 4 parçada 10 dizin içeren 4 TB'lık bir koleksiyonu parçaya yeniden parçalayabileceğinizden eminiz. saat veya daha az. Dengeleyicinin taşıma işlemlerini gerçekleştirmesine izin vermek 30 gün veya daha fazla zaman alır.

     
     

2. Yeniden parçalama neden dengeleyicinin verileri taşımasına izin vermekten daha hızlı?

   
   

   • Dengeleyici ve yeniden parçalamanın taşıma verilerinin iç yapısı farklıdır. Yeniden parçalama, belgeleri yığın geçişlerinden farklı bir sırayla okur ve yeniden parçalama, eski koleksiyonun bir damlasıyla sona erdiğinden, disk alanını serbest bırakmak için aralığın silinmesini beklemek gerekmez.

     
     

3. Benzersizlik kısıtlaması olan ve karma dizinleri benzersizliği zorlamayı desteklemeyen bir koleksiyonda parçadan parçaya kullanmak istiyorum.

   
   

   • Koleksiyonunuzun benzersizlik kısıtlaması varsa parçadan parçaya kullanabilirsiniz ancak farklı bir yaklaşım izlemeniz gerekecektir. Bölümleme stratejisini değiştirmek yerine geçici parça anahtarınıza ek bir alan ekleyerek, istediğiniz parça anahtarını yeniden parçalama yeteneğinin kilidini açarsınız. Örneğin, istediğiniz parça anahtarınız şuysa:

     
     

      { launch_vehicle: 1, payload: 1}

     
     

   • Geçici parça anahtarınız şöyle olacaktır:

      { launch_vehicle: 1, payload: 1, launch_pad: 1}

     
     

   • Lütfen sorgunun tam parça anahtarını içermesini gerektiren sorgulara ilişkin sınırlamalara (ör. updateOne(), updateMany(), deleteOne()) dikkat edin. Uygulamanız, bir sorgunun yeniden parçalama işlemi tamamlanana kadar başarıyla yürütülmesi için tam parça anahtarının gerekli olduğu tüm senaryolarda geçici parça anahtarını içermelidir .

   
   

4. Devam eden bir yeniden parçalama işlemini nasıl izlerim?

   • Aşağıdaki komutu çalıştırın:

      db.getSiblingDB("admin").aggregate([ { $currentOp: { allUsers: true, localOps: false } }, { $match: { type: "op", "originatingCommand.reshardCollection": "<database>.<collection>" } } ])

   
   

5. Devam eden bir yeniden parçalama işlemini nasıl durdurabilirim?

   
   

   • Yeniden parçalama işlemini anında iptal eden aşağıdaki komutu çalıştırın:

      sh.abortReshardCollection("<database>.<collection>")

   
   

6. Küme performansımı etkileyen yeniden parçalama konusunda endişeliyim.

   
   

   • Daha önce özetlenen yeniden parçalama gereksinimlerini karşılıyorsanız işlemin küme performansınızı etkilememesi gerekir. Ancak kümeniz Atlas'ta dağıtıldıysa yeniden donanımdan parçaya işlemi yürütürken kümenizin ölçeğini geçici olarak artırabilir ve işlem tamamlandıktan sonra kümenin ölçeğini yeniden küçültebilirsiniz.

     
     

7. Yeniden parçalama işlemi yürütülürken kümemin hangi ölçümlerini izlemeliyim?

   
   

   • Depolama alanı mevcut - parçalarınızdan herhangi birinde 100 GB'tan az kullanılabilir depolama alanı varsa yeniden parçalamayı iptal etmelisiniz

   • CPU kullanımı - kümeniz mevcut tüm bilgi işlem kaynaklarını tüketiyorsa kaynak çekişmesine neden olabilirsiniz ve yeniden parçalamayı iptal etmelisiniz

   • G/Ç tüketimi - kümeniz mevcut IOPS'nin tümünü tüketiyorsa kaynak çekişmesine neden olabilirsiniz ve yeniden parçalamayı iptal etmeniz gerekir.

     
     

8. Geçici koleksiyon tüm parçalarıma eşit şekilde dağıtılmış gibi görünüyor; yeniden parçalama neden tamamlanmadı?

   
   

   • Yeniden parçalamanın istediğiniz parça anahtarıyla koleksiyona geçmeden önce, yetişmek yeniden parçalamanın başlatılmasından bu yana gerçekleşen tüm yazma işlemleriyle birlikte. Yazma iş yükünüz ağırsa, yakalama aşamasının tamamlanması uzun zaman alabilir.