Hangi veritabanı milyarlarca / trilyonlarca kaydın depolanmasını sağlayabilir?

Çok büyük miktarlarda topladığımız netflow verilerini yakalamak ve analiz etmek için bir araç geliştirmeyi düşünüyoruz. Her gün json biçiminde şöyle görünecek yaklaşık 1.4 milyar akış kaydı yakaladık:

{
   "tcp_flags": "0",
   "src_as": "54321",
   "nexthop": "1.2.3.4",
   "unix_secs": "1352234521",
   "src_mask": "23",
   "tos": "0",
   "prot": "6",
   "input": "105",
   "doctets": "186",
   "engine_type": "0",
   "exaddr": "2.3.4.5",
   "engine_id": "2",
   "srcaddr": "9.8.7.6",
   "dst_as": "12345",
   "unix_nsecs": "752265174",
   "sysuptime": "2943529544",
   "dst_mask": "24",
   "dstport": "80",
   "last": "2943523241",
   "srcport": "52672",
   "dpkts": "4",
   "output": "111",
   "dstaddr": "6.5.4.3",
   "first": "2943517993"
}

Veri kümesinde hızlı aramalar (10 saniyeden az), büyük olasılıkla dar zaman dilimlerinde (10 - 30 dakika aralıklarla) yapabilmek istiyoruz. Ayrıca veri noktalarının çoğunu endekslemek istiyoruz, böylece her birinde hızlı bir şekilde arama yapabiliriz. Ayrıca aramalar yapılırken verilerin güncel bir görüntüsünü almak istiyoruz. Açık kaynaklı dünyada kalmak harika olurdu, ancak bu proje için tescilli çözümlere bakmaya karşı değiliz.

Buradaki fikir yaklaşık bir ay veri tutmaktır ki bu da ~ 43,2 milyar kayıt olacaktır. Her bir kaydın yaklaşık 480 bayt veri içerdiği tahmininde, ayda yaklaşık 18.7 terabayt verinin ve endekslerin üç katı olabileceği tahmin edilmektedir. Sonunda, bu sistemin trilyonlarca kayıt saklama kapasitesini artırmak istiyoruz.

Bu proje için mümkün olan en yakın aday olan kanepe üssü, cassandra ve mongodb'leri (çok temelde) değerlendirdik, ancak her biri kendi zorluklarını öneriyor. Sofabase ile, indeksleme aralıklarla yapılır ve verilerin eklenmesi sırasında değil, görünümler güncel olmaz, cassandra'nın ikincil endeksleri genellikle sonuçlar için tüm kümenin taranmasını gerektirdiklerinden sonuçları döndürmede çok etkili değildirler ve mongodb umut verici görünüyor ama Master / Slave / Sharded olduğu için ölçeklendirmek çok daha zor görünüyor. Değerlendirmeyi planladığımız diğer bazı adaylar; elasticsearch, mysql (eğer bunun uygulanabilir olup olmadığından emin değilsiniz) ve birkaç sütun odaklı ilişkisel veritabanıdır. Herhangi bir öneri veya gerçek dünya deneyimi takdir edilecektir.

Çalıştığım bir şirkette benzer miktarda veri (yaklaşık 10 TB'lık gerçek zamanlı aranabilir veri) ile uğraşıyoruz. Bunu Cassandra ile çözüyoruz ve çoklu TB veritabanı veritabanında O (1) araması yapmanıza izin verecek birkaç fikirden bahsetmek istiyorum. Bu, Cassandra db'ye özgü değildir, ancak diğer db ile de kullanabilirsiniz.

teori

• Verilerinizi paylaşın. Tek bir sunucunun bu tür verileri güvenilir ve gerçekçi bir şekilde tutması mümkün değildir.
• Donanım hataları ve tüm düğüm hataları için hazır olun, verileri çoğaltın.
• Baştan beri birçok arka uç sunucu kullanmaya başlayın.
• Üst düzey yüksek performanslı olanlara kıyasla daha ucuz emtia sunucuları kullanın.
• Verilerin parçalara eşit olarak dağıtıldığından emin olun.
• Sorgularınızı planlamak için çok zaman harcayın. Sorgulardan API'yi alın ve sonra tabloları dikkatlice tasarlayın. Bu en önemli ve uzun süreli görevdir.
• Cassandra'da bir bileşik sütun anahtarı tasarlayabilir ve O (1) 'de o anahtara erişebilirsiniz. Üzerinde çalışarak zaman geçirin. Bu, ikincil indeks yerine aranabilir kayıtlara erişmek için kullanılacaktır.
• Geniş satırları kullanın. Zaman damgalı olayları saklamak için faydalıdırlar.
• Asla tam tarama yapmayın ya da bu tür bir hacimde O (Log N) 'den daha fazla işlem yapmayın. O (Log N) 'den başka bir şeye ihtiyacınız olursa, bu işlemleri Map-Reduce algoritmalarına boşaltın.

Uygulama

• İşletim sistemi görüntüleri oluşturmak veya sunucuları fiziksel makinelere kurmak için zaman harcamayın. Hızlı prototipleme için bulut tabanlı sağlayıcıları kullanın. Amazon EC2 ile çalıştım ve sadeliği, güvenilirliği ve prototipleme hızı için bunu tavsiye edebilirim.
• Windows makineleri önyükleme sırasında daha yavaş olma eğilimindedir ve Boşta olma durumunda önemli ölçüde daha fazla kaynak alır. Unix tabanlı işletim sistemi kullanmayı düşünün. Şahsen, Ubuntu sunucusunu güvenilir bir işletim sistemi olarak buldum, fakat ayrıca askubuntu'da oldukça iyi bir topluluk var.
• Ağ kurmayı düşünün, düğümler hızlı dedikodu ve meta-veri değişimini sağlamak için ideal olarak birbirine yakın olmalıdır.
• Aşırı durumlara girmeyin: gerçekten geniş sütun sıraları veya son derece uzun sütun aileleri (tablolar). Akılcı sınırlarda en iyi performans elde edilir - eğer db tasarım gereği bu kadar N sırasını destekliyorsa, iyi performans gösterdiği anlamına gelmez.
• Aramamız yaklaşık 3-5 saniye sürüyor, bunun nedeni, kullanıcı arayüzü ile veritabanı arasındaki ara düğümler. İstekleri veritabanına nasıl yaklaştıracağınızı düşünün.
• Bir ağ yükü dengeleyicisi kullanın. Yerleşik bir tane seçin. Basit ama hızlı ölü olan HAProxy kullanıyoruz. Asla onunla problem yaşamadım.
• Karmaşık çözümlere sadeliği tercih edin.
• Bir kurumun büyüklüğü bütçesi tarafından desteklenmediğiniz sürece ücretsiz açık kaynaklı çözümler arayın. Birden fazla sunucuya gittiğinizde, altyapı maliyetleri daha da yükselebilir.

Amazon için çalışmıyorum ve HAProxy ve Ubuntu ekipleriyle hiçbir ilişkim yok. Bu herhangi bir terfi değil kişisel bir görüş.

Bunu SQL Server'a koyacak olsaydım, şöyle bir tablo önerirdim:

CREATE TABLE tcp_traffic
(
    tcp_traffic_id bigint constraint PK_tcp_traffic primary key clustered IDENTITY(1,1)
    , tcp_flags smallint    /* at most 9 bits in TCP, so use SMALLINT */
    , src_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , netxhop bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , unix_secs bigint  
    , src_mask int      /* an assumption */
    , tos tinyint       /* values are 0-255, see RFC 791 */
    , prot tinyint      /* values are 0-255, see RFC 790 */
    , input int         /* an assumption */
    , doctets int       /* an assumption */
    , engine_type int   /* an assumption */
    , exaddr bigint     /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , engine_id int     /* an assumption */
    , srcaddr bigint    /* use a big integer for the IP address instead of storing
                             it as dotted-decimal */
    , dst_as int        /* Since there are less than 2 billion A.S.'s possible, use INT */
    , unix_nsecs bigint /* an assumption */
    , sysuptime bigint  /* an assumption */
    , dst_mask int      /* an assumption */
    , dstport smallint  /* ports can be in the range of 0 - 32767 */
    , [last] bigint     /* an assumption */
    , srcport smallint  /* ports can be in the range of 0 - 32767 */
    , dpkts int         /* an assumption */
    , output int        /* an assumption */
    , dstaddr bigint    /* use a big integer for the IP address instead of storing
                            it as dotted-decimal */
    , [first] bigint    /* an assumption */
);

Bu, tek bir masa için toplam tahmini depolama gereksinimi ile sonuçlanır, 43.2 beeellion kayıtları için başka bir 5.5 TB indeks içermez (sizin belirttiğiniz gereksinim). Bu, verilerin kendisi için 130 bayt, ayrıca genel giderler için 7 bayt, ayrıca genel giderler için 96 bayt olarak hesaplanır. SQL Server, verileri 8KB sayfalarda depolar ve sayfa başına 59 satır sağlar. Bu, tek bir aylık veri için 732.203.390 sayfaya eşittir.

SQL Server, fiziksel giriş / çıkış başına 472 satıra eşit olan 8 sayfalık bölümlerde (64KB) diske yazmayı sever. Her saniyede 16.203 akış kaydı oluşturulurken, her saniye garanti edilen minimum I / O hızına sahip 34 IOps'a ihtiyacınız olacak. Bu kendi başına çok büyük bir miktar olmamasına rağmen, sistemdeki diğer G / Ç'lerin (SQL Server ve başka şekilde) bu gerekli IOps oranını asla ihlal etmemesi gerekir. Bu nedenle, en azından bir büyüklük sırası daha fazla IOps veya 340 sürekli IOps yapabilen bir sistem tasarlamanız gerekir - Verimliliği garanti altına almak için 2 büyüklükte daha sürdürülebilir IOps'a ihtiyacınız olduğunu tahmin etme eğilimindeyim.

IP adreslerini noktalı ondalık biçiminde saklamadığımı fark edeceksiniz. Bu, depolamada çok büyük miktarda tasarruf sağlar (adres başına 7 bayt) ve ayrıca IP adreslerini indeksleme, alma, sıralama ve karşılaştırma işlemlerini çok daha verimli hale getirir. Buradaki dezavantajı, noktalı ondalık IP'leri kaydetmeden önce 8 bayt tam sayılara dönüştürmeniz ve görüntüleme için noktalı ondalık IP'lere geri dönmeniz gerekir. Bunu yapmak için gereken kod önemsizdir, ancak satır oranınız, işlenen her akış satırına önemli miktarda işlem ek yükü ekleyecektir - bu dönüştürme işlemini SQL Server'dan fiziksel olarak farklı bir makinede yapmak isteyebilirsiniz.

Gereksinim duyduğunuz dizinleri tartışmak tamamen ayrı bir konudur çünkü herhangi bir özel gereksinimi listelemediniz. Bu tablonun tasarımı, akış satırlarını SQL Server tarafından alındıkları fiziksel sıraya göre depolar, tcp_traffic_idalan her kayıt için benzersizdir ve satırların kaydedildikleri sıraya göre sıralanmasına izin verir (bu durumda bire bir) akış olayının zamanına).

HBase tavsiye ederim . Sormanız gerekenlere bağlı olarak, tüm ham verileri bir veya daha fazla HBase tablosunda saklayabilirsiniz. HBase, büyük veri kümelerini kaldırabilir ve bölge bölmeleri boyunca otomatik netleme yapar.

Ayrıca, satır anahtarlarını iyi tasarlarsanız, son derece hızlı, hatta O (1) sorguları alabilirsiniz. Büyük bir veri kümesi alıyorsanız, veri alımı bir O (n) işlemi olduğundan, bu işlemin yavaş olacağını unutmayın.

Her alanda sorgulamak istediğiniz için, her biri için benzersiz bir tablo oluşturmanızı tavsiye ederim. Src_address verileri için örnek, şuna benzeyen bir tabloya sahip:

1.2.3.4_timestamp1 : { data }
1.2.3.4_timestamp2 : { data }

Bu nedenle, 1.2.3.4'ten itibaren Mar 27 12:00 AM ile Mar 27 12:01 AM arasında başlayan tüm verileri sorgulamak istiyorsanız, belirtilen başlatma ve durdurma satırlarıyla aralık taraması yapabilirsiniz.

IMHO, satır anahtarı tasarımı HBase kullanımının en kritik kısmıdır - eğer iyi tasarlarsanız hızlı sorgulamalar yapabilir ve büyük miktarlarda veri depolayabilirsiniz.

Bunu dedi :

... bu proje için tescilli çözümlere bakmaya karşı değiliz

IBM Informix database + TimeSeries veritabanını göz önünde bulundurmanızı öneririm. Bazı insanların söylediklerinin tersine, Informix yaşıyor ve çok iyi gidiyor. Son sürüm geçen ay yayımlandı (Mart / 2013, sürüm 12.10).

TimeSeries, sizinki gibi durumlarla başa çıkabilen bir "eklenti" (ücretsiz) gibidir.
Ve Informix veritabanının ücretsiz sürümü (editör Innovator-C ) ile üretimde kullanabilirsiniz . (elbette, ücretsiz sürümün çok sınırlı kaynağı olduğundan yalnızca teknik parçaları değerlendirmek için)

Burada referans olarak neyin kullanılabileceğini gösteren bir benchmark PDF dosyasını kontrol edebilirsiniz. İşte daha teknik örneklerle iki sunum: aptallar kılavuzu ve diğer ipuçları

TimeSeries ile kişisel deneyimim yok , bu yüzden "çözüm" olacağını kabul edemiyorum, sadece bir öneri.

Informix TimeSeries'e bakma tavsiyesini ikinci olarak öğrendim. IBM literatürü, TimeSeries’in bu tür bilgileri alanın 1 / 5’inde saklayabildiğini ve geleneksel ilişkisel tabloların 5 kat daha hızlı gerçekleştirilebileceğini iddia ediyor.

Ek faydalar, TimeSeries verilerinin son kullanıcı için geleneksel ilişkisel tablolar gibi görünmesini sağlayabilen Sanal Masa Arayüzü (TimeSeries'in faydalarını alırken uygulama geliştirmeyi basitleştirir), şimdi 12.1 sürümündeki TimeSeries verilerini destekleyen HDR düğümlü basit HA ve TimeSeries verilerinin, karmaşık veri ambarı raporlarını hızlandırmak için kullanılabilecek Informix Warehouse Accelerator'a entegrasyonu ve ücretsiz Informix Developer veya Innovator-C sürümlerini kullanarak Informix'teki bir TimeSeries çözümünü prototipleme kabiliyeti.