Merhaba Habrovsk sakinleri. Her zamanki gibi yeni kursların başlamasından önce ilginç materyaller paylaşmaya devam ediyoruz. Bugün özellikle sizin için kursun lansmanına denk gelecek şekilde Google Cloud Spanner hakkında bir makale yayınladık .
İlk olarak şu tarihte yayınlandı: .
Dünyanın dört bir yanındaki perakendecilere, restoran sahiplerine ve çevrimiçi satıcılara çeşitli bulut tabanlı POS çözümleri sunan bir şirket olarak Lightspeed, çeşitli işlemsel, analitik ve arama kullanım durumları için birkaç farklı türde veritabanı platformu kullanıyor. Bu veritabanı platformlarının her birinin kendine özgü güçlü ve zayıf yönleri vardır.Bu nedenle Google, neredeyse sınırsız yatay ölçeklenebilirlik ve %99,999 hizmet düzeyi sözleşmesi (SLA) gibi ilişkisel veritabanları dünyasında görülmemiş umut verici özellikler olan Cloud Spanner'ı pazara sunduğunda, — onu ele geçirme fırsatını kaçıramazdık!
Cloud Spanner deneyimimize ve kullandığımız değerlendirme kriterlerine kapsamlı bir genel bakış sağlamak için aşağıdaki konuları ele alacağız:
- Değerlendirme kriterlerimiz
- Kısaca Cloud Spanner
- Değerlendirmemiz
- Bizim bulgularımız
1. Değerlendirme kriterlerimiz
Cloud Spanner'ın ayrıntılarına, piyasadaki diğer çözümlerle benzerliklerine ve farklılıklarına dalmadan önce, Cloud Spanner'ı altyapımızda nereye dağıtacağımızı düşünürken aklımızdaki ana kullanım örneklerinden bahsedelim:
- (Baskın) geleneksel SQL veritabanı çözümünün yerine geçmek üzere
- OLAP desteğiyle OLTP çözümü nasıl yapılır
Not: Basitlik ve karşılaştırma kolaylığı açısından bu makale, Cloud Spanner'ı GCP Cloud SQL ve Amazon AWS RDS çözüm ailelerinin MySQL varyantlarıyla karşılaştırmaktadır.
Geleneksel SQL veritabanı çözümünün yerine Cloud Spanner'ı kullanma
Çevrede geleneksel veritabanlarında, veritabanı sorgusu yanıt süresi önceden tanımlanmış uygulama eşiklerine yaklaştığında veya hatta bu eşikleri aştığında (esas olarak kullanıcı ve/veya istek sayısındaki artış nedeniyle), yanıt süresini kabul edilebilir seviyelere düşürmenin birkaç yolu vardır. Ancak bu çözümlerin çoğu manuel müdahaleyi içermektedir.
Örneğin atılacak ilk adım, performansla ilgili çeşitli veritabanı parametrelerine bakmak ve bunları uygulama kullanım senaryosu kalıplarına en iyi şekilde uyacak şekilde ayarlamaktır. Bu yeterli değilse veritabanını dikey veya yatay olarak ölçeklendirmeyi seçebilirsiniz.
Bir uygulamanın dikey olarak ölçeklendirilmesi, genellikle daha fazla işlemci/çekirdek, daha fazla RAM, daha hızlı depolama vb. ekleyerek sunucu örneğinin yükseltilmesini gerektirir. Daha fazla donanım kaynağı eklemek, öncelikle saniyedeki işlemlerde ve OLTP sistemleri için işlem gecikmesinde ölçülen artan veritabanı performansıyla sonuçlanır. MySQL gibi ilişkisel veritabanı sistemleri (çok iş parçacıklı bir yaklaşım kullanan) dikey olarak iyi ölçeklenir.
Bu yaklaşımın birçok dezavantajı vardır ancak en bariz olanı piyasadaki maksimum sunucu boyutudur. En büyük sunucu örneğinin sınırına ulaşıldığında geriye tek bir seçenek kalır: yatay ölçeklendirme.
Yatay ölçeklendirme, bir kümeye daha fazla sunucunun eklendiği, ideal olarak sunucu sayısı eklendikçe performansın doğrusal olarak arttığı bir yaklaşımdır. Çoğunluk geleneksel Veritabanı sistemleri yatay olarak iyi ölçeklenmiyor veya hiç ölçeklenmiyor. Örneğin, MySQL, bağımlı okuyucular ekleyerek okuma işlemleri için yatay olarak ölçekleyebilir, ancak yazmalar için yatay olarak ölçekleyemez.
Öte yandan Cloud Spanner doğası gereği minimum müdahaleyle yatay olarak kolayca ölçeklenebilmektedir.
Tam özellikli Hizmet olarak DBMS farklı açılardan değerlendirilmesi gerekir. Temel olarak buluttaki en popüler DBMS'yi (Google için GCP Cloud SQL ve Amazon için AWS RDS) aldık. Değerlendirmemizde aşağıdaki kategorilere odaklandık:
- Özellik eşleme: SQL, DDL, DML kapsamı; bağlantı kitaplıkları/bağlayıcıları, işlem desteği vb.
- Geliştirme desteği: Kolay geliştirme ve test etme.
- Yönetim desteği: örnek yönetimi - örneğin ölçek büyütme/küçültme ve örnekleri yükseltme; SLA, yedekleme ve kurtarma; güvenlik/erişim kontrolü.
Cloud Spanner'ı OLAP özellikli bir OLTP çözümü olarak kullanma
Google, Cloud Spanner'ın analitik işleme için tasarlandığını açıkça iddia etmese de, OLAP iş yükleri için tasarlanan Apache Impala & Kudu ve YugaByte gibi diğer motorlarla bazı özellikleri paylaşıyor.
Cloud Spanner'ın (az ya da çok) kullanılabilir bir OLAP özellik kümesine sahip, tutarlı, ölçeklenebilir bir HTAP (karma işlem/analitik işleme) motoru içermesi çok küçük bir ihtimal olsa bile, bunun dikkate değer olacağını düşünüyoruz.
Bunu aklımızda tutarak aşağıdaki kategorilere baktık:
- Veri yükleme, indeksleme ve bölümleme desteği
- Sorgu Performansı ve DML
2. Kısaca Cloud Spanner
Google Spanner, Google'ın kendi hizmetlerinin birçoğu için kullandığı kümelenmiş bir ilişkisel veritabanı yönetim sistemidir (RDBMS). Google, bu özelliği 2017'nin başlarında Google Cloud Platform kullanıcılarının kullanımına sundu.
Cloud Spanner özelliklerinden bazıları şunlardır:
- Son Derece Tutarlı, Ölçeklenebilir RDBMS Kümesi: Veri tutarlılığını sağlamak için donanım zaman senkronizasyonunu kullanır.
- Çapraz tablo işlem desteği: İşlemler birden fazla tabloya yayılabilir; tek bir tabloyla sınırlı olması gerekmez (Apache HBase veya Apache Kudu'dan farklı olarak).
- Birincil anahtar tabanlı tablolar: Tüm tabloların, tablodaki birden çok sütundan oluşabilen, beyan edilmiş bir birincil anahtarı (PC) olması gerekir. Tablo verileri PC sırasına göre saklanır, bu da PC aramasını çok verimli ve hızlı hale getirir. Diğer PC tabanlı sistemler gibi, uygulamanın da önceden tasarlanmış kullanım senaryoları göz önünde bulundurularak modellenmesi gerekir. .
- Çizgili tablolar: Tabloların birbirlerine fiziksel bağımlılıkları olabilir. Bir alt tablodaki satırlar, bir üst tablodaki satırlarla eşleştirilebilir. Bu yaklaşım, müşterilerin ve faturalarının aynı yerde konumlandırılması gibi veri modelleme aşamasında tanımlanabilecek ilişkilerin araştırılmasını hızlandırır.
- Dizinler: Cloud Spanner ikincil dizinleri destekler. Dizin, dizine eklenen sütunlardan ve tüm PC sütunlarından oluşur. İstenirse indeks, indekslenmemiş diğer sütunları da içerebilir. Sorguları hızlandırmak için indeks ana tabloya eklenebilir. Dizinde saklanan ek sütunların maksimum sayısı gibi dizinler için çeşitli kısıtlamalar geçerlidir. Ayrıca indeksler aracılığıyla yapılan sorgulamalar diğer RDBMS'lerdeki kadar basit olmayabilir.
"Cloud Spanner bir dizini yalnızca nadir durumlarda otomatik olarak seçer. Özellikle, bir sorgunun depolanmayan sütunları istemesi durumunda Cloud Spanner otomatik olarak ikincil dizini seçmez. '.
- Hizmet Düzeyi Sözleşmesi (SLA): %99,99 SLA ile tek bölgede dağıtım; %99,999 SLA ile çok bölgeli dağıtımlar. Her ne kadar HDS'nin kendisi yalnızca bir anlaşma olsa ve herhangi bir garanti olmasa da, Google'daki kişilerin bu kadar güçlü bir iddiada bulunabilecek bazı somut verilere sahip olduğuna inanıyorum. (Referans olarak %99,999, ayda 26,3 saniyelik hizmet kullanılamaması anlamına gelir.)
- Daha:
Not: Apache Tephra projesi, Apache HBase'e gelişmiş işlem desteği ekler (artık Apache Phoenix'te beta olarak da uygulanmaktadır).
3. Değerlendirmemiz
Hepimiz Google'ın Cloud Spanner'ın faydaları hakkındaki iddialarını okuduk: yüksek tutarlılığı ve çok yüksek HDS'yi korurken neredeyse sınırsız yatay ölçeklendirme. Her ne kadar bu gereklilikleri başarmak son derece zor olsa da, amacımız onları çürütmek değildi. Bunun yerine, çoğu veritabanı kullanıcısının önemsediği diğer şeylere odaklanalım: eşlik ve kullanılabilirlik.
Cloud Spanner'ı Sharded MySQL'in yerine geçecek ürün olarak değerlendirdik
Bulut pazarındaki en popüler OLTP DBMS'lerden ikisi olan Google Cloud SQL ve Amazon AWS RDS, çok geniş bir özellik kümesine sahiptir. Ancak bu veritabanlarını tek bir düğüm boyutunun ötesine ölçeklendirmek için uygulama bölümlendirmesi yapmanız gerekir. Bu yaklaşım hem uygulamalar hem de yönetim için ek karmaşıklık yaratır. Spanner'ın birden fazla parçayı tek bir örnekte birleştirme senaryosuna nasıl uyduğunu ve hangi özelliklerin (varsa) feda edilmesi gerekebileceğini inceledik.
SQL, DML ve DDL'nin yanı sıra bağlayıcı ve kitaplıklar da destekleniyor mu?
Öncelikle herhangi bir veritabanına başlarken bir veri modeli oluşturmanız gerekir. JDBC Spanner'ı favori SQL aracınıza bağlayabileceğinizi düşünüyorsanız, onunla verilerinizi sorgulayabileceğinizi ancak onu bir tablo oluşturmak veya değiştirmek (DDL) veya herhangi bir ekleme/güncelleme/silme işlemi için kullanamayacağınızı göreceksiniz. işlemler (DML). Google'ın resmi JDBC'si bunlardan hiçbirini desteklemiyor.
"Sürücüler şu anda DML veya DDL bildirimlerini desteklemiyor."
Anahtar Belgeleri
GCP konsolunda da durum daha iyi değil; yalnızca SELECT sorguları gönderebilirsiniz. Neyse ki, işlemler de dahil olmak üzere topluluktan DML ve DDL desteği sağlayan bir JDBC sürücüsü var . Bu sürücü son derece kullanışlı olsa da Google'ın kendi JDBC sürücüsünün olmaması şaşırtıcı. Neyse ki Google, istemci kitaplıkları için (gRPC'ye dayalı) oldukça geniş bir destek sunuyor: C#, Go, Java, node.js, PHP, Python ve Ruby.
Cloud Spanner özel API'lerinin neredeyse zorunlu kullanımı (JDBC'de DDL ve DML eksikliği nedeniyle), bağlantı havuzları veya veritabanı bağlama çerçeveleri (ör. Spring MVC) gibi ilgili kod alanları için bazı sınırlamalara neden olur. Tipik olarak, JDBC kullanırken, test edilmiş ve iyi çalışan favori bağlantı havuzunuzu (örn. HikariCP, DBCP, C3PO, vb.) seçmekte özgürsünüz. Özel Spanner API'leri söz konusu olduğunda, kendi oluşturduğumuz çerçevelere/bağlayıcı havuzlara/oturumlara güvenmek zorundayız.
Birincil anahtar (PC) merkezli tasarım, Cloud Spanner'ın verilere PC üzerinden erişirken çok hızlı olmasını sağlar, ancak aynı zamanda bazı sorgu sorunlarını da beraberinde getirir.
- Birincil anahtar değerini güncelleyemezsiniz; Önce girişi orijinal PC'den silmeli ve yeni değerle yeniden eklemelisiniz. (Bu, diğer PC odaklı veritabanı/depolama motorlarına benzer.)
- Herhangi bir UPDATE ve DELETE ifadesi, WHERE'de PC'yi belirtmelidir, bu nedenle boş olamaz tüm DELETE ifadeleri - her zaman bir alt sorgu olmalıdır, örneğin: UPDATE xxx WHERE id IN (SELECT id FROM table1)
- Otomatik artış seçeneğinin veya PC alanının sırasını belirleyen benzer herhangi bir şeyin olmaması. Bunun çalışması için uygulama tarafında ilgili değerin oluşturulması gerekir.
İkincil dizinler?
Google Cloud Spanner, ikincil dizinler için yerleşik desteğe sahiptir. Bu, diğer teknolojilerde her zaman bulunmayan çok güzel bir özelliktir. Apache Kudu şu anda ikincil dizinleri hiç desteklememektedir ve Apache HBase, dizinleri doğrudan desteklememektedir ancak bunları Apache Phoenix aracılığıyla ekleyebilir.
Kudu ve HBase'deki dizinler, farklı bir birincil anahtar bileşimiyle ayrı bir tablo olarak modellenebilir, ancak ana tabloda ve ilgili dizin tablolarında gerçekleştirilen işlemlerin atomikliği, uygulama düzeyinde yapılmalıdır ve doğru şekilde uygulanması önemsiz değildir.
Cloud Spanner incelemesinde de belirtildiği gibi dizinleri MySQL dizinlerinden farklı olabilir. Bu nedenle, sorguları oluştururken ve profil oluştururken, ihtiyaç duyulan yerde doğru endeksin kullanılmasını sağlamak için özel dikkat gösterilmelidir.
Temsil mi?
Bir veritabanındaki çok popüler ve kullanışlı bir nesne görünümlerdir. Çok sayıda kullanım durumu için faydalı olabilirler; benim iki favorim mantıksal soyutlama katmanı ve güvenlik katmanıdır. Maalesef Cloud Spanner görünümleri DESTEKLEMEZ. Ancak bu bizi yalnızca kısmen sınırlıyor çünkü görünümlerin geçerli bir çözüm olabileceği sütun düzeyinde erişim izinleri için ayrıntı düzeyi bulunmuyor.
Kotaların ve kısıtlamaların ayrıntılarını içeren bir bölüm için Cloud Spanner belgelerine bakın (), özellikle bazı uygulamalar için sorunlu olabilecek bir tane var: Cloud Spanner, kullanıma hazır olarak örnek başına maksimum 100 veritabanı sınırına sahiptir. Açıkçası bu, 100'den fazla veritabanına ölçeklenecek şekilde tasarlanmış bir veritabanı için büyük bir darboğaz olabilir. Neyse ki Google teknik temsilcimizle görüştükten sonra bu sınırın Google Destek aracılığıyla neredeyse her değere artırılabileceğini öğrendik.
Geliştirme desteği mi?
Cloud Spanner, API'siyle çalışmak için oldukça iyi bir programlama dili desteği sunuyor. Resmi olarak desteklenen kütüphaneler C#, Go, Java, node.js, PHP, Python ve Ruby alanlarındadır. Belgeler oldukça ayrıntılıdır ancak diğer gelişmiş teknolojilerde olduğu gibi topluluk, en popüler veritabanı teknolojileriyle karşılaştırıldığında oldukça küçüktür ve bu da daha az yaygın kullanım durumlarını veya sorunları çözmek için daha fazla zaman harcanmasına yol açabilir.
Peki yerel kalkınmayı desteklemeye ne dersiniz?
Şirket içinde Cloud Spanner örneği oluşturmanın bir yolunu bulamadık. Elimizdeki en yakın şey Docker görüntüsüydü. prensipte benzer, ancak pratikte çok farklıdır. Örneğin CockroachDB PostgreSQL JDBC'yi kullanabilir. Geliştirme ortamının üretim ortamına mümkün olduğunca yakın olması gerektiğinden Cloud Spanner, tam bir Spanner örneğine dayanması gerektiğinden ideal değildir. Maliyetlerden tasarruf etmek için tek bölgeli bir bulut sunucusu seçebilirsiniz.
Yönetim desteği?
Cloud Spanner örneği oluşturmak çok basittir. Çoklu bölge veya tek bölgeli bir örnek oluşturma arasında seçim yapmanız, bölgeleri ve düğüm sayısını belirtmeniz yeterlidir. Bir dakikadan kısa bir süre içinde örneğiniz çalışır durumda olacak.
Çeşitli temel metriklere Google Konsolundaki Spanner sayfasından doğrudan erişilebilir. Metrik eşiklerini ve uyarı politikalarını da ayarlayabileceğiniz Stackdriver aracılığıyla daha ayrıntılı görünümlere ulaşabilirsiniz.
Kaynaklara erişim?
MySQL, kullanıcı izinleri/rolleri için kapsamlı ve çok ayrıntılı ayarlar sunar. Belirli bir tabloya, hatta sütunlarının yalnızca bir alt kümesine erişimi kolayca yapılandırabilirsiniz. Cloud Spanner, yalnızca çok yüksek düzeyde politika ve izinler belirlemenize olanak tanıyan Google'ın Kimlik ve Erişim Yönetimi (IAM) aracını kullanır. En ayrıntılı seçenek, çoğu üretim kullanım durumuna uymayan veritabanı düzeyinde çözünürlüktür. Bu sınırlama, Spanner kaynaklarının yetkisiz kullanımını önlemek için sizi kodunuza, altyapınıza veya her ikisine de ek güvenlik önlemleri eklemeye zorlar.
Yedeklemeler mi?
Basitçe söylemek gerekirse Cloud Spanner'da yedekleme yoktur. Her ne kadar Google'ın yüksek HDS gereklilikleri donanım veya veri tabanı arızaları, insan hataları, uygulama kusurları vb. nedeniyle herhangi bir veriyi kaybetmemenizi sağlasa da. Hepimiz şu kuralı biliyoruz: Yüksek kullanılabilirlik, sağlam bir yedekleme stratejisinin yerine geçmez. Şu anda verileri yedeklemenin tek yolu, verileri bir veritabanından ayrı bir depolama ortamına programlı olarak aktarmaktır.
Sorgu performansı?
Veri yüklemek ve sorguları test etmek için Yahoo!'yu kullandık. Bulut Hizmet Karşılaştırması. Aşağıdaki tablo, %95 okuma-%5 yazma oranına sahip YCSB iş yükü B'yi göstermektedir.
* Yük testi, n1 standardı 32 Compute Engine (CE) (32 vCPU, 120 GB bellek) üzerinde gerçekleştirildi ve test örneği, testlerde hiçbir zaman bir darboğazla karşılaşmadı.
** Tek bir YCSB örneğindeki maksimum iş parçacığı sayısı 400'dür. Toplam 2400 iş parçacığı elde etmek için YCSB testlerinin toplam altı paralel örneğinin çalıştırılması gerekiyordu.
Karşılaştırma sonuçlarına, özellikle de CPU yükü ve TPS kombinasyonuna baktığımızda, Cloud Spanner'ın oldukça iyi ölçeklendiğini açıkça görebiliriz. Çok sayıda iş parçacığının oluşturduğu ağır yük, Cloud Spanner kümesindeki çok sayıda düğümle dengelenir. Gecikme oldukça yüksek görünse de, özellikle 2400 iş parçacığıyla çalışırken, daha doğru sayılar elde etmek için hesaplama motorunun 6 küçük örneğiyle yeniden test yapmak gerekebilir. Her örnek, 6 paralel testten oluşan büyük bir CE örneği yerine bir YCSB testi çalıştıracaktır. Bu şekilde, Cloud Spanner istek gecikmesi ile Cloud Spanner ile testi çalıştıran CE örneği arasındaki ağ bağlantısının eklediği gecikmeyi ayırt etmek daha kolay olacaktır.
Cloud Spanner OLAP olarak nasıl performans gösterir?
Bölümleme mi?
Verileri, bölüm adı verilen fiziksel ve/veya mantıksal olarak bağımsız bölümlere bölmek, çoğu OLAP motorunda bulunan çok popüler bir kavramdır. Bölümler, sorgu performansını ve veritabanı sürdürülebilirliğini önemli ölçüde artırabilir. Bölümlendirmenin daha derinlerine inmek ayrı bir makale/makaleler olacaktır, o yüzden bir bölümleme ve alt bölümleme şemasına sahip olmanın öneminden bahsedelim. Verileri bölümlere ve hatta alt bölümlere ayırma yeteneği, analitik sorgu performansının anahtarıdır.
Cloud Spanner bu tür bölümleri desteklemez. Verileri dahili olarak sözde bölümlere ayırır. bölmek-s birincil anahtar aralıklarına dayalıdır. Bölümleme, Cloud Spanner kümesindeki yükü dengelemek için otomatik olarak gerçekleştirilir. Cloud Spanner'ın çok kullanışlı bir özelliği, üst tablonun temel yükünün (başka bir tabloyla serpiştirilmemiş bir tablo) bölünmesidir. Spanner, içerip içermediğini otomatik olarak algılar bölmek diğerlerindeki verilere göre daha sık okunan veriler bölmek-ah ve daha fazla ayrılmaya karar verebilir. Bu şekilde bir isteğe daha fazla düğüm dahil edilebilir ve bu da verimi etkili bir şekilde artırır.
Veri yükleniyor?
Toplu verilere yönelik Cloud Spanner yöntemi, normal yüklemeyle aynıdır. Maksimum performansa ulaşmak için aşağıdakiler de dahil olmak üzere bazı yönergelere uymanız gerekir:
- Verilerinizi birincil anahtara göre sıralayın.
- 10'a bölün*düğüm sayısı ayrı bölümler.
- Verileri paralel olarak yükleyen bir dizi iş görevi oluşturun.
Bu veri yükleme işleminde tüm Cloud Spanner düğümleri kullanılır.
10 milyon satırlık bir veri kümesi oluşturmak için YCSB iş yükü A'yı kullandık.
* Yük testi, n1-standart-32 bilgi işlem motorunda (32 vCPU, 120 GB bellek) gerçekleştirildi ve test örneği, testlerde hiçbir zaman bir darboğazla karşılaşmadı.
**Hiçbir üretim iş yükü için tek düğüm kurulumu önerilmez.
Yukarıda belirtildiği gibi Cloud Spanner, bölmeleri yüklerine göre otomatik olarak işler, böylece ardışık birkaç test tekrarından sonra sonuçlar iyileşir. Burada sunulan sonuçlar elde ettiğimiz en iyi sonuçlardır. Yukarıdaki sayılara baktığımızda, kümedeki düğüm sayısı arttıkça Cloud Spanner'ın nasıl (iyi) ölçeklendiğini görebiliriz. Öne çıkan rakamlar, yukarıdaki bölümde açıklandığı gibi karma iş yükleri (%95 okuma ve %5 yazma) sonuçlarıyla çelişen son derece düşük ortalama gecikmelerdir.
Ölçeklendirme mi?
Cloud Spanner düğümlerinin sayısını artırmak ve azaltmak tek tıklamayla gerçekleştirilen bir iştir. Verileri hızlı bir şekilde yüklemek istiyorsanız örneğinizi maksimuma çıkarmayı (bizim durumumuzda ABD-DOĞU bölgesinde 25 düğümdü) ve tüm veriler yüklendikten sonra normal yüklemeniz için uygun düğüm sayısını azaltmayı düşünebilirsiniz. veritabanı , 2 TB/düğüm sınırına atıfta bulunur.
Çok daha küçük bir veritabanıyla bile bu limit bize hatırlatıldı. Birkaç yükleme testi çalıştırmasından sonra veritabanımızın boyutu yaklaşık 155 GB'a ulaştı ve 1 düğümlü bir örneğe ölçeklendirdiğimizde aşağıdaki hatayı aldık:
Örneği 25'ten 2'ye düşürmeyi başardık ancak iki düğümde sıkışıp kaldık.
Cloud Spanner kümesindeki düğüm sayısını artırmak ve azaltmak, REST API kullanılarak otomatikleştirilebilir. Bu özellikle yoğun çalışma saatleri sırasında artan sistem yükünü azaltmak için yararlı olabilir.
OLAP sorgularının performansı?
Başlangıçta bu kısımda Spanner'ı değerlendirmemize önemli miktarda zaman ayırmayı planlamıştık. Birkaç SELECT COUNT'tan sonra testin kısa süreceğini ve Spanner'ın OLAP için uygun bir motor OLMADIĞINI hemen fark ettik. Kümedeki düğüm sayısından bağımsız olarak, 10M satır tablosundaki satır sayısını seçmek 55 ile 60 saniye arasında sürdü. Ayrıca, ara sonuçları depolamak için daha fazla belleğe ihtiyaç duyan herhangi bir sorgu, bir OOM hatasıyla başarısız oldu.
SELECT COUNT(DISTINCT(field0)) FROM usertable; — (10M distinct values)-> SpoolingHashAggregateIterator ran out of memory during new row.
TPC-H sorgularına ilişkin bazı numaralar Todd Lipcon'un makalesinde bulunabilir. , slayt 42 ve 43. Bu rakamlar bizim sonuçlarımızla tutarlıdır (maalesef).
4. Sonuçlarımız
Cloud Spanner'ın özelliklerinin mevcut durumu göz önüne alındığında, özellikle ihtiyaçlarınız bunu aştığında, bunun mevcut OLTP çözümünüzün basit bir alternatifi olduğunu hayal etmek zor. Cloud Spanner'ın eksikliklerine çözüm bulmak için önemli miktarda zaman harcanması gerekecektir.
Cloud Spanner'ı değerlendirmeye başladığımızda yönetim özelliklerinin diğer Google SQL çözümleriyle aynı seviyede olmasını veya en azından onlardan çok da uzak olmamasını bekliyorduk. Ancak yedeklemelerin tamamen eksikliği ve kaynaklara erişim üzerindeki kontrolün çok sınırlı olması bizi şaşırttı. Görünüm yok, yerel geliştirme ortamı yok, desteklenmeyen diziler, DML ve DDL desteği olmayan JDBC vb.'den bahsetmiyorum bile.
Peki işlemsel bir veritabanını ölçeklendirmesi gereken biri nereye gider? Piyasada tüm kullanım durumlarına uyan tek bir çözüm yok gibi görünüyor. Her birinin kendine özgü güçlü ve zayıf yönleri olan çok sayıda kapalı ve açık kaynak çözümü vardır (bazıları bu makalede belirtilmiştir), ancak hiçbiri %99,999 SLA ve yüksek tutarlılığa sahip SaaS sunmamaktadır. Ana hedefiniz yüksek bir SLA ise ve özel bir çoklu bulut çözümü oluşturma eğiliminde değilseniz Cloud Spanner, aradığınız çözüm olabilir. Ancak tüm sınırlamalarının farkında olmalısınız.
Adil olmak gerekirse, Cloud Spanner yalnızca 2017 baharında halka sunuldu, bu nedenle mevcut eksikliklerinden bazılarının eninde sonunda ortadan kalkacağını (umarız) ve bunu yaptıklarında oyunun kurallarını değiştirebileceğini beklemek mantıklıdır. Sonuçta Cloud Spanner Google için yalnızca bir yan proje değil. Google bunu diğer Google ürünleri için temel olarak kullanır. Google yakın zamanda Google Cloud Storage'daki Megastore'u Cloud Spanner ile değiştirdiğinde, Google Cloud Storage'ın küresel ölçekteki nesne listeleri için oldukça tutarlı hale gelmesine olanak tanıdı (bu durum hala geçerli değil) ).
Yani hâlâ umut var... Umarız.
Bu kadar. Yazının yazarı gibi biz de umut etmeye devam ediyoruz ama siz bu konuda ne düşünüyorsunuz? Yorumlara yazın
Herkesi sitemizi ziyaret etmeye davet ediyoruz Bu kursta size kurs hakkında detaylı bilgi vereceğiz OTUS'tan.
Kaynak: habr.com