Benim durumumda MongoDB doğru seçim mi? [kapalı]

İlk gerçek projemi Rails'te 3 ana bölümden oluşan bir web uygulamasından oluşturacağım:

• Veritabanının kullanılmadığı statik kısım
• Bir veritabanı gerektiren Kullanıcı kayıt kısmı ve her kullanıcının satırı aynı alanlara sahip olacağından MySQL kullanabilirim
• Kullanıcıların koleksiyonlardaki öğeleri oluşturabileceği, düzenleyebileceği, düzenleyebileceği ve diğer kullanıcılarla paylaşabileceği "Uygulama"

Birkaç öğe türü olacak ve her biri farklı seçeneklere sahip olacak, örneğin aşağıdaki seçeneklerle "video" öğeleri olabilir:

• İD
• Kullanıcı kimliği
• collection_id
• Başlık
• platform (gömülü ise)
• url (yerleştirilmişse)
• dosya adı (uygulamamda barındırılıyorsa)
• dosya boyutu (uygulamamda barındırılan kimlik)

ve "harita" öğeleri:

• İD
• Kullanıcı kimliği
• collection_id
• Başlık
• platformu (google haritaları, bing haritaları ...)
• yer
• uRL
• harita boyutu

Kullanıcılar için olabildiğince MySQL'i öğeler için kullanabilirim.

Şimdiye kadar her zaman PHP ve MySQL kullandım (her zaman küçük projeler için paylaşılan barındırmada) ve ölçeklenebilirlik benim için tamamen yeni bir kelime.

Öğrenecek zamanım var ama 1 ay gibi bir şeyde somut bir şeyler yapabilmek istiyorum.

MongoDB ve NoSQL vs RDMS ve MySQL hakkında çok şey okudum ve denedikten sonra ben MongoDB nasıl çalışır gibi söylemek gerekir: hiçbir tablo, satır ve onun gibi JSON belgeleri:

• Benim durumumda ne istiyorsunuz? neden?
• Ölçeklenebilirlik hakkında MongoDB ile ilgili sorunlar olabilir mi? evet ise (DB boyutu açısından) ve bu sorunlar benim app önemli ölçüde yavaşlayabilir?

Düzenleme: uygulamanın nasıl çalışacağı

Birçok kişi bu uygulamanın nasıl çalışmasını istediğini sordum beri:

1. Bir kullanıcı kaydı
2. Giriş yaptı
3. Sonsuz eşya yaratabileceği ilk koleksiyonunu yaratıyor
4. Öğeler çeşitli türdedir ve her türün veritabanına kaydedilmesi için farklı veriler gerekir ve öğe türleri eklenebilir veya değiştirilebilir

Kullanıcılar içinde başka koleksiyonlar ve öğeler oluşturabilir.

Bu yüzden içindeki koleksiyonlar ve öğeler için CRUD var ve her koleksiyon / öğe belirli bir kullanıcıya yönlendiriliyor

MySQL ile ana sorun, esnek bir şema olmadığı, bunu çözmek için bir yol var (bir geçici çözüm?)?

NoSQL hakkında düşünme sahip olduğum tek şüphe katılmakla ilgili, örneğin belirli bir koleksiyon verilen Koleksiyonda id = user_id alanı ile Kullanıcı ile ilgili verileri almak istiyorum

EDIT: MySQL kullanmaya devam etmek için fikir

"Öğeler" tablosunda isteğe bağlı ayarlarla bir alan oluşturun, her ayar bir | veya başka bir sembol.

Daha sonra bir yere her öğenin isteğe bağlı ayarlarının bir yapısını kaydedeceğim, örneğin "notlar" öğe türü iki isteğe bağlı ayar "renk" ve "strange_setting" gerekir, MySQL'den veri aldığımda isteğe bağlı ayarlar için alanı bir dizideki ilk öğenin "renk" için olduğunu bilerek dizi.

Ne düşünüyorsun? bu çözümde sorun mu var? başka fikrin var mı?

Siz uygulama ile ne yapmak istediğinizi bize söyleyene kadar size yardımcı olamayabiliriz. İlişkisel veritabanları bazı şeyler için iyidir ve NoSQL veritabanları diğerleri için iyidir.

Birinin bana burada SO'da söylediği gibi:

ilişkisel bir DB'nin ilişkisel kısmı diğer bazı parçalardan çok daha optimize edilmiştir

Bu, kullanım durumlarınıza uygun görünüyorsa ilişkisel bir veritabanı da kullanabileceğiniz anlamına gelir. Esnekliği / ölçeklenebilirliği nedeniyle sadece MongoDB ile devam etmeyin. Wikipedia'da MongoDB hakkında ilk satır:

MongoDB ("humongous" tan), açık kaynaklı bir doküman odaklı NoSQL veritabanı sistemidir.

Gerçekten belge yönelimli bir DB kullanmayı düşünüyor musunuz? Kullanım durumlarınızda biraz grafik varsa, Neo4j gibi bir grafik veritabanına gidebilirsiniz. Ya da bazı insanlar gibi hem SQL hem de NoSQL'in en iyisini birlikte kullanabilirsiniz.

BTW, ayrıca hem SQL hem de NoSQL'in en iyi bölümlerini kullandığım bir proje yapıyorum.

EDIT: Bir kez daha söylüyorum:

Bu makaledeki Neo4j vs Hadoop bölümüne göz atın . Diyor ki:

Prensip olarak, Hadoop ve diğer Anahtar-Değer depoları çoğunlukla nispeten düz veri yapıları ile ilgilidir . Yani, değerler, belgeler ve hatta nesneler gibi basit nesnelerin alınması konusunda son derece hızlı ve ölçeklenebilirdirler.

Aynı makaleye referansla, MongoDB için gideceğiniz düz bir veri yapısına gerçekten ihtiyacınız var mı? Bu, sonunda ayrıntılı kullanım durumlarınıza, 3. ve 4. adımların nasıl yapılacağına bağlıdır.

Ayrıca, aşağıdaki sorulara da başvurabilirsiniz:

/programming/2124274/mongodb-what-to-know-before-using

/programming/1476295/when-to-use-mongodb-or-other-document-oriented-database-systems

( İkinci sorunun üst / seçilen cevabını kesin olarak kontrol edin. Bunun çözebileceği ikilemdesiniz. )

Sanırım bu sorular bilmek istediğiniz tüm bilgilere sahip. Sonunda, MongoDb mi yoksa başka bir şey mi olduğuna karar vermek zorunda kalacaksınız, sadece önerebiliriz. Ayrıntılı kullanım durumlarınızı bilen tek kişi siz ve ekibinizdir.

TEKRAR DÜZENLE (MySQL kısmı için): Anladığım gibi, db'de bir şey saklamayı ve bunları bir ayırıcıyla ayırmayı planlıyorsunuz. Bu 2 sorun yaratır:

1. Ayrıca, ayırıcıya sahip olan herhangi bir girişi işlemeniz gerekir.
2. İlişkisel bir veritabanının ilişkisel depolama kısmı, dize eşleme kısmından çok daha optimize edilmiştir. Ben belirli bir sonuç elde etmek için bir veritabanında dize eşleşen yapmak gereken bir şema için gitmek değildir. Tekrar vurguluyorum:

   ilişkisel bir DB'nin ilişkisel kısmı diğer bazı parçalardan çok daha optimize edilmiştir (örneğin, dize eşleme)

3. Birden çok değerli öznitelikler kullanmayın. İnsanlar genellikle onları korkutuyor.

Bu soruyu çok görüyorum. Her zaman ya / ya da olarak düşünülür. MongoDB yeni ve harika bir araçtır. Ayrıca bazen her şey için parlak bir araç gibi görünüyor ve bu benim deneyimimde kötü bir seçim olabilir.

En iyi kombinasyonun kesinlikle İKİ olduğunu düşünüyorum ve kullanıcılar gibi bazı parçalar için mylsql kullanma yaklaşımınız için sizi takdir etmek istiyorum, ancak kimlik doğrulama ve yetkilendirmenin en iyi mySQL ile yapıldığını hissettiğim için ve diğer bölümler için MongoDB'yi kullanıyorum bunu gerçekten iyi yapan bir ton örnek ve modül.

'Çok sayıda öğe' parçası için, hacminiz yüksekse ve / veya çoğunlukla okunuyorsa ve / veya yapılandırılmamış verilerde mongoDB'yi kullanmayı düşünmek istediğiniz yer burasıdır.

Kararınızı Mongo'nun şemasız esnekliğine dayandırmamanızı tavsiye ederim. SQL ve sql-şemaları, yapılandırılmış verilere sahip olma ve sadece böyle bir yapı ile mümkün olan hesaplamaları ve dönüşümleri gerçekleştirme ihtiyacından kaynaklanır. Bunu veri ambarı rolünde çalıştığım 5 yıl boyunca öğrendim. MongoBD'ye sadece performans sorunu için bakardım. 100.000 kullanıcı ve saniyede 20 istek gibi yüksek hacimli kullanıcı ve istek bekliyorsanız veya bekliyorsanız, mongoDB kullanırım, aksi takdirde sql ile kalmayı denerdim. Birçok durumda mySQL'i düşük hacim için kullanacağım ve daha sonra hacim, gelir ve altyapı desteklediği için mongoDB'de karıştırılmadan önce Oracle'a geçeceğim. Hacim sorunları ile karşılaşmadan önce uğraşmaya çalışmamanız gerektiğini kabul ediyorum, ancak nereye gittiğinize ve ne yaptığınıza dair adil bir fikriniz varsa Şeyleri yarıya kadar yeniden yazmak istemiyorsanız, başlangıçta doğru teknolojileri seçmek çok mantıklıdır. Sadece bu yüksek hacme sahipseniz, kullanmak istediğiniz yığının tüm seviyelerinde çok sayıda seçenek ve teknoloji olduğunu unutmayın.

Gevşek yapılandırılmış verilerin dezavantajı vardır. Burada otopark benzetmesini kullanıyorum. giren ilk 3 araba için hiçbir bölme çizgisi harika değildir, ancak daha fazla araba girdikçe, çok dağınıklık olmaya başlar ve park etmeye veya kolayca araba saymaya ve şeritleri serbest tutmaya çalışmak bir kabus haline gelir. Bunu düzenlemek işi ön plana çıkarır - çizgileri, bölücüler ve trafik akışlarını vb. İşaretlemek, ancak işe yarar. Bazen işler elbette değişir (arabalar büyür) ve bazı değişiklikler yapmanız gerekir - çizgileri yeniden boyamak. Ayrıca yıllık boyamalar ve bakım için sadece standart duruş süresi.

Şema tasarım yönü geleneksel mysql kullanıcıları için muhtemelen en büyük engel olacaktır. Bence şema tasarımı ile ilgili MongoDb sayfası bu konuda yardımcı oluyor. Son nokta, karışıma eklediğiniz her teknolojinin karmaşıklık katması. Herhangi bir parça için onu kullanmanız gerektiğini söyleyen büyük savunucular vardır, ama gerçekten büyük bir faktörün kaç tane parça olduğunu buldum. Bu, daha fazla olası başarısızlık noktasını ve daha da önemlisi, başkalarının üzerinde çalışmayı bilmesi gereken bir bilgi tabanını gerektirir.

fyi Rick Obsorne oldukça benzersiz bir karşılaştırma şemasına sahiptir!

Burada NoSQL vs MySQL için geçerli birçok argüman görüyorum. Ancak eksik bir bağlantı ölçekle ilgilidir: Eğer gerçekten ölçeklemek ve bir şirket içi veritabanı ile yapmak istiyorsanız, veritabanları hakkında çok fazla bilgiye ihtiyacınız olacaktır. İnsanların sonsuza dek ölçeklenecek bir sistemi uygulamaya çalışmakta başarısız oldukları çok fazla korku hikayesi var.

Gerçekten NoSQL yoluna gitmeyi seçerseniz (ve bununla birlikte gelen masrafları almaya hazırsanız - birleştirme yok gibi), AWS DynamoDB'yi (http://aws.amazon.com/dynamodb/) dikkate alın. Burada tüm veritabanı ölçekleme bölümünü unutabilir ve uygulamanıza konsantre olabilirsiniz. İyi şanslar.

Feragatname: AWS DynamoDB ekibinin geliştiricisiyim, ancak ürünümüze gerçekten inanıyorum. Deneyin :)

Böylece, tasarımınız veritabanınıza iki farklı nesne türünü kaydeder:

• Kullanıcı nesnesi (her zaman alanları vardır).
• Uygulama nesneleri (farklı alanlara sahip olabilir). Bir uygulama yalnızca bir kullanıcıya ait olacaktır.

Bir koleksiyon, yalnızca farklı uygulamaları gruplamak için kullanılan bir etiket gibi, farklı bir nesne olarak oluşturulabilir veya oluşturulamaz. Tartışma uğruna, diyelim ki koleksiyon yok ve kullanıcıların sadece bir uygulama listesi var.

MySQL'de ulaşılabilir olduğunu düşünürken, MongoDB'de uygulama nesnelerinin yapısı açısından daha büyük bir esnekliğe sahip olacaksınız ve muhtemelen kodunuzu daha doğal hale getirerek veritabanınıza daha doğal bir şekilde temsilinizi eşleştirecek.

MySQL'de farklı uygulamalar için farklı biçimlerle ilgili sorunlarınız olacaktır, ancak bu mümkündür. Bazı fikirler:

• Tüm nesneler arasındaki tüm ortak bilgileri (id, user_id, title, vb.), Ardından türü içeren bir ara tablo oluşturabilirsiniz, böylece bu format için yalnızca ortak olmayan alanların bulunduğu başka bir tabloda (ör. dosya_adı ve dosyalar için dosya_boyutu). Her farklı biçim için farklı bir tablo oluşturmanız gerekir. Her iki tablo da app_id (Birincil anahtar) ile dizinlenirse, bir tabloya dizinlenmiş bir değerle erişilmesi hızlı olduğundan, yeterince hızlı olacaktır.
• Verileri bir biçimde kodlayabilir ve standart olarak saklayabilirsiniz. Örneğin, JSON'daki yaygın olmayan verileri bir dize olarak kodlayın ve bir VARCHAR alanında saklayın. Bu alanın boyutuna dikkat edin, böylece alanınız bitmez. Biçim karmaşık (JSON) veya basit olabilir (yalnızca virgülle ayrılmış değerler)
• İnt1, int2, str1, str2 gibi farklı "genel" alanlar oluşturabilir ve farklı bir tür için "konum" olabilirken, bir uygulama türü için str1'in "dosya_adı" olduğunu tanımlayabilirsiniz.

MongoDB'de, biri kullanıcılar için diğeri uygulamalar için olmak üzere iki MongoDB koleksiyonu kullanmak kadar basit olabilir. Bir çeşit sınır varsayalım (açıkladığınız gibi değil, sadece söylemek için), uygulamaları kullanıcı nesnesinin içinde bir liste olarak saklayabilirsiniz. Alanlar ne olursa olsun her türlü nesneyi depolayabileceğiniz için verilerin depolanması ve alınması daha doğaldır. Bir kullanıcıya ait tüm uygulamaları almak için user_id ile arama yapabilirsiniz. MongoDB'de yine de birleştirme sorguları yapma olasılığınızı kaybedersiniz, ancak bu durumda temel sorguların kullanıcıyı alıp kullanıcıyla ilgili uygulamaları alacağını düşünüyorum. "Bana her birinde üç veya daha fazla uygulama içeren ikiden fazla koleksiyona sahip kullanıcıları ver" gibi bir çok şey yapmayı planlıyorsanız, bunu bir katılma sorgusu olarak değil, ancak kodda bir işlem olarak ve ilişkisel bir veritabanından daha az doğal olacaktır ve işlenmesi daha fazla zaman alabilir. Parametreleri aramak istiyorsanız (örneğin, belirli bir kullanıcıya ait tüm uygulamaları bana verin; X türündeki tüm uygulamaları bana verin), bu MongoDB'de oldukça kolaydır ve birleştirmeleri kullanmanıza gerek yoktur.

MongoDB on Rails'in desteğinden emin değilim. Python ve JavaScript ile kullandım.

EDIT: İki tablo ve başka bir MySQL seçeneğine erişirken zaman hakkında yorum eklendi

En iyi bildiğiniz teknolojiyi, özellikle de gerçek bir proje ise ve hızlı bir şekilde dışarı itmek istiyorsanız kullanın. MySQL ve Mongo kullanmanın her ikisi de kendi yararları ve baş ağrılarıyla birlikte gelir. Her ikisiyle de çalıştıktan sonra, iyi tasarım ilkelerinizi takip ederseniz MySQL'den Mongo'ya taşınmanın çok zor olmadığını da ekleyeceğim.

Bununla birlikte, sizin durumunuzda MongoDB ile gitmenin iyi bir nedeni verilerinizdir. Bahsettiğiniz gibi, koleksiyonlarınız için birkaç farklı giriş türünüz olacak: harita, video vb. Bunu RDBMS kullanarak uygulayacaksanız, 3 yaklaşımınız vardır:

• tür başına tablo: her tablo, her bir nesne türüne özgü sütunlar içerir

  Dezavantajları : Tüm veri türlerinde arama yapmak için N sorgusu.

  Avantajları : iyi OO tasarımı, bakımı kolay

• tek tablo: tüm türler için tüm olası öznitelikleri içeren büyük bir tablo, çoğu belirli bir giriş için boş

  Dezavantajları : Herhangi bir nesnede değişiklik yapmak tabloyu değiştirmeyi gerektirir, tablo büyüdüğünde acı verir. Bakımı zor.

  Avantajları : Kolay uygulanır.

• meta veri içeren çekirdek tablo: temel nitelikleri olan tek bir tablonuz var, başlık, tarihler ve ek özellikler için anahtar / değer çiftleri içeren bir meta veri tablosu var

  Dezavantajları : Tek bir nesne için tüm verileri almak için iki sorgu.

  Avantajları : Son derece esnektir, uygulanması çok zor değildir.

Bu yaklaşımların her birini daha önce kullandım ve hiçbirinin Mongo ile doğal çalışma olmadığını söyleyebilirim. Verileriniz muhtemelen şöyle görünecektir:

{_id:"collection1",
 name:"My first Collection",
 owner: "user123243342",
 entries: [
    {type:"video",
     url: "http://www.youtube.com/234324",
     tags: ["roadtrip", "fun", "camera"]
     },
    {type:"map",
     coordinates: [LOC: [38, –102], LOC: [43, –33], LOC: [228, –102]],
     description: "Road trip to nowhere",
 ]
}

Ancak, etki alanı nesneleriniz doğrudan bu şekilde kalıcı olabileceğinden, şema tasarımı hakkında endişelenmenize gerek yoktur. MongoDB temelde sorgulayabileceğiniz nesne deponuzdur.

MySql ve Mongodb arasındaki performans karşılaştırması hakkında herhangi bir tartışmayı bıraktım. Performansı her zaman aklınızda tutmanız gerekirken, veri erişim düzenini bilmediğiniz sürece etkili bir şekilde karar veremezsiniz. İyi bir proje, büyüdükçe ve yeni zorluklar ortaya çıktıkça, muhtemelen birkaç yeniden düzenleme tekrarından geçecektir. Performanstan önce endişelenmeyin ve en iyi bildiğiniz aracı seçin ve kodlamaya başlayın.

Düzenle

MySQL kullanma ve nitelikleri "|" kullanarak aynı alanda tutma konusundaki özel sorunuza yanıt vermek için. Bunu yapma. Bu yaklaşım size çözdüğünden daha fazla sorun verecektir. Her şeyden önce, MySql kullanarak ayrı ayrı öznitelikleri sorgulayamazsınız. İkincisi, veri erişim katmanınıza çok fazla karmaşıklık katar. Bunun yerine tablo başına türü veya meta veri yaklaşımını kullanın. Daha önce WordPress ile çalıştıysanız, meta veri yaklaşımını kullanır:

• kullanıcı tablosu + kullanıcı için usemeta
• yazı masası + postmeta masa sonrası

Bu, veri yapısını son derece esnek ve makul bir hızla sorgulanabilir hale getirir.

Aşağıdaki makalede, veritabanındaki veri miktarı ve alınan veri miktarı dikkate alınarak MySQL ve MongoDB'yi seçme, getirme ve ekleme açısından karşılaştırarak iyi sonuçlar verilmektedir. Sonuçlar MongoDB için "kesici uçlar" konusunda büyük bir performans gösterirken, diğer durumlarda MySQL kazanır. Aşağıya bakınız:

http://www.moredevs.ro/mysql-vs-mongodb-performance-benchmark/

MongoDB kullanarak iyi bir çözüm olduğunu düşünüyorum. Her gün binlerce koleksiyon eklemek için kullandım. Solr çözümü ile birlikte (önbellek çözümü, günde bir kez güncellenir), gerektiğinde toplama kimliğiyle MongoDB verilerini alabilirim, böylece anında seçimlere ihtiyacım yok. Bu nedenle, çok sayıda kesici uçla uğraşmanız gerektiğine ve seçmek ve getirmeye dikkat etmenize gerek olmadığına bakıldığında, MongoDB harika bir fikir olabilir, her duruma ve iyi bir analiz yapmaya bağlıdır.