Google, Büyük Sorgu Tablolarınızı Nasıl Saklar ve Sizi Nasıl Etkiler?

Bu, blogumuzun size özel geliştirici Adam Knox tarafından sunulan bir teknik konuşma yüklemesidir.

Big Query, SQL'e çok benzer bir sözdizimi kullanıyor olsa da, aslında büyük miktarda veriyi işlemek için bir çözümden önemli ölçüde farklı bir incelik gerektirir. Big Query, şeyleri kaba kuvvete zorlama eğilimindedir ve aslında dizinleri kullanmaz, bu nedenle çok fazla veri, çok sayıda işlemci ve işlem süresi anlamına gelir. Bunu başarmak için Google, sorgularınızı tasarlama şeklinizi etkileyebilecek farklı bir veri depolama yöntemi kullandı.

Dosya formatı

Bir tablo oluşturulduğunda Google, verilerinizi depolamak için kendi ColumnIO biçimini kullanır. Her sütun, istisna olarak yinelenen alanlar olmak üzere ayrı bir dosya olarak saklanır. Şu sütunları içeren bir tablonuz varsa: name (string), phoneNumbers (yinelenen tamsayı); ad, diğer adlarla birlikte tek bir satırda saklanacak ve bu adla ilişkili tüm telefon numaraları, telefon numaralarıyla birlikte tek bir satırda saklanacaktır. Sütunlar da çok büyürlerse bölünebilir, ancak bunun iş akışı üzerinde bir etkisi olmaz.

Bunu bilmek, aslında umursamadığınız sütunları işlemeyerek daha hızlı sorgular çalıştırma yeteneği sağlar ve hatta bazı durumlarda sorguları çalıştırmayı daha önce imkansız hale getirir. Sistem, işlenen veri miktarına göre ücret aldığından ve sorguya bir sütun eklenmezse, bu veriler işlenmediğinden sorgular da daha ucuza gelebilir.

Dosya Depolama

Bir tablo oluşturduysanız, hiçbir yere gitmeyeceği konusunda oldukça güvende hissedebilirsiniz, çünkü dosyalarınız oluşturulduktan sonra, bunlar üç farklı veri merkezinde ve hatta her veri merkezinde üç farklı yerde depolanır. Big Query, işlemcileri sorunlara attığından, verilerin kolayca erişilebilir olması gerekir. Bunun uyarısı geçici veri kümeleridir. Bir veri kümesi içindeki tablolar için bir sona erme süresi belirleme seçeneği vardır ve tablolar bu sona erme tarihinden daha eski olduğunda kaybolur.

Tablo Hiyerarşisi

Bir proje, her biri tablo içerebilen veri kümelerini saklama yeteneğine sahiptir. Big Query sözdiziminde bir tabloya erişmek için tam komut [projectname:datasetname.tablename] , ancak tabloya şu anda üzerinde çalıştığınız projeden erişiyorsanız bu, dataset.tablename olarak kısaltılabilir.

İlgili verileri ayrı tablolara bölmek (örneğin, tarihe göre veya belirli bir olay gerçekleştikten sonra), sorgular genellikle bir tablodaki tüm satırlarda çalıştığından, daha sürdürülebilir sorgular yapmak için faydalı olabilir. Bu, birden çok tabloya bakmak isteyebileceğiniz anlamına gelir; bu nedenle, her veri kümesinde gizlenmiş ve [projectname:datasetname.__TABLES__] adresinden erişilebilen ve veri kümesindeki her bir tablo hakkında bilgi içeren ve aşağıdakiler için tabloları toplamak için kullanılabilen meta tablo adı verilen bir şey vardır. sorgulama.

TABLE_QUERY komutu, toplama üzerinde bir sorgu çalıştırmadan önce birden çok benzer tablonun toplanmasına izin veren bir komuttur ve bu toplamayı oluşturmak için __TABLES__ içindeki herhangi bir sütun kullanılabilir. Örneğin, bir proje için 1 Ocak 2016'dan bu yana yanıt süreleri hakkında bir fikir edinmek istersem, minimum, medyan ve maksimum yanıt sürelerini gösteren aşağıdaki sorguyu çalıştırabilirim:

 SELECT QUANTILES((protoPayload.endTime - protoPayload.startTime), 3) AS responseTimeBucketsInMilliseconds FROM (TABLE_QUERY(appengine_logs, "table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000"))

Her biri tamsayı içeren yalnızca iki sütun kullanıldığından, bu hala oldukça ucuz bir sorgu (0,0003 ABD doları), 28+'e erişiyor olsa da, aşağıdaki sorgu tarafından bana söylenen 1.857 TB olduğu ve her alana erişmek için yaklaşık 9 ABD dolarına mal olacağı söylendi. .

 SELECT SUM(size_bytes)/1000000000 FROM [repcore-prod:appengine_logs.__TABLES__] WHERE table_id CONTAINS 'appengine_googleapis_com_request_log' AND creation_time > 1451606400000

Dosyaları Güncelleme

Bir tabloya yeni satırlar aktarabileceğiniz için Big Query, değişiklikleri günlüğe kaydetme ve söz konusu değişiklikleri analiz etme konusunda harikadır. Bununla birlikte, dizinlerin olmaması nedeniyle belirli satırların hızlı ve sık aranması için korkunç bir veri depolama aygıtıdır ve ayrıca bir tablodaki satırlar değiştirilemeyeceği veya kaldırılamayacağı için değiştirmeyi umduğunuz nesnelerin tekil temsillerini depolama konusunda da iyi değildir. .

Bölme Tabloları

Bazı durumlarda, tek bir sütuna erişmek bile Big Query'de ele alınamayacak kadar fazladır. Listeleme oluşturma tarihine göre listeleme kimliklerini döndüren aşağıdaki kullanılamaz sorguyu size sunuyorum:

 SELECT lid FROM [repcore-prod:datastore.LIS] ORDER BY ct

Teknik olarak, bunun başarılı olması yakın zamanda mümkün oldu, ancak daha yüksek bir faturalandırma katmanının etkinleştirilmesini gerektirdiğinden Vendasta'daki insanlar için değil. Önceden sipariş edilmiş endeksler olmadığından, az miktarda veriyi çok yoğun bir şekilde işliyor, bu durumda işlem için ücret alıyorlar. Faturalandırma katmanını değiştirmek, Big Query kullanıcı arayüzündeki etkileşimli sorgularda, "seçenekler" düğmesi altında "sınırsız izin ver" (etkinleştirilmişse) işaretlenerek yapılabilir.

Sorgunuzun olabildiğince verimli olduğunu varsayarsak, bu tür katı sınırları aşmak için tablo boyutlarını ayrıştırmak için birkaç yaklaşım kaldı. Birincisi masa zamanı dekoratörleri ve ikincisi bir hash ile.

Burada masa dekoratörleri hakkında daha fazla bilgi edinebilirsiniz. LIMIT/WHERE/HAVING/OMIT gibi komutları kullanarak sonuçları filtrelemenin aksine, tablo dekoratörleri aslında bir tabloyu sorgulamanın maliyetini düşürür, çünkü verilen aralığın dışındaki verilere bile erişemez. Ne yazık ki, bu yöntem Vendasta'da işe yaramaz çünkü aslında akış yaptığımız ListingHistoryModel gibi tablolar için bile, yine de tüm tabloyu bırakıp her gün NDB'den bir kopya ile değiştiriyoruz, yani tablo zamanı dekoratörleri yalnızca üzerinde çalışacak. ListingHistoryModel, yalnızca geçerli günün girişlerini önemsiyorsanız.

Günlüğe kaydetmeye bakmak, Vendasta'da oldukça yardımcı olabilecekleri tek yerdir. Gerçek günlük içeriğinin boyutu nedeniyle, hesaplama ve bellek sınırlarına ulaşmak kolaydır ve yalnızca günlük içeriği sütununu sorgulamak bile pahalıdır. Günlüklerle, genellikle yalnızca zamandaki belirli noktalarla ilgilenilir, bu da tam olarak zaman dekoratörünün yardımcı olduğu şeydir.

Sorgu Sonuçları

Her sorgu çalıştırdığınızda, yeni bir tablo oluşturur ve bazen arka planda bilinmeyen gizli tablolar oluşturur. İsterseniz, sonuç tablosuna tutması için bir ad verebilir veya google'ın verdiği adla kalmasına ve bir gün sonra kaybolmasına izin verebilirsiniz. “Geri döndürülemeyecek kadar büyük bir Tepki” ile karşılaşırsanız, bunun nedeni sizi kendinizden korumalarıdır. Muazzam tablolar oluşturmak kolaydır (özellikle çapraz birleşimlerle). Bu olursa ve olmasını bekliyorsanız, tabloyu adlandırmanız ve “Büyük Sonuçlara İzin Ver” seçeneğini etkinleştirmeniz gerekir. Yeni satır akışı olmayan bir sorguyu tekrarlarsanız, hala etraftalarsa önbelleğe alınmış sonuçları alırsınız.