Çalışma İstatistikleri Bürosu'na göre, veri mimarisini ve veritabanlarını yönetmeyle ilgili işlerin görünümü oldukça iyi görünüyor: Verileri yönetmeyle ilgili rollere sahip profesyonellerin sayısı büyümek nedeniyle 2022'den 2032'ye kadar yüzde sekiz. Ancak veriler üzerinde çalışan rollerin sayısı artarken, tek başına veritabanı yöneticisinin (DBA) konumu aslında düşüyor. Bunun yerine, DBA uzmanı rolünün yerini DevOps dünyasının site güvenilirliği mühendisi (SRE) aldı. 

Google'da geliştirilen SRE rolü, web sitesi yönetimi ve operasyonları konusundaki becerilerini teknolojinin diğer alanlarına uyguladı. SRE'ler, bir DBA'nınkinden çok daha geniş bir iş kapsamına sahiptir; operasyonel yönetim, kullanılabilirlik, sistem yedekliliği ve güvenlik gibi aynı türden görevleri kapsar, ancak yalnızca mevcut veritabanlarını değil, tüm BT altyapısını kapsar. Ancak DBA'ların gerçekleştirdiği görevler azalmadı ve DBA'ların diğer çalışanların anlayamadığı bazı nüanslar var.

DBA'lar Hangi Sorunlarla Karşılaşıyor? 

SRE'lerin çoğunluğu veritabanı örneklerini yönetebilecek ve çalışır durumda tutabilecek olsa da, veritabanı teorisi ve yönetimi üzerine yoğunlaşmış birinin sahip olacağı deneyim ve bilgi derinliğine sahip olmayacaklar. Sıra dışı bir şey olduğunda, SRE'lerin neler olduğunu ve sorunu çözüp çözemeyeceklerini veya bir uzman çağırmaları gerekip gerekmediğini anlaması gerekecek.

Bunun iyi bir örneği, nasıl kurulacağı ve yönetileceğidir. Yapılandırılmış sorgu diliveya SQL'i seçin. SQL, IEEE'nin 2023'teki en popüler dili olabilir, ancak çok az kişinin kendisini uzmanlaşmaya adaydığı karmaşık bir sözdizimine sahiptir. Çoğu geliştirici, etkili ve verimli SQL sorgularının nasıl yazılacağına aşina değildir, bu nedenle, sonuçların döndürülmesi daha uzun süren, düşük performans gösteren isteklerle karşılaşabilirler. Alternatif olarak geliştiriciler, SQL isteklerini yerine getirmek için sıklıkla Nesne İlişkisel Haritalayıcılara (ORM'ler) başvuruyor. ORM'ler geliştiriciler için durumu daha basit hale getirse de, kendi SQL kodunuzu yazarken görülen düşük performans ve kötü sorgu tasarımından ve ORM'nin kendisini güncelleme ve yönetme ihtiyacından muzdarip olabilirler. Bu kombinasyon genellikle performansı engelleyen uzun süreli işlemleri kullanma eğilimiyle birlikte görülüyor. 

DBA'lar için bu sorunları tespit etmek ve düzeltmek tam zamanlı işin bir parçasıydı. Ancak veritabanı performansına aşina olmayan SRE'ler için bu yavaş işlemler, bir şeylerin ters gittiğinin belirtisi olmaktan ziyade "işlerin nasıl olduğu" olarak kabul edilebilir. Alternatif olarak geliştiriciler, çalıştırılacak daha büyük makineler veya bulut örnekleri satın alarak soruna daha fazla kaynak ayırmayı deneyebilirler.

Sorgu tasarımının yanı sıra DBA'lar veritabanlarında veri dizinleri oluşturmaktan da sorumluydu. Verileri indekslemek, aşırı indeksleyen veya yetersiz indeksleyen birçok kişi için Harry Potter benzeri karanlık bir sanattır ve bu da düşük performansa yol açar. Geçmişte, DBA'lar artık kullanılmayan gereksiz dizinleri veya dizine eklenmemiş popüler sorguları arar ve daha sonra daha iyi performans için veritabanını düzeltirdi. 

Son olarak DBA'lar, ANALYZE TABLE'ı kullanarak zaman içindeki performansı izlemek için sorguları kendileri çalıştırmaktan sorumlu olacaktır. Bu, optimize ediciye ilişkin istatistikleri güncel tutacak ve değişiklik veya eklemelerin performans düzeylerini etkilediği alanları işaretleyecektir. Bu öngörü olmadan SRE'ler, en iyi ihtimalle artık ihtiyaç duyulmayan veya en kötü ihtimalle performansı olumsuz yönde etkileyen endeksleri yerinde bırakabilir. 

Ahead Planlama

Veritabanlarının operasyonel tarafında da yeniden öğrenilmesi gereken dersler var. Örneğin, bir DBA'nın yalnızca son yedeklemesi kadar iyi olduğuna dair eski bir söz vardır. Bir sorundan sonra hiçbir zaman verileri kurtarmanıza gerek kalmayacağını umsanız da, herhangi bir kritik dosya için çalışır durumda ve tamamen test edilmiş bir yedeğe sahip olmak çok önemlidir. Veritabanları dünyasında, birçok SRE artık bunu kendileri adına yürütmek için bulut sağlayıcılarına güveniyor. Ancak bu yeterli olmak için yeterli mi? 

Hizmet Düzeyi Sözleşmenizin yedekleme ve geri yükleme süreciyle ilgili olarak ne ifade ettiğini belirtebilirsiniz ancak bu, bir sorun sonrasında ne kadar hızlı bir şekilde yedeklenip çalışır duruma gelebileceğinizi doğru şekilde yansıtmayabilir. Öncelikle bu SLA, yedeğinizin iyi olmasına ve ondan tamamen kurtulabilmenize bağlıdır. Bir yedeklemeyi gerçekten yükleyip bu verileri yeniden kullanmaya başlayana kadar operasyonlarınızı tam olarak koruduğunuzdan emin olamazsınız. İkinci olarak, SLA süreniz, çevrimdışı kalarak işlem yapmamak için ayırabileceğiniz süreden çok farklı olabilir. Veri kaybını tespit etmek ve onu iyi bir duruma döndürmek eskiden DBA'nın göreviydi. Bir bulut hizmet sağlayıcısı, verileriniz için SLA'larının ne olduğunu size söyleyebilir ancak dahili hizmet gereksinimlerinizi karşılamak için ihtiyaç duyduğunuz her şeyi mutlaka sağlayamayabilir.

Benzer şekilde, veritabanı tablolarının yapılandırılması, verilerin nasıl yönetildiğine ilişkin çok fazla bilgi gerektirir. Geliştiriciler, uygulamaları için ihtiyaç duydukları verileri depolamak, sıralamak ve döndürmek için veritabanlarının nasıl kullanılabileceğini anlayabilse de, zaman içinde bu verilerden en iyi şekilde yararlanmak için tabloların nasıl düzgün şekilde hizalanacağı konusunda bazı nüanslar vardır. Bunun yanı sıra ilişkisel modeli doğru bir şekilde anlamak, verilerin ayrı tablolara bölümlendirilmesinin performansın düşmesine neden olduğunu anlamanıza yardımcı olur. Bu örnekleri doğrudan yönetmenin bir parçası olarak öğreneceğiniz veritabanına özgü püf noktaları da vardır; örneğin, çoğu kişi MySQL'in artık her tabloda birincil anahtarlara sahip olmanızı istediğini veya sütunlar varsa PostgreSQL'in tabloları doldurması gerekebileceğini bilmiyor. sekiz baytlık bir sınıra pek uymuyor. 

Veri Yönetiminin Geleceği

Veriler şirketler için giderek daha önemli hale geliyor. Müşterilere verimli bir şekilde hizmet vermenin temelini oluşturur, ancak aynı zamanda yeni ürünlerde kullanılan yeni iş hizmetlerinin veya derin analitik projelerinin de merkezinde yer alır. Bu veriler olmadan, bu ürünler ve bunların getirdikleri gelir ya mevcut olmaz ya da sağlamak üzere tasarlandıkları değeri sağlayamaz.

Aynı zamanda, veri yönetimiyle ilgili beceriler kuruluşlardan sızıyor, daha geniş rollere dahil ediliyor veya hizmet sağlayıcılara devrediliyor. Her şey çalışırken bu sorun değil. Ancak bir sorun ortaya çıktığında, sorunu çözmek ve bunun bir daha olmayacağından emin olmak için bu derinlemesine bilgiye ihtiyacınız olacak. Bu aynı zamanda, tuttuğunuz verileri korumak ve bu verilerle ilgili çalışmalar yürütmek için ihtiyacınız olandan daha fazlasını harcayabileceğiniz anlamına da gelir.

DBA'nın rolü DevOps ve SRE çevresindeki daha yeni pozisyonlar tarafından devralınmış olsa da, bu rolle ilişkili görevler hâlâ bizdedir. SRE ve DevOps profesyonelleri için veri teorinizi bilmek, altyapıya para harcamak ile performanstan tasarruf etmek arasındaki farkı yaratabilir.

• SEO Destekli İçerik ve Halkla İlişkiler Dağıtımı. Bugün Gücünüzü Artırın.
• PlatoData.Network Dikey Üretken Yapay Zeka. Kendine güç ver. Buradan Erişin.
• PlatoAiStream. Web3 Zekası. Bilgi Genişletildi. Buradan Erişin.
• PlatoESG. karbon, temiz teknoloji, Enerji, Çevre, Güneş, Atık Yönetimi. Buradan Erişin.
• PlatoSağlık. Biyoteknoloji ve Klinik Araştırmalar Zekası. Buradan Erişin.
• Kaynak: https://www.dataversity.net/devops-and-data-lessons-teams-can-learn-about-managing-databases/