Geleneksel Olmayan Veri Depoları İçin Bir Veri Mühendisi Kılavuzu

Veri Mühendisliği

Büyük veri ve veri biliminin yükselişiyle birlikte birçok mühendislik rolüne meydan okunmakta ve genişletilmektedir. Yeni çağın rollerinden biri veri mühendisliğidir .

Başlangıçta, veri mühendisliğinin amacı, dış veri kaynaklarının yüklenmesi ve veritabanlarının tasarlanmasıydı (verileri toplamak, işlemek, depolamak ve analiz etmek için boru hatları tasarlamak ve geliştirmek).

O zamandan beri, büyük verilerin hacmini ve karmaşıklığını desteklemek için büyüdü. Bu nedenle, veri mühendisliği artık web tarama, veri temizleme, dağıtılmış bilgi işlem ve veri depolama ve alma gibi çok çeşitli becerileri kapsıyor.

Veri mühendisliği ve veri mühendisleri için, veri depolama ve alma, verilerin nasıl kullanılabileceği ve analiz edilebileceği ile birlikte boru hattının kritik bileşenidir.

Son zamanlarda birçok yeni ve farklı veri depolama teknolojisi ortaya çıkmıştır. Ancak hangisi en uygun ve veri mühendisliği için en uygun özelliklere sahip?

Çoğu mühendis, satır odaklı depolama ile ilişkisel veri tablolarında yapılandırılmış PostgreSQL, MSSQL ve MySQL gibi SQL veritabanlarına aşinadır.

Bu veritabanlarının ne kadar yaygın olduğu göz önüne alındığında, bugün onları tartışmayacağız. Bunun yerine, popülaritesi artan ve verilerle başa çıkmak için farklı yaklaşımlar sunan üç tür alternatif veri deposunu araştırıyoruz.

Veri mühendisliği bağlamında bu teknolojiler arama motorları, belge depoları ve sütunlu depolardır.

• Arama motorları metin sorgularında başarılıdır. LIKE gibi SQL veritabanlarındaki metin eşleşmeleriyle karşılaştırıldığında, arama motorları daha yüksek sorgu yetenekleri ve kullanıma hazır daha iyi performans sunar.
• Belge depoları , geleneksel veritabanlarından daha iyi veri şeması uyarlanabilirliği sağlar. Verileri, genellikle JSON'lar olarak temsil edilen ayrı belge nesneleri olarak depolayarak, şema ön tanımlaması gerektirmezler.
• Sütunlu mağazalar , tek sütunlu sorgularda ve değer toplamalarında uzmanlaşmıştır. SUM ve AVG gibi SQL işlemleri, aynı sütundaki veriler sabit sürücüde birbirine daha yakın depolandığından, sütunlu depolarda önemli ölçüde daha hızlıdır.

Bu makalede, üç teknolojiyi de inceliyoruz: Arama motoru olarak Elasticsearch, belge deposu olarak MongoDB ve sütunlu mağaza olarak Amazon Redshift.

Alternatif veri depolamayı anlayarak, her durum için en uygun olanı seçebiliriz.

Bu teknolojileri karşılaştırmak için, verileri nasıl endekslediklerini, parçayı ve toplu halde inceleyeceğiz.

Her veri indeksleme stratejisi, belirli sorguları geliştirirken diğerlerini engeller.

Hangi sorguların en sık kullanıldığını bilmek, hangi veri deposunun benimseneceğini etkileyebilir.

Veritabanlarının verilerini parçalara böldüğü bir metodoloji olan Sharding, daha fazla veri alındıkça altyapının nasıl büyüyeceğini belirler.

Büyüme planımıza ve bütçemize uygun olanı seçmek çok önemlidir ve bu, büyüklüğünden bağımsız olarak herhangi bir veri bilimi firması için geçerlidir.

Son olarak, bu teknolojilerin her biri verilerini çok farklı şekilde toplar.

Gigabaytlarca ve terabaytlarca veriyle uğraşırken, yanlış toplama stratejisi, oluşturabileceğimiz raporların türlerini ve performanslarını sınırlayabilir.

Veri mühendisleri olarak, farklı veri depolarını değerlendirirken her üç yönü de dikkate almalıyız.

yarışmacılar

Arama Motoru: Elasticsearch

Elasticsearch, ölçeklenebilirliği ve entegrasyon kolaylığı nedeniyle benzerleri arasında hızla popülerlik kazandı. Apache Lucene üzerine kurulu, güçlü, kullanıma hazır metin arama ve dizin oluşturma işlevi sunar. Geleneksel arama motoru görevleri, metin arama ve kesin değer sorgularının yanı sıra Elasticsearch, katmanlı toplama yetenekleri de sunar.

Belge Mağazası: MongoDB

Bu noktada MongoDB, go-to NoSQL veritabanı olarak kabul edilebilir. Kullanım kolaylığı ve esnekliği hızla popülerliğini kazandı. MongoDB, karmaşık belgeleri araştırmak için zengin ve uyarlanabilir sorgulamayı destekler. Sıklıkla sorgulanan alanlar, dizin oluşturma yoluyla hızlandırılabilir ve büyük miktarda veri toplanırken MongoDB çok aşamalı bir işlem hattı sunar.

Sütunlu Mağaza: Amazon Redshift

NoSQL'in popülaritesinin artmasının yanı sıra, sütunlu veritabanları da özellikle veri analitiği için ilgi topladı. Verileri olağan satırlar yerine sütunlarda depolayarak, toplama işlemleri doğrudan diskten yürütülebilir ve bu da performansı büyük ölçüde artırır. Birkaç yıl önce Amazon, Redshift adlı sütunlu bir mağaza için barındırılan hizmetini kullanıma sundu.

indeksleme

Elasticsearch'ün İndeksleme Yeteneği

Arama motorları birçok yönden metinleri indekslemede uzmanlaşmış veri depolarıdır.

Diğer veri depoları, alanın kesin değerlerine dayalı olarak dizinler oluştururken, arama motorları (genellikle metin) alanın yalnızca bir parçası ile erişime izin verir.

Varsayılan olarak, bu alma, analizörler aracılığıyla her alan için otomatik olarak yapılır.

Çözümleyici , alan değerlerini değerlendirerek ve bunları daha küçük değerlere bölerek birden çok dizin anahtarı oluşturan bir modüldür.

Örneğin, temel bir analizör, "hızlı kahverengi tilki tembel köpeğin üzerinden atladı" ifadesini "the", "hızlı", "kahverengi", "tilki" gibi kelimelerle inceleyebilir.

Bu yöntem, kullanıcıların aynı belge verileriyle kaç parçanın eşleştiğine göre sıralanan sonuçlar içinde parçaları arayarak verileri bulmasını sağlar.

Daha karmaşık bir çözümleyici, kapsamlı bir alma dizini oluşturmak için düzenleme mesafelerini, n-gramları kullanabilir ve stopwords ile filtreleyebilir.

MongoDB'nin İndeksleme Yeteneği

Genel bir veri deposu olarak MongoDB, verileri indekslemek için çok fazla esnekliğe sahiptir.

Elasticsearch'ün aksine, varsayılan olarak yalnızca _id alanını dizine ekler ve yaygın olarak sorgulanan alanlar için manuel olarak dizinler oluşturmamız gerekir.

Elasticsearch ile karşılaştırıldığında, MongoDB'nin metin analizörü o kadar güçlü değil. Ancak, optimum sorgulama için bileşik ve jeo-uzamsaldan TTL'ye ve depolamayı azaltmak için seyrek olarak indeksleme yöntemleriyle çok fazla esneklik sağlar.

Redshift'in İndeksleme Yeteneği

Elasticsearch, MongoDB ve hatta PostgreSQL dahil geleneksel veritabanlarından farklı olarak Amazon Redshift, bir dizin oluşturma yöntemini desteklemez.

Bunun yerine, diskte tutarlı bir sıralama sağlayarak sorgu süresini azaltır.

Kullanıcılar olarak, tablo sıralama anahtarı olarak sıralı bir sütun değerleri kümesi yapılandırabiliriz. Redshift, diskte sıralanan verilerle, değeri sorgulanan aralığın dışına düşerse, alma sırasında tüm bloğu atlayabilir ve performansı büyük ölçüde artırır.

parçalama

Elasticsearch'ün Parçalama Yeteneği

Elasticsearch, yatay olarak ölçeklendirmek ve üretime hazır olması için Lucene'nin üzerine inşa edildi.

Ölçekleme, birden çok Lucene örneği (parçası) oluşturularak ve bunları bir küme içindeki birden çok düğüme (sunucu) dağıtarak yapılır.

Varsayılan olarak, her belge kendi _id alanı aracılığıyla ilgili parçasına yönlendirilir.

Alma sırasında, ana düğüm, nihai olarak bunları toplamadan ve çıktı için sıralamadan önce her parçaya sorgunun bir kopyasını gönderir.

MongoDB'nin Parçalama Yeteneği

Bir MongoDB kümesinde üç tür sunucu vardır: yönlendirici, yapılandırma ve parça.

Yönlendiriciyi ölçeklendirerek sunucular daha fazla istek kabul edebilir, ancak ağır yük parça sunucularında gerçekleşir.

Elasticsearch'te olduğu gibi, MongoDB belgeleri (varsayılan olarak) _id aracılığıyla ilgili parçalarına yönlendirilir. Sorgu zamanında, yapılandırma sunucusu sorguyu parçalayan yönlendiriciyi bilgilendirir ve ardından yönlendirici sunucusu sorguyu dağıtır ve sonuçları toplar.

Redshift'in Parçalama Yeteneği

Bir Amazon Redshift kümesi, bir lider düğümden ve birkaç işlem düğümünden oluşur.

Lider düğüm, sorguların derlenmesi ve dağıtılmasının yanı sıra ara sonuçların toplanmasını da yönetir.

MongoDB'nin yönlendirici sunucularının aksine, lider düğüm tutarlıdır ve yatay olarak ölçeklenemez.

Bu bir darboğaz yaratırken, popüler sorgular için derlenmiş yürütme planlarının verimli bir şekilde önbelleğe alınmasına da olanak tanır.

Toplama

Elasticsearch'ün Toplama Yeteneği

Elasticsearch içindeki belgeler, kesin, aralıklı ve hatta zamansal ve coğrafi konum değerlerine göre gruplandırılabilir.

Bu kovalar, iç içe toplama yoluyla daha ince ayrıntı düzeyinde gruplandırılabilir.

Ortalamalar ve standart sapmalar dahil olmak üzere metrikler, tek bir sorgu içinde bir analiz hiyerarşisi hesaplama yeteneği sağlayan her katman için hesaplanabilir.

Belge tabanlı bir depolama olduğundan, belge içi alan karşılaştırmalarının sınırlamasından muzdariptir.

Örneğin, bir alanın takipçisi 10'dan büyükse filtrelemede iyi olsa da, takipçinin başka bir alandan daha büyük olup olmadığını kontrol edemeyiz .

Alternatif olarak, komut dosyalarını özel tahminler olarak enjekte edebiliriz. Bu özellik, tek seferlik analiz için harikadır, ancak üretimde performans düşer.

MongoDB'nin Toplama Yeteneği

Toplama İşlem Hattı güçlü ve hızlıdır.

Adından da anlaşılacağı gibi, dönen veriler üzerinde aşamalı bir şekilde çalışır.

Her adım, belgeleri filtreleyebilir, toplayabilir ve dönüştürebilir, yeni metrikler sunabilir veya önceden toplanmış grupları çözebilir.

Bu işlemler aşamalı olarak yapıldığından ve belge ve alanların yalnızca filtrelenmiş hale getirilmesi sağlanarak bellek maliyeti en aza indirilebilir. Elasticsearch ve hatta Redshift ile karşılaştırıldığında, Toplama İşlem Hattı, verileri görüntülemenin son derece esnek bir yoludur.

Uyarlanabilirliğine rağmen, MongoDB, Elasticsearch ile aynı belge içi alan karşılaştırma eksikliğinden muzdariptir.

Ayrıca, $group dahil olmak üzere bazı işlemler, sonuçların ana düğüme iletilmesini gerektirir.

Bu nedenle, dağıtılmış bilgi işlemden yararlanmazlar.

Aşamalı boru hattı hesaplamasına aşina olmayanlar, bazı görevleri sezgisel bulmayacaktır. Örneğin, bir dizi alanındaki öğelerin sayısını toplamak için iki adım gerekir: önce $unwind ve ardından $group işlemi.

Redshift'in Toplama Yeteneği

Amazon Redshift'in faydaları küçümsenemez.

Mobil trafiği analiz ederken MongoDB'deki sinir bozucu yavaş toplamalar Amazon Redshift tarafından hızla çözülür.

SQL'i destekleyen geleneksel veritabanı mühendisleri, sorgularını Redshift'e geçirmek için kolay bir zamana sahip olacak.

Yerleştirme süresi bir yana, SQL, belge/satır içi alan karşılaştırmalarını kolaylıkla destekleyen kanıtlanmış, ölçeklenebilir ve güçlü bir sorgu dilidir. Amazon Redshift, işlem düğümlerinde yürütülen popüler sorguları derleyerek ve önbelleğe alarak performansını daha da artırır.

İlişkisel bir veritabanı olarak Amazon Redshift, MongoDB ve Elasticsearch'ün sahip olduğu şema esnekliğine sahip değildir. Okuma işlemleri için optimize edilmiştir, güncellemeler ve silmeler sırasında performans düşüşlerine maruz kalır.

En iyi okuma süresini korumak için, ekstra operasyonel çabalar eklenerek satırlar sıralanmalıdır.

Petabayt boyutunda sorunları olanlara uyarlanmış, ucuz değildir ve diğer veritabanlarında ölçekleme sorunları olmadıkça muhtemelen yatırım yapmaya değmez.

Kazananı Seçmek

Bu yazıda, veri mühendisliği bağlamında Elasticsearch, MongoDB ve Amazon Redshift olmak üzere üç farklı teknolojiyi inceledik. Ancak, bu teknolojilerin her biri kendi depolama türü kategorisinde lider olduğu için net bir kazanan yok.

Veri mühendisliği için kullanım durumuna bağlı olarak bazı seçenekler diğerlerinden daha iyidir.

• MongoDB harika bir başlangıç ​​veritabanıdır. Veri şeması henüz belirlenecekken istediğimiz esnekliği sağlar. Bununla birlikte, MongoDB, diğer veritabanlarının uzmanlaştığı belirli kullanım durumlarından daha iyi performans göstermez.
• Elasticsearch , MongoDB'ye benzer bir akışkan şeması sunarken, yazma performansı ve depolama boyutu pahasına birden çok dizin ve metin sorgusu için optimize edilmiştir. Bu nedenle, kendimizi MongoDB'de çok sayıda indeks tutarken bulduğumuzda Elasticsearch'e geçmeyi düşünmeliyiz.
• Redshift , önceden tanımlanmış bir veri şeması gerektirir ve MongoDB'nin sağladığı uyarlanabilirlikten yoksundur. Buna karşılık, yalnızca tek (veya birkaç) sütun içeren sorgular için diğer veritabanlarını geride bırakır. Bütçe izin verdiğinde, Amazon Redshift, diğerleri veri miktarını kaldıramadığında büyük bir gizli silahtır.