[ad_1]
Yazılım geliştiricilerin bugün kendilerine açık olan daha fazla seçeneği var. Yeni uygulamaları hızla oluşturmalarına, ardından bu hizmetleri dünya çapındaki müşterilere sunmalarına ve ardından artan talebi karşılamak için bunları ölçeklendirmelerine yardımcı olabilecek araçlara ve hizmetlere sahiptirler. Mikro hizmet mimarileri ve çevik geliştirme, müşteri ihtiyaçları ve iş ihtiyaçlarının karşılanması gerektiğinde daha hızlı hareket etmeye ve yeni hizmetler sunmaya vurgu yapar.
Bu aynı zamanda veriler için de geçerlidir. Geliştiriciler, uygulamalarının oluşturduğu verileri desteklemelidir ve bu, bir veritabanı uygulamak anlamına gelir. Doğru tasarımı seçmek, uygulamada tüm farkı yaratabilir; uygulamanın zaman içinde kullanılabilir, performanslı ve ölçeklenebilir olmasını sağlamaya yardımcı olur. Ancak geliştiriciler, veritabanlarını kendileri uygulamak ve yönetmek zorunda kalmak istemezler. Bu yüzden şirketlerin çoğunluğu – yüzde 90, IDC’ye göre— veritabanlarını ve veri iş yüklerini buluta taşımanın ortasındalar.
Bu firmalar için birçok farklı seçenek mevcuttur. Bunlara yönetilen hizmetler, bulut tabanlı veritabanı yüklemeleri ve hizmet olarak veritabanı (DBaaS) teklifleri dahildir. Bu hizmetlerin tümü, veri yönetimi yükünü hafifleteceklerini ve geliştiricilerin yeni uygulamaları ve uygulama güncellemelerini daha hızlı gönderme hedeflerine ulaşmalarına yardımcı olacağını vaat ediyor. “Şemasız” ve “tamamen yönetilen” gibi ifadeler, veritabanlarının devredilebilir gibi görünmesini sağlayarak geliştiricileri bir gönül rahatlığı duygusuna kaptırabilir.
Gerçekte, geliştiriciler, özellikle tasarım seçenekleri ve veritabanının nasıl uygulanacağı söz konusu olduğunda, geleneksel şirket içi sistemlerde olduğu kadar bulut altyapısından da sorumludur. Bu, yalnızca DBaaS ürünlerinin varsayılan ayarlarının uygulamaları için doğru olduğuna güvenmeyi içermez.
Doğru veritabanını seçmek
Bu nedenle geliştiriciler ve uygulama mimarları, uygulama projeleri için uzun vadeli geleceğe bakmalı ve bu projelerin sahip olacağı temel gereksinimleri anladıklarından emin olmalıdır. İlk soru, proje için hangi veritabanı tasarımının kullanılacağıdır.
Bugün o kadar çok veritabanı seçeneği mevcut ki, seçenekler hızla bunaltıcı hale geliyor. bu DB Motorları Sıralaması Örneğin, 359 farklı veritabanını listeler, bu nedenle zaten bildiğiniz bir veritabanını veya ne sunacağı konusunda kapsamlı sözler veren bir veritabanını kullanmak için pek çok cazibe vardır. MongoDB’yi uyguladıysanız, diyelim ki, neden aynı veritabanını bir sonraki projeniz için kullanmıyorsunuz?
Ancak, bir uygulamada işe yarayan şeyin başka bir uygulamada işe yarayacağının garantisi yoktur. Grafik ve zaman serisi veritabanları gibi belirli kullanım durumları için daha uygun veri tabanları ve veri yönetimi yaklaşımları vardır ve kullanılacak programlama diline veya yazılım geliştirme kaynaklarına bağlı olarak daha uygun olabilecek başkaları da vardır. Uygun olmayan bir veritabanı dağıtımını bir kullanım durumuna uydurmaya zorlamak mümkün olsa da, yanlış seçim performansı ciddi şekilde azaltabilir ve maliyetleri artırabilir.
Doğru veritabanını seçmek, bir uygulama iş yükünün zaman içinde nasıl performans göstereceğini, nasıl büyüyeceğini ve erişim modellerinin nasıl değişebileceğini anlamayı içerir. Herhangi bir veritabanı uygulaması büyüdükçe, daha fazla sorguyu ve daha fazla depolanan veriyi işlemesi gerekecektir. Başlangıçta doğru yaklaşımı uygulamaya koymak, bu verilere karşı daha fazla sorgunun işlenmesini kolaylaştırabilir. Bunu göz ardı etmek ve sizin adınıza yönetmek için veritabanı hizmetine güvenmek başlangıçta iyi sonuç verebilir, ancak yolun aşağısındaki performansı ve maliyeti önemli ölçüde etkileyebilir. Önceden planlamaya zaman ayırmak, bu nedenle uzun vadede önemli maliyet düşüşlerine yol açabilir.
Veritabanı tasarımı hakkında nasıl düşünülür?
Şemasız bir yaklaşım benimsemek birçok geliştiriciye hitap ediyor. Sonuçta, verileri düzenleme işini veritabanı hizmetine bırakırsanız, bunu yapmanız gerekmez. Ancak, durum gerçekten böyle değil. Tüm veritabanı sağlayıcıları, hatta JSON veya nesne ekleme yeteneği kullanan “şemasız” yaklaşımlar sunanlar bile, bir tür şema doğrulamasını teşvik eder. Şemasız veritabanları, bilgileri yapılandırılmamış veriler olarak depolar ve bu, uygulama büyüdükçe performans ve maliyet açısından önemli bir etkiye sahiptir.
Veritabanları büyüdükçe en küçük kararların bile büyük etkisi olabilir. Örneğin veri formatlarını alın. Başvurunuzda, birinin hangi ülkede yaşadığı gibi veri girişlerini kabul edecek bir formunuz olduğunu hayal edin. Hangi formatı kullanmalısınız?
Ülke adlarının uzunluğu değişiklik gösterecektir, bu nedenle giriş için ortalama 12 karakter olduğunu varsayalım. Bu verileri değişken bir karakterde saklamak (varchar
) biçimi, karakter başına üç bayt veya her giriş için toplamda 39 bayt alacaktır. Bu kulağa çok büyük gelmiyor, ancak bunu kullanarak karşılaştıralım int
veya enum
aynı alan için: Bir int
her giriş için toplamda yalnızca dört bayt gerektirirken, bir enum
sadece bir bayt alır. Bunu 100 milyon veri noktasına kadar ölçeklendirin ve varchar
seçeneği 3700 megabayt (MB) yer kaplarken, enum
seçenek, %97,5’lik bir azalmayla 95MB gerektirir.
Sakladığınız veri miktarının, kullandığınız disk alanını artırmaktan daha büyük bir etkisi vardır. Çalışacak daha fazla veriye sahip olduğunuzda, normal olarak, bu verileri bellekte işlemek için kullandığınız makine görüntüsünü büyüteceksiniz. Verilere daha az verimli bir yaklaşım uygularsanız, verileri işlemek için CPU ve bellek kaynaklarını artırmanız gerekir. Diskte terabaytlarca veri depolamanın maliyeti nispeten ucuz olsa da, CPU maliyeti ve hesaplama süresi pahalıdır, bu nedenle mümkün olan en verimli yaklaşımı almaya çalışmalısınız.
Bunun yanında, veri erişim modellerini de dikkate almak önemlidir. Verileri nasıl aramayı planladığınız, veritabanınızı nasıl tasarladığınızı etkiler. Uygulamanız için ortak arama istekleri olmasını bekliyorsanız, performansı artırabilecek dizinler oluşturabilirsiniz. Benzer şekilde, kullanıcılarınızın davranışlarının zaman içinde değiştiğini ve belirli sorguların daha popüler hale geldiğini görebilirsiniz. Bunu yönetmek için, mevcut sorgular ve dizinler gelecekte ihtiyacınız olan şey olmayacağından bu kalıpları gözden geçirmelisiniz.
Buradaki önemli bir unsur, veritabanı tasarımının üzerinde düşünmenin potansiyel olarak zor olmasıdır. Ancak, olası uç durumları veya gelecekteki gereksinimleri karşılamaya çalışmak yerine dağıtımınızı olabildiğince basit tutarsanız, bunu kendiniz için çok daha kolay hale getirebilirsiniz. Şu anda gelecekteki ihtiyaçlara odaklanmak yerine, veritabanı şemanızı genişletmek veya dağıtımınızı gelecekte genişletmek her zaman mümkündür.
inşa etmeden önce düşünün
Kodlamaya başlamadan önce verdiğiniz karar, bir projenin ömrü boyunca verdiğiniz herhangi bir kararla karşılaştırıldığında, ölçeklenebilirliğiniz ve kararlılığınız üzerinde en büyük etkiye sahip olacaktır. Bu nedenle, verilerinize ve bu verileri yönetmek için neyi kullanmayı seçtiğinize uygun saygıyı göstermeniz önemlidir.
Tüm sorumluluğu bir bulut hizmetine veya üçüncü taraf bir sağlayıcıya devretmek yerine, neyi başarmak istediğinizi ve bu hedefe en iyi nasıl ulaşacağınızı anlayın. Ancak, bir hizmet seçerek bu kararın sorumluluğundan vazgeçmezsiniz ve performans ve maliyet için esneklikten ödün verirsiniz. Yalnızca daha fazla bulut kaynağı eklemek, ölçeği büyütmek için verimli bir yaklaşım değildir. Seçtiğiniz veritabanı ve tasarım seçenekleri, yeni uygulamanızın veya hizmetinizin zaman içinde ne kadar başarılı olacağı üzerinde etkili olacaktır.
Matt Yonkovit açık kaynak stratejisinin başıdır. Perkon.
–
New Tech Forum, ortaya çıkan kurumsal teknolojiyi benzeri görülmemiş bir derinlikte ve genişlikte keşfetmek ve tartışmak için bir alan sağlar. Seçim, önemli olduğuna inandığımız ve InfoWorld okuyucularının en çok ilgisini çeken teknolojileri seçmemize dayalı olarak özneldir. InfoWorld, yayın için pazarlama teminatı kabul etmez ve katkıda bulunan tüm içeriği düzenleme hakkını saklı tutar. Tüm sorularınızı [email protected] adresine gönderin.
Telif Hakkı © 2022 IDG Communications, Inc.
[ad_2]
Kaynak : https://www.infoworld.com/article/3665914/why-database-design-choices-matter-to-developers.html#tk.rss_all