Sonraki Yeni Parlak Şey İçin Bir Veri Deposu Nasıl Seçilir

Not: Bu, Baş Mühendis Silvia Botros tarafından yazılmış teknik bir blog yazısıdır ve ilk olarak 25 Aralık 2017'de Sysadvent blogunda yayınlanmıştır.

Veritabanları zor olabilir. Daha zor olan ne biliyor musun? İlk etapta birini seçmek. İster ürününü/pazarını hala uygun bulan yeni bir şirkette olun, ister hedef kitlesini bulmuş ve ürün teklifini genişleten bir şirkette olun, bu zorlu bir iştir.

Yeni bir şey inşa ederken, bu tasarım sürecinin ilk bölümlerinden biri hangi veri depolarını kullanmalıyız ve bu tek mi yoksa çoğul mu olmalı? İlişkisel mağazaları kullanmalı mıyız yoksa bir anahtar değer deposu mu seçmemiz gerekiyor? Peki ya zaman seçenekleri? Ayrıca bazı dağıtılmış günlük tekrarlarını da serpmeli miyiz?

Böyle. Birçok. Seçenekler…

Bu makalede, bu karara umarız rehberlik edecek bir süreci açıklamaya çalışacağım ve uygun olduğunda, kuruluşunuzun büyüklüğü ve olgunluğunun bu kararı nasıl etkileyebileceğini açıklayacağım.

Temel gereksinimler

Veri, herhangi bir ürünün can damarıdır. Tasarımda uygulama durumunu depolamak için daha fazla son teknoloji kullanmayı planlıyor olsak bile (çünkü MySQL veya Postgres artık “havalı” değildir), seçtiğimiz her şey hala bir veri deposudur ve bu nedenle, seçimimizi yapıyoruz.

Hatırlanması gereken en önemli şey, hiçbir şeyin ücretsiz olmadığıdır. Tüm veri depoları tavizlerle birlikte gelir ve bir iş riski olarak hangi tavizleri aldığınız konusunda açık değilseniz, mümkün olan en kötü zamanda kendini gösterecek bilinmeyen bir risk alıyor olacaksınız.

Ürün yöneticinizin, veri deponuz için ne kullandığınızı bilmesi ve hatta umursaması pek olası değildir, ancak seçenek listesini daraltan ihtiyaçları yönlendirecektir. Bazen bunun bile geliştirme ekibi tarafından biraz dürtülmesi gerekir. Ürün ekibinden seçeneklerinizi artırmanıza yardımcı olması için istemeniz gereken şeylerin bir listesi:

• Büyüme oranı: Verinin kendisi veya ona erişimin zaman içinde nasıl değişmesi bekleniyor?
• Faturalandırma ekibi bu yeni verileri nasıl kullanacak?
• ETL ekibi bu verileri nasıl kullanacak?
• Bu yeni özellik için hangi doğruluk/tutarlılık gereksinimleri bekleniyor?
• Bu tutarlılık için hangi zaman aralığı kabul edilebilir? İşlem sonrası düzeltme kabul edilebilir mi?

Söylenmeyen bağlamı bulun

Veri deposu seçimi, DBA veya Operasyon ekibi veya hatta sadece kodu yazan mühendis için ayrılmış bir seçim değildir.

Bilinen bir adreslenebilir pazarı olan olgun organizasyonlar, organizasyon genelindeki paydaşlardan bir karara varmalıdır.

Ürün ekibinden gelen gereksinimler bir düzine veri deposuna uyuyorsa, açıkça belirtilmeyen gereksinimleri nasıl belirlersiniz?

Sözsüz gereksinimleri mümkün olan en kısa sürede ortaya çıkarmanız gerekir, çünkü bu, başarısız beklentilere giden yoldur.

Pek çok ima edilen şey, bu 'çok fazla seçenek' tuzağında başarısız olmanıza neden olabilir. Bu, aşağıdakileri içerir ancak bunlarla sınırlı değildir:

• Eksik özellik listeleri
• Açıkça listelenmeyen performans gereksinimleri
• Varsayılan tutarlılık ihtiyaçları
• Belirtilmeyen büyüme oranı
• Henüz mevcut olmayan/bilinen olmayan faturalandırma veya ETL sorgu ihtiyaçları

Bunların hepsi, bir mühendislik ekibinin, sırf birlikte çalıştıkları açık kriterler çok müsamahakar veya eksik olduğu için, uzun bir veri deposu seçenekleri listesini incelemeye çok uzun süre başlarını döndürmesine neden olabilecek olası yollardır.

Daha 'yeşil alan' ürünleri için, daha önce de belirttiğim gibi, hedefiniz esnekliktir. Bu nedenle, daha genel amaçlı, kalitesi bilinen bir veri deposu, ileride yeni ölçeğinize daha uygun bir veri deposuna geçmeniz gerekebileceğini bilerek, bir çıktıya yaklaşmanıza yardımcı olacaktır.

Listenizi yapın

Potansiyel çözümleri ihtiyaç listenize göre filtrelemenin zamanı geldi. Ortaya çıkan listenin bir avuç olası veri deposundan fazla olmaması gerekir. Kullanabileceğiniz potansiyel veritabanlarının listesi bundan daha fazlaysa, gereksinimleriniz çok serbesttir ve geri dönüp daha fazla bilgi bulmanız gerekir.

Daha genç, daha az olgun şirketler için veri deposu gereksinimleri en çok bilinmeyenlerin olduğu alandır. Muhtemelen henüz kimsenin sunmadığı yeni bir şey inşa ediyorsunuz ve bu nedenle toplam adreslenebilir pazar büyüklüğü ve büyüme oranı gibi şeyler nispeten bilinmeyen ve ölçülmesi zor olabilir.

Bu durumda ihtiyacınız olan şey, tek hileli midilli veri deposu kullanarak yeni şirketinizin kullanım ömründe kendinizi çok erken sınırlamamaktır. Evet, bir noktada verileriniz yeni ve beklenmedik şekillerde büyüyecek, ancak şu anda ihtiyacınız olan şey, pazar nişinizi bulmaya çalışırken ve verilerinizin büyümesinin nasıl görüneceğini ve hangi belirli ölçeklenebilirlik özelliklerinin sizin için çok önemli hale geleceğini öğrenirken esnekliktir. senin büyümen.

Giderek artan sayıda ödeme yapan müşterisi olan daha büyük bir şirketseniz, buradaki göreviniz seçenek listesini, tercihen halihazırda sahip olduğunuz ve bakımını yaptığınız veri depolarına daraltmaktır. Halihazırda çok sayıda ödeme yapan müşteriniz olduğunda, ekibinizin aşina olmadığı yeni veri depoları ekleme riski artar ve verilerin bağlamına bağlı olarak kabul edilemez hale gelir.

Akılda tutulması gereken başka bir şey de, veri depoları için halihazırda hangi araçların mevcut olduğu ve ekibinizin yapması gereken ön çalışma açısından yenisini benimsemenin ne anlama geldiğidir. Yapılandırma yönetimi, yedekleme komut dosyaları, veri kurtarma komut dosyaları, yeni izleme kontrolleri, oluşturmak ve aşina olmak için yeni panolar. Riskten bağımsız olarak yeni bir veri deposunun işletim maliyeti listesi önemsiz değildir.

Zehirini seç

İşte DBA'ların tutunduğu kötü saklanan bir sır. Veritabanlarının hepsi bir konuda korkunç. Hatta bununla ilgili bütün bir teorem var. Sadece geleneksel anlamda veritabanları değil, durumu saklayan herhangi bir teknoloji, onu nasıl kullandığınıza özgü bir şekilde korkunç olacaktır.

Bu, şimdi daha iyi içselleştirmeniz gereken bir yaşam gerçeğidir. Hayır, bu teknolojilerden herhangi birini kullanmaktan kaçınmanız gerektiğini söylemiyorum, beklentilerinizi aklı başında tutun ve verdiğiniz sözleri yerine getirmenin nihai olarak SİZ ve yalnızca siz ve ekibiniz olduğunu bilin diyorum.

Bu soyut olmayan terimlerle ne anlama geliyor? Hangi veri depolarının oluşturduğunuz şeyin bir parçası olacağı konusunda sağlam bir fikriniz olduğunda, işe bu veri depolarının zayıf yönlerini bilmekle başlamalısınız. Bu zayıflıklar aşağıdakileri içerir ancak bunlarla sınırlı değildir:

• Bu veri deposu, tarama sorguları altında iyi çalışır mı?
• Bu veri deposu, veri çoğaltma için bir dedikodu protokolüne mi dayanıyor? öyleyse, ağ bölümlerini nasıl işler? Bu dedikoduda ne kadar veri var?
• Bu veri deposunun tek bir arıza noktası var mı?
• Topluluktaki sürücüler onunla konuşmak için ne kadar olgun ya da kendi aracınızı sürmeniz mi gerekiyor?
• Bu liste çok büyük olabilir

Hala listenizde bulunan potansiyel çözümlerin zayıf yönleri üzerinde düşünmek, listeden daha fazla seçeneği silecektir. Bu artık teknolojinin yüksek vaatlerini karşılayan gerçek.

Hesap tablosu ve fırından çıkın!

Seçenekler listeniz küçük bir avuç haline geldiğinde, hepsini bir elektronik tabloya koymanın ve biraz daha derine inmeye başlamanın zamanı geldi. Bir artılar sütununa ve bir eksiler sütununa ihtiyacınız var ve bu noktada, belirli görevlerin nasıl yapılacağına ilişkin önemli ayrıntıları bulmak için her bir veritabanı belgesinde biraz zaman harcamanız gerekecek.

Bu, büyük bir büyüme oranına sahip olmasını beklediğiniz verilerse, bu seçeneklerden hangisinin ölçeğini genişletmenin daha kolay olduğunu bilmeniz gerekir. Bu, çok fazla bulanık arama yapan bir özellikse, hangi veri deposunun taramaları veya çok sayıda satırda aramayı daha iyi ve hangi tasarımla gerçekleştirebileceğini bilmeniz gerekir. Bu aşamadaki hedef, yalnızca dokümantasyon yoluyla listeyi ideal olarak 2 veya 3 seçeneğe indirgemektir, çünkü bu yeni özellik şirketin başarısı için yeterince kritikse, üçünü de karşılaştırmanız gerekecektir.

Neden kıyaslama diyorsun? Çünkü hiçbir 2 şirket aynı veri deposunu aynı şekilde kullanmaz. Çünkü bazen belgeler, yalnızca diğer insanların savaş hikayelerinde açığa çıkan uyarıları ima eder.

Çünkü bu veri deposunun istikrarına, güvenilirliğine ve öngörülebilirliğine sizden başka kimse sahip değil.

Karşılaştırma ölçütünüzü önceden tasarlayın. İdeal olarak, üretim düzeyi spesifikasyonlarıyla listenizdeki veri depolarının tam bir örneğini kurar ve yük testini gereksiz kılmak için çok küçük olmayan test verileri üretirsiniz. Yalnızca 'normal yük' için kıyaslama yaptığınızdan emin olun, aynı zamanda bazı arıza senaryolarını da test edin.

Umut, kıyaslama yoluyla, tüm kod yazıldığında ve artık yangın tatbikatı aşamasında çok fazla zamanınız olduğunda, daha sonra değil, şimdi seçenek listesini tekrar ziyaret etmenize neden olacak kadar ciddi uyarıları öğrenebilirsiniz. ve yaptığınız seçime adanmış çaba.

Seçiminizi belgeleyin

Ne yaparsanız yapın, tercihinize hangi yöntemle ulaştığınızı ve o karara giden yolda incelenen alternatifleri belgelemeli ve dahili olarak yayınlamalısınız. Bu yeni özelliğin ve tüm bileşenlerinin nasıl oluşturulacağına dair kapsamlı bir mimari planı olduğunu varsayarsak, ekibin aldığı karara ulaşmak için yapılan tüm kıyaslamalara bağlantılarla bu yeni özelliği destekleyen veri deposuna ayrılmış bir bölüm oluşturduğunuzdan emin olun. .

Bu, yalnızca gelecekteki yeni işe alımların yararına değil, aynı zamanda ekibinizin de şimdiki yararınadır. İnsanların eşzamansız olarak okuyabildiği ve üzerinde görüş geliştirebileceği bir belge, karar sürecini şeffaf tutmanın, ekip üyeleri arasında bir en iyi niyet duygusunu geliştirmenin ve öngörmediğiniz bakış açılarından eleştiri getirmenin bir yolunu sağlar.

paket servisler

Bu adımlar, yalnızca iş teklifini büyütürken verilere dayalı kararlara yol açmayacak, aynı zamanda sağlam bir altyapıya ve ödemenize değer sağlamak için sürekli büyüyen bir teknoloji alanını ne zaman ve nerede kullanacağınız konusunda daha disiplinli bir yaklaşıma yol açacaktır. müşteriler.