Herkese selam! Benim adım Golov Nikolay. Daha önce Avito'da çalıştım ve altı yıl boyunca Veri Platformunu yönettim, yani tüm veritabanları üzerinde çalıştım: analitik (Vertica, ClickHouse), akış ve OLTP (Redis, Tarantool, VoltDB, MongoDB, PostgreSQL). Bu süre zarfında, çok farklı ve alışılmadık çok sayıda veri tabanıyla ve bunların standart dışı kullanım durumlarıyla uğraştım.
Şu anda ManyChat'te çalışıyorum. Özünde bu bir startup; yeni, iddialı ve hızla büyüyor. Şirkete ilk katıldığımda klasik bir soru ortaya çıktı: "Genç bir girişim şimdi DBMS ve veritabanı pazarından ne almalı?"
Bu makalede, raporuma dayanarak Bu soruyu cevaplayacağım. Raporun video versiyonu şu adreste mevcuttur: .
Yaygın olarak bilinen veritabanları 2020
Yıl 2020, etrafıma baktım ve üç tür veritabanı gördüm.
Birinci tip - klasik OLTP veritabanları: PostgreSQL, SQL Server, Oracle, MySQL. Uzun zaman önce yazılmışlardı ancak geliştirici topluluğuna çok aşina oldukları için hala güncelliğini koruyorlar.
İkinci tip - "sıfır"dan başlayan bazlar. Yerleşik parçalama ve diğer çekici özellikler ekleyerek SQL'i, geleneksel yapıları ve ACID'yi terk ederek klasik kalıplardan uzaklaşmaya çalıştılar. Örneğin bu Cassandra, MongoDB, Redis veya Tarantool'dur. Tüm bu çözümler pazara temelde yeni bir şey sunmak istiyordu ve belirli görevler için son derece uygun oldukları ortaya çıktığı için kendi nişlerini işgal ediyordu. Bu veritabanlarını NOSQL şemsiye terimiyle belirteceğim.
“Sıfırlar” bitti, NOSQL veritabanlarına alıştık ve benim açımdan dünya bir sonraki adımı attı; yönetilen veritabanları. Bu veritabanları klasik OLTP veritabanları veya yeni NoSQL veritabanlarıyla aynı çekirdeğe sahiptir. Ancak DBA ve DevOps'a ihtiyaçları yoktur ve bulutlarda yönetilen donanım üzerinde çalışırlar. Bir geliştirici için bu, bir yerde çalışan "sadece bir temeldir", ancak sunucuya nasıl kurulduğu, sunucuyu kimin yapılandırdığı ve onu kimin güncellediği kimsenin umurunda değildir.
Bu tür veritabanlarına örnekler:
- AWS RDS, PostgreSQL/MySQL için yönetilen bir sarmalayıcıdır.
- DynamoDB, Redis ve MongoDB'ye benzer şekilde belge tabanlı bir veritabanının AWS analogudur.
- Amazon Redshift, yönetilen bir analitik veritabanıdır.
Bunlar temelde eski veritabanlarıdır, ancak donanımla çalışmaya gerek kalmadan yönetilen bir ortamda oluşturulmuştur.
Not. Örnekler AWS ortamı için alınmıştır ancak bunların benzerleri Microsoft Azure, Google Cloud veya Yandex.Cloud'da da mevcuttur.
Bunda yeni olan ne var? 2020'de bunların hiçbiri yok.
Sunucusuz konsept
2020'de piyasada gerçekten yeni olan şey, sunucusuz veya sunucusuz çözümlerdir.
Bunun ne anlama geldiğini normal bir servis veya arka uç uygulaması örneğini kullanarak açıklamaya çalışacağım.
Düzenli bir arka uç uygulamasını dağıtmak için bir sunucu satın alır veya kiralarız, kodu üzerine kopyalarız, uç noktayı dışarıda yayınlarız ve düzenli olarak kira, elektrik ve veri merkezi hizmetleri için ödeme yaparız. Bu standart şemadır.
Başka yolu var mı? Sunucusuz hizmetlerle bunu yapabilirsiniz.
Bu yaklaşımın odak noktası nedir: Sunucu yok, bulutta sanal örnek kiralama bile yok. Hizmeti dağıtmak için kodu (işlevleri) depoya kopyalayın ve uç noktada yayınlayın. Daha sonra, çalıştırıldığı donanımı tamamen göz ardı ederek, bu işleve yapılan her çağrı için ödeme yaparız.
Bu yaklaşımı resimlerle anlatmaya çalışacağım.
Klasik dağıtım. Belli bir yüke sahip bir hizmetimiz var. İki örnek oluşturuyoruz: fiziksel sunucular veya AWS'deki örnekler. Harici istekler bu örneklere gönderilir ve orada işlenir.
Resimde görebileceğiniz gibi sunucular eşit şekilde dağıtılmamıştır. Biri %100 kullanılıyor, iki istek var ve biri yalnızca %50, kısmen boşta. Üç istek değil de 30 istek gelirse, tüm sistem yükle baş edemeyecek ve yavaşlamaya başlayacaktır.
Sunucusuz dağıtım. Sunucusuz bir ortamda böyle bir hizmetin örnekleri veya sunucuları yoktur. Belirli bir ısıtılmış kaynak havuzu vardır - dağıtılmış işlev koduna sahip küçük hazırlanmış Docker konteynerleri. Sistem harici istekleri alır ve bunların her biri için sunucusuz çerçeve, kod içeren küçük bir kapsayıcı oluşturur: bu özel isteği işler ve kapsayıcıyı öldürür.
Bir istek - bir kapsayıcı oluşturuldu, 1000 istek - 1000 kapsayıcı. Donanım sunucularına dağıtım zaten bulut sağlayıcının işidir. Sunucusuz çerçeve tarafından tamamen gizlenmiştir. Bu konseptte her arama için ödeme yapıyoruz. Mesela günde bir arama geldi, bir aramanın parasını ödedik, dakikada bir milyon geldi, bir milyonun parasını ödedik. Veya bir saniye sonra bu da olur.
Sunucusuz bir işlev yayınlama kavramı, durum bilgisi olmayan bir hizmet için uygundur. Ve eğer (durum) durum bilgisi olan bir servise ihtiyacınız varsa, servise bir veritabanı ekliyoruz. Bu durumda, durumla çalışmaya gelince, her durum dolu işlev basitçe veritabanına yazar ve okur. Üstelik makalenin başında açıklanan üç türden herhangi birinin veri tabanından.
Tüm bu veritabanlarının ortak sınırlaması nedir? Bunlar sürekli kullanılan bir bulut veya donanım sunucusunun (veya birkaç sunucunun) maliyetleridir. Klasik veya yönetilen veritabanı kullanmamız, Devops'umuz ve yöneticimiz olup olmaması önemli değil, yine de donanım, elektrik ve veri merkezi kiralamasını 24/7 ödüyoruz. Klasik bir tabanımız varsa, efendi ve köle için para öderiz. Çok yüklü bir parçalı veritabanı ise 10, 20 veya 30 sunucuya ödeme yapıyoruz ve sürekli ödeme yapıyoruz.
Maliyet yapısında kalıcı olarak ayrılmış sunucuların varlığı önceden gerekli bir kötülük olarak algılanıyordu. Geleneksel veritabanlarının ayrıca bağlantı sayısındaki sınırlamalar, ölçeklendirme kısıtlamaları, coğrafi olarak dağıtılmış fikir birliği gibi başka zorlukları da vardır; bunlar belirli veritabanlarında bir şekilde çözülebilir, ancak hepsi aynı anda ve ideal olarak çözülemez.
Sunucusuz veritabanı - teori
2020'nin sorusu: Bir veritabanını sunucusuz hale getirmek de mümkün mü? Herkes sunucusuz arka ucu duymuştur... veritabanını sunucusuz yapmayı deneyelim mi?
Bu kulağa garip geliyor çünkü veritabanı durum bilgisi olan bir hizmettir ve sunucusuz altyapı için pek uygun değildir. Aynı zamanda, veritabanının durumu çok büyük: gigabaytlar, terabaytlar ve analitik veritabanlarında hatta petabaytlar. Hafif Docker konteynerlerinde onu yükseltmek o kadar kolay değil.
Öte yandan, neredeyse tüm modern veritabanları büyük miktarda mantık ve bileşen içerir: işlemler, bütünlük koordinasyonu, prosedürler, ilişkisel bağımlılıklar ve çok fazla mantık. Oldukça fazla veritabanı mantığı için küçük bir durum yeterlidir. Gigabaytlar ve Terabaytlar, sorguların doğrudan yürütülmesinde yer alan veritabanı mantığının yalnızca küçük bir kısmı tarafından doğrudan kullanılır.
Buna göre fikir şudur: Eğer mantığın bir kısmı durum bilgisi olmayan yürütmeye izin veriyorsa, neden tabanı Durum Bilgili ve Durum Bilgisi Olmayan parçalara ayırmayalım.
OLAP çözümleri için sunucusuz
Pratik örnekler kullanarak bir veritabanını Durum Bilgili ve Durum Bilgisi Olmayan parçalara ayırmanın nasıl görünebileceğini görelim.
Örneğin analitik bir veritabanımız var: harici veriler (soldaki kırmızı silindir), verileri veritabanına yükleyen bir ETL işlemi ve veritabanına SQL sorguları gönderen bir analist. Bu klasik bir veri ambarı operasyon şemasıdır.
Bu şemada ETL şartlı olarak bir kez gerçekleştirilir. Daha sonra, sorgu gönderilecek bir şeyin olması için veritabanının ETL ile doldurulmuş verilerle çalıştığı sunucular için sürekli ödeme yapmanız gerekir.
AWS Athena Serverless'ta uygulanan alternatif bir yaklaşıma bakalım. İndirilen verilerin depolandığı kalıcı olarak ayrılmış bir donanım yoktur. Bunun yerine:
- Kullanıcı Athena'ya bir SQL sorgusu gönderir. Athena optimizer, SQL sorgusunu analiz eder ve sorguyu yürütmek için gereken belirli verileri meta veri deposunda (Meta Veriler) arar.
- Optimize edici, toplanan verilere dayanarak gerekli verileri harici kaynaklardan geçici depolamaya (geçici veritabanı) indirir.
- Kullanıcıdan gelen bir SQL sorgusu geçici depolamada yürütülür ve sonuç kullanıcıya döndürülür.
- Geçici depolama temizlenir ve kaynaklar serbest bırakılır.
Bu mimaride yalnızca isteğin yürütülmesi süreci için ödeme yaparız. Talep yok - maliyet yok.
Bu, çalışan bir yaklaşımdır ve yalnızca Athena Serverless'ta değil aynı zamanda Redshift Spectrum'da (AWS'de) de uygulanmaktadır.
Athena örneği, Sunucusuz veritabanının onlarca ve yüzlerce Terabayt veri içeren gerçek sorgular üzerinde çalıştığını göstermektedir. Yüzlerce Terabayt yüzlerce sunucu gerektirecektir, ancak bunlar için ödeme yapmamıza gerek yok; istekler için ödeme yapıyoruz. Her isteğin hızı, Vertica gibi özel analitik veritabanlarıyla karşılaştırıldığında (çok) düşüktür, ancak kesinti süreleri için ödeme yapmıyoruz.
Böyle bir veritabanı, nadir analitik anlık sorgular için uygulanabilir. Örneğin, devasa miktarda veri üzerinde spontane bir hipotezi test etmeye karar verdiğimizde. Athena bu durumlar için mükemmeldir. Düzenli talepler için böyle bir sistem pahalıdır. Bu durumda verileri özel bir çözümde önbelleğe alın.
OLTP çözümleri için sunucusuz
Önceki örnekte OLAP (analitik) görevlere bakıldı. Şimdi OLTP görevlerine bakalım.
Ölçeklenebilir PostgreSQL veya MySQL'i hayal edelim. Minimum kaynakla düzenli olarak yönetilen bir PostgreSQL veya MySQL örneği oluşturalım. Örnek daha fazla yük aldığında, okuma yükünün bir kısmını dağıtacağımız ek kopyaları bağlayacağız. Herhangi bir istek ya da yük yoksa replikaları kapatıyoruz. İlk örnek ana öğedir ve geri kalanı kopyalardır.
Bu fikir, Aurora Serverless AWS adlı bir veritabanında uygulanmaktadır. Prensip basittir: Harici uygulamalardan gelen istekler proxy filosu tarafından kabul edilir. Yükün arttığını görünce, önceden ısıtılmış minimum örneklerden bilgi işlem kaynaklarını tahsis eder; bağlantı mümkün olduğu kadar hızlı kurulur. Örneklerin devre dışı bırakılması da aynı şekilde gerçekleşir.
Aurora'da Aurora Kapasite Birimi (ACU) kavramı vardır. Bu (şartlı olarak) bir örnektir (sunucu). Her özel ACU bir ana veya bir bağımlı olabilir. Her Kapasite Biriminin kendine ait RAM'i, işlemcisi ve minimum diski vardır. Buna göre biri ana, geri kalanı salt okunur kopyalardır.
Çalışan bu Aurora Kapasite Birimlerinin sayısı yapılandırılabilir bir parametredir. Minimum miktar bir veya sıfır olabilir (bu durumda, istek yoksa veritabanı çalışmaz).
Üs istek aldığında, proxy filosu Aurora Kapasite Birimlerini yükselterek sistemin performans kaynaklarını artırır. Kaynakları artırma ve azaltma yeteneği, sistemin kaynaklarla "hokkabazlık yapmasına" olanak tanır: bireysel ACU'ları otomatik olarak görüntüler (onları yenileriyle değiştirir) ve mevcut tüm güncellemeleri geri çekilen kaynaklara dağıtır.
Aurora Serverless tabanı okuma yükünü ölçeklendirebilir. Ancak belgeler bunu doğrudan söylemiyor. Bir çoklu master'ı kaldırabileceklermiş gibi hissedebilirler. Büyü yok.
Bu veritabanı, öngörülemeyen erişime sahip sistemlere büyük miktarda para harcamayı önlemek için çok uygundur. Örneğin MVP oluştururken veya kartvizit siteleri pazarlarken genellikle istikrarlı bir yük beklemiyoruz. Buna göre eğer erişim yoksa bulut sunucuları için ödeme yapmıyoruz. Örneğin bir konferans veya reklam kampanyasından sonra beklenmedik bir yük oluştuğunda, kalabalık insan siteyi ziyaret ettiğinde ve yük önemli ölçüde arttığında, Aurora Serverless bu yükü otomatik olarak alır ve eksik kaynakları (ACU) hızlı bir şekilde birbirine bağlar. Daha sonra konferans geçer, herkes prototipi unutur, sunucular (ACU) kararır ve maliyetler sıfıra düşer; bu da kullanışlıdır.
Bu çözüm, yazma yükünü ölçeklendirmediği için kararlı yüksek yük için uygun değildir. Kaynakların tüm bu bağlantıları ve bağlantı kesintileri, veritabanının bir işlem veya geçici tablolar tarafından desteklenmediği bir zaman noktası olan "ölçek noktası" adı verilen noktada meydana gelir. Örneğin, bir hafta içinde ölçek noktası gerçekleşmeyebilir ve taban aynı kaynaklar üzerinde çalışır ve basitçe genişleyemez veya daralamaz.
Hiçbir sihir yok; normal PostgreSQL. Ancak makine ekleme ve bağlantılarını kesme süreci kısmen otomatiktir.
Tasarım gereği sunucusuz
Aurora Serverless, Sunucusuz'un bazı avantajlarından yararlanmak amacıyla bulut için yeniden yazılan eski bir veritabanıdır. Şimdi size sunucusuz yaklaşım için orijinal olarak bulut için yazılmış olan tabandan bahsedeceğim - Tasarım itibariyle Sunucusuz. Fiziksel sunucularda çalışacağı varsayımı olmadan hemen geliştirildi.
Bu üsse Kar Tanesi denir. Üç anahtar bloğu vardır.
Birincisi bir meta veri bloğudur. Bu, güvenlik, meta veriler, işlemler ve sorgu optimizasyonu (soldaki çizimde gösterilmektedir) ile ilgili sorunları çözen hızlı bir bellek içi hizmettir.
İkinci blok, hesaplamalar için bir dizi sanal bilgi işlem kümesidir (resimde bir dizi mavi daire vardır).
Üçüncü blok S3 tabanlı bir veri depolama sistemidir. S3, AWS'deki boyutsuz nesne depolamadır; iş için boyutsuz Dropbox'a benzer.
Soğuk bir başlangıç varsayarak Snowflake'in nasıl çalıştığını görelim. Yani bir veritabanı var, veriler ona yükleniyor, çalışan sorgu yok. Buna göre, eğer veritabanına herhangi bir istek yoksa, hızlı bellek içi Metadata hizmetini (ilk blok) yükselttik. Ve tablo verilerinin depolandığı, mikro bölümlere bölünmüş S3 depolama alanımız var. Basitleştirmek gerekirse: eğer tablo işlemler içeriyorsa, mikro bölümler işlem günleridir. Her gün ayrı bir mikro bölüm, ayrı bir dosyadır. Ve veritabanı bu modda çalıştığında yalnızca verinin kapladığı alan için ödeme yaparsınız. Üstelik koltuk başına oran çok düşüktür (özellikle ciddi sıkıştırma dikkate alındığında). Meta veri hizmeti de sürekli çalışır ancak sorguları optimize etmek için çok fazla kaynağa ihtiyacınız yoktur ve hizmet, paylaşılan yazılım olarak değerlendirilebilir.
Şimdi bir kullanıcının veritabanımıza geldiğini ve bir SQL sorgusu gönderdiğini düşünelim. SQL sorgusu işlenmek üzere hemen Meta Veri hizmetine gönderilir. Buna göre, bir talep alındığında bu hizmet, talebi, mevcut verileri, kullanıcı izinlerini analiz eder ve her şey yolundaysa talebin işlenmesi için bir plan hazırlar.
Daha sonra hizmet, bilgi işlem kümesinin başlatılmasını başlatır. Bilgi işlem kümesi, hesaplamaları gerçekleştiren bir sunucu kümesidir. Yani bu, 1 sunucu, 2 sunucu, 4, 8, 16, 32 - istediğiniz kadar içerebilen bir kümedir. Bir istek atarsınız ve bu kümenin başlatılması hemen başlar. Gerçekten saniyeler sürüyor.
Daha sonra, küme başladıktan sonra isteğinizi işlemek için gereken mikro bölümler S3'ten kümeye kopyalanmaya başlar. Yani, bir SQL sorgusunu yürütmek için bir tablodan iki ve ikinci tablodan bir bölüme ihtiyacınız olduğunu varsayalım. Bu durumda, tüm tabloların tamamı değil, yalnızca gerekli üç bölüm kümeye kopyalanacaktır. İşte tam da bu nedenle ve her şey tek bir veri merkezinde yer aldığından ve çok hızlı kanallarla birbirine bağlandığından, tüm aktarım süreci çok hızlı bir şekilde gerçekleşir: bazı canavarca isteklerden bahsetmediğimiz sürece saniyeler içinde, çok nadir olarak dakikalar içinde. Buna göre mikro bölümler bilgi işlem kümesine kopyalanır ve tamamlandıktan sonra bu bilgi işlem kümesinde SQL sorgusu yürütülür. Bu isteğin sonucu bir satır, birkaç satır veya bir tablo olabilir; bunlar kullanıcıya harici olarak gönderilir, böylece indirebilir, BI aracında görüntüleyebilir veya başka bir şekilde kullanabilir.
Her SQL sorgusu yalnızca önceden yüklenmiş verilerden gelen toplamları okumakla kalmaz, aynı zamanda veritabanına yeni veriler yükleyebilir/oluşturabilir. Yani, örneğin başka bir tabloya yeni kayıtlar ekleyen, bilgi işlem kümesinde yeni bir bölümün görünmesine yol açan ve bu da otomatik olarak tek bir S3 depolama alanına kaydedilen bir sorgu olabilir.
Yukarıda açıklanan senaryoda, kullanıcının gelişinden kümenin yükseltilmesine, verilerin yüklenmesine, sorguların yürütülmesine, sonuçların elde edilmesine kadar, yükseltilmiş sanal bilgi işlem kümesinin, sanal deponun kullanıldığı dakikalar oranında ödeme yapılır. Oran, AWS bölgesine ve küme boyutuna bağlı olarak değişir ancak ortalama olarak saat başına birkaç dolardır. Dört makineden oluşan bir küme, iki makineden oluşan bir kümeden iki kat daha pahalıdır; sekiz makineden oluşan bir küme ise yine iki kat daha pahalıdır. Taleplerin karmaşıklığına bağlı olarak 16, 32 makinelik seçenekler mevcuttur. Ancak yalnızca kümenin gerçekten çalıştığı dakikalar için ödeme yaparsınız, çünkü hiçbir istek olmadığında, bir nevi ellerinizi çekersiniz ve 5-10 dakika bekledikten sonra (yapılandırılabilir bir parametre) kendi kendine kapanacaktır. Kaynakları serbest bırakın ve özgür olun.
Tamamen gerçekçi bir senaryo, bir istek gönderdiğinizde, kümenin göreceli olarak bir dakika içinde açılması, bir dakika daha sayılması, ardından kapanmak için beş dakika sayılması ve sonunda bu kümenin yedi dakikalık çalışması için ödeme yapmanızdır. aylar ve yıllar boyunca değil.
Tek kullanıcılı bir ortamda Snowflake kullanılarak açıklanan ilk senaryo. Şimdi gerçek senaryoya daha yakın olan çok sayıda kullanıcının olduğunu hayal edelim.
Diyelim ki veritabanımızı sürekli olarak çok sayıda basit analitik SQL sorgusu ile bombalayan çok sayıda analistimiz ve Tableau raporumuz var.
Ayrıca diyelim ki, verilerle korkunç şeyler yapmaya çalışan, onlarca Terabayt ile çalışan, milyarlarca ve trilyonlarca satırlık veriyi analiz eden yaratıcı Veri Bilimcilerimiz var.
Yukarıda açıklanan iki tür iş yükü için Snowflake, farklı kapasitelere sahip birkaç bağımsız bilgi işlem kümesi oluşturmanıza olanak tanır. Üstelik bu bilgi işlem kümeleri bağımsız olarak ancak ortak tutarlı verilerle çalışır.
Çok sayıda hafif sorgu için, her biri yaklaşık 2 makine olmak üzere 3-2 küçük küme oluşturabilirsiniz. Bu davranış, diğer şeylerin yanı sıra, otomatik ayarlar kullanılarak da uygulanabilir. Yani diyorsunuz ki, “Kar tanesi, küçük bir küme oluştur. Üzerindeki yük belirli bir parametrenin üzerine çıkarsa, benzer bir ikinci, üçüncüyü yükseltin. Yük azalmaya başladığında fazlalığı söndürün.” Böylece kaç analist gelip raporlara bakmaya başlarsa başlasın herkesin yeterli kaynağı var.
Aynı zamanda analistler uyuyorsa ve raporlara kimse bakmıyorsa kümeler tamamen kararabilir ve onlar için ödeme yapmayı bırakabilirsiniz.
Aynı zamanda, yoğun sorgular için (Veri Bilimcilerinden), 32 makine için çok büyük bir küme oluşturabilirsiniz. Bu kümeye yalnızca dev isteğinizin orada çalıştığı dakikalar ve saatler için de ödeme yapılacaktır.
Yukarıda açıklanan fırsat, yalnızca 2 değil, aynı zamanda daha fazla iş yükü türünü kümelere ayırmanıza da olanak tanır (ETL, izleme, rapor gerçekleştirme,...).
Snowflake'i özetleyelim. Temel, güzel bir fikir ile uygulanabilir bir uygulamayı birleştiriyor. ManyChat'te elimizdeki tüm verileri analiz etmek için Snowflake'i kullanıyoruz. Örnekte olduğu gibi üç kümemiz yok, ancak 5'ten 9'a kadar farklı boyutlarda kümelerimiz var. Bazı görevler için geleneksel 16 makineli, 2 makineli ve süper küçük 1 makineli makinelerimiz de mevcuttur. Yükü başarıyla dağıtıyorlar ve çok tasarruf etmemizi sağlıyorlar.
Veritabanı okuma ve yazma yükünü başarıyla ölçeklendirir. Bu, yalnızca okuma yükünü taşıyan aynı "Aurora" ile karşılaştırıldığında çok büyük bir fark ve büyük bir atılımdır. Snowflake, yazma iş yükünüzü bu bilgi işlem kümeleriyle ölçeklendirmenize olanak tanır. Yani, bahsettiğim gibi, ManyChat'te birkaç küme kullanıyoruz, küçük ve süper küçük kümeler çoğunlukla ETL için, veri yüklemek için kullanılıyor. Ve analistler zaten ETL yükünden kesinlikle etkilenmeyen orta kümelerde yaşıyorlar, bu yüzden çok hızlı çalışıyorlar.
Buna göre veritabanı OLAP görevleri için oldukça uygundur. Ancak ne yazık ki henüz OLTP iş yükleri için geçerli değildir. İlk olarak, bu veritabanı, ortaya çıkan tüm sonuçlarla birlikte sütunludur. İkinci olarak, her istek için gerekirse bir bilgi işlem kümesi oluşturup onu verilerle doldurduğunuz yaklaşımın kendisi, ne yazık ki henüz OLTP yükleri için yeterince hızlı değildir. OLAP görevleri için saniyelerce beklemek normaldir, ancak OLTP görevleri için kabul edilemez; 100 ms daha iyi olurdu, veya 10 ms daha da iyi olurdu.
sonuç
Sunucusuz bir veritabanı, veritabanını Durumsuz ve Durumlu parçalara bölerek mümkündür. Yukarıdaki örneklerin tümünde, Durum Bilgisi olan kısmın, nispeten konuşursak, S3'te mikro bölümleri depoladığını ve Durum Bilgisi olmayanın, meta verilerle çalışan, bağımsız hafif Durum Bilgisi olmayan hizmetler olarak ortaya çıkabilecek güvenlik sorunlarını ele alan optimize edici olduğunu fark etmiş olabilirsiniz.
SQL sorgularının yürütülmesi, Snowflake bilgi işlem kümeleri gibi sunucusuz modda açılabilen, yalnızca gerekli verileri indiren, sorguyu yürüten ve "dışarı çıkan" hafif durum hizmetleri olarak da algılanabilir.
Sunucusuz üretim seviyesindeki veritabanları zaten kullanıma hazır, çalışıyorlar. Bu sunucusuz veritabanları OLAP görevlerini yerine getirmeye hazırdır. Ne yazık ki, OLTP görevlerinde sınırlamalar olduğundan nüanslarla kullanılıyorlar. Bir yandan bu bir eksi. Ama bir yandan da bu bir fırsat. Belki de okuyuculardan biri, Aurora sınırlamaları olmaksızın bir OLTP veritabanını tamamen sunucusuz hale getirmenin bir yolunu bulacaktır.
Umarım ilginç bulmuşsunuzdur. Sunucusuz gelecek :)
Kaynak: habr.com