Mysql: 192 Trilyon Kayıtla Çalışma… (Evet, 192 Trilyon)


39

İşte soru bu ...

192 trilyon kayıt dikkate alındığında, düşüncelerim neler olmalı?

Asıl endişem hızdır.

İşte masa ...

    CREATE TABLE `ref` (
  `id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
  `rel_id` INTEGER(13) NOT NULL,
  `p1` INTEGER(13) NOT NULL,
  `p2` INTEGER(13) DEFAULT NULL,
  `p3` INTEGER(13) DEFAULT NULL,
  `s` INTEGER(13) NOT NULL,
  `p4` INTEGER(13) DEFAULT NULL,
  `p5` INTEGER(13) DEFAULT NULL,
  `p6` INTEGER(13) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`s`),
  KEY (`rel_id`),
  KEY (`p3`),
  KEY (`p4`)
    );

İşte sorgular ...

SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"

SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"

INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")

İşte bazı notlar ...

  • SEÇİM, INSERT'den çok daha sık yapılacaktır. Ancak, bazen bir seferde birkaç yüz kayıt eklemek istiyorum.
  • Yük olarak, saatlerce hiçbir şey olmayacak, belki bir kerede birkaç bin sorgu yapacaksınız.
  • Daha fazla normalleştirebileceğimi sanma (bir kombinasyondaki p değerlerine ihtiyacım var)
  • Bir bütün olarak veritabanı çok ilişkiseldir.
  • Bu şu ana kadarki en büyük masa olacak (bir sonraki en büyük 900 bin civarında olacak)

GÜNCELLEME (08.08.2010)

İlginç bir şekilde, bana ikinci bir seçenek verildi ...

192 trilyon yerine 2.6 * 10 ^ 16 (15 sıfır, yani 26 katrilyon) depolayabilirim ...

Ancak bu ikinci seçenekte bir tablodaki indeks olarak sadece bir bigint (18) kaydetmem gerekiyor. İşte bu - sadece bir sütun. Bu yüzden sadece bir değerin varlığını kontrol ediyor olurdum. Zaman zaman kayıt ekleme, asla silmeme.

Bu sayede daha iyi bir çözüm olması gerektiğini düşünmekteyim, sayıları saklamak için mysql ...

Bu ikinci seçenek göz önüne alındığında, ilk al ya da yapalım mı ...

[edit] Sadece yapılan bazı testlerden haberleri aldım - bu kurulumda 100 milyon satır, soruyu 0.0004 saniyede döndürür [/ değiştir]


7
Bunun için MySQL'i nasıl kullanacaksınız? Biri bunu yapmak için sağlam argümanlar sunsa, farklı bir dbms'ye geçmeye ikna olabilir misiniz?
WheresAlice,

3
10 ^ 12 veya 10 ^ 18'deki gibi trilyon?
andol

15
192 Trilyon kayıtta, bazı tartışma forumlarına değil, MySQL taahhüt şirketlerine soru sormanıza izin veren bir bütçeniz olmalıdır.
Remus Rusanu

5
Bir veritabanı ile bu büyük (ve tabii ki iyi bir bütçe) neden büyük DB'leri kolayca idare edebileceği kanıtlanmış oracle veya sql serer ile devam etmiyorsunuz?
Jim B

5
Bunu uygularken bizi güncel tuttuğunuzdan emin olun. Kesinlikle ilgilenirim. Ayrıca highscalability.com
Tom O'Connor

Yanıtlar:


30

pQd'nin 7PB'deki tahmini makul görünüyor ve bu bir RDBMS için çok fazla veri. Herhangi bir paylaşılan disk sistemiyle 7PB yapan birisinin, MySQL'in tek başına olduğunu duyduğuma emin değilim. Bu veri hacmini herhangi bir paylaşılan disk sistemiyle sorgulamak alışılmadık derecede yavaş olacaktır. En hızlı SAN donanımı, büyük akış sorguları için ayarlanmış olsa bile 20GB / sn'de maksimuma çıkarır. Bu özelliğin SAN donanımını karşılayabilirseniz, iş için uygun olan bir şeyi MySQL'den daha iyi kullanabilirsiniz.

Aslında, bu özelliğin bir disk alt sistemi için bütçenizin olabileceği ancak daha iyi bir DBMS platformu için olmayan bir senaryoyu düşünmek için mücadele ediyorum. 600GB diskler kullanıyor olsanız bile (şu anda piyasadaki en büyük 15K 'kurumsal' sürücü) 7PB'yi depolamak için 12.000 fiziksel disk sürücüsü gibi bir şey için hazırsınız. SATA diskleri daha ucuz olurdu (ve 2 TB disklerde sayının 1 / 3'üne ihtiyacınız olacak), ancak biraz daha yavaş.

Bu spesifikasyonun EMC veya Hitachi gibi büyük bir satıcısından aldığı SAN, milyonlarca dolara koşar. En son büyük bir üreticiden SAN ekipmanıyla çalıştığımda, bir IBM DS8000 ürünündeki alanın transfer maliyeti, denetleyiciler için herhangi bir sermaye ödeneği dahil değil, 10 k / sterlin üzerindedir.

Bu kadar veri için gerçekten Teradata veya Netezza gibi paylaşılan bir sisteme ihtiyacınız yok. Bir MySQL veritabanını paylaşmak işe yarayabilir, ancak VLDB platformu için bir amaç önerdim. Paylaşılan hiçbir şey sistemi ayrıca düğümlerde daha ucuz doğrudan bağlantı diski kullanmanıza izin verir - Sun'ın X4550 (thumper) platformuna bir olasılıkla göz atın.

Ayrıca performans gereksinimlerinizi de düşünmeniz gerekir.

  • Bir sorgu için kabul edilebilir bir çalışma süresi nedir?
  • Veri kümenizi ne sıklıkla sorgulayacaksınız?
  • Sorguların çoğunluğu bir endeks kullanılarak çözülebilir mi (yani küçük bir kesime bakacaklar mı - örneğin: verinin% 1'inden daha az) veya tam tablo taraması yapmaları mı gerekiyor?
  • Veri veritabanına ne kadar hızlı yüklenir?
  • Sorgularınızın güncel verilere ihtiyacı var mı, yoksa düzenli aralıklarla yenilenen bir raporlama tablosu ile yaşayabilir misiniz?

Kısacası, MySQL'in en güçlü argümanı, eğer mümkünse, 7PB veri üzerinde iyi bir sorgu performansı elde etmek için geri çekilmeler yapıyor olmanızdır. Bu veri hacmi, oldukça hızlı bir şekilde sorgulayabilecek bir şey yapmak için sizi hiçbir şey paylaşılmayan bir bölgeye sokuyor ve muhtemelen başlangıçtan itibaren paylaşılan hiçbir işlem için tasarlanmış bir platforma ihtiyacınız olacak. Tek başına diskler, herhangi bir makul DBMS platformunun maliyetini cüce edecek.

Not: Operasyonel ve raporlama veritabanlarınızı bölerseniz, her ikisi için de aynı DBMS platformunu kullanmanız gerekmez. Aynı 7PB tablosundan hızlı ekler ve ikinci alt raporlar almak en azından teknik bir zorluk olacaktır.

Raporlamada biraz gecikmeyle yaşayabileceğiniz yorumlarınızdan dolayı, ayrı yakalama ve raporlama sistemlerini göz önünde bulundurabilirsiniz ve tüm 7PB verilerini operasyonel yakalama sisteminizde tutmanız gerekmeyebilir. Veri toplama için Oracle (MySQL bunu InnoDB ile yapabilir) gibi operasyonel bir platform düşünün (yine, tek başına disklerin maliyeti, çok fazla kullanıcınız yoksa DBMS'nin maliyetini düşürecektir ) ve Teradata, Sybase gibi bir VLDB platformu IQ, RedBrick, Netezza (not: tescilli donanım) veya Greenplum raporlama için


1
@ConcernedOfTunbridgeW - her zaman bu tarafa gidebilirler: blog.backblaze.com/2009/09/01/… - SAN'dan çok daha eğlenceli, sadece ~ 120-130 4U kutu gerekli ... ama emin değilim ' iş 'mutlu olurdu ....
pQd

Temelde bir bütçe üzerinde Sun Thumper ve gerçekten paylaşılan bir sistemde bir düğüm için bir seçenek örneği. Bunun için başka seçenekler de gördüğümden eminim ama nerede olduğunu düşünemiyorum. Asıl soru ne donanım değil, hangi veritabanı platformudur.
ConcOedOfTunbridgeWells

Bununla birlikte, keskin gözlemciler, bunun gibi herhangi bir doğrudan bağlantı tabanlı kutunun, paylaşılan bir platformda çalışmak üzere tasarlanan bir şey lehine en az bir önemli argüman olan bir SAN'a dayanan her şeyden çok, çok daha ucuz olduğunu belirteceklerdir. .
ConcOedOfTunbridgeWells

@ConcernedOfTunbridgeWells ve tüm bu sorguları / bakımları ve başka herhangi bir şeyi [aksi halde aç olan] kutularında paralel olarak çalıştırabilirsiniz.
pQd

1
@ConcernedOfTunbridgeWells - size sorularınızı cevaplamak için ... Mümkünse bir saniyenin altına geri dönmek için yaklaşık 500 sorguya ihtiyacım var. Bunu günde sadece birkaç yüz kez yapacağım. Bir sorgu olsa da, tam tablonun taranması gerekir. Ayrıca INSERT'ler SELECT'lerden daha düşük bir öncelik taşır, bu nedenle hemen yakınında hiçbir yerde olması gerekmez. "Yeni" verilerin veritabanına girmesi için birkaç saat bekleyebilirim.
Sarah

16

Parçala. Bu boyutta büyük bir örneğe sahip olmak bir intihardır - olası yedekleme onarımları, masa alanı bozulmaları, yeni sütunlar ekleme veya başka herhangi bir 'ev tutma' süreci hakkında düşünün - bu ölçekte makul bir zamanda yapılması imkansızdır.

zarf hesaplamalarının basit arkası - 64bit kimliği dışındaki tüm sütunlar için 32bit tam sayıları; dahil endeks yok:

8 * 4B + 8B = satır başına 40B [ve bu çok iyimser]

192 Trilyon sıra 40B bize neredeyse 7 PB veriyor.

belki her şeyi yeniden düşünebilir, hızlı raporlama için bilgileri özetleyebilir ve birinin daha derin ayrıntılara girmesi gerektiğinde, belirli zaman aralıklarında sıkıştırılmış kayıtları saklayabilirsiniz.

cevaplanması gereken sorular:

  • sistemin çökmesi / yeniden başlatılması durumunda kabul edilebilir arıza süresi nedir?
  • Planlanan bakım için yedeklemeyi kurtarmanız veya sunucuyu üretim dışı bırakmanız gerektiğinde erişilebilecek kapalı kalma süresi.
  • ne sıklıkta ve nerede yedekleme yapmak istiyorsunuz?

rasgele bağlantılar - uçların hızı:


Kabul ediyorum - 7PB oldukça ağır. Yeniden düşünmeyi ve daha hafif bir çözüm bulmayı çok isterdim, ancak p alanlarının belirli bir kombinasyonunun varlığını (veya yokluğunu) bulmam gerekiyor. Masaları bölmek fikrimi aştı - daha mantıklı, ama sonra sırayla her tabloyu sorguladığım anlamına geliyor. İlgilenmediğiniz yere, buraya kaç tane tablo ayırmanızı önerirsiniz?
Sarah

5
@Sarah - sadece masalara değil, makinelere de ayırmanızı tavsiye ederim. Sorgularınızı performans kazanmak için paralel olarak çalıştırabilirsiniz [daha küçük ölçekte yapıyorum]. Sunucu yeniden başlatıldıktan sonra dosya sistemi bozulmaları veya hatta rutin kontroller ne olacak? Belirli bir kombinasyon bularak ne demek istediğinizi bilmiyorum ... belki basit bir anahtar-değer deposu yardımcı olabilir mi? masa boyutu - en az birkaç GB GB; tek sunucudaki veriler - çok az TB değil. daha küçük ölçekte hangi baş ağrısının olacağını bilmek için stackoverflow.com/questions/654594 adresine bakın ; innodb_file_per_table kullanmak
PQD


2

Tüm yapmak istedikleriniz sette olup olmadığını görmek için katrilyonlarca sayıyı saklamak yerine başka bir yol olabilir. Bloom filtreleri birçok yolla karma, olasılıklı bir yöntemdir. Ayrıca, yanlış pozitifler mümkündür, ancak yanlış negatifler değildir. (Yani, sayı sette olduğunu söyleyebilir - ve yanlış olun, ama gerçekten orada olsaydı, orada olmadığını söylemez). Ayrıca hala depolanacak çok sayıda eşya sorunu var, ancak en azından çalışan veri kümesi boyutunu biraz aşağı çekebilir.


Yanlış negatifler ile yaşayabilsem de ilginç geliyor - ama yanlış pozitifler değil :)
Sarah

2

Düzenleme: Aslında, X konumundaki bir "tamsayı" nın bir tamsayı aralığında olması ya da yok olması durumunda, veri deposunu ortadan kaldırabilir ve sadece bitmap'i kullanabilirsiniz ... Yani, 10 veya 100 TB disk alanına sahip makineler (bu nedenle, performans ve yedekleme için 10 bitmaranızın kopyası vardır) ve sunucu başına 128 GB RAM yaptıysanız, 26 Quadrillion bit X'in bitine başlamadan önce ilk kontrolü yapmak için belleğe yüksek çözünürlüklü bir üst düzey blok grubu dizini sığdırabilirsiniz. .

Ben # 2 seçeneği için giderdim:

Her biri 64TB (32 2TB sürücü) bulunan 375 makine (arızalar için gerçekçi bir şekilde 400 makine) daha sonra kayıtları her biri 2 TB olan ZVOL'lerle eşleştirir. Ardından bir veya daha fazla dizin sunucusunda, 26 Quadrillion konumundan 1'ine bir kayıt eklediyseniz bir eşlemesi olan bir Judy dizisinde veya kritik dizide veya yalnızca düz bitmap'te depolayın. Endeks 50 ile 100 TB arasında olacak ve 64 GB RAM'in altına sığacak ve hızlı bir başlangıç ​​kontrolü sağlayacak belirli bir 64k adres bloğuna yazılmış herhangi bir kayıt olup olmadığını gösteren bir ikinci seviye endeksine bile sahip olabilirsiniz. Belli bir "mahalle" boş ya da olmasaydı.

Sonra bu kaydı okumak için ilk önce dizine bakarak bulacağınız bir kayıt olup olmadığını kontrol edin. Varsa, basit indeks hesaplamasına göre bu 2TB bloğu içindeki makine / kayıt yeri # (Z) üzerindeki makine # (X) / ZOL # (Y) 'ye gidin. Tek kayıt aramaları çok hızlı olacaktır ve veri deposunun bazı bölümlerini farklı dbs'lere yükleme (gerçek zamanlı olarak veri deposunu kullanırken) ve tüm veritabanınızı destekleyip desteklemediklerini görmek için performans testi yapmayı test edebilirsiniz. sadece veri deposunu bu şekilde kullanın.

ZOL, diğer dosya sistemlerinde seyrek bir dosya olarak düşünülebilecek bir ZFS olayıdır, bu yüzden benzer şeyler geçerli olacaktır. Veya diskteki belirli bir bayt numarasına indeksleyebilirsiniz, ancak disk başına farklı boyutta olan disklerde, her disk için çalışan bir seviyede disk başına kullanılan bayt sayısını (yani 2 TB disk başına 1,75 TB), . Veya sabit bir boyuta sahip metadevices yarat


Merhaba Sarah - hala bunun üzerinde çalışıyorsanız emin değilim, ama yardıma ihtiyacınız olursa, 100TB'lik bir makinede sizin için fikrimi prototip edebilir ve aynı zamanda (büyük bir ABD veri merkezinde) barındırmaya ve tam üretim kümesini yönetmeye hazırım. Gerektiği gibi 400-500 makine. BTW, SF'de CNET'te hiç çalıştınız mı?

1

SELECT'lerinizi insanlıktan olabildiğince önbelleğe almak için çılgınca (yardım için mysqltuner kullanın) DB parametrelerinizi ayarlamanın yanı sıra, araştırmanız gereken tek şey, kaçınmak için birkaç yüz rekoru eklerken START TRANSACTION / CoMMIT (InnoDB varsayımı) 'dır. satır üste kilitleme satır ve büyük bir faktör tarafından ekleme zamanını aşağı getirmek. Ayrıca hem MyISAM hem de InnoDB olarak tabloyu oluşturacağım ve önbellekleme sıkılaştırıldıktan sonra hangisinin daha hızlı olduğunu görmek için testler yapacaktım.

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

Testiniz sırasında eşzamanlı iş parçacıklarının sayısı, sunucuda önbellekleri ayarlamaya adamak için ne kadar RAM alabileceğinizi belirleyebileceğiniz tatlı nokta bulana kadar aşağı yukarı değişmelidir; Matematik tarafından daha fazla iş parçacığını destekleyebiliyorken, iş parçacığı sayısı çok yükselirse, DB'nin kendisinin daha kötü performans gösterdiğini görebilirsiniz.

Ayrıca, eğer masa başına MyISAM ve / veya InnoDB dosyası kullanırsanız, / var / lib / mysql için daha küçük bir blok boyutuna ayarlanmış ve fs-tipi paramları ayarlamış farklı bir dosya sistemi bağlama noktası oluşturmayı inceleyebilirsiniz - yani ext3 / ext4 / resiserfs, data = dergi için geri yazma ve G / Ç hızı için dosya sistemindeki erişim zamanlarının güncellenmesini devre dışı bırakabilirsiniz.


1
myisam işlem şartları nedeniyle söz konusu değil gibi görünüyor.
pQd

0

İkinci seçenek için gerçekte kaç sayı girilmesi muhtemeldir?

Binde veya 10K, 100K, vb. Yalnızca bir tane olacaksa, kullanılmış (veya kullanılmayan) sayı aralıklarını saklamak trilyonlarca giriş yapmanıza yardımcı olabilir. örneğin: ('ücretsiz', 0,100000), ('alınmış', 100000,100003), ('ücretsiz', 100004,584234) - satırları gerektiği gibi iki veya üç satıra bölme ve ilk numaraya dizine ekleme, Aranan numarayı içeren aralığın alınmış veya serbest olup olmadığını görmek için x <= {needle} aranıyor.

Her iki duruma da ihtiyacınız olmayabilir. Hangi durumun mümkün olduğunu en düşük seviyede saklayın.

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.