Bugün başlamak,  .   Timescale'de Dinamik PostgreSQL veritabanları oluşturabilirsiniz  Dinamik   , hem sağlanan veritabanlarının hem de sunucusuz veritabanlarının sorunlarını çözen, bulut veritabanlarının doğal evrimidir. Yükünüze göre önceden tanımlanmış bir min/maks aralık dahilinde mevcut bilgi işlemlerinizi anında ölçeklendiren bir Zaman Ölçeği yeniliği olan dinamik bilgi işlem ile desteklenir. En yüksek seviyeye ulaşmak (ve bunun için her zaman ödeme yapmak) yerine artık bir işlem aralığı seçebilirsiniz: veritabanınız temel kapasitede çalışacak ve yalnızca ihtiyaç duyulduğunda en yüksek seviyeye anında erişecektir. Üssü satın al, zirveyi kirala. PostgreSQL  Bu, benzersiz bir fiyat performansı sağlar: Üretim iş yüklerini çalıştıran müşteriler, AWS RDS for PostgreSQL'den geçiş yaparken %10-20, AWS Aurora Serverless'tan geçiş yaparken ise %50-70 tasarruf sağlayacaktır.  Dinamik PostgreSQL'i bugün deneyebilirsiniz. Platforma 30 gün boyunca tam erişim sağlayan ücretsiz bir deneme sunuyoruz (kredi kartı gerekmez).  Dinamik PostgreSQL hizmeti oluşturmak için Timescale'de oturum açarken PostgreSQL seçeneğini seçmeniz yeterlidir:   Uygulamanız her zaman açık, veritabanınız neden olmasın?  Geleceğe Hoşgeldiniz.  Sorun 1: Geliştiriciler ihtiyaç duyduklarından çok daha fazla bilgi işlem sağlıyor  Geçtiğimiz birkaç yılda, Timescale'i ilk başlattığımızdan bu yana, geliştiricilerin veritabanlarını nasıl kullandıkları konusunda ön sırada yer aldık. Örneğin, sadece son birkaç ayda,  Insights ürünümüzün bir parçası olarak.   Bir trilyondan fazla sorguyu analiz ettik   Öğrendiğimiz bir şey, geliştiricilerin genellikle gerçekte ihtiyaç duyduklarından çok daha fazla bilgi işlem sağladıklarıdır.  Bir yandan bu mantıklı: Veritabanınız hakkında asla endişelenmek istemezsiniz. Çoğu veritabanı iş yükü, genellikle bazı değişkenlik veya patlamalarla birlikte süreklidir. Örneğin, geceleri daha fazla kullanılan bir oyun, gündüzleri daha fazla kullanılan bir iş uygulaması veya hafta sonları hafta içine göre daha fazla kullanılan bağlı bir ev cihazı.   Veritabanınızın kaynaklarının tükenmesini asla istemezsiniz. Veritabanınız maksimum kapasitedeyse, bu durum berbat bir müşteri deneyimine (veya hiç müşteri deneyimi olmamasına) yol açar. Bu nedenle çoğu geliştirici, zirve artı bir arabellek için provizyon sağlar. Bu, geliştiricilerin gerçekte ihtiyaç duyduklarından çok daha fazla bilgi işlem için ödeme yapmasına neden olur.  Öte yandan bu bize çılgınca geliyor. Kuruluşların ihtiyaç duyduklarından çok daha fazlasını harcamasında başka hangi iş kaynağı olabilir? Boşa harcanan bilgi işlem, boşa harcanan paraya eşittir.  Sorun 2: Sunucusuz veritabanları üretim iş yükleri için yetersiz kalıyor  Bazılarınız şu soruyu sorabilir: "Sunucusuz veritabanları ne olacak?"  Sunucusuz kavramı durum bilgisi olmayan iş yüklerinden doğmuştur. Kullanıcıların donanım konusunda endişelenmeye gerek duymadığı buluttaki sanal makinelerin başarısından sonra, uygulama sunucularını çalıştırma konusunda neden endişelendiklerini sordular. Sonuçta birçok kullanıcı yalnızca işlevleri çalıştırmak ve yalnızca bu işlevlerin çalıştığı süre boyunca ücretlendirilmek istiyordu. Ayrıca, işlevlerin gerektiği gibi etkinleştirilmesi kolay ve sorunsuzdur, çünkü bunlar neredeyse tam olarak vatansızdır. Sunucusuz ve hizmet olarak işlev veya FaaS, AWS Lambda'nın devralmasıyla popüler hale geldi.  Geliştiriciler daha sonra kendilerine şu soruyu sordular: "Veritabanımı kullanmadığım halde neden para ödeyeyim?" Asıl soru güzel: boşa harcanan kaynaklar çok büyük bir veritabanı sorunudur. Ve belirli bir sunucu örneğinde (örneğin, bir db.m6gd.2xlarge) bir AWS RDS veritabanı sağlama uygulaması kesinlikle modern veya esnek gelmiyor: sabit CPU, sabit bellek, sabit yerel disk. Çoğu zaman çoğu zaman yeterince kullanılmaz.  Ancak işlerin karmaşıklaştığı nokta burasıdır: veritabanları Lambda işlevlerinden çok farklıdır.   Günümüzde sunucusuz veritabanları, çoğu üretim iş yükü için iki ana nedenden dolayı yanlıştır:  Sunucusuz veritabanları ölçeklendirmenin yukarı ve aşağı, hatta sıfıra kadar uç noktalarına odaklanır.  Sunucusuz veritabanları, değişen taleplere (ve daha da kötüsü, çoğu zaman anlaşılması veya tahmin edilmesi zor olan fiyatlandırma modellerine) hizmet etmek için ayrılan kaynak "boşluğunu" hesaba katmak için çok daha yüksek fiyatlandırma sunar.  Sıcak bir konu olan "sıfıra ölçeklendirme" konusunu tartışarak başlayalım. Gerçek şu ki çoğu üretim veri tabanı sıfıra ölçeklendirmeye ihtiyaç duymaz ve aslında bundan faydalanmayacaktır.  Artık "sıfıra ölçeklendirmenin" anlamlı olduğu bazı kullanım durumları var. Örneğin, kavram kanıtlama demoları veya daha fazla hobi amaçlı uygulamalar. Veri kümenize karşı ara sıra geçici bir sorgu çalıştırma yeteneği (AWS Athena ve Google BigQuery, çok aralıklı kullanım için düşük maliyetli, sunucusuz bir bulut veri ambarı için güçlü bir örnek oluşturuyor). Bir başka uygun kullanım örneği, bir bulut geliştirme örneğini tamamlandığında yavaşlatmayı unutmaktan kaçınmak olabilir; üretim dışı bir veritabanını "otomatik olarak duraklatmanın" değeri vardır (her ne kadar bu, sunucusuz tarafından öngörülenden çok daha basit işlevsellik gerektirse de).   Ancak üretim veritabanınız için ve daha operasyonel ortamlarda? Sıfıra ölçeklendirmek istemezsiniz.  Sıfıra ölçeklendirme, yeniden başlatma sırasında "soğuk başlatma" anlamına gelir: boş veritabanı paylaşılan arabellekleri, boş işletim sistemi önbelleği, boş katalog önbellekleri (PostgreSQL durumunda).  (Evet, bazı sunucusuz veritabanları, veritabanının çalışmaya başlaması için gereken süreyi kısaltır, ancak bunu boş bir durumdan yaparlar. PostgreSQL gibi ilişkisel bir veritabanında, sıcak bir çalışma kümesinin yeniden oluşturulması dakikalar (veya daha uzun!) sürebilir, özellikle daha büyük veritabanları için.)  Pek çok sunucusuz veritabanının farklı bulut depolama mimarilerini benimsemesi nedeniyle, soğuk başlatma performansı darbesi daha da büyüktür; burada veritabanı sayfalarının uzak depolamadan belleğe getirilmesinin maliyeti ve gecikmesi daha da yüksektir. Bu genel giderler yine daha kötü performansa neden olur veya platform sağlayıcılarını daha fazla fiziksel kaynak kullanarak telafi etmeye zorlar (örneğin, Amazon Aurora veritabanları RDS'nin iki katı belleğe sahiptir), bu da sonuçta kullanıcılara yansıyan bir maliyettir.  Dolayısıyla birçok senaryoda sunucusuz veritabanları daha yüksek ve öngörülemeyen fiyatlara neden olur.  Örneğin, Aurora Serverless'ı Amazon RDS ile karşılaştırırsanız, Sunucusuz'da 8 vCPU bilgi işlem ve 500 GB depolamanın RDS'den %85 daha pahalı olduğunu görürsünüz (1.097 $'a karşılık 593 $). Ve bu, Aurora I/O Optimized'ı ve yalnızca altı ay önce piyasaya sürülen daha öngörülebilir depolama fiyatlarını kullanıyor. (Ancak burada bile, Aurora Serverless'in fiyatlarını opak "Aurora Kapasite Birimleri"ni karıştırarak belirlediğinden, gerçek işlem kapasitesinin sonucunu çıkarmamız gerekiyor; bu, en iyi bilgiye dayalı tahminlerimize göre 1 ACU = 0,25 vCPU'dur.)    Yakında bu sonuçları destekleyen eksiksiz bir kıyaslama yayınlayacağız. Bizi izlemeye devam edin. Editörün notu:  Daha önce, Aurora Standard ile kullanıcılar her dahili G/Ç işlemi için de ödeme yapıyordu; bu da tahmin edilmesi veya bütçelendirilmesi neredeyse imkansızdı. Birçok sunucusuz veritabanı bu tür okuma ve yazma işlemleri için ücret almaya devam ediyor. Aslında sunucusuz AWS Timestream'i karşılaştırdığımızda şunları gördük:  tüm bu yüksek marjinal maliyetler nedeniyle Timescale'e göre. Maliyetlerin öngörülemezliği ve değişkenliği endişesizliğin tam tersiydi.   100 kattan fazla artan maliyetler  Kısacası, sunucusuz veritabanları, iş yükleri arttıkça daha düşük performansa, öngörülemeyen faturalara ve yüksek maliyetlere eğilimlidir. Yalnızca ara sıra hızlanan aralıklı iş yükleri için çok uygundurlar ve bellek içi veri önbelleğe alma eksikliği nedeniyle soğuk başlatmaları tolere edebilirler.  Geliştirici ikilemi   Geldiğimiz nokta burası:  Birçok geliştirici, güvenilir performansları, kontrolleri ve anlaşılırlıkları nedeniyle üretim uygulamaları için provizyon içeren geleneksel DBaaS hizmetlerini hâlâ tercih ediyor ancak aşırı provizyon gerekliliğinden kaynaklanan israftan nefret ediyor.  Bazı geliştiriciler, görünüşteki maliyet tasarrufları, esneklikleri ve kullanım kolaylıkları nedeniyle sunucusuz veritabanlarını seçiyorlar, ancak performans artışından ve tahmin edilemeyen, belirsiz fiyatlandırmadan (genellikle tedarik edilen bir örnekten gizemli bir şekilde daha yüksek faturalarla sonuçlanan) nefret ediyorlar.  Geliştiriciler olarak bu seçeneklerin hiçbiri pek çekici değil! Daha iyisi için bir fırsat var.  Çözüm: Dinamik PostgreSQL'e Giriş  Bu yüzden Dinamik PostgreSQL'i geliştirdik.  Dinamik PostgreSQL, temelinizi tutarlı bir şekilde destekler ve ihtiyaç duyduğunuzda, tanımlanmış bir maksimum değere kadar hesaplamayı sorunsuz bir şekilde ölçeklendirir. Bu, onu genellikle üretim ayarlarında gördüğünüz sürekli iş yükü aralığı (tek tip, değişken veya patlamalı) için mükemmel kılar.  Dinamik PostgreSQL, PostgreSQL topluluğu ve ekosisteminin tüm avantajlarına ek olarak, %100 PostgreSQL'dir.  . Dinamik PostgreSQL oluşturmak için PostgreSQL'in dahili bileşenlerini değiştirmek yerine PostgreSQL altyapımızı nasıl çalıştıracağımız konusunda yenilikler yaptık. Bu, çatallı bir PostgreSQL sorgusu veya depolama motoru üzerinde çalışma korkusu olmadan PostgreSQL'in ve Timescale platformunun sunduğu her şeye erişmenizi sağlar.   Timescale'in veritabanı platformunun olgunluğu  Dinamik PostgreSQL ile iş yükü ihtiyaçlarınıza karşılık gelen bir işlem   (minimum ve maksimum CPU) seçersiniz. Bu bilgi işlem aralığı aynı zamanda çoğu DBaaS hizmetinin geleneksel olarak bilgi işlem aralığının "maksimum" ucunda sunduğuna eşdeğer etkili bellekle birlikte gelir. aralığı  CPU aralığınızın tabanı (minimum) tam olarak sağlanan DBaaS modeli gibi davranır: minimum CPU her zaman uygulamanızı çalıştırmak için hizmetinize ayrılmıştır. Yükünüz arttıkça (harici uygulamanızın talebi nedeniyle veya artımlı yedeklemeler veya tablo otomatik vakumlama gibi ara sıra dahili veritabanı görevleri nedeniyle) veritabanınız sıfır gecikmeyle CPU aralığınızın en üst noktasına (maksimum) kadar kullanabilir.  Sıfır gecikmeye nasıl ulaşırız? Dinamik bilgi işlem, diğer bazı sunucusuz veya otomatik ölçeklendirmeli veritabanı tekliflerinden farklı şekilde çalışır; bu nedenle, genellikle uzaktan geçişlerde gördüğünüz yavaş ölçeklendirmeyi (ve performans düşüşünü) içermez. Bunun yerine, altyapı yapılandırmamız ve iş yükü yerleştirme algoritmalarımız, veritabanlarının, yeniden başlatma veya yeniden yapılandırma olmadan temel düğümlerinde ölçeklenebilmesini sağlar. Örneğiniz her zaman ihtiyaç duyulduğunda maksimum işlemine erişebilir.  Ve en iyi yanı, yalnızca taban artı bunun üzerinde kullandığınız kadarını ödersiniz. Bir işlem aralığı seçme ve bu aralık arasında ölçeklendirme yapma şeklindeki bu modele "   " adını veriyoruz.  tabanı satın al, zirveyi kirala  Örneğin, 4-8 CPU seçeneğini tercih ederseniz her zaman hizmetinize ayrılmış 4 CPU'nuz ve 32 GB etkin belleğiniz olur. Bu her zaman iyi bir temel performans sağlar. Yükünüz arttığında, uygulamanız ihtiyaç duyduğu anda en fazla 8 CPU kullanabilir (kesirli CPU bazında ölçülür ve faturalandırılır) ve maksimum sınırınız buysa asla 8 CPU'dan fazlasını kullanmaz.  Dinamik model, veritabanınızı daha uygun maliyetli ve endişesiz bir şekilde "boyutlandırmanıza" olanak tanır. Standart talebinizin minimuma uyduğu bir bilgi işlem aralığı seçebilir, ancak gerektiğinde büyüyebilir veya zirveye (maksimum) çıkabilirsiniz. Bu maksimum değer, temel bilgi işlem seviyenizin üzerindeki herhangi bir kullanım için doğal bir sınır oluşturarak anlaşılması kolay bir maliyet tavanına yol açar. Ayrıca, hem temel hem de ölçülü kullanımınız için (kesirli) CPU saati başına aynı ücreti ücretlendiririz: Tabanınızın üzerinde kullanım için herhangi bir ek ücret alınmaz ve bu nedenle ölçeklendirme için herhangi bir fiyat cezası yoktur.  Son olarak, çok düşük veya çok yüksek bir boyut aralığı sağladığınızı fark ederseniz, işlem aralığınızı uygulamanızın ihtiyaçlarına daha uygun bir boyuta kolayca ayarlayabilirsiniz.   Paradan tasarruf etmenizi sağlayacak şekilde tasarlandı  Şu anda iş yükü boyutunuza bağlı olarak beş farklı işlem aralığı sunuyoruz ve anlık kullanımınıza bakılmaksızın aralık için aldığınız etkin belleğe karşılık geliyor.   Dinamik PostgreSQL aynı zamanda Timescale'in kullanıma dayalı depolama alanını da kullanır; burada, sağlanan disk boyutu için değil, yalnızca depolanan veri hacmi (GB-saat cinsinden) için ödeme yaparsınız. Aşırı sağlanan bir diskle para israfı konusunda endişelenmenize veya benzer şekilde disk alanınızın biteceğinden endişelenmenize gerek yok. Timescale'in dinamik bulut altyapısı, ihtiyacınız olduğunda yeterli depolama kapasitesine sahip olmanızı ve yalnızca kullandığınız kadar ödeme yapmanızı sağlar.  Paradan tasarruf etmenizi sağlamak için Dinamik PostgreSQL'i özellikle geliştirdik. Üretim iş yüklerini çalıştıran müşteriler genellikle AWS RDS for PostgreSQL'den geçiş yaparken %10-20, AWS Aurora Serverless'tan geçiş yaparken ise %50-70 tasarruf sağlar.  Ayın sonunda, faturanız iki basit, anlaşılması kolay ölçümden oluşur: (1) saatlik temel işlem artı bunun üzerindeki ancak zirve noktanızdan fazla olmayan kısmi CPU kullanımı olarak faturalandırılan işlem maliyetleriniz; ve (2) GB-saat cinsinden veri tüketimi olarak faturalandırılan depolama maliyetleriniz. Ölçülecek veya anlaşılacak yeni metrikler veya türetilmiş birimler yok.  Sadece kullandığınız kadar ödeyin. Sıfır ekstra maliyet veya gizli ücret.  Hesaplama: tanımlanmış bir aralığa dayalı olarak öngörülebilir  Depolama: yalnızca sakladığınız kadar ödeme yapın  Kaynak israfı yok. Fazla ödeme yok. Geceleri uykusuz kalmak yok. Patronunuza açıklayabileceğiniz bir fatura.  Bugün deneyin  Dinamik PostgreSQL'i bugün deneyebilirsiniz!  —kredi kartı gerekmez—bu size 30 gün boyunca platforma tam erişim sağlar. Dinamik PostgreSQL hizmeti oluşturmak için Timescale'de oturum açarken PostgreSQL seçeneğini seçmeniz yeterlidir:    Timescale ücretsiz deneme sunuyor  Platform artık veritabanlarınızın özel ihtiyaçlarını karşılamak için iki hizmet türü sunuyor:    en zorlu iş yükleriniz için sorgu hızını ve ölçeklenebilirliği artırmak üzere tasarlanmış olup hipertablolar, sütunlu sıkıştırma, sürekli toplamalar ve katmanlı depolama gibi temel Zaman Ölçeği özelliklerini sunar. Sensör verilerinizi, enerji ölçümlerinizi, finansal verilerinizi, etkinliklerinizi ve diğer veri yoğunluklu iş yükünüzü barındırmak için bunları kullanın. Zaman serisi hizmetleri,    maliyet verimliliği ve kullanım kolaylığı için optimize edilmiş dinamik Postgres hizmetleridir. Bunları yalnızca ilişkisel veritabanlarınız (örneğin iş kayıtları) için kullanın. PostgreSQL hizmetleri,  “PostgreSQL”i seçtiğinizde Dinamik PostgreSQL hizmetinizi yapılandırmak son derece basittir. Bölgenizi, dinamik bilgi işlem aralığınızı, yüksek kullanılabilirlik ve bağlantı havuzu seçeneklerinizi seçin; patlama! 💥 Artık üretimde kullanıma hazır bir Dinamik PostgreSQL veritabanına sahipsiniz.   Eğer sorunuz varsa,  . Geri bildirimlerinizi duymayı ve PostgreSQL kullanım senaryonuzda (zaman serisi olsun veya olmasın) size yardımcı olmayı çok isteriz!   bize ulaşın  Bu sadece başlangıç. Art arda üç lansman haftasının ortasındayız ve bu, 2. Hafta: Dinamik Altyapı Haftasının yalnızca başlangıcı. Bu hafta, bu ay, bu yıl ve gelecek yıllar için daha fazlası için bizi izlemeye devam edin. 🙂   - Mike Freedman ve Grant Godeke tarafından yazılmıştır.   Burada da yayınlandı.

Stop database overprovisioning with Dynamic PostgreSQL. Try it out for free

Stop database overprovisioning with Dynamic PostgreSQL Try it out for free

Bu ses hikayenin orijinal dilinde üretilmiştir!

Dinamik PostgreSQL ile Tanışın: Bulut Veritabanlarının Doğal Evrimi

About Author

YORUMLAR

ETİKETLERİ ASIN

BU YAZI

Related Stories

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Claude Sonnet 3.5 Sistem Bilgi Sızıntısı: Adli Analiz

HackerNoon Yazma Yarışmasını mı Kazanmak İstiyorsunuz? İşte #crypto-api Yarışması Kazananlarının Önerileri

Kazanmak için Dokun: Telegram, Solana'dan Önce Sonraki 10 Milyar Kripto Kullanıcısına Katılabilir

Kullanıcı Odaklı Kripto Ürünleri Oluşturma: Müşteri Geri Bildiriminin Önemi

Light-Mode

Classic

Newspaper

Minty

Dark-Mode

Neon Noir

Minty

HN StartUps