MongoDB MMAPv1 vs WiredTiger depolama motorları


25

MongoDB3'te yeni bir depolama motoru göründü: WiredTiger . Ancak, MMAPv1 hala Mongo'da varsayılan seçimdir .

Biri diğerinden daha iyi olmayabilir, bu genellikle kullanım durumu ve iş için doğru aracı seçmekle ilgilidir. Ama hangi motor hangi iş için doğru?

Aslında, MMAPv1 varsayılan motor olsa da, WiredTiger hemen hemen her alanda daha iyi görünüyor. MMAPv1 plus ile aynı özelliklere sahiptir:

  • daha iyi yazma performansı
  • belge düzeyinde eşzamanlılık,
  • sıkıştırma,
  • Anlık görüntüler ve kontrol noktaları sistemi.

MongoDB'nin blogunda karşılaştırma tablosu buldum :

WiredTiger ve MMAPv1 karşılaştırması

Öyleyse Solaris'te iseniz, WiredTiger'ı seçmemek için bir neden var mı?


DÜZENLE

WiredTiger ve MMAPv1'in iç kısımlarını ayrıntılı olarak anlatan iki video .


Buradaki tüm insanlar ... konuyla ilgili çok iyi bir açıklama için blog.clevertap.com/… adresini ziyaret edebilirsiniz
therealprashant

Yanıtlar:


26

Şahsen ben şu an itibariyle üç nedenden dolayı mmapv1 depolama motorunu tercih ediyorum.

Sebep 1: Vade

O WiredTiger olgunlaşmamış değil. Ancak mmapv1 iyi anlaşılmakta ve savaş, yukarı ve aşağı, ileri geri ve ileri ve ötesinde test edilmektedir. WiredTiger oldukça yakın zamanda ciddi sorunlar yaşadı ( http://jira.mongodb.com adresine bakın) oldukça yakın zamanda ve müşterilerimin bir sonrakini zor yoldan bulmasını istemiyorum.

Sebep 2: Özellikler

Verilen, WT bazı f ... temelde harika özelliklere sahiptir. Mesele şu ki: Onlardan yararlanan birini görmedim. Sıkıştırma? Her iki durumda da, oldukça ucuz disk alanı için performans elde etmek için oldukça zor fedakarlık. Belgeleri genişletmek için belge göçü sorunu yok mu? Eh, hala 16 MB boyut sınırına sahibiz ve gömülü dokümanlar için, özellikle gömme işlemi aşıldığında fazla karmaşıklık ekledik.

Orada diğer özellikleri vardır, ama genel olarak: Ben onlardan çok yararına görmüyorum bugün itibariyle .

Sebep 3: Toplam sahip olma maliyeti

Yeni projeler için, aşağıdakilerin geçerli olmadığından WT, özellikle 3.2'den beri iyi olabilir.

Veri taşıma işlemi yapmak pahalı. Planlanması gerekiyor, planın tüm paydaşlar tarafından kararlaştırılması, acil durum acil durum planlarının oluşturulması ve kararlaştırılması, göçün hazırlanması, yürütülmesi ve gözden geçirilmesi gerekiyor. Şimdi, bu sürecin bir parçası olan paydaşlarla ve veri göçü ile ilgili yüksek maliyetler için gereken süreyi çarpın. Öte yandan yatırım getirisi oldukça küçük görünüyor. Bu faktörleri hesaba katarsanız, geçiş yapmak yerine biraz ölçeklendirebilirsiniz. Size bir izlenim vermek için: Bir göçün planlanması, yürütülmesi ve uygun şekilde gözden geçirilmesi durumunda, her paydaş için yaklaşık bir "adam hafta" olduğunu tahmin ediyorum. Kişi başına saat başı 100 ABD doları ve yalnızca üç kişinin (yönetici, DBA ve geliştirici) maliyeti 12.000 ABD dolarıdır. Bunun muhafazakar bir tahmin olduğunu unutmayın.

Sonuç

Yukarıdaki tüm bu faktörler, WT'yi hiçbir şekilde kullanmama sonucuna getirdi. Şu an.


Güncelleştirme

Bu yayın şimdi biraz eski, bu yüzden bir güncelleme hak ediyor

Vade tarihinde

Olgunluğa ilişkin orjinal yorumlarım eski moda. WiredTiger bir süredir herhangi bir önemli sorunu yaşamadı ve MongoDB 3.2'den itibaren varsayılan depolama motoru oldu.

Özelliklerde

Orijinal yorumlarım hala biraz geçerliliğe sahip.

Sıkıştırma

Bununla birlikte, bütçe açısından kısıtlı olunca veya daha genel olarak konuşursak, performans birincil endişe değildir, performans tradeoff'ı oldukça küçüktür ve temelde ne kadar boşta kalırsa onu kullanmak için temelde küçük performans etkileri (sıkıştırılmamış WT ile karşılaştırıldığında) ticareti yaparsınız civarında: CPU.

Şifreleme

MongoDB 3.2 Enterprise, WiredTiger depolarının şifrelenmesini sağladı. Gelişmiş güvenlik gereksinimleri olan veriler için bu bir katil özelliktir ve WT'yi hem teknik olarak (MMAPv1 şifrelemeyi desteklemez) hem de kavramsal olarak tercih edilen tek depolama motoru yapar. Tabii ki, bazı ortamlarda bu seçeneğiniz olmayabilir, ancak şifreli disk bölümleri olasılığını bir kenara koyun.

Belge seviyesi kilitleme

Yukarıdaki analizde WT'nin bu özelliğini temelde atladığımı itiraf etmeliyim, çünkü asıl cevabı yazdığımda bu benim veya müşterilerim için geçerli değildi.

Kurulumunuza bağlı olarak, özellikle çok fazla eşzamanlı yazma istemciniz olduğunda, bu özellik büyük bir performans artışı sağlayabilir.

Toplam sahip olma maliyeti

Göç yapmak hala pahalı. Bununla birlikte, vadedeki değişimler ve özellikler üzerindeki değişmiş görüş dikkate alındığında, aşağıdaki durumlarda bir göç yatırım yapılabilir;

  • Şifrelemeye ihtiyacınız var (yalnızca Enterprise Edition!)
  • Performans sizin mutlak öncelikli kaygınız değildir ve sıkıştırmayı kullanarak uzun vadede (tasarruflu bir şekilde hesaplayın) tasarruf edebilirsiniz
  • Eşzamanlı olarak yazdığınız birçok işleminiz var, çünkü performanstaki artış sizi dikey veya yatay ölçeklendirmeden koruyabilir.

Güncellenmiş Sonuç

Yeni projeler için şimdi WiredTiger kullanıyorum. Sıkıştırılmış bir sıkıştırılmamış WiredTiger deposuna geçiş oldukça kolay olduğundan, CPU kullanımını artırmak için sıkıştırma ile çalışmaya meyilliyim ("paranın karşılığını daha fazla al"). Sıkıştırmanın performans veya UX üzerinde belirgin bir etkisi olması durumunda, sıkıştırılmamış WiredTiger'e taşınırım.

Çok sayıda eşzamanlı yazarı olan projeler için, göçmek veya göçmemek konusundaki cevap, proje bütçesi yatırımı yasaklamadığı sürece hemen hemen her zaman "Evet" olur. Uzun vadede, dağıtım başka türlü makul bir şekilde planlandıysa, performans artışı kendisinin ödemelidir. Ancak, bazı durumlarda sürücünün güncellenmesi gerektiğinden ve hesaplanması gereken sorunlar olabileceğinden, hesaplamaya biraz geliştirme süresi eklemeniz gerekir.

Bütçe açısından kısıtlı olan ve şu an için daha fazla disk alanı sağlayamayan projeler için, sıkıştırılmış bir WiredTiger'e geçiş yapmak bir seçenek olabilir, ancak sıkıştırma işlemcileri MMAPv1 ile duyulmamış bir işlemciye biraz yük getiriyor. Ayrıca, göç maliyetleri böyle bir proje için çok pahalı olabilir.


Cevapladığın için teşekkürler Markus. Argümanlarını anlıyorum. Yeni projeler için varsayılanlara MMAPv1'e geri dönmeyi bile tavsiye eder misiniz? Demek istediğim, eğer performans bir endişe ise, sıkıştırma de tamamen devre dışı bırakılabilir. Disk alanı ucuzdur, ancak sıkıştırma çalışma grubunun RAM'e sığmasına yardımcı olabilir… Yoksa yanlış mıyım?
Buzut

1
Bildiğim kadarıyla, sıkıştırma sadece veri dosyalarına uygulanır. Yeni projelere gelince, şöyle söyleyeyim: Artılarını ve eksilerini gösteren bir yönetim kararı istiyorum. Projelerimden birinde kişisel olarak WT kullanıyorum ve henüz sorun yaşamadım, ancak SLA'lar (mmapv1 ile deneyime dayanarak oldukça iyi hesaplayabiliyorum), sıkı bütçeler (sıkıştırılmış WT için disk alanından tasarruf edin). Risk ve fırsatların tartılması bir DBA kararı değildir. Bir DBA, arama yapmak için gerekli bilgileri sağlamalıdır.
Markus W Mahlberg

1
Bu makale, endekslerin saklanma şeklinin oldukça büyük bir fayda olduğunu göstermektedir, çünkü endekslerinizin alanını 10 kat azaltabilir : ilearnasigoalong.blogspot.com/2015/03/… . Disk alanı ucuz, ancak RAM değil.
BT,

Özellikler konusundaki amacınız hakkında biraz kafam karıştı, MMAPv1'in WiredTiger'ın sahip olmadığı özellikler olduğunu mu söylüyorsunuz? Bu bölüm biraz daha net olsaydı iyi olurdu.
BT,

@BT Hiç de değil. Söylemeye çalıştığım şey, WT'nin bazı kullanım durumlarında yardımcı olabilecek, ancak genel olarak kullanışlı olmayan bazı harika özelliklere sahip olmasıdır. Veri depolama konusunda savaşta test edilmiş bir depolama motorunu en yeni teknolojiye tercih ediyorum. Makaleye göre: Evet, RAM’i kurtarmak için önek sıkıştırması ile mümkündür ve başka bir endişe yoksa bu iyi bir fikir olabilir. Veri kaybı veya performans sorunları için güvenilir olduğunuzu düşünün.
Markus W Mahlberg

5

Benim iki Sentim:

Günlüklerinde WiredTiger o dergi kaydı depolamak için bellek içi arabelleğe kullanması nedeniyle zor kapatmalar güncellemeleri kaybedebilir.

Yazma işlemleri arasında, günlük kayıtları WiredTiger tamponlarında kalırken, mongodun zorla kapatılmasının ardından güncellemeler kaybolabilir.

Günlüklerinde MMAPv1 Disktekiler dergi dosyalardaki değişiklikler yazar.

Eğer mongod örneği, veri dosyalarına yazma işlemine gerek kalmadan çökecek olsaydı, dergi, yazma işlemlerini veri dosyalarına en sonunda yazmak için tekrar görüntüleyebilir.


4

7x - 10x performans kazancıyla MMAPv1'den WiredTiger'e geçtik. WiredTiger önbelleği% 100 çarptığında MongoDB kilitleneceğinden MMAPv1'e geri dönmek zorunda kaldık. Buradaki tecrübemizi belgelendirdik - https://blog.clevertap.com/sleepless-nights-with-mongodb-wiredtiger-and-our-return-to-mmapv1/


2
Güzel yazı. Kinda bana Uber’in 2013’de MySQL’den PostgreSQL’e gideceğini ve Haziran 2016’da MySQL’e geri döneceğini hatırlatıyor.
RolandoMySQLDBA

iyi açıklanmış aynı zamanda kablolu kaplanla da aynı deneyime sahip olduğumuzu açıkladı bu yüzden MMAPV1'e yeniden yorumladım
viren
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.