MongoDB veya CouchDB - üretime uygun mu? [kapalı]

MongoDB veya CouchDB'nin bir üretim ortamına hazır olup olmadığını söyleyebilecek biri olup olmadığını merak ediyordum .

Şimdi bu depolama çözümlerine bakıyorum (şu anda MongoDB'yi destekliyorum), ancak bu projeler oldukça genç ve bu yüzden yöneticimi bunu benimsememiz gerektiğine ikna etmek için çok çalışmam gerekeceğini tahmin ediyorum. yeni teknoloji.

Bilmek istediğim şey:

1. Bugün üretim ortamında MongoDB veya CouchDB'yi kimler kullanıyor?

2. MongoDB / CouchDB'yi nasıl kullanıyorsunuz?

3. Bu yeni depolama mekanizmasını kabul ettiğinizde (varsa) hangi problemlerle karşılaştınız (ve bunların üstesinden nasıl geldiniz)?

4. Anlaşmanız gereken göç sorunlarıyla nasıl başa çıktınız?

5. Paylaşmak istediğiniz bu çözümlerden herhangi biriyle ilgili iyi / kötü deneyimleriniz var mı?

Ben 10gen CTO'suyum (MongoDB geliştiricileri), bu yüzden biraz önyargılıyım, ancak üretimde MongoDB kullanan birkaç siteyi de yönetiyorum.

businessinsider , bir yılı aşkın bir süredir üretimde mongo kullanıyor. Kullanıcılardan ve blog yayınlarından sitedeki her resme kadar her şey için kullanıyorlar.

shopwiki bunu gerçek zamanlı analitik ve önbellek katmanı gibi birkaç şey için kullanıyor. Oldukça büyük bir veritabanına saniyede 1000'den fazla yazma yapıyorlar.

Eğer giderseniz mongodb Üretim dağıtımlar sayfasında üretimde mongo kullanan bazı insanlar göreceksiniz.

Üretim dağıtımlarının ölçeği veya kapsamı hakkında herhangi bir sorunuz varsa, kullanıcı listemize gönderin ve size yardımcı olmaktan memnuniyet duyarız.

BBC ve meebo.com üretimde CouchDB kullanabilir ve böylece müşterilerimden biri yapar. Burada Couch: CouchDB kullanan diğer insanların bir listesi

En büyük zorluk belgelerinizi nasıl düzenleyeceğinizi bilmek ve ilişkisel veriler açısından düşünmeyi bırakmaktır.

SourceForge , MongoDB kullanır. Bu sunuma bakın veya buradan okuyun .

CouchDB'yi mağazalarımız için MySQL yerine geçiyor (70.0000 ürün / mağaza, tüm öğelerin toplam 4 milyon özelliği, öğeler arasındaki çapraz bağlantılar).

Hedeflerimiz:

1. Bir master-db'den farklı belgelere sahip birkaç istemciye kolay çoğaltma.

2. "Bu özelliğe ve o filtreye sahip kaç parçam var, bu koşullara uygun" gibi hızlı önceden hesaplanmış veriler

Gerçekler:

1. Mağazalarımız artık MySQL'den çok daha hızlı çalışıyor (ve mysql-database ek olarak 1-3 günlük ön hesaplama gerektiriyor (bu nedenle güncelleme ayda iki kez yapıldı), bu da verileri ürün sayımı ve filtrelemeye hazır hale getiriyor, CouchDB 5 saate ihtiyaç duyuyor. ürün verilerini her gece güncelleyebiliriz)
2. Mağaza düğümlerine veri dağıtımı ve yedeklemeleri ayarlamak (filtrelenmiş) hızlı ve kolaydır

Ayrıca:

1. Harita / indirgeyi ve katılmamanın sınırlarını anlamak oldukça zor
2. Harici programlar olmadan "nerede sil" veya "nerede güncelle" gibi veriler üzerinde işlem yapılmaz
3. Bir sorun olmadığı sürece çoğaltma iyi çalışır; o zaman sebebinin ne olduğunu bulmak gerçekten zor (yeni başlayanlar için)
4. Bir Linux geek değilseniz, CouchDB'nin ikili olmadan kurulumu (evet, vahşi bir bazıları var, ancak her işletim sistemi / sürüm için değil) zor olabilir. Ancak CouchDB Topluluğu yararlıdır (#couchdb) ve neyse ki ücretsiz şirketlerden büyük işletmelere hizmet sunan şirketler var (cloudant, iriscouch).
5. CouchDB ilerliyor, bu yüzden çalışma şeklinizi değiştirebilecek birçok değişiklik (iyileştirme) var. Ancak temel şeyler sabit kalır.

Sonuç olarak: MySQL veri oluşturma ve bakımı için bir veritabanı olarak güvenilir ve anlaşılması ve işlenmesi kolaydır. Bence bunu değiştirmeyeceğiz. Ancak CouchDB görünümlerinin gücünü ve çoğaltma kolaylığını da kaçırmak istemiyorum.

Üretim kanepeleri bazen yanlış konfigürasyon ve unutulmuş logroitler (görünüm oluşturma çok uzun sürüyor veya takılıyor, çoğaltma duruyor) nedeniyle aylarca çalıştıktan sonra sorun yarattı, ancak asla veri kaybı olmadı ve her zaman kolayca sıfırlanabilir.

Üretimde CouchDB kullanıyorum. Şu anda orijinal DB şemasında olmayan tüm bu 'isteğe bağlı' alanları saklamaktadır. Ve şimdi tüm verileri CouchDB'ye taşımayı düşünüyorum.

Oldukça riskli bir adım, itiraf ediyorum. Birincisi, çünkü henüz v1.0 değil. İkincisi, tahrik alanına aç olduğu için. Hesaplamalarıma göre, CouchDB dosyası (dizinlerle) aynı satırlara sahip MySQL veritabanından ~ 30 kat daha büyük. Ama gayet iyi çalışacağından eminim.

CouchDB 0.11 (Mart sonunda piyasaya sürüldü) 1.0 için bir özellik dondurma sürümüdür. Bu, şu anki API ile uyumluluğu 1.0 olarak koruyacağımız anlamına gelir, bu nedenle şimdi bir süredir CouchDB'ye bir göz atmak için iyi bir zaman.

CouchDB 0.11 kaynak kodu sürüm burada mevcuttur. Burada ikili yükleyiciler ve diğer güzellikler bağlı.

MongoDB hakkında hiçbir şey bilmiyorum ama CouchDB SSS bölümünden :

CouchDB Üretime Hazır mı?

Evet, CouchDB kullanan projelerin kısmi bir listesi için InTheWild'e bakın . Diğer iyi bir bakış CouchDB Örnek Olaylar

Ayrıca, bazı bağlantılar:

• Re: Mevcut CouchDB durumu?
• SimpleDB, CouchDB ve Diğer "YENİ" Veri Depoları - Geribildirim

Sofadb'yi üretimde kullanıyoruz ve proje Apache şemsiyesi altına girmeden hemen önce var.

Bunu, aksi takdirde bir dbms kullanabileceğimiz her şeyi ve her türlü yapılandırılmamış veriyi depolamak için kullanırız. Şahsen, her türlü veriyi nasıl atabileceğinizi ve duruma bağlı olarak ihtiyacınız olmayan şeyleri ayıklamak için görünümleri nasıl kullanabileceğinizi gerçekten seviyorum.

En zor kısmı dbms zihniyetinden uzaklaşıyordu. Depolama biçimi güvenli olarak değiştiğinde kendi taşıma araçlarımızı yazdık, bu gerçekten bir sorun değildi.

Henüz olumsuz bir deneyim yaşamadık, ancak yine de herhangi bir büyük yük altında kurulum yapmadık. Ben tüm yazma alır tek bir ana sunucudan çoğaltma iki köle tipi sunucu var çünkü işler oldukça iyi olacağını düşünüyorum . Çoğaltmanın düzgün çalışması için bunu böyle yapmak zorunda olmadığımızdan eminim, ancak başlangıçta bu şekilde ayarladık ve sıkıştı.

Mobil gelen ve giden iletileri saklamak ve yazdığım bazı özel görünümler aracılığıyla bu trafiği raporlamak için CouchDB'yi kullanıyoruz. Ön uç Python ile yazılmıştır. Gerçek bir teknik sorunumuz yoktu ve Aralık ayının sonundan beri devam ediyor. Karşılaştığım tek engel başlangıçta MapReduce açısından düşünüyordu, ancak bunu nasıl yapacağımı öğrendiğimde, her şey sorunsuz gitti.

Şu anda üretimde önbellek katmanı olarak MongoDB'nin yanı sıra ürün verilerini almak ve işlemek için depolama motorunu kullanıyoruz. 10 milyon distribütörü kapsayan ve MongoDB olmadan iki milyondan fazla ürünü (100+ milyon özellik) yöneten bir e-ticaret şirketiyiz, bu görev imkansız olacaktı.

LAN üzerinden işbirliğimiz için mongodb'u dosya depolama hizmeti olarak kullanıyoruz. Ayrıca, trello gibi projeler mongodb'u arka uç veri deposu olarak kullanıyor. Couchdb'yi daha önce kullandım, ancak üretim kapasitesinde kullanmadım.

Mobil arka uç servisimiz Netmera'da MongoDB'yi üretimde kullanıyoruz. Tüm kullanıcı ve içerik verilerini depolamak için kullanıyoruz.

Neredeyse 2 yıldır CouchDB'yi üretimde kullanıyorum. Proje doğrudan CouchDB uygulamasıyla başladığı için bir göç çalışması yoktur. Tek bir elektronik ürünün verilerini başlangıçtan ambalaja kadar depolayan bir veritabanı görevi görür.

Yüksek doğrulukta bir talep ile sensör sattığımız için, farklı aşamada çok fazla test yapıyoruz ve tüm bunlar CouchDB'de tek bir belgede saklanacak.

Deneyimlerimden öğrendiğim, görüşlerden tam olarak yararlanmak (ya da kalıcı görüşler olarak da bilinen) bir öğrenme eğrisi var. Görünümler, Veritabanı'nın sıkça çağrılacak bir kısmının "küçük filtresi" olmalıdır.

Benim CouchDB veritabanım diğer devasa şirketler kadar çılgın değil. Ama şimdiye kadar hala iyiyim. Şu anda 700MB'da 24000 dokümanım var.

CouchDB'den beğendiğim özellik 'çoğaltma', 'belgenin revizyonlarını saklamak'.

MongoDB üzerinde çok iyi değerlendirmeleri okumak ve bir şans varsa denemek isteyeceğim.

Üretimde mongodb kullanıyoruz

www.beachfront.io - saniyede 5k yazma isteğine yakın

Verilerin arşivlenmesinde karşılaşılan tek zorluk, özel bileşenimizi uygulayarak üstesinden geliyoruz.

Bu soru zaten cevabı kabul etti, ancak şimdi bir gün daha fazla NoSQL DB harika özelliklerinin çoğu için trend. Bu Couchbase; olarak hangi çalışır CouchbaseLitemobil platformda ve Couchbase Serversunucu tarafında.

İşte Couchbase Lite'ın bazı temel özellikleri.

Couchbase Lite, mobil uygulamalara gömmek için uygun, hafif, belge odaklı (NoSQL), senkronize edilebilir bir veritabanı motorudur.

Hafif:

Gömülü — veritabanı motoru, ayrı bir sunucu işlemi değil, uygulamaya bağlı bir kütüphanedir. Küçük kod boyutu — genellikle hücre ağları üzerinden indirilen mobil uygulamalar için önemlidir. Hızlı başlatma süresi — mobil cihazlarda nispeten yavaş CPU bulunduğundan önemlidir. Düşük bellek kullanımı — tipik mobil veri setleri nispeten küçüktür, ancak bazı belgelerin büyük multimedya ekleri olabilir. İyi performans — kesin rakamlar elbette verilerinize ve uygulamanıza bağlıdır.

Belge odaklı araçlar:

Kayıtları önceden tanımlanmış şemalar veya normalleştirme yerine esnek JSON biçiminde depolar. Belgeler, multimedya içeriği gibi gelişigüzel boyutlu ikili eklere sahip olabilir. Uygulama veri formatı, açık geçişlere gerek kalmadan zaman içinde gelişebilir. MapReduce endekslemesi, özel sorgu dilleri kullanmanıza gerek kalmadan hızlı aramalar sağlar.

Senkronize edilebilir anlamına gelir:

Veritabanının herhangi iki kopyası verimli, güvenilir, kanıtlanmış bir çoğaltma algoritmasıyla senkronize edilebilir. Senkronizasyon isteğe bağlı veya sürekli olabilir (birkaç saniye gecikmeyle). Aygıtlar, uzak sunucudaki büyük bir veritabanının alt kümesiyle eşitlenebilir. Senkronizasyon motoru aralıklı ve güvenilir olmayan ağ bağlantılarını destekler. Uygulama mantığı birleştirme üzerinde tam denetime sahip olarak çakışmalar tespit edilebilir ve çözülebilir. Revizyon ağaçları, veri kaybı veya yanlış çakışmalar olmaksızın sunucudan sunucuya (birden çok veri merkezi için) ve eşler arası da dahil olmak üzere karmaşık çoğaltma topolojilerine izin verir. Couchbase Lite, kesintisiz iOS (Objective-C) ve Android (Java) geliştirme için yerel API'ler sağlar. Ek olarak, PhoneGap için Couchbase Lite Eklentisini,

Couchbase Lite hakkında daha fazlasını keşfedebilirsiniz

ve Couchbase Sunucusu

Bu bir sonraki büyük şeye gidiyor.

Konuşma üretimi, kesintisiz yük devretme / kurtarma hem bebek bakıcısı gerektirir
1- Kanepe, kesintisiz yük devretme / kurtarma yoktur, manuel müdahale gereklidir.
yeniden dengeleme çok fazla zaman alır, birden fazla düğüm kaybolursa çok fazla risk alır.

2- Moğollu Moğol, bir yapılandırma sunucusunu kaybetmekten veri kurtarma, kolay bir iş değildir

Adobe kullanıyor MongoDB onların yaklaşan serbest bırakılması için Adobe Experience Manager (eski Günü CQ çekirdek DB motoru olarak ) .

Çalıştığım ajanstaki birçok müşteri CouchDB'yi büyük müşteriler için projelerde kullanıyor .

Her ikisi de benim görüşüme göre, büyük ve uygulanabilir DB vardır. :)

İşte mongoDB ile üretim tarafından dağıtılan sitelerin bir listesi

• Yeni Yorks Times : Fotoğraf gönderimleri için form oluşturma uygulamasında kullanma. Mongo'nun şema eksikliği, üreticilere özel form alanlarının herhangi bir kombinasyonunu tanımlama yeteneği verir.
• SourceForge : Tüm projeler için SourceForge ön sayfalarında, proje sayfalarında ve indirme sayfalarında arka uç depolaması için kullanılır.
• Bit.ly
• Etsy
• IGN : IGN'nin gerçek zamanlı trafik analizine ve RESTful İçerik API'larına güç sağlar.
• Justin.tv : Justin.tv'nin, kullanıma hazır çözümlerin sağlayamadığı virallık, kullanıcı tutma ve genel kullanım istatistikleri için dahili analiz araçlarına güç sağlar.
• Posterous
• sezmek
• Oturaklı : Kırık Mongo veritabanları oturaklı çoğu veri için kullanılır.
• Business Insider : 2008 başından beri kullanıyor. Sitenin yayınlar, yorumlar ve hatta resimler dahil tüm verileri MongoDB'de saklanıyor.
• Github : dahili bir raporlama uygulaması için kullanılır.
• İnceleyici : sitelerini Cold Fusion ve SQL Server'dan Drupal 7 ve MongoDB'ye taşıdı.
• Grooveshark : şu anda günde bir milyondan fazla benzersiz kullanıcı oturumunu yönetmek için Mongo'yu kullanıyor.
• BuzzFeed
• disk
• Evite : Analitik ve hızlı raporlama için kullanılır.
• Squarespace
• Shutterfly : Shutterfly içindeki çeşitli kalıcı veri depolama gereksinimleri için kullanılır. MongoDB, Shutterfly'ya müşteriler ve hayatlarında en önemli olan kişiler arasında daha derin ve daha kişisel ilişkiler sağlayan rakipsiz bir hizmet oluşturmasına yardımcı olur.
• Topsy
• Bunu Paylaş
• Mongohq : MongoDB için bir hosting platformu sağlar ve ayrıca hizmetinin arka ucu olarak MongoDB'yi kullanır. Hosting merkezleri sayfamız MongoHQ ve diğer MongoDB hosting seçenekleri hakkında daha fazla bilgi sağlar.

ve dahası...

Alıntı: http://lineofthought.com/tools/mongodb

Orada diğer veritabanlarını veya araçları da kontrol edebilirsiniz.

MongoDB'nin işletmelere lisans verme konusunda bazı sorunları var, ayrıntılardan emin değilim ama hukuk departmanımız bize hiçbir koşulda MongoDB'yi ürünlerimizde kullanmamıza izin verilmediğini söyledi.