NoSQL veri deposu kullanarak hangi ölçeklenebilirlik sorunlarıyla karşılaştınız? [kapalı]

NoSQL, ilişkisel veritabanlarının ve ACID garantilerinin geçmişinden kopan ilişkisel olmayan veri depolarını ifade eder. Popüler açık kaynaklı NoSQL veri mağazaları şunları içerir:

• Cassandra (tablo şeklinde, Java ile yazılmış, Cisco, WebEx, Digg, Facebook, IBM, Mahalo, Rackspace, Reddit ve Twitter tarafından kullanılır)
• CouchDB (Erlang dilinde yazılmış, BBC ve Engine Yard tarafından kullanılan belge)
• Dynomite (anahtar değeri, Erlang dilinde yazılmış, Powerset tarafından kullanılır)
• HBase (anahtar / değer, Java ile yazılmış, Bing tarafından kullanılıyor)
• Hypertable (tablo şeklinde, C ++ ile yazılmış, Baidu tarafından kullanılmış)
• Kai (anahtar / değer çifti, Erlang ile yazılmış)
• MemcacheDB (C değeriyle yazılmış, Reddit tarafından kullanılan anahtar / değer çifti)
• MongoDB (C ++ ile yazılmış, Electronic Arts, Github, NY Times ve Sourceforge tarafından kullanılan belge)
• Neo4j (grafik, Java ile yazılmış, bazı İsveç üniversiteleri tarafından kullanılıyor)
• Project Voldemort (LinkedIn tarafından kullanılan anahtar / değer, Java ile yazılmış)
• Redis (C değeriyle yazılmış, Craigslist, Engine Yard ve Github tarafından kullanılan anahtar / değer çifti)
• Riak (anahtar değeri, Erlang ile yazılmış, Comcast ve Mochi Media tarafından kullanılır)
• Ringo (Nokia tarafından kullanılan Erlang dilinde yazılmış anahtar / değer çifti)
• Scalaris ( OnScale tarafından kullanılan Erlang dilinde yazılmış anahtar / değer çifti)
• Terrastore (belge, Java ile yazılmış)
• ThruDB (C ++ ile yazılmış, JunkDepot.com tarafından kullanılan belge)
• Tokyo Kabini / Tokyo Tyrant (C dilinde yazılmış, Mixi.jp (Japon sosyal paylaşım sitesi) tarafından kullanılan anahtar / değer çifti)

Siz - SO okuyucu - veri depolarını ve kullandığınız NoSQL veri deposunu kullanarak çözdüğünüz belirli sorunları bilmek istiyorum.

Sorular:

• Çözmek için NoSQL veri depolarını hangi ölçeklenebilirlik sorunlarını kullandınız?
• Hangi NoSQL veri deposunu kullandınız?
• NoSQL veri deposuna geçmeden önce hangi veritabanını kullandınız?

İlk elden deneyimler arıyorum, bu yüzden lütfen sahip olmadığınız sürece cevap vermeyin.

Yükü kaldırabilmek için MySQL'den CouchDB'ye küçük bir alt projeye geçtim. Sonuç şaşırtıcıydı.

Yaklaşık 2 yıl önce, http://www.ubuntuusers.de/ adresinde (muhtemelen en büyük Alman Linux topluluğu web sitesi olan) kendi kendine yazılmış bir yazılım yayınladık . Site Python ile yazılmış ve tüm istisnaları yakalayabilen ve bunları MySQL destekli başka bir küçük web sitesine gönderebilen bir WSGI ara katmanı ekledik. Bu küçük web sitesi farklı hataları belirlemek için bir karma kullandı ve olay sayısını ve son olayı da sakladı.

Ne yazık ki, piyasaya sürüldükten kısa bir süre sonra, traceback-logger web sitesi artık yanıt vermiyordu. Ana sitemizin üretim db'sinde, hemen hemen her isteği istisnalar ve test aşamasında keşfetmediğimiz birkaç hata ile bazı kilitleme sorunları yaşadık. Ana sitemizin sunucu kümesi, traceback-logger gönderme sayfası saniyede birkaç k. Geri izleme günlüğü barındıran küçük sunucu için çok fazla bir yoluydu (sadece geliştirme amaçlı kullanılan eski bir sunucuydu).

Şu anda CouchDB oldukça popülerdi ve bu yüzden denemeye ve onunla küçük bir traceback-logger yazmaya karar verdim. Yeni günlükçü, yalnızca sıralama ve filtre seçenekleriyle bir hata listesi ve bir gönderme sayfası sağlayan tek bir python dosyasından oluşuyordu. Ve arka planda bir CouchDB süreci başlattım. Yeni yazılım, tüm isteklere son derece hızlı bir şekilde yanıt verdi ve çok sayıda otomatik hata raporunu görüntüleyebildik.

İlginç bir şey, önceki çözümün, diğer taraftan yeni CouchDB tabanlı sitenin sadece çok sınırlı kaynaklara sahip paylaşılan bir xen örneğinde çalıştığı eski bir adanmış sunucuda çalışmasıydı. Ve anahtar-değer mağazalarının gücünü yatay ölçeklemek için bile kullanmadım. CouchDB / Erlang OTP'nin hiçbir şeyi kilitlemeden eşzamanlı talepleri işleme yeteneği zaten ihtiyaçları karşılamak için yeterliydi.

Şimdi, hızlı bir şekilde yazılan CouchDB-traceback logger hala çalışıyor ve ana web sitesindeki hataları keşfetmenin yararlı bir yoludur. Her neyse, ayda yaklaşık bir kez veritabanı çok büyür ve CouchDB süreci öldürülür. Ancak, CouchDB'nin compact-db komutu, birkaç GB'den bazı KB'lere yeniden boyutu küçültür ve veritabanı tekrar çalışır durumdadır (belki de orada bir cronjob eklemeyi düşünmeliyim ... 0o).

Özetle, CouchDB bu alt proje için kesinlikle en iyi seçim (ya da en azından MySQL'den daha iyi bir seçim) idi ve işini iyi yapıyor.

Şu anki projem aslında.

18.000 nesneyi normalleştirilmiş bir yapıda depolamak: 8 farklı tabloda 90.000 satır. Bunları almak ve Java nesne modelimizle eşleştirmek için 1 dakika sürdü, her şey doğru bir şekilde dizine eklenmiş vb.

Bunları hafif metin temsili kullanarak anahtar / değer çiftleri olarak saklama: 1 tablo, 18.000 satır, hepsini almak ve Java nesnelerini yeniden oluşturmak için 3 saniye.

İş açısından: ilk seçenek mümkün değildi. İkinci seçenek, uygulamamızın çalıştığı anlamına gelir.

Teknoloji ayrıntıları: SQL ve NoSQL için MySQL üzerinde çalışıyor! İyi işlem desteği, performans ve verileri bozmamak, oldukça iyi ölçeklendirme, kümeleme desteği vb. İçin kanıtlanmış geçmiş performansı için MySQL'e bağlı kalmak.

MySQL'deki veri modelimiz artık sadece kilit alanlar (tamsayılar) ve büyük "değer" alanı: temelde büyük bir METİN alanı.

Yeni oyuncuların hiçbiriyle (CouchDB, Cassandra, MongoDB, vb.) Gitmedik, çünkü her biri kendi başlarına harika özellikler / performans sunsa da, koşullarımız için her zaman dezavantajlar vardı (örn. Eksik / olgunlaşmamış Java desteği).

MySQL kullanılarak (ab) Ekstra fayda - modelimizin bitleri do ilişkisel işi kolayca anahtar / değer verileri saklamak için bağlantılı olabilir.

Güncelleme: işte patronumun beni vurduğu gibi gerçek iş alanımızı değil ("ürünler" ile çalışmıyoruz) metin içeriğini nasıl temsil ettiğimize bir örnek, ancak yinelenen yönü (bir varlık, burada) "diğerleri" içeren bir ürün). Umarım normalleştirilmiş bir yapıda bunun birkaç tablo olabileceği açıktır, örneğin bir ürünü diğer ürünlerin bulunduğu lezzetler yelpazesine katmak, vb.

Name=An Example Product
Type=CategoryAProduct
Colour=Blue
Size=Large
Flavours={nice,lovely,unpleasant,foul}
Contains=[
Name=Product2
Type=CategoryBProduct
Size=medium
Flavours={yuck}
------
Name=Product3
Type=CategoryCProduct
Size=Small
Flavours={sublime}
]

Todd Hoff'un highscalability.com , bazı vaka çalışmaları da dahil olmak üzere NoSQL'in büyük bir bölümünü kapsamaktadır.

Ticari Vertica sütunsal DBMS amaçlarınıza uygun olabilir (SQL'i desteklese bile): analitik sorguları için geleneksel ilişkisel DBMS'lerle karşılaştırıldığında çok hızlıdır. Bkz. Stonebraker, et al., Vertica'yı harita azaltma ile kontrast oluşturan son CACM kağıdı .

Güncelleme: Ve Twitter, Cassandra'yı HBase, Voldemort, MongoDB, MemcacheDB, Redis ve HyperTable gibi diğerlerinden daha fazla seçti.

Güncelleme 2: Rick Cattell, Yüksek Performanslı Veri Mağazalarında birkaç NoSQL sisteminin bir karşılaştırmasını yayınladı . Ve highscalability.com'un Rick'in kağıdını ele geçirmesi burada .

Verilerimizin bir kısmını mysql'den mongodb'a taşıdık, ölçeklenebilirlik için çok fazla değil, daha çok dosyalar ve tablo olmayan veriler için daha uygun olduğu için.

Üretimde şu anda saklıyoruz:

• 25 bin dosya (60 GB)
• 130 milyon diğer "belge" (350 GB)

günlük cirosu 10GB civarındadır.

Veritabanı, mongodb python api (pymongo) kullanılarak apache / wsgi / python istemcileriyle iki düğümde (6x450GB sas raid10) "eşleştirilmiş" bir yapılandırmada dağıtılır. Disk kurulumu muhtemelen aşırıya kaçmış ama mysql için kullandığımız şey bu.

Pymongo threadpools ve mongodb sunucusunun engelleme doğası ile ilgili bazı sorunların yanı sıra iyi bir deneyim oldu.

İlk elden deneyimim olmadığından, kalın metninize karşı çıktığınız için özür dilerim, ancak bu blog yayınları kümesi CouchDB ile ilgili bir sorunu çözmenin iyi bir örneğidir.

CouchDB: Bir Vaka Çalışması

Esasen, textme uygulaması, patlayan veri sorunlarıyla başa çıkmak CouchDB'yi kullandı. SQL'in büyük miktarda arşiv verisi ile başa çıkmak için çok yavaş olduğunu buldular ve CouchDB'ye taşıdılar. Mükemmel bir okuma ve CouchDB'nin hangi sorunları çözebileceğini ve bunları nasıl çözdüğünü bulmanın tüm sürecini tartışıyor.

Postgresql ve Memcached'da depoladığımız bazı verilerimizi Redis'e taşıdık . Önemli değer depoları, hiyerarşik nesne verilerini depolamak için çok daha uygundur. Blob verilerinizi, blobunuzu bir RDBMS ile eşleştirmek için ORM kullanmaktan çok daha hızlı ve daha az geliştirme süresi ve çabasıyla depolayabilirsiniz.

Depolamak ve 1 satır ile herhangi bir POCO nesneleri almak sağlayan bir açık kaynak c # redis istemcisi var:

var customers = redis.Lists["customers"]; //Implements IList<Customer>
customers.Add(new Customer { Name = "Mr Customer" });

Yeni bir sunucu ekleyip daha sonra yeni sunucuyu eklemek için yükünüzü eşit olarak bölümlendirebileceğinizden, anahtar değer depolarını 'ölçeklendirmek' çok daha kolaydır. Daha da önemlisi, ölçeklenebilirliğinizi sınırlayacak merkezi bir sunucu yoktur. (yine de, isteklerinizi dağıtmak için tutarlı bir karma için bir stratejiye ihtiyacınız olacaktır).

Redis'i birden çok istemci için hızlı, eşzamanlı ve atomik erişim sağlayan steroidlerde 'yönetilen bir metin dosyası' olarak görüyorum, bu yüzden şimdi Redis'i kullandığım için bir metin dosyası veya gömülü veritabanı kullanmak için kullandığım her şey. Örneğin, tüm hizmetlerimiz için gerçek zamanlı birleştirilmiş bir haddeleme hata günlüğü elde etmek için (ki bu bizim için zor bir görev olmuştur), hatayı bir Redis sunucusu yan listesine önceden beklemekle sadece birkaç satırla ve daha sonra listeyi yalnızca son 1000 kullanıcı saklanacak şekilde kırpın, örneğin:

var errors = redis.List["combined:errors"];
errors.Insert(0, new Error { Name = ex.GetType().Name, Message = ex.Message, StackTrace = ex.StackTrace});
redis.TrimList(errors, 1000);

İlk elden deneyimim yok, ama bu blog girişini oldukça ilginç buldum .

Yazılım etki alanı nesnelerini (ör. ASalesOrder, aCustomer ...) iki boyutlu ilişkisel veritabanına (satırlar ve sütunlar) eşleme çabası, kaydetmek / güncellemek ve daha sonra birden çok tablodan bir etki alanı nesnesi örneği oluşturmak için çok fazla kod alır . Tüm bu birleştirmelere sahip olmanın performans vuruşundan bahsetmemek gerekirse, tüm bu disk okur ... sadece bir müşteri siparişi veya müşteri kaydı gibi bir etki alanı nesnesini görüntülemek / değiştirmek için.

Nesne Veritabanı Yönetim Sistemlerine (ODBMS) geçtik. Listelenen noSQL sistemlerinin yeteneklerinin ötesindedir. GemStone / S (Smalltalk için) böyle bir örnektir. Birçok dil için sürücüleri olan başka ODBMS çözümleri vardır. Önemli bir geliştirici avantajı olan sınıf hiyerarşiniz otomatik olarak veritabanı şemanız, alt sınıflarınız ve her şeydir. Nesneleri veritabanında kalıcı hale getirmek için nesne yönelimli dilinizi kullanmanız yeterlidir. ODBMS sistemleri, ACID düzeyinde işlem bütünlüğü sağlar, bu nedenle finansal sistemlerde de çalışır.

MySQL'den (InnoDB) bir M2M sistemi için cassandra'ya geçtim, bu da temel olarak her cihaz için zaman serileri sensörlerini sakladı. Her veri (cihaz_kimliği, tarih) ve (cihaz_kimliği, tip_of_sensör, tarih) ile endekslenir. MySQL sürümü 20 milyon satır içeriyordu.

MySQL:

• Master-master senkronizasyonunda kurulum. Senkronizasyon kaybı konusunda çok az sorun ortaya çıktı . Stresliydi ve özellikle başlangıçta düzeltilmesi saatler sürebilirdi.
• Ekleme süresi sorun değildi, ancak sorgulama daha fazla bellek gerektiriyordu veri büyüdükçe . Sorun, endekslerin bir bütün olarak kabul edilmesidir. Benim durumumda, sadece indekslerin belleğe yüklenmesi gereken çok ince bir kısmını kullanıyordum (cihazların sadece yüzde birkaçı sık sık izlendi ve en son verilerdeydi).
• O was yedekleme zor . Rsync büyük InnoDB tablo dosyalarında hızlı yedekleme yapamaz.
• Ağır tablo şemasını güncellemenin mümkün olmadığı hemen anlaşıldı , çünkü çok fazla zaman aldı (saat).
• Verilerin içe aktarılması saatler sürdü (sonunda endeksleme yapıldığında bile). En iyi kurtarma planı her zaman veritabanının birkaç kopyasını tutmaktı (veri dosyası + günlükler).
• Hareketli bir diğerine bir barındırma şirketten gerçekten büyük bir anlaşma oldu . Çoğaltma çok dikkatli bir şekilde ele alınmalıydı.

Cassandra:

• Kurulumu MySQL'den daha da kolay.
• Çok fazla RAM gerektirir. 2GB'lık bir örnek ilk sürümlerde çalıştıramadı, şimdi 1GB'lık bir örnek üzerinde çalışabilir, ancak fikir değil (çok fazla veri basması). Bizim durumumuzda 8GB vermek yeterliydi.
• Verilerinizi nasıl düzenlediğinizi anladıktan sonra depolamak kolaydır. Talep etmek biraz daha karmaşık. Ama bir kez etrafta dolaşırsanız, gerçekten hızlıdır (gerçekten istemedikçe gerçekten hata yapamazsınız).
• Önceki adım doğru yapılmışsa, süper hızlıdır ve kalır.
• Neredeyse verilerin yedeklenmesi için organize edilmiş gibi görünüyor. Her yeni veri yeni dosya olarak eklenir. Kişisel olarak, ama iyi bir şey değil, her gece ve her kapanmadan önce verileri yıkayın (genellikle yükseltme için), böylece geri yükleme daha az zaman alır, çünkü okumak için daha az günlükümüz var. Sıkıştırıldıkları için fazla dosya oluşturmaz.
• Verileri içe aktarmak cehennem kadar hızlıdır. Ve daha fazla ev sahibi daha hızlı. Gigabaytlarca veriyi dışa ve içe aktarmak artık sorun değil.
• Bir şemaya sahip olmamak çok ilginç bir şeydir, çünkü verilerinizi ihtiyaçlarınızı takip etmek için gelişmesini sağlayabilirsiniz. Bu, aynı sütun ailesinde verilerinizin aynı anda farklı sürümlerine sahip olmak anlamına gelebilir.
• Bir ana bilgisayar eklemek kolay olsa da (hızlı değil) ama bunu çok veri merkezinde bir kurulumda yapmadım.

Not: Ben de kullandım elasticsearch (belge Lucene dayalı yönelimli) ve ben bir NoSQL veritabanı olarak kabul edilmelidir düşünüyorum. Dağıtılmış, güvenilir ve genellikle hızlıdır (bazı karmaşık sorgular oldukça kötü performans gösterebilir).

Yapmıyorum. İşlem sırasında arayabileceğim basit ve ücretsiz bir anahtar / değer deposu kullanmak istiyorum, ancak böyle bir şey Windows platformunda afaik yok. Şimdi Sqlite kullanıyorum ama Tokyo Dolabı gibi bir şey kullanmak istiyorum. BerkeleyDB lisans "sorunları" vardır.

Ancak Windows işletim sistemini kullanmak istiyorsanız, NoSQL veritabanı seçiminiz sınırlıdır. Ve her zaman bir C # sağlayıcısı yoktur

Ben MongoDB denedim ve Sqlite 40 kat daha hızlı, bu yüzden belki de kullanmalıyım. Ama hala basit bir süreç çözümü umuyorum.

Günlük iletilerini makineler arasında depolamak için redis kullandım. Uygulaması çok kolaydı ve çok faydalıydı. Redis gerçekten kayalar

Sabit bir şemaya sahip olmamamız bizim için güçlü bir avantaj olduğu için postgres veritabanını CouchDB belge veritabanıyla değiştirdik. Her belgede, o belgeye erişmek için kullanılan değişken sayıda dizin bulunur.

Geçmişte Couchbase kullandım ve yeniden dengeleme sorunları ve diğer birçok sorunla karşılaştık. Şu anda Redis'i çeşitli üretim projelerinde kullanıyorum. Redis kümelerinizi ölçeklendirmeye özen gösteren Redis için yönetilen bir hizmet olan redislabs.com kullanıyorum . Blogumda, http://thomasjaeger.wordpress.com adresindeki Redis'i bir sağlayıcı modelinde nasıl kullanacağınızı ve C # nesnelerinizi Redis'e nasıl depolayacağınızı gösteren nesne kalıcılığı hakkında bir video yayınladım . Bir göz at.

Bunu 3.0 okuyan herkesin bir kez daha Couchbase'i denemesini tavsiye ederim. Yeni başlayanlar için 200'den fazla yeni özellik var. Couchbase Server'ın performansı, kullanılabilirliği, ölçeklenebilirliği ve kolay yönetim özellikleri son derece esnek ve yüksek düzeyde kullanılabilir bir veritabanı sağlar. Yönetim kullanıcı arabirimi yerleşiktir ve API'ler otomatik olarak küme düğümlerini bulur, böylece uygulamadan DB'ye bir yük dengeleyicisine gerek kalmaz. Şu anda yönetilen bir hizmetimiz olmasa da AWS, RedHat Gears, Cloudera, Rackspace, CloudSoft gibi Docker Container'ları ve çok daha fazlası için couchbase çalıştırabilirsiniz. Yeniden dengelemeyle ilgili olarak, özellikle neye atıfta bulunduğunuza bağlıdır, ancak Couchbase tasarlandığı gibi bir düğüm hatasından sonra otomatik olarak yeniden dengelenmez, ancak bir yönetici ilk düğüm hatası için otomatik yük devretme ayarlayabilir ve API'larımızı kullanarak, onları etkinleştirmeden önce okuma için çoğaltma vbuckets'e erişebilir veya RestAPI'yi kullanarak bir izleme aracıyla yük devretmeyi uygulayabilirsiniz. Bu özel bir durumdur, ancak yapılması mümkündür.

Düğüm tamamen çevrimdışı değilse ve asla geri dönmezse veya yeni bir düğüm otomatik olarak dengelenmeye hazır değilse, hemen hemen hiçbir modda yeniden dengeleme eğiliminde değiliz. İşte en yüksek performanslı NoSQL veritabanlarından birinin ne hakkında olduğunu görmek isteyen herkese yardımcı olacak birkaç kılavuz.

1. Couchbase Sunucusu 3.0
2. Yönetim Kılavuzu
3. REST API'sı
4. Geliştirici Kılavuzları

Son olarak, ben de dağıtılmış sorgulama için N1QL kontrol etmenizi öneririz:

1. N1QL Eğitimi
2. N1QL Kılavuzu

Okuduğunuz için teşekkürler ve daha fazla yardıma ihtiyacınız varsa bana veya başkalarına bildirin!

Austin

Vertica'yı geçmişte kullandım. Daha hızlı veri yüklemeleri ve daha yüksek eşzamanlılık, analitik verileri minimum gecikmeyle daha fazla kullanıcıya sunmanıza olanak tanır.

Daha önce, milyarlarca kayıt içeren Oracle veritabanını sorgulamıştık ve performans çok düşüktü. Sorgular, SSD ile optimize ettikten sonra bile 8 ila 12 saniye sürdü. Bu nedenle, daha hızlı okunan optimize edilmiş, analitik odaklı bir veritabanı kullanma ihtiyacını hissettik. Yalın hizmet katmanının arkasındaki Vertica Clusters ile, API'ları ikinci saniyenin altında performansla çalıştırabiliriz.

Vertica, verileri projeksiyonlarda sorgu yürütmeyi optimize eden bir biçimde saklar. Gerçekleştirilmiş görünümlere benzer şekilde, projeksiyonlar sonuç kümelerini sorguda her kullanıldıklarında hesaplamak yerine disk VEYA SSD'de depolar.

1. Depolama alanını azaltmak için verileri sıkıştırın ve kodlayın.
2. Veritabanı kümesinde dağıtımı basitleştirin.
3. Yüksek kullanılabilirlik ve kurtarma sağlayın.

Vertica, Segmentation kullanarak kümeye veri dağıtarak veritabanını optimize eder.

1. Segmentasyon, verinin bir kısmını bir düğüme yerleştirir.
2. Verileri tüm düğümlere eşit olarak dağıtır. Böylece, her bir düğüm sorgulama işleminin bir parçasını gerçekleştirir.
3. Sorgu kümede çalışır ve her düğüm sorgu planını alır.
4. Sorguların sonuçları toplanır ve çıktıyı oluşturmak için kullanılır.

Daha fazla bilgi için lütfen Vertica belgelerine bakın @ https://www.vertica.com/knowledgebase/