Sütunlu veritabanlarını veri bilimine uygun yapan şey nedir?
Yanıtlar:
Sütun odaklı bir veritabanı (= columnar data-store), bir tablonun verilerini disk üzerinde sütuna göre depolarken, satır yönelimli bir veritabanı tablonun verilerini satır satır saklar.
Satır odaklı bir veritabanına kıyasla sütun odaklı bir veritabanını kullanmanın iki temel avantajı vardır. İlk avantaj, yalnızca birkaç özellik üzerinde işlem yapmamız durumunda, okunması gereken veri miktarıyla ilgilidir. Basit bir sorgu düşünün:
SELECT correlation(feature2, feature5)
FROM records
Geleneksel bir uygulayıcı tüm masayı okurdu (tüm özellikleri):
Bunun yerine, sütun temelli yaklaşımımızı kullanarak sadece ilgilenen sütunları okumak zorundayız:
Büyük veritabanları için de çok önemli olan ikinci avantaj, sütun temelli depolamanın daha iyi sıkıştırma sağlamasıdır, çünkü belirli bir sütundaki veriler gerçekten tüm sütunların genelinde homojendir.
Sütun yönelimli bir yaklaşımın ana dezavantajı, verilen bir sıranın tamamını değiştirmek (arama, güncelleme veya silme) verimsiz olmasıdır. Bununla birlikte, durum analitik veritabanlarında nadiren meydana gelmelidir (“depolama”), bu da çoğu işlemin salt okunur olduğu, aynı tabloda pek çok niteliği nadiren okuduğu ve yazılanların yalnızca ekli olduğu anlamına gelir.
Bazı RDMS, sütun odaklı bir depolama motoru seçeneği sunar. Örneğin, PostgreSQL'in tabloları sütun tabanlı bir şekilde saklama seçeneği yoktur, ancak Greenplum kapalı kaynak kodlu bir tane yarattı (DBMS2, 2009). İlginç bir şekilde, Greenplum, ölçeklenebilir veritabanı analizleri için açık kaynaklı bir kütüphanenin de arkasında, MADlib (Hellerstein ve ark., 2012) tesadüf değil. Daha yakın zamanlarda, yüksek hızlı, analitik veritabanı üzerinde çalışan bir girişim olan CitusDB, PostgreSQL, CSTORE için kendi açık kaynaklı sütunlu mağaza uzantısını yayınladı (Miller, 2014). Google’ın büyük ölçekli makine öğrenme sistemi olan Sibyl’de ayrıca sütun odaklı veri formatı kullanılmaktadır (Chandra ve diğ., 2010). Bu eğilim, büyük ölçekli analitik için sütun odaklı depolamaya olan ilginin artmakta olduğunu gösteriyor. Stonebraker ve diğ. (2005) ayrıca sütun odaklı DBMS'nin avantajlarını tartışmaktadır.
İki somut kullanım örneği: Büyük ölçekli makine öğrenmesi için çoğu veri seti nasıl depolanır?
(: cevap çoğunun Ek C gelir BeatDB: Bir uçtan uca yaklaşımı masif sinyal veri kümelerinden saliencies açıklayacak Franck Dernoncourt, SM, tez, Kampusu EECS MİT Bölümü. )
Bu ne yaptığınıza bağlı .
Sütun depolarının iki önemli faydası vardır:
- tüm sütunlar atlanabilir
- Çalışma boyu sıkıştırma, sütunlarda daha iyi çalışır (belirli veri türleri için; özellikle birkaç farklı değerle)
Ancak onların dezavantajları da var:
- Pek çok algoritma tüm sütunlara ihtiyaç duyar ve sadece bir kerede kayıt yapar (örneğin k-aracı) veya çift mesafeli bir matris hesaplamak bile gerekebilir
- Sıkıştırma teknikleri yalnızca seyrek veri türleri ve faktörleri üzerinde iyi çalışır, ancak çift değerli sürekli veriler üzerinde iyi çalışmaz
- sütun depolarına eklenir pahalıdır, bu nedenle veri akışı / verileri değiştirmek için ideal değildir
Sütun depolama OLAP aka "aptal analitik" (Michael Stonebraker) ve elbette tüm sütunları atmakla gerçekten ilgilenebileceğiniz yerlerin ön işleme tabi tutulması için gerçekten popülerdir (ancak önce yapılandırılmış veriye sahip olmanız gerekir - JSON'leri sütunda saklamayın biçim). Çünkü sütun düzeni, geçen hafta kaç tane elma sattığınızı saymak için gerçekten güzel.
Bilimsel / veri bilimi kullanım durumlarının çoğu için, dizi veritabanları gitmenin yolu gibi görünmektedir (artı, tabii ki yapılandırılmamış girdi verileri). Örneğin SciDB ve RasDaMan.
Çoğu durumda (örneğin derin öğrenme), matrisler ve diziler sütunlara değil ihtiyacınız olan veri türlerine sahiptir. MapReduce vb. Tabi ki ön işlemlerde faydalı olabilir. Belki sütun verileri bile (ancak dizi veritabanı genellikle sütun benzeri bir sıkıştırmayı da destekler).
Sütunlu bir veritabanı kullanmadım, ancak Parke adlı açık kaynaklı bir sütunlu dosya formatı kullandım ve büyük olasılıkla küçük bir alt kümeyi sorgulamanız gerektiğinde faydaların muhtemelen aynı olduğunu düşünüyorum - verilerin daha hızlı işlenmesi sütun sayısı. 140 düğüm Hadoop kümesinde yaklaşık bir buçuk saat süren 673 sütunla yaklaşık 50 terabayt Avro dosyası (satır odaklı dosya biçimi) üzerinde çalışan bir sorgu vardı. Parke ile aynı sorgu yaklaşık 22 dakika sürdü, çünkü sadece 5 sütuna ihtiyacım vardı.
Eğer az sayıda sütununuz olsaydı ya da sütunlarınızın büyük bir bölümünü kullanıyor olsaydınız, bir sütunlu veritabanının satır tabanlı olandan çok bir fark yaratacağını düşünmüyorum, çünkü temelde tüm verilerinizi taramanız gerekecek. Sütunlu veritabanlarının sütunları ayrı ayrı depoladığını ve satır odaklı veritabanlarının satırları ayrı depoladığına inanıyorum. Sorgu, diskten daha az veri okuyabildiğiniz zaman daha hızlı olacaktır.
Bu bağlantı daha fazla ayrıntıyı açıklar.
Not: Bu benim sorum, ve buradaki harika cevaplar için gerçekten müteşekkirim, bu da kavramı kavramada bana yardımcı oldu.
Böylece, kavramı anladığım şekliyle açıklardım:
Genellikle, veritabanlarındaki veriler aşağıdaki formatlarda bellekte saklanır:
Bu verileri dikkate alın:
X1 X2
1 0.7091409 -1.4061361
2 -1.1334614 -0.1973846
3 2.3343391 -0.4385071
İlişkisel bir sıra tabanlı mağazada, bu gibi saklanır:
1, 0.7091409, -1.4061361, 2, -1.1334614, -0.1973846, 3, 2.3343391, -0.4385071
Satır şeklinde.
Sütunlu mağazada, şöyle saklanır:
1, 2, 3, 0.7091409 ,-1.1334614, 2.3343391, -1.4061361, -0.1973846, -0.4385071
sütun şeklinde.
Peki, bu ne anlama geliyor?
Bu, satır ekleme sütun deposunda ekleme (ve güncelleme) ve silme işlemlerinin hızlı olması, yalnızca son birkaç değerin veya ilk birkaç değerin kaldırılması olduğu anlamına gelir. Bununla birlikte, her bir blok deposundaki değerin kaldırılması gerektiğinden sütunlu depolarda durum böyle değildir.
Bununla birlikte, sütunlu topaklara ve işlemlere ihtiyaç duyulduğunda, sütunlu depolar, sütun şeklinde depolandıkları için sıra tabanlı meslektaşları üzerinde bir kenara sahiptir ve sonuç olarak, tek tek sütunlara erişim çok kolaydır.