Sütun odaklı DBMS - Column-oriented DBMS

Bir sütun odaklı DBMS veya sütunlu DBMS bir veritabanı Yönetim sistemi (DBMS) veri tablolarını depolayan sütun satır yerine. Bir sütun deposunun bir sıralı depoya göre pratik kullanımı, ilişkisel DBMS dünya. Hem sütunlu hem de satır veritabanları, verileri yüklemek ve sorguları gerçekleştirmek için SQL gibi geleneksel veritabanı sorgu dillerini kullanabilir. Hem satır hem de sütunlu veritabanları, ortak veri tabanları için veri sunan bir sistemde omurga haline gelebilir. ayıkla, dönüştür, yükle (ETL) ve veri goruntuleme araçlar. Ancak, verileri satırlar yerine sütunlar halinde depolayarak, veritabanı satırlardaki istenmeyen verileri taramak ve atmak yerine bir sorguyu yanıtlamak için ihtiyaç duyduğu verilere daha kesin bir şekilde erişebilir.

Açıklama

Arka fon

İlişkisel bir veritabanı yönetim sistemi, iki boyutlu bir tabloyu, sütun ve satırları temsil eden veriler sağlar. Örneğin, bir veritabanında şu tablo olabilir:

Satır KimliğiEmpIdSoyadıİsimMaaş
00110SmithJoe60000
00212JonesMary80000
00311JohnsonCathy94000
00422JonesBob55000

Bu basit tablo bir çalışan tanımlayıcısı (EmpId), ad alanları (Soyadı ve Adı) ve bir maaşı (Maaş) içerir. Bu iki boyutlu format bir soyutlamadır. Gerçek bir uygulamada, depolama donanımı verilerin serileştirilmiş bir biçimde veya başka bir şekilde.

İçerdiği en pahalı işlemler sabit diskler vardır arıyor. Genel performansı iyileştirmek için, ilgili veriler arama sayısını en aza indirecek şekilde depolanmalıdır. Bu olarak bilinir referans yeri ve temel kavram bir dizi farklı bağlamda ortaya çıkar. Sabit diskler bir dizi bloklar sabit boyutta, genellikle tablonun birkaç satırını depolamaya yetecek kadar. Tablonun verilerini, satırlar bu blokların içine sığacak şekilde düzenleyerek ve ilgili satırları sıralı bloklar halinde gruplayarak, okunması veya aranması gereken blok sayısı, arama sayısı ile birlikte birçok durumda en aza indirilir.

Pinnecke ve diğerleri tarafından yapılan bir anket.[1] 2017 itibariyle sütun / satır hibridizasyon tekniklerini kapsar.

Sıra odaklı sistemler

Bir tabloyu depolamanın yaygın bir yöntemi, her veri satırını aşağıdaki gibi serileştirmektir:

001: 10, Smith, Joe, 60000; 002: 12, Jones, Mary, 80000; 003: 11, Johnson, Cathy, 94000; 004: 22, Jones, Bob, 55000;

Veriler tabloya eklendikçe, bir dahili kimlik atanır, Rowid verilere başvurmak için sistem içinde dahili olarak kullanılır. Bu durumda kayıtlar sıralı Rowidkullanıcı tarafından atananlardan bağımsız empid. Bu örnekte, DBMS depolamak için kısa tamsayılar kullanır Rowids. Pratikte, normal olarak daha büyük sayılar, 64 bit veya 128 bit kullanılır.

Satır tabanlı sistemler, mümkün olduğunca az işlemle tüm satır veya kayıt için verileri verimli bir şekilde döndürmek üzere tasarlanmıştır. Bu, sistemin belirli bir nesne hakkında bilgi almaya çalıştığı yaygın kullanım durumuyla eşleşir, örneğin bir kullanıcı için iletişim bilgileri Rolodex sistem veya ürün bilgisi çevrimiçi alışveriş sistemi. Sistem, kaydın verilerini ilgili kayıtlarla birlikte disk üzerinde tek bir blokta depolayarak minimum disk işlemi ile kayıtları hızlı bir şekilde alabilir.

Satır tabanlı sistemler, az sayıdaki belirli kayıtların aksine, tüm tablo üzerinde set çapında işlemler gerçekleştirmede verimli değildir. Örneğin, örnek tablodaki maaşları 40.000 ile 50.000 arasında olan tüm kayıtları bulmak için, DBMS'nin eşleşen kayıtları aramak için tüm tabloyu tamamen taraması gerekir. Yukarıda gösterilen örnek tablo büyük olasılıkla tek bir disk bloğuna sığacak olsa da, birkaç yüz sıralı bir tablo bile sığmaz ve verileri almak ve incelemek için birden fazla disk işlemi gerekir.

Bu tür işlemlerin performansını iyileştirmek için (bunlar çok yaygındır ve genellikle bir DBMS kullanmanın amacıdır), çoğu DBMS, veritabanı dizinleri, bir sütun kümesindeki tüm değerleri birlikte depolayan Rowid işaretçiler orijinal tabloya geri dönüyor. Maaş sütunundaki bir endeks şuna benzer:

55000:004; 60000:001;80000:002;94000:003;

Tüm satırlar yerine yalnızca tek veri parçalarını depoladıkları için, dizinler genellikle ana tablo depolarından çok daha küçüktür. Bu daha küçük veri kümesini taramak, disk işlemlerinin sayısını azaltır. Dizin yoğun şekilde kullanılıyorsa, genel işlemlerin süresini önemli ölçüde azaltabilir. Ancak, dizinlerin korunması, özellikle veri tabanına yeni veriler yazıldığında sisteme ek yük getirir. Kayıtların sadece ana tabloda saklanması gerekmez, aynı zamanda ekli dizinlerin de güncellenmesi gerekir.

Dizinlerin büyük veri kümelerinde performansı önemli ölçüde artırmasının ana nedeni, bir veya daha fazla sütundaki veritabanı dizinlerinin tipik olarak değere göre sıralanmasıdır. aralık sorguları işlemler (yukarıdaki "40.000 ile 50.000 arasında maaş içeren tüm kayıtları bulma" örneği gibi) çok hızlı (daha düşük zaman karmaşıklığı ).

Bir dizi satır odaklı veritabanları tamamen uyacak şekilde tasarlanmıştır. Veri deposu, bir bellek içi veritabanı. Bu sistemler disk işlemlerine bağlı değildir ve tüm veri kümesine eşit zamanlı erişime sahiptir. Orijinal verileri tipik toplama amaçları için tam bir dizin olarak tam olarak taramak için aynı miktarda işlem gerektirdiğinden, bu, dizin ihtiyacını azaltır. Bu tür sistemler bu nedenle daha basit ve daha küçük olabilir, ancak yalnızca belleğe sığacak veritabanlarını yönetebilir.

Sütun odaklı sistemler

Sütun odaklı bir veritabanı, bir sütunun tüm değerlerini, ardından bir sonraki sütunun değerlerini ve benzerlerini bir arada serileştirir. Örnek tablomuz için veriler şu şekilde saklanacaktır:

10: 001,12: 002,11: 003,22: 004; Smith: 001, Jones: 002, Johnson: 003, Jones: 004; Joe: 001, Mary: 002, Cathy: 003, Bob: 004; 60000: 001,80000: 002,94000: 003,55000: 004;

Bu düzende, sütunlardan herhangi biri satır tabanlı bir sistemdeki bir dizinin yapısıyla daha yakından eşleşir. Bu, sütun odaklı bir mağazanın her sütunda bir indeksi olan bir sıra deposu "gerçekten sadece" olduğu yanlış bir inanca yol açabilecek karışıklığa neden olabilir. Ancak, önemli ölçüde farklılık gösteren verilerin haritalandırılmasıdır. Satır yönelimli dizinli bir sistemde, birincil anahtar, dizinlenmiş verilerden eşlenen satır kimliğidir. Sütun odaklı sistemde birincil anahtar, satırlardan eşlenen verilerdir.[2] Bu ince görünebilir, ancak fark, yukarıdaki iki "Jones" öğesinin iki satırlı tek bir öğeye sıkıştırıldığı aynı mağazaya yapılan bu ortak modifikasyonda görülebilir:

…; Smith: 001;Jones: 002,004; Johnson: 003;…

Sütun odaklı bir sistemin operasyonda daha verimli olup olmayacağı, büyük ölçüde otomatikleştirilen iş yüküne bağlıdır. Belirli bir nesnenin (tüm satır) tüm verileri alan işlemler daha yavaştır. Satır tabanlı bir sistem, tek bir disk okumasındaki satırı alabilirken, sütunlu bir veritabanından birden çok sütundan veri toplamak için çok sayıda disk işlemi gerekir. Ancak, bu sıralı işlemler genellikle nadirdir. Çoğu durumda, yalnızca sınırlı bir veri alt kümesi alınır. Örneğin bir rolodex uygulamasında, bir kişi listesi oluşturmak için birçok satırdan ad ve soyadları toplamak, herhangi bir tek adres için tüm verileri okumaktan çok daha yaygındır. Bu, özellikle veri birçok isteğe bağlı sütunla "seyrek" olma eğilimindeyse, veri tabanına veri yazmak için daha da doğrudur. Bu nedenle, sütun depoları birçok teorik dezavantaja rağmen mükemmel gerçek dünya performansı göstermiştir.[3]

Bölümleme, indeksleme, önbelleğe alma, görünümler, OLAP küpleri ve gibi işlem sistemleri önceden yazma günlük kaydı veya multiversion eşzamanlılık kontrolü tümü, her iki sistemin fiziksel organizasyonunu önemli ölçüde etkiler. Bahsedilen, çevrimiçi işlem işleme (OLTP) odaklı RDBMS sistemleri daha satır odaklıyken çevrimiçi analitik işleme (OLAP) odaklı sistemler, satır odaklı ve sütun odaklı bir dengedir.

Faydaları

Satır yönelimli ve sütun yönelimli veritabanları arasındaki karşılaştırmalar, genellikle belirli bir iş yükü için sabit disk erişiminin verimliliği ile ilgilidir. arama süresi bilgisayarlardaki diğer darboğazlara kıyasla inanılmaz derecede uzun. Örneğin, tipik bir Seri ata (SATA) sabit sürücü, 16 ila 22 milisaniye arasında ortalama arama süresine sahiptir [4] Intel Core i7 işlemcide DRAM erişimi ortalama 60 nanosaniye sürer, bu da yaklaşık 400.000 kat daha hızlıdır.[5] Açıkça, disk erişimi, büyük verilerin işlenmesinde büyük bir darboğazdır. Sütunlu veritabanları, hem benzer sütunlu verileri verimli bir şekilde sıkıştırarak hem de yalnızca sorguyu yanıtlamak için gereken verileri okuyarak diskten okunması gereken veri miktarını azaltarak performansı artırır.

Uygulamada, sütunlu veritabanları aşağıdakiler için çok uygundur: OLAP benzeri iş yükleri (ör. veri depoları ) tipik olarak tüm veriler üzerinde oldukça karmaşık sorgular içeren (muhtemelen petabayt ). Ancak, sütunlu bir veritabanına veri yazmak için bazı çalışmalar yapılmalıdır. İşlemler (INSERT'ler) sütunlara ayrılmalı ve saklandıkça sıkıştırılmalıdır; bu, OLTP iş yükleri için daha az uygun hale gelir. Satır odaklı veritabanları aşağıdakiler için çok uygundur: OLTP interaktif işlemlerle daha fazla yüklü olan benzeri iş yükleri. Örneğin, tek bir satırdan tüm verileri almak, satır odaklı mimarilerde olduğu gibi, bu veriler tek bir konuma yerleştirildiğinde (disk aramalarını en aza indirerek) daha etkilidir. Bununla birlikte, sütun yönelimli sistemler hem OLTP hem de OLAP işlemlerini yapabilen melezler olarak geliştirilmiştir. Bu tür sütun yönelimli sistemlerin karşılaştığı bazı OLTP kısıtlamalarına (diğer özelliklerin yanı sıra) aracılık edilir. bellekte veri depolama.[6] Hem OLAP hem de OLTP rolleri için uygun sütun odaklı sistemler, ayrı sistemlere olan ihtiyacı ortadan kaldırarak toplam veri ayak izini etkili bir şekilde azaltır.[7]

Sıkıştırma

Sütun verileri tek tip tiptedir; bu nedenle, sütun odaklı verilerde bulunan ve satır odaklı verilerde bulunmayan depolama boyutu optimizasyonları için bazı fırsatlar vardır. Örneğin, birçok popüler modern sıkıştırma şeması, örneğin LZW veya çalışma uzunluğu kodlaması, sıkıştırılacak bitişik verilerin benzerliğinden yararlanın. Klinik verilerde yaygın olan eksik değerler ve tekrarlanan değerler, iki bitlik bir işaretleyici ile temsil edilebilir.[8] Satır odaklı verilerde aynı teknikler kullanılabilirken, tipik bir uygulama daha az etkili sonuçlar verecektir.[9][10]

Sıkıştırmayı iyileştirmek için satırları sıralamak da yardımcı olabilir. Örneğin, kullanma bitmap dizinleri sıralama, sıkıştırmayı bir büyüklük sırasına göre iyileştirebilir.[11] Sıkıştırma faydalarını en üst düzeye çıkarmak için sözlük düzeni göre çalışma uzunluğu kodlaması düşük kullanmak en iyisidirkardinalite ilk sıralama anahtarları olarak sütunlar.[12] Örneğin, cinsiyet, yaş, ad sütunlarının olduğu bir tablo verildiğinde, en iyisi önce cinsiyet değerine (iki değerin esas niteliği), ardından yaşa (<128 kardinalite), sonra ada göre sıralamak en iyisidir.

Sütunlu sıkıştırma, alma verimliliği pahasına disk alanında bir azalma sağlar. Komşu sıkıştırma ne kadar büyük olursa, verilerin okunması için sıkıştırılmamış olması gerekebileceğinden rastgele erişim o kadar zor hale gelebilir. Bu nedenle, sütun tabanlı mimariler bazen sıkıştırılmış verilere erişim ihtiyacını en aza indirmeyi amaçlayan ek mekanizmalarla zenginleştirilir.[13]

Tarih

Sütun depoları veya aktarılmış dosyalar, DBMS geliştirmenin ilk günlerinden itibaren uygulanmıştır. TAXIR, biyolojide bilgi edinmeye odaklanan sütun odaklı bir veritabanı depolama sisteminin ilk uygulamasıydı[14] Analiz edilebilecek olandan çok daha fazla niteliğe sahip hasta kayıtlarından alınan klinik veriler, 1975 ve sonrasında zaman odaklı bir veritabanı sistemi (TODS) tarafından işlendi.[8] İstatistik Kanada RAPID sistemini uyguladı[15] 1976'da Kanada Nüfus ve Konut Sayımının yanı sıra diğer bazı istatistiksel uygulamaların işlenmesi ve geri çağrılması için kullandı. RAPID, dünyadaki diğer istatistik kuruluşlarıyla paylaşılmış ve 1980'lerde yaygın olarak kullanılmıştır. 1990'lara kadar Statistics Canada tarafından kullanılmaya devam etti.

Başka bir sütun odaklı veritabanı SCSS.[16][17][18]

Daha sonra sütun odaklı veritabanı paketleri şunları içerir:

Yaklaşık 2004'ten beri ek açık kaynak ve ticari uygulamalar var. MonetDB altında yayınlandı açık kaynak lisansı 30 Eylül 2004 tarihinde,[19] yakından takiben şimdi feshedilmiş C-Mağaza.[20]

C-store, sonunda ekip üyeleriyle birlikte bir üniversite projesiydi. Michael Stonebraker devam etmek Vertica 2005 yılında kurucu ortağı olduğu.[21][22]

MonetDB ile ilgili X100 projesi, VectorWise.[23][24] Druid 2012 sonlarında açık kaynaklı olan ve şu anda çok sayıda kuruluş tarafından kullanılan sütun odaklı bir veri deposudur.[25]

Klasik İlişkisel DBMS satır yönelimli ve sütun yönelimli tabloları karıştırarak sütun yönelimli stratejiler kullanabilir. DBMS karmaşıklığına rağmen, bu yaklaşımın 2010 yıllarından günümüze kadar değerli olduğu kanıtlanmıştır. Örneğin, 2014'te Citusdata, aşağıdakiler için sütun tabanlı tablolar sunmuştur: PostgreSQL[26] ve McObject, sürümüyle sütunsal depolama için destek ekledi. eXtremeDB 2012'de Finansal Sürüm[27] daha sonra bağımsız olarak denetlenen STAC-M3 kıyaslaması için yeni bir performans standardı oluşturmak için kullanıldı.[28]

Ayrıca bakınız

Referanslar

  1. ^ Marcus Pinnecke; David Broneske; Gabriel Campero Durand; Günter Saake (2017). Veritabanları GPU'lardaki Karma İş Yüklerine Uygun mu? Bir Depolama Motorunun Perspektifi (PDF). IEEE 33rd International Conference on Data Engineering (ICDE). doi:10.1109 / ICDE.2017.237.
  2. ^ Daniel Abadi; Samuel Madden (31 Temmuz 2008). "Başka Bir Efsaneyi Çürütmek: Sütun Depoları ve Dikey Bölümleme". Veritabanı Sütunu. Arşivlenen orijinal 4 Aralık 2008.
  3. ^ Stavros Harizopoulos; Daniel Abadi; Peter Boncz. "Sütun Odaklı Veritabanı Sistemleri" (PDF). VLDB 2009 Eğitimi. s. 5.
  4. ^ Masiero, Manuel (8 Ocak 2013). "Western Digital'in 4 TB WD4001FAEX İncelemesi: Geri Siyah". Tom'un Donanımı.
  5. ^ Levinthal, Dr David (2009). "Intel® Core ™ i7 İşlemci ve Intel® Xeon ™ 5500 işlemciler için Performans Analizi Kılavuzu" (PDF). Intel. s. 22. Alındı 2017-11-10.
  6. ^ "Hibrit OLTP ve OLAP Veritabanlarında İşlem Verilerini Sıkıştırma" (PDF). Alındı 1 Ağustos, 2017.
  7. ^ "Bellek İçi Sütun Veritabanı Kullanarak OLTP ve OLAP İçin Ortak Bir Veritabanı Yaklaşımı" (PDF). Alındı 1 Ağustos, 2017.
  8. ^ a b Stephen Weyl; James F. Fries; Gio Wiederhold; Frank Germano (1975). "Modüler Kendini Tanımlayan Klinik Veritabanı Sistemi". Biyomedikal Araştırmada Bilgisayarlar. 8 (3): 279–293. doi:10.1016/0010-4809(75)90045-2.
  9. ^ D. J. Abadi; S. R. Madden; N. Hachem (2008). Sütun mağazaları ve sıra mağazaları: gerçekte ne kadar farklılar?. SIGMOD’08. s. 967–980.
  10. ^ Bruno, N (2009). "Eski bir file yeni numaralar öğretmek" (PDF). arXiv:0909.1758 [cs.DB ].
  11. ^ Daniel Lemire, Owen Kaser, Kamel Aouiche, "Sıralama, sözcük hizalı bitmap dizinlerini iyileştirir", Veri ve Bilgi Mühendisliği, Cilt 69, Sayı 1 (2010), s. 3-28.
  12. ^ Daniel Lemire ve Owen Kaser, Daha Küçük Dizinler İçin Sütunları Yeniden Sıralama, Bilgi Bilimleri 181 (12), 2011
  13. ^ Dominik Ślęzak; Jakub Wróblewski; Victoria Eastwood; Piotr Synak (2008). Brighthouse: ad hoc sorgular için analitik veri ambarı (PDF). 34. VLDB Konferansı Bildirileri. Auckland, Yeni Zelanda. Arşivlenen orijinal (PDF) 2016-05-07 tarihinde. Alındı 2009-05-04.
  14. ^ George F. Estabrook; Robert C. Brill (Kasım 1969). "TAXIR katılımcısının teorisi". Matematiksel Biyobilimler. 5 (3–4): 327–340. doi:10.1016/0025-5564(69)90050-9.
  15. ^ "Büyük istatistiksel veritabanları için bir DBMS". acm.org. Vldb '79. 1979. s. 319–327.
  16. ^ Eylül 1977'de zaten piyasada
  17. ^ SCSS: SPSS Diyaloğa Dayalı İstatistik Sistemi Kullanıcı Kılavuzu. 1980. ISBN  978-0070465336.
  18. ^ "SPSS, Inc'den SCSS". Bilgisayar Dünyası. 26 Eylül 1977. s. 28.
  19. ^ "Hakkımızda kısa bir tarihçe". monetdb.org.
  20. ^ "C-Store". mit.edu. Arşivlenen orijinal 2012-03-21 tarihinde. Alındı 2008-01-22.
  21. ^ "Vertica Analitik Veritabanı: 7 Yıl Sonra C-Store" (PDF) " (PDF). VLDB.org. 28 Ağustos 2012.
  22. ^ Charles Babcock (21 Şubat 2008). "Database Pioneer, Verileri Organize Etmenin En İyi Yolunu Yeniden Düşünüyor". Bilgi Haftası. Alındı 2018-12-08.
  23. ^ Marcin Zukowski; Peter Boncz (20 Mayıs 2012). X100'den vektörel yöne: fırsatlar, zorluklar ve çoğu araştırmacının düşünmediği şeyler. 2012 ACM SIGMOD Uluslararası Veri Yönetimi Konferansı Bildirileri. ACM. sayfa 861–862. doi:10.1145/2213836.2213967. ISBN  978-1-4503-1247-9.
  24. ^ D. Inkster; M. Zukowski; P.A. Boncz (20 Eylül 2011). "VectorWise'ın Ingres ile Entegrasyonu". ACM SIGMOD Kaydı. 40 (3): 45. CiteSeerX  10.1.1.297.4985. doi:10.1145/2070736.2070747.
  25. ^ "Druid". druid.io.
  26. ^ https://github.com/citusdata/cstore_fdw/graphs/contributors
  27. ^ Saujani, Sandeep (19 Haziran 2012). "McObject eXtremeDB Financial Edition In-Memory DBMS, Sermaye Piyasalarının Veri Yönetimi Darboğazını Aşıyor". bobs rehberi.
  28. ^ STAC Benchmark Council, Leadership (3 Kasım 2012). "Kove XPD L2 Depolama Sistemi, Dell PowerEdge R910 Sunucu ve Mellanox ConnectX-2 ve MIS5025Q QDR InfiniBand Anahtarlı McObject eXtremeDB 5.0 Financial Edition". STAC.

Dış bağlantılar