Milyarlarca satır için en iyi veri deposu


87

Milyarlarca kayıt için (bir yıl boyunca ~ 3 milyar / ay) küçük veri bitlerini (yaklaşık 50-75 bayt) depolayabilmem gerekiyor.

Tek gereksinim, aynı GUID'ye ve .net'ten veri deposuna erişim olanağına sahip tüm kayıtlar için hızlı girişler ve hızlı aramalardır.

Ben bir SQL sunucusu uzmanıyım ve SQL Server'ın bunu yapabileceğini düşünüyorum , ancak BigTable, CouchDB ve diğer nosql çözümleri hakkındaki tüm konuşmalara rağmen, geleneksel bir RDBS'ye bir alternatif gibi geliyor kulağa gittikçe daha çok benziyor. dağıtılmış sorgular ve ölçeklendirme. Cassandra'yı denedim ve .net kitaplıkları şu anda derlenmiyor veya tümü değişime tabi (cassandra'nın kendisiyle birlikte).

Mevcut birçok nosql veri deposunu araştırdım, ancak sağlam bir üretime hazır platform olarak ihtiyaçlarımı karşılayan bir tane bulamıyorum.

.Net'ten erişilebilir olmaları için 36 milyar küçük, düz kaydı saklamak zorunda olsaydınız, neyi seçer ve neden?


Evet, numaralarım doğru. Şu anda sisteme gelen bu kadar çok veriye sahibiz, ancak bunları topluyoruz ve yalnızca toplam sayıları depoluyoruz, böylece kayıt başına verileri kaybediyoruz ve yalnızca saatlik veri toplamlarını koruyoruz. İş gereksinimlerinden dolayı, her kaydı başlangıçta olduğu gibi tutmak istiyoruz ve bu ayda 3 milyar satır.
Jody Powlette

Bazı güzel sorular yönelttin. Cevaplar:% 95 çalışma süresi yeterli - veriler zaten değişken bir miktarı geciktiriyor, bu yüzden her halükarda onu eşitlemem gerekecek, bu yüzden kısa süreliğine kapalı olmak bir anlaşma kırıcı değil. Uçları ve hatta binlerce ucu kaybetmek dünyanın sonu değil. Yine de bir günlük veriyi kaybetmek oldukça kötü olur. Tutarlılık da o kadar önemli değil. Temel olarak, bir günde 30Mil satır ekledikten sonra, tüm satırları aynı GUID'ye (belki 20 satır) getirmem ve hepsini geri alacağımdan makul ölçüde emin olmam gerekiyor.
Jody Powlette

Günlük / saatlik planlanmış toplu işlerde günde 30 milyon satır döküyor musunuz, yoksa bunlar birer birer sabit bir akışla mı geliyorlar?
Remus Rusanu

Veriler bir FTP sitesinden geliyor ... dosyalar sürekli olarak geliyor ve dosyaları ayrıştıran bir işlemim var ve şu anda toplanmış verileri oluşturuyor ve toplanan değerleri (belki 1000 satır) bir işlem olarak ekliyor. Yeni işlemin, gelen her dosyadan yüz binlerce satır eklemesi gerekecek, muhtemelen bunu yapmanın en verimli yolu toplu ekleme kullanmak olacaktır.
Jody Powlette

Bu, SSIS ve SQL Server için bir ETL işi gibi görünüyor. 2TB / saatin üzerinde yükleme hızında ETL için dünya rekoru kırıyorlar
Remus

Yanıtlar:


103

Yaklaşık 3,5 TB veri depolamak ve yaklaşık 1K / sn 7 gün 24 saat eklemek ve ayrıca belirtilmemiş bir hızda sorgulama yapmak SQL Server ile mümkündür, ancak daha fazla soru vardır:

  • bunun için hangi kullanılabilirlik gereksiniminiz var? % 99,999 çalışma süresi mi yoksa% 95 yeterli mi?
  • hangi güvenilirlik gereksiniminiz var? Bir eki kaçırmak size 1 milyon dolara mal oluyor mu?
  • ne tür bir kurtarılabilirlik gereksiniminiz var? Bir günlük veriyi kaybederseniz, fark eder mi?
  • hangi tutarlılık gereksiniminiz var? Bir yazının bir sonraki okumada görünür olması garanti edilmeli mi?

Vurguladığım tüm bu gereksinimlere ihtiyacınız varsa, önerdiğiniz yük, hangi hileleri denerseniz deneyin (parçalama, bölümleme vb.) İlişkisel bir sistemde, herhangi bir sistemde milyonlarca donanıma ve lisanslamaya mal olacak. Bir nosql sistemi, kendi tanımı gereği, tüm bu gereksinimleri karşılamayacaktır.

Açıkçası, bu gereksinimlerin bazılarını zaten gevşetmişsiniz. NoSQL Systems Visual Guide to NoSQL Systems'daki '3'ün 2'sini seç' paradigmasına dayanan nosql tekliflerini karşılaştıran güzel bir görsel kılavuz var :

nosql karşılaştırması

OP yorum güncellemesinden sonra

SQL Server ile bu, basit bir uygulama olacaktır:

  • tek bir tablo kümelenmiş (GUID, zaman) anahtarı. Evet, parçalanacak , ancak parçalanma önden okumaları etkiliyor mu ve önden okuma yalnızca önemli aralık taramaları için gerekli. Yalnızca belirli bir GUID ve tarih aralığı için sorguladığınızdan, parçalanmanın pek önemi olmayacaktır. Evet, geniş bir anahtardır, bu nedenle yaprak olmayan sayfaların anahtar yoğunluğu zayıf olacaktır. Evet, zayıf doldurma faktörüne yol açacaktır. Ve evet, sayfa bölünmeleri olabilir. Bu sorunlara rağmen, gereksinimler göz önüne alındığında, hala en iyi kümelenmiş anahtar seçimdir.
  • Tabloyu zamana göre bölümlere ayırın, böylece süresi dolan kayıtları otomatik bir kayan pencere aracılığıyla verimli bir şekilde silebilirsiniz . GUID kümelemesinin getirdiği zayıf doldurma faktörünü ve parçalanmayı ortadan kaldırmak için geçen ayın çevrimiçi dizin bölümü yeniden yapılandırmasıyla bunu artırın.
  • sayfa sıkıştırmayı etkinleştirin. Öncelikle GUID'e göre kümelenmiş anahtar grupları olduğundan, bir GUID'nin tüm kayıtları yan yana olacak ve bu da sayfa sıkıştırmaya sözlük sıkıştırmasını dağıtmak için iyi bir şans verecektir .
  • günlük dosyası için hızlı bir GÇ yoluna ihtiyacınız olacaktır. Bir günlüğün saniyede 1K ekleme hızına ayak uydurması için düşük gecikmeyle değil, yüksek verimlilikle ilgileniyorsunuz, bu nedenle ayırma bir zorunluluktur.

Bölümleme ve sayfa sıkıştırmanın her biri bir Enterprise Edition SQL Server gerektirir, Standard Edition üzerinde çalışmazlar ve her ikisi de gereksinimleri karşılamak için oldukça önemlidir.

Bir yan not olarak, kayıtlar bir ön uç Web sunucuları çiftliğinden geliyorsa, her web sunucusuna Express'i koyardım ve arka uca INSERT yerine, SENDyerel bir bağlantı / işlem kullanarak bilgiyi arka uca yazardım. Web sunucusuyla aynı yerde bulunan Express'te. Bu, çözüme çok daha iyi bir kullanılabilirlik hikayesi verir.

İşte SQL Server'da bunu böyle yapardım. İyi haber, karşılaşacağınız sorunların iyi anlaşılması ve çözümlerinin bilinmesidir. bu, bunun Cassandra, BigTable veya Dynamo ile elde edebileceğinizden daha iyi olduğu anlamına gelmez. Sql-ish olmayan şeylerde daha bilgili birine davasını tartışmasına izin vereceğim.

Programlama modelinden, .Net desteğinden ve benzerlerinden hiç bahsetmediğimi unutmayın. Dürüst olmak gerekirse, büyük dağıtımlarda önemsiz olduklarını düşünüyorum. Geliştirme sürecinde büyük bir fark yaratırlar, ancak bir kez konuşlandırıldıktan sonra, ORM ek yükü performansı düşürürse, geliştirmenin ne kadar hızlı olduğu önemli değildir :)


Nathan'ın sitesine sıcak bağlantı verdim, ancak bu slashdot ön sayfası değil;)
Remus Rusanu

@RemusRusanu: dba.se geçişine bakıyor. Sadece sizi hazırlamak için :-) Ve +1
gbn

Microsoft SQL Server 2016'dan itibaren, Tablo Bölümleme için Enterprise sürümü artık gerekli değildir, çünkü Tablo Bölümleme artık SQL Server 2016'nın neredeyse tüm sürümlerinde mevcuttur.
TChadwick

17

Popüler inancın aksine, NoSQL performans veya hatta ölçeklenebilirlik ile ilgili değildir. Esas olarak Nesne-İlişkisel empedans uyumsuzluğunu en aza indirmekle ilgilidir, ancak aynı zamanda bir RDBMS'nin daha tipik dikey ölçeklenebilirliğine karşı yatay ölçeklenebilirlik ile ilgilidir .

Hızlı girişlerin ve hızlı aramaların basit gereksinimi için hemen hemen her veritabanı ürünü yeterli olacaktır. İlişkisel veriler eklemek veya birleştirmek istiyorsanız veya uygulamanız gereken karmaşık işlem mantığı veya kısıtlamalarınız varsa, ilişkisel bir veritabanı istersiniz. Hiçbir NoSQL ürünü karşılaştırılamaz.

Şemasız verilere ihtiyacınız varsa, MongoDB veya CouchDB gibi belge odaklı bir veritabanı kullanmak istersiniz. Gevşek şema bunların ana çekicisidir; Şahsen MongoDB'yi seviyorum ve birkaç özel raporlama sisteminde kullanıyorum. Veri gereksinimleri sürekli değiştiğinde bunu çok faydalı buluyorum.

Diğer ana NoSQL seçeneği, BigTable veya Cassandra gibi Anahtar-Değer Depolarına dağıtılmıştır. Veritabanınızı ticari donanım çalıştıran birçok makinede ölçeklendirmek istiyorsanız, bunlar özellikle yararlıdır. Açıkçası sunucularda da iyi çalışıyorlar, ancak üst düzey donanımın yanı sıra SQL Server veya Oracle veya dikey ölçekleme için tasarlanmış diğer veritabanlarından yararlanmıyorlar ve açıkçası ilişkisel değiller ve normalleştirmeyi zorlamak için iyi değiller veya kısıtlamalar. Ayrıca, fark ettiğiniz gibi, .NET desteği en iyi ihtimalle sivilceli olma eğilimindedir.

Tüm ilişkisel veritabanı ürünleri, sınırlı bir türdeki bölümlemeyi destekler. BigTable veya diğer DKVS sistemleri kadar esnek değiller, yüzlerce sunucu arasında kolayca bölümleme yapmıyorlar , ancak gerçekten aradığınız şey bu gibi gelmiyor. Verileri düzgün bir şekilde dizine ekleyip normalleştirdiğiniz, veritabanını güçlü donanımlarda (özellikle de karşılayabiliyorsanız SSD'lerde) çalıştırdığınız ve eğer 2 veya 3 veya 5 fiziksel diske ayırdığınız sürece milyarlarca kayıt sayımlarını işlemekte oldukça iyidirler gerekli.

Yukarıdaki kriterleri karşılıyorsanız, kurumsal bir ortamda çalışıyorsanız ve iyi donanım ve veritabanı optimizasyonu için harcayacak paranız varsa, şimdilik SQL Server'a bağlı kalırım. Kuruş para çekiyorsanız ve bunu düşük kaliteli Amazon EC2 bulut bilgi işlem donanımında çalıştırmanız gerekiyorsa, bunun yerine Cassandra veya Voldemort'u tercih etmek isteyebilirsiniz (her ikisini de .NET ile çalışabileceğinizi varsayarak).


11

Çok az kişi multi-milyar satır kümesi boyutunda çalışıyor ve çoğu zaman yığın taşması durumunda buna benzer bir istek görüyorum, veriler rapor edildiği boyuta yakın değil.

36 milyar, ayda 3 milyar, yani günde yaklaşık 100 milyon, saatte 4,16 milyon, dakikada ~ 70 bin satır, sisteme saniyede 1,1 bin satır, 12 ay boyunca kesintisiz bir şekilde, kesinti olmadığı varsayılarak.

Bu rakamlar uzun bir farkla imkansız değil, daha büyük sistemler yaptım, ancak gerçekten kastettiğiniz miktarların bu olup olmadığını tekrar kontrol etmek istiyorsunuz - çok az uygulamada bu miktar var.

Saklama / geri alma açısından ve bahsetmediğiniz oldukça kritik bir husus, eski verilerin yaşlandırılmasıdır - silme ücretsiz değildir.

Normal teknoloji bölümlemedir, ancak GUID tabanlı arama / alma, 12 aylık süre boyunca eşleşen her değeri almanız gerektiğini varsayarak, zayıf bir performansa neden olacaktır. GUID sütununa kümelenmiş dizinler yerleştirebilirsiniz, ilişkili veri kümenizi okuma / yazma için alır, ancak bu miktarlarda ve ekleme hızında, parçalanma desteklenemeyecek kadar yüksek olacak ve yere düşecektir.

Ayrıca, eğer bu OLTP tipi yanıt hızlarına sahip ciddi bir uygulama ise, yani bazı yaklaşık tahminlere göre, indeksleme açısından çok az genel gider, yaklaşık 2,7 TB veri varsayarsak, çok iyi bir donanım bütçesine ihtiyacınız olacağını da öneririm.

SQL Server kampında, bakmak isteyebileceğiniz tek şey, büyük datamart'lara karşı yüksek hız sağlamak için verileri parçalamak ve ona karşı paralel sorgular çalıştırmak için daha çok tasarlanan yeni paralel veri ambarı sürümüdür (madison).


3
Biyoinformatikte milyar satırlık veri kümeleri nadir değildir. Ancak bunlar genellikle düz dosyalardan tamamen akış şeklinde ele alınır.
Erik Garrison

3
@Erik: akış işleme için (yani yalnızca belirli koşulları algılamak gerekir, ancak verileri daha sonra sorgulamak için depolamaya gerek yoktur) StreamInsight gibi bir şey herhangi bir veritabanından daha iyidir microsoft.com/sqlserver/2008/en/us/r2 -complex-event.aspx
Remus

2

"Milyarlarca kayıt için (bir yıl boyunca ~ 3 milyar / ay) küçük veri bitlerini (yaklaşık 50-75 bayt) depolayabilmem gerekiyor.

Tek gereksinim, aynı GUID'ye ve .net'ten veri deposuna erişim yeteneğine sahip tüm kayıtlar için hızlı girişler ve hızlı aramalardır. "

Deneyimlerime dayanarak bunun SQL Server'da mümkün olduğunu söyleyebilirim, çünkü bunu 2009'un başlarında yaptım ... ve hala bu güne kadar çalışıyor ve oldukça hızlı.

Tablo 256 bölüm halinde bölümlendi, bunun 2005 SQL sürümü olduğunu unutmayın ... ve tam olarak ne söylediğinizi yaptık ve bu, bilgi bitlerini GUID'e göre depolamak ve GUID ile hızlı bir şekilde almaktır.

Ayrıldığımda yaklaşık 2-3 milyar kaydımız vardı ve veri saklama politikası henüz oluşturulmak üzereyken veri alımı hala oldukça iyiydi (UI üzerinden geçilirse 1-2 saniye veya RDBMS'de ise daha az).

Yani, uzun lafın kısası, GUID dizesinden 8. karakteri (yani ortada bir yerde) aldım ve SHA1, onu küçük int (0-255) olarak atıp uygun bölümde depoladım ve alırken aynı işlev çağrısını kullandım veriler geri geldi.

Daha fazla bilgiye ihtiyacın olursa bana ping at ...


2

Aşağıdaki makale , Microsoft SQL'de 16 milyar satırlık bir tablonun içe aktarılması ve kullanımını tartışmaktadır . http://sqlmag.com/t-sql/adventures-big-data-how-import-16-billion-rows-single-table .

Makaleden:

İşte deneyimlerimden bazı damıtılmış ipuçları:

  • Tanımlanmış kümelenmiş dizine sahip bir tabloda ne kadar çok veriniz varsa, sıralanmamış kayıtları buraya aktarmak o kadar yavaş olur. Bir noktada pratik olamayacak kadar yavaşlar.
  • Tablonuzu mümkün olan en küçük dosyaya aktarmak istiyorsanız, onu yerel format yapın. Bu, çoğunlukla sayısal sütunlar içeren tablolarla en iyi şekilde çalışır çünkü ikili alanlarda karakter verilerinden daha kompakt bir şekilde temsil edilirler. Tüm verileriniz alfasayısal ise, yerel formatta dışa aktararak fazla bir kazanç elde edemezsiniz. Sayısal alanlarda boş değerlere izin vermemek, verileri daha da sıkıştırabilir. Bir alanın null yapılabilir olmasına izin verirseniz, alanın ikili gösterimi, kaç baytlık verinin takip edileceğini belirten 1 baytlık bir önek içerir.
  • BCP sayacı değişkeni 4 baytlık bir tam sayı olduğundan, 2.147.483.647'den fazla kayıt için BCP kullanamazsınız. MSDN'de veya İnternette buna ilişkin herhangi bir referans bulamadım. Tablonuz
    2.147.483.647'den fazla kayıt içeriyorsa, onu parçalar halinde dışa aktarmanız
    veya kendi dışa aktarma rutininizi yazmanız gerekir.
  • Önceden doldurulmuş bir tabloda kümelenmiş bir dizin tanımlamak çok fazla disk alanı gerektirir. Testimde, günlüğüm
    tamamlanmadan önce orijinal tablo boyutunun 10 katına çıktı .
  • BULK INSERT deyimini kullanarak çok sayıda kaydı içe aktarırken, BATCHSIZE parametresini dahil edin ve
    bir seferde kaç kaydın işleneceğini belirtin . Bu parametreyi dahil etmezseniz,
    tüm dosyanız tek bir işlem olarak içe aktarılır ve bu
    da çok fazla günlük alanı gerektirir.
  • Kümelenmiş dizine sahip bir tabloya veri almanın en hızlı yolu, önce verileri önceden sıralamaktır. Daha sonra
    ORDER parametresiyle BULK INSERT deyimini kullanarak içeri aktarabilirsiniz .

1

Göz ardı edilmiş gibi görünen alışılmadık bir gerçek var.

" Temelde bir günde 30 Milyon satır ekledikten sonra, aynı GUID'ye (belki 20 satır) sahip tüm satırları getirmem ve hepsini geri alacağımdan makul ölçüde emin olmam gerekiyor "

Yalnızca 20 sütuna ihtiyaç duyan GUID'de kümelenmemiş bir dizin gayet iyi çalışacaktır. Bölümler arasında veri dağılımı için başka bir sütunda kümeleme yapabilirsiniz.

Veri ekleme ile ilgili bir sorum var: Nasıl ekleniyor?

  • Bu, belirli bir programa göre (dakika başına, saat başına vb.) Toplu bir ekleme mi?
  • Bu veriler hangi kaynaktan çekiliyor (düz dosyalar, OLTP vb.)?

Denklemin bir tarafının anlaşılmasına yardımcı olmak için bunların yanıtlanması gerektiğini düşünüyorum.


1

Amazon Redshift harika bir hizmettir. Soru ilk olarak 2010'da yayınlandığında mevcut değildi, ancak şimdi 2017'de önemli bir oyuncu. Postgres'ten çatallanan sütun tabanlı bir veritabanıdır, bu nedenle standart SQL ve Postgres bağlayıcı kitaplıkları onunla çalışacaktır.

En iyi, özellikle toplama olmak üzere raporlama amacıyla kullanılır. Tek bir tablodaki veriler, Amazon'un bulutundaki farklı sunucularda depolanır ve tanımlı tablo dağıtım anahtarları tarafından dağıtılır, böylece dağıtılmış CPU gücüne güvenirsiniz.

Bu nedenle, SEÇİM'ler ve özellikle toplu SEÇİM'ler yıldırım hızındadır. Büyük verilerin yüklenmesi tercihen Amazon S3 csv dosyalarındaki COPY komutuyla yapılmalıdır. Dezavantajları, SİLME ve GÜNCELLEMELERİN normalden daha yavaş olması, ancak bu nedenle Redshift'in öncelikle uluslar arası bir veritabanında değil, daha çok bir veri ambarı platformunda olmasıdır.


0

Cassandra veya HBase kullanmayı deneyebilirsiniz, ancak kullanım durumunuza göre sütun ailelerini nasıl tasarlayacağınızı okumalısınız. Cassandra kendi sorgu dilini sağlar ancak verilere doğrudan erişmek için HBase Java API'lerini kullanmanız gerekir. Hbase kullanmanız gerekiyorsa, verileri bir Açık Kaynak projesi olan Map-R'den Apache Drill ile sorgulamanızı tavsiye ederim. Drill'in sorgu dili SQL Uyumludur (matkaptaki anahtar sözcükler, SQL'de sahip oldukları anlama sahiptir).


0

Yılda bu kadar çok kayıtla sonunda alanınız tükenecek. 2 ^ 64 dosyalarını destekleyen ve daha küçük kutular kullanan xfs gibi dosya sistemi depolaması neden olmasın? İnsanların elde etmek istedikleri şey veya harcayacakları para miktarı ne olursa olsun, SQL NoSQL veri tabanı ne olursa olsun bir sistem elde etmek için harcanır .. bu kayıtların çoğu genellikle elektrik şirketleri ve çevre bakanlığı gibi daha küçükleri kontrol eden hava istasyonları / sağlayıcıları tarafından yapılır. ülke genelinde istasyonlar. Basınç depolamak gibi bir şey yapıyorsanız .. sıcaklık .. rüzgar hızı .. nem vb ... ve rehber konumdur .. Verileri yıl / ay / gün / saate göre bölebilirsiniz. Sabit sürücü başına 4 yıllık veri depoladığınızı varsayarsak. Daha sonra, daha iyi okuma hızları sağlayacak ve birden çok montaj noktasına sahip olacak şekilde daha küçük bir Nas üzerinde çalıştırabilirsiniz. oluşturulduğu yıla göre. Sadece aramalar için bir web arayüzü oluşturabilirsiniz. Yani döküm yeri1 / 2001/06/01 // sıcaklık ve yer1 / 2002/06/01 // temperature, bu 2 yılda (24 saat * 2) 48 küçük dosyaya karşılık, milyarlarca kayıt içeren ve muhtemelen milyonlarca harcanan bir veritabanını aramaya kıyasla yazın yalnızca ilk günü için saatlik sıcaklık içeriğini döker. Şeylere bakmanın basit yolu .. Tanrı ile dünyadaki 1,5 milyar web sitesi her biri kaç sayfa bilir Google gibi bir şirket, süper bilgisayarlar için ödeme yapmak için 3 milyar aramaya milyonlar harcamak zorunda kalırsa iflas ederdi. Onun yerine elektrik faturası var ... birkaç milyon boktan bilgisayar. Ve kafein indeksleme ... geleceğe hazır ... daha fazlasını eklemeye devam edin. Ve evet, SQL'de indekslemenin mantıklı olduğu yerde o zaman harika Hava durumu gibi sabit şeylerle berbat görevler için süper bilgisayarlar inşa etmek ... istatistikler vb. Teknisyenler sistemlerini xtb'de xtb'de böbürleyerek övünebilsinler ... başka bir yerde geçirdim ..


-2

Kayıtları düz ikili dosyalarda saklayın, her GUID için bir dosya, bundan daha hızlı olamaz.


5
Bunun gerçekten iyi performans göstermesini bekliyor musunuz?
ChaosPandion

3
Evet, dosya sisteminde milyarlarca dosya oluşturmak bazı dosya sistemleri için yıkıcı olabilir. Böyle bir şey yapma hatasını yaptım, ancak yalnızca 1 milyonla ve bu klasörlerden birine bir kabuk açmaya çalışırken sistemi hemen hemen devre dışı bıraktım. Ayrıca, bir kılavuza göre arama yapmadığınız sürece, sorgu mekanizmasının nasıl çalışması gerekiyor?
Rob Goodwin

Kaç benzersiz GUID'in beklendiğini bilmeden bunun nasıl çalışacağını tahmin etmek zordur :) Ancak bu, düz dosyalara yazmaktan daha kolay olamaz. Ve GUID ile arama ile birlikte hızlı girişler tek gereksinimdi.
Thomas Kjørnes

Çalışabilir, ancak klasör başına dosya sayısını sınırlamanız gerekir. Her n dosya için yeni bir klasör oluşturmanız gerekir. Klasör adı olarak kılavuzun bir alt dizesini kullanabilirsiniz.
TTT

1
evet, birçok dosya sistemi için inode sayısında bir sınır vardır ve kendimizi redhat varsayılan dosya sisteminde sınırlandırdığımızı hatırlıyorum .... sınır yaklaşık 1.000.000 dosya kadardı.
Dean Hiller

-3

MongoDB'yi kullanabilir ve kılavuzu parçalama anahtarı olarak kullanabilirsiniz; bu, verilerinizi birden çok makineye dağıtabileceğiniz anlamına gelir, ancak seçmek istediğiniz veriler, parçalama anahtarıyla seçtiğiniz için yalnızca bir makinede olur.

MongoDb'de parçalama henüz üretime hazır değil.

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.