Hangisi daha iyi – Oracle veya Redis veya Platform seçimi nasıl gerekçelendirilir?

Kimseye hitap etmeden yüksek sesle, "Bu gerekli," dedi. - Bu gerekli! Tam olarak şunu söylüyor: Bir şirketin asıl görevi, hissedarların çıkarları doğrultusunda kar elde etmektir. Peki bunun hakkında düşün! Hiçbir şeyden korkmuyorlar!

Yuliy Dubov, “Daha Az Kötü”

Böyle bir manşet gördüğünüzde muhtemelen makalenin ya aptallık ya da provokasyon olduğuna karar vermişsinizdir. Ancak aceleyle sonuca varmayın: Büyük şirketlerin çalışanları, özellikle de devlet katılımı olan şirketler, çoğu zaman tamamen farklı platformlar da dahil olmak üzere farklı platformları - örneğin başlıktakileri - karşılaştırmak zorunda kalır.

Hangisi daha iyi – Oracle veya Redis veya Platform seçimi nasıl gerekçelendirilir?

Elbette hiç kimse DBMS'leri bu şekilde karşılaştıramaz çünkü güçlü ve zayıf yönleri iyi bilinmektedir. Kural olarak bazı uygulama sorunlarını çözen platformlar karşılaştırmaya tabi tutulur. Makalede bu durumda kullanılan metodolojiyi, Habr okuyucularının ilk elden aşina olduğu bir konu olan veri tabanları örneğini kullanarak göstereceğim. Bu yüzden,

Motivasyon

Bir eğitim projesine veya bir hobi projesine başladığınızda, bir platform seçme motivasyonu çok çeşitli olabilir: "En iyi bildiğim platform bu", "Bunu anlamakla ilgileniyorum", "en iyi dokümantasyon burada" ... Ticari bir şirket durumunda seçim kriteri aynı: Ne kadar ödemem gerekecek ve bu paranın karşılığında ne alacağım.

Doğal olarak daha az ödeyip daha fazlasını almak istersiniz. Ancak neyin daha önemli olduğuna karar vermeniz, daha az ödemenin mi yoksa daha fazla almanın mı ve her düğüme bir ağırlık atamanız gerekir. Bizim için kaliteli çözümün ucuz çözümden daha önemli olduğunu varsayalım ve “Maliyet” düğümüne %40, “Fırsatlar” düğümüne ise %60 ağırlık atayacağız.

Hangisi daha iyi – Oracle veya Redis veya Platform seçimi nasıl gerekçelendirilir?

Büyük şirketlerde genellikle bunun tersi doğrudur; maliyet ağırlığı %50'nin altına düşmez ve belki %60'ın üzerine çıkmaz. Model örneğinde önemli olan herhangi bir ana düğümün alt düğümlerinin toplam ağırlığının %100 olması gerektiğidir.

Kesme koşulları

web sitesi db-engines.com Bilinen 500'e yakın veritabanı yönetim sistemi bulunmaktadır. Doğal olarak, bu kadar çok seçenek arasından bir hedef platform seçerseniz, bir inceleme makalesi ile karşılaşabilirsiniz, ancak ticari bir proje olamaz. Seçim alanını azaltmak için kesme kriterleri formüle edilir ve platform bu kriterleri karşılamıyorsa dikkate alınmaz.

Kesme kriterleri teknolojik özelliklerle ilgili olabilir, örneğin:

  • ASİT garantileri;
  • ilişkisel veri modeli;
  • SQL dil desteği (bunun "ilişkisel model" ile aynı olmadığını unutmayın);
  • yatay ölçeklendirme imkanı.

Genel kriterler olabilir:

  • Rusya'da ticari desteğin mevcudiyeti;
  • açık kaynak;
  • platformun Telekom ve Kitle İletişim Bakanlığı Sicilinde bulunması;
  • platformun bazı derecelendirmelerde bulunması (örneğin, db-engines.com derecelendirmesinin ilk yüzünde);
  • pazardaki uzmanların varlığı (örneğin, hh.ru web sitesindeki bir özgeçmişte platformun adını aramanın sonuçlarına dayanarak).

Sonuçta kuruma özel kriterler olabilir:

  • personelde uzmanların mevcudiyeti;
  • tüm desteğin dayandığı izleme sistemi X veya yedekleme sistemi Y ile uyumluluk...

En önemli şey, kesme kriterlerinin bir listesinin olmasıdır. Aksi takdirde, yönetimin özel güvenini kazanan ve “neden Z platformunu seçmediniz, biliyorum en iyisi” diyen bir uzman (ya da “uzman”) mutlaka çıkacaktır.

Maliyet tahmini

Çözümün maliyeti elbette lisans maliyetinden, destek maliyetinden ve ekipman maliyetinden oluşuyor.

Sistemler yaklaşık olarak aynı sınıftaysa (örneğin, Microsoft SQL Server ve PostgreSQL), basitlik açısından her iki çözüm için ekipman miktarının yaklaşık olarak aynı olacağını varsayabiliriz. Bu, ekipmanı değerlendirmenize gerek kalmayacak, böylece çok fazla zaman ve emekten tasarruf edeceksiniz. Tamamen farklı sistemleri karşılaştırmanız gerekiyorsa (örneğin, Oracle ve Redis), o zaman doğru bir değerlendirme için boyutlandırmanın (ekipman miktarının hesaplanması) yapılması gerektiği açıktır. Var olmayan bir sistemi boyutlandırmak çok nankör bir iştir, bu yüzden hala bu tür karşılaştırmalardan kaçınmaya çalışıyorlar. Bunu yapmak kolaydır: kesme koşullarında sıfır veri kaybı ve ilişkisel bir model yazılır veya tam tersi - saniyede 50 bin işlem yükü.

Lisansları değerlendirmek için satıcıdan veya ortaklarından sabit sayıda çekirdek lisansının maliyetini ve sabit bir süre boyunca desteği istemek yeterlidir. Kural olarak şirketlerin yazılım satıcılarıyla zaten güçlü ilişkileri vardır ve eğer veri tabanı operasyon departmanı maliyet sorusunu tek başına cevaplayamıyorsa bu bilgiyi almak için bir mektup yeterlidir.

Farklı satıcıların farklı lisanslama ölçümleri olabilir: çekirdek sayısına, veri hacmine veya düğüm sayısına göre. Yedek baz ücretsiz olabilir veya ana bazla aynı şekilde lisanslanabilir. Metriklerde herhangi bir farklılık tespit edilirse model standını detaylı bir şekilde tanımlamanız ve standın lisans maliyetini hesaplamanız gerekecektir.

Doğru bir karşılaştırma için önemli bir nokta aynı destek koşullarıdır. Örneğin, Oracle desteği yıllık lisans fiyatının %22'sine mal olur ancak PostgreSQL desteği için ödeme yapmanız gerekmez. Bu şekilde kıyaslamak doğru mu? Hayır, çünkü kendi başınıza düzeltilemeyen bir hatanın tamamen farklı sonuçları vardır: ilk durumda, destek uzmanları sorunu hızlı bir şekilde düzeltmenize yardımcı olacaktır, ancak ikinci durumda, projenin gecikmesi veya bitmiş projenin aksama süresi riski vardır. Sistem süresiz olarak geçerlidir.

Hesaplama koşullarını üç şekilde eşitleyebilirsiniz:

  1. Oracle'ı desteksiz kullanın (gerçekte bu olmaz).
  2. PostgreSQL desteğini satın alın - örneğin Postgres Professional'dan.
  3. Destek eksikliğinden kaynaklanan riskleri dikkate alın.

Örneğin, bir risk hesaplaması şu şekilde görünebilir: Ölümcül bir veritabanı arızası durumunda sistem kesintisi 1 iş günü olacaktır. Sistemin kullanılmasından elde edilmesi öngörülen kar yıllık 40 milyar MNT, kaza oranının ise 1/400 olduğu, dolayısıyla destek eksikliği riskinin yıllık yaklaşık 100 milyon MNT olduğu tahmin ediliyor. Açıkçası, "planlanan kâr" ve "tahmini kaza sıklığı" sanal değerlerdir, ancak böyle bir modele sahip olmak, hiç sahip olmamaktan çok daha iyidir.

Gerçekte sistem, uzun vadeli kesinti süresinin itibar maliyeti açısından kabul edilemeyecek kadar önemli olabilir; bu nedenle desteğe ihtiyaç duyulacaktır. Kesinti süresine izin veriliyorsa desteği reddetmek bazen paradan tasarruf etmenin iyi bir yolu olabilir.

Tüm hesaplamalar sonucunda A platformunun 5 yıllık işletme maliyetinin 800 milyon MNT, B platformunun işletme maliyetinin 650 milyon MNT, C platformunun işletme maliyetinin ise 600 milyon MNT olduğunu varsayalım. Kazanan olarak Platform C, fiyat karşılığında tam puan alırken, A ve B platformları, kaç kat daha pahalı olduklarıyla orantılı olarak biraz daha az puan alıyor. Bu durumda sırasıyla 0.75 ve 0.92 puan.

Fırsat değerlendirmesi

Fırsatların değerlendirilmesi birçok gruba ayrılır ve bunların sayısı yalnızca değerlendirmeyi yapan kişinin hayal gücüyle sınırlıdır. En uygun seçenek, yetenekleri bu yetenekleri kullanacak ekiplere bölmek gibi görünüyor; örneğimizde bunlar geliştiriciler, yöneticiler ve bilgi güvenliği görevlileridir. Bu fonksiyonların ağırlıklarının 40:40:20 olarak dağıtıldığını varsayalım.

Geliştirme işlevleri şunları içerir:

  • veri işleme kolaylığı;
  • ölçeklendirme;
  • ikincil indekslerin varlığı.

Kriter listesi ve ağırlıkları oldukça subjektiftir. Aynı problemi çözerken bile bu listeler, madde ağırlıkları ve cevaplar, ekibinizin yapısına bağlı olarak önemli ölçüde farklılık gösterecektir. Örneğin, Facebook veri depolamak için MySQL'i kullanıyor ve Instagram Cassandra üzerine kurulu. Bu uygulamaların geliştiricilerinin bu tür tabloları doldurması pek olası değildir. Mark Zuckerberg'in tam teşekküllü bir ilişkisel model seçtiği ve bunun bedelini uygulamalı parçalama ihtiyacıyla ödediği, Kevin Systrom'un ise verilere erişim kolaylığından ödün vererek platformu kullanarak ölçeklendirme oluşturduğu tahmin edilebilir.

Yönetim işlevleri şunları içerir:

  • yedekleme sistemi yetenekleri;
  • izleme kolaylığı;
  • kapasite yönetimi kolaylığı – diskler ve düğümler;
  • veri çoğaltma yetenekleri.

Soruların niceliksel bir şekilde ifade edilmesi gerektiğini lütfen unutmayın. Belirli bir işlevin nasıl değerlendirileceği konusunda bile anlaşabilirsiniz. Örneğin, Oracle DBMS ile birlikte sağlanan araç örneğini kullanarak yedekleme araçlarını derecelendirmeye çalışalım:

Araç
Yorumlamak
Değerlendirme

göstr/exp
Verileri yükleme ve yükleme
0.1

yedeklemeyi başlat/sonlandır
Dosyalar kopyalanıyor
0.3

RMAN
Artımlı kopyalama yeteneği
0.7

ZDLRA
Yalnızca artımlı kopyalama, noktaya en hızlı kurtarma
1.0

Açık bir değerlendirme kriteri yoksa, birkaç uzmandan derecelendirme vermesini istemek ve ardından bunların ortalamasını almak mantıklı olacaktır.

Son olarak bilgi güvenliği fonksiyonlarını basitçe listeliyoruz:

  • şifre yönetimi politikalarının mevcudiyeti;
  • harici kimlik doğrulama araçlarına (LDAP, Kerberos) bağlanma yeteneği;
  • erişimin rol modeli;
  • denetim yetenekleri;
  • diskteki verilerin şifrelenmesi;
  • ağ üzerinden iletim sırasında şifreleme (TLS);
  • yöneticiden veri koruması.

Performans testi

Ayrıca, sizin tarafınızdan yapılmayan herhangi bir yük testinin sonuçlarının argüman olarak kullanılmasına karşı uyarmak isterim.

Öncelikle test edilen uygulamaların veri yapısı ve yük profili, çözeceğiniz problemden önemli ölçüde farklı olabilir. Yaklaşık 10-15 yıl önce, veritabanı satıcıları TPC testlerinde elde edilen sonuçları göstermeyi severdi, ancak görünen o ki artık kimse bu sonuçları ciddiye almıyor.

İkinci olarak, sistem performansı büyük ölçüde kodun orijinal olarak hangi platform için yazıldığına ve testin hangi ekipmana yapıldığına bağlıdır. Oracle'ın PostgreSQL ile karşılaştırıldığı birçok test gördüm. Sonuçlar bir sistemin koşulsuz üstünlüğünden diğerinin eşit derecede koşulsuz üstünlüğüne kadar değişir.

Ve son olarak üçüncüsü, testi kimin yaptığı hakkında hiçbir şey bilmiyorsunuz. Her iki nitelik de önemlidir; işletim sisteminin ve platformun kurulumunun kalitesinin yanı sıra test sonuçlarını diğer tüm faktörlerden daha fazla etkileyen motivasyonu da etkiler.

Performans kritik bir faktörse testi kendiniz, tercihen üretim sistemini yapılandıracak ve bakımını yapacak kişilerin yardımıyla gerçekleştirin.

sonuç

Son olarak, yapılan tüm çalışmaların sonucu, tüm tahminlerin birleştirildiği, çarpıldığı ve toplandığı bir elektronik tablo olmalıdır:

Hangisi daha iyi – Oracle veya Redis veya Platform seçimi nasıl gerekçelendirilir?

Anladığınız gibi ölçekleri değiştirerek ve derecelendirmeleri ayarlayarak istediğiniz sonuca ulaşabilirsiniz, ancak bu tamamen farklı bir hikaye...

Kaynak: habr.com

Yorum ekle