How strategic database migration + data (re)modeling improved latencies and cut database costs 5X ZEE, Hindistan'ın en büyük medya ve eğlence işletmesidir, yayın televizyonu, filmleri, akış medyası ve müziği kapsar. ZEE5, 190'den fazla ülkede ~150 milyon aylık aktif kullanıcıya sahip olan önde gelen OTT akış hizmetidir. ve her kullanıcının oynatma deneyimi, güvenlik ve önerileri günde 100B+ kalp atışını işleyen bir "kalp atışı API"na dayanır. Sistemin arkasındaki mühendisler, işletmelerin devamlı büyümesinin altyapısını (ve veritabanı faturalarını inceleyen kişileri) vurgulayacağını biliyordu. Bu nedenle, ekibi, herhangi bir kalp krizi geçirmeden önce sistemin yeniden düşünmeye karar verdi. TL;DR, içeride ve kullanıcılar tarafından sevilen bir sistem tasarladılar. ve Jivesh Threja (Tech Lead) ve Srinivas Shanmugam (Başarılı Mimar) geçmiş yıl Valentine Günü'nde deneyimlerini paylaşmak için bize katıldılar. Değişim için teknik gereksinimleri ( bulut tarafsızlığı, çok kiracının hazırlığı, yeni kullanım durumlarının kolaylıkla onboard edilmesi ve optimum maliyetlerde yüksek geçiş ve düşük gecikme) ve bunun ScyllaDB'ye nasıl yol açtığını ve ardından hedeflerini yeni bir akış işleme boru hattı, yeni bir API tabakası ve veri (re)modelleriyle nasıl gerçekleştirdiklerini açıklamışlar. Toplayarak, ScyllaDB'yi kullanmayı düşünen veya kullanan herkese fayda sağlayabilecek dersleri paylaştılar. 5X cost savings (from $744K to $144K annually) and single-digit millisecond P99 read latency https://youtu.be/nArmqus9fbo?embedable=true İşte o konuşmanın bazı önemli noktaları... Bir Heartbeat Nedir? “Heartbeat”, ZEE5 OTT platformunda video oynatma sırasında düzenli aralıklarla başlatılan bir isteğe işaret eder. Bu basit istekleri, kullanıcıların ne izlediğini ve her videoda ne kadar ilerlediğini izlemek için kullanılır. Bunlar, kullanıcıların bir aygıtta içeriği durdurmalarına ve ardından herhangi bir aygıtta devam etmelerine olanak sağlayan ZEE5’in “sürekli izleme” işlevselliği için gereklidir. Neden Değişmek? ZEE5'in orijinal kalp atışı sistemi, her biri akış deneyiminin belirli bir bölümünü ele alan farklı veritabanlarının bir webiydi. Ekip, altyapısını kolaylaştırma fırsatını tanıdılar ve bunu aradılar. herhangi bir belirli bulut sağlayıcısına kilitlenmemiş bir sistem istiyorlardı, işletme maliyeti daha düşük olurdu ve büyük ölçeklerini sürekli hızlı performansla ele alabilirlerdi – özellikle tek rakamlı milisekundelik yanıtlar. Artı, yeni özellikleri kolayca ekleme esnekliği ve sistemlerini diğer akış platformlarına sunma yeteneğini istiyorlardı. Srinivas dediği gibi: “Herhangi bir OTT sağlayıcısı için yeniden kullanılabilmesi için çok kiracı hazır olması gerekiyordu. Sistem mimarisi, önce ve sonra İşte birkaç veri tabanına sahip orijinal sistem mimarisine bir göz atın: DynamoDB, temel kalp atış verilerini depolayacak Amazon RDS, sonraki ve önceki bölüm bilgileri depolayabilir Apache Solr kalıcı metadata depolamak için Metadata Cache için bir Redis örneği İzleyicilik detaylarını depolamak için başka bir Redis örneği ZEE5 ekibi bu proje için dört ana veritabanı seçeneğini gözden geçirdi: Redis, Cassandra, Apache Ignite ve ScyllaDB. Değerlendirme ve benchmarking sonrasında, ScyllaDB'yi seçtiler. Kalıcı veritabanının üstünde ekstra bir bellek katmanı gerektirmez. ScyllaDB, aynı altyapıda hem bellek katmanı hem de kalıcı veritabanını yönetir, bölgeler arası düşük gecikme, replika ve çok bulut hazırlığı sağlar. Azure, AWS ve GCP de dahil olmak üzere herhangi bir bulut sağlayıcısı ile çalışır ve şimdi bir saatten daha az bir dönüm süresi ile yönetilen destek sunar. Kalıcı veritabanının üstünde ekstra bir bellek katmanı gerektirmez. ScyllaDB, aynı altyapıda hem bellek katmanı hem de kalıcı veritabanını yönetir, bölgeler arası düşük gecikme, replika ve çok bulut hazırlığı sağlar. Azure, AWS ve GCP de dahil olmak üzere herhangi bir bulut sağlayıcısı ile çalışır ve şimdi bir saatten daha az bir dönüm süresi ile yönetilen destek sunar. Yeni mimari, önceki sistem mimarisi yapısını basitleştirir ve düzleştirir. Şimdi, tüm kalp atışları olayları kalp atışları konusuna basılır, akış işleme aracılığıyla işlenir ve ScyllaDB Cloud'a ScyllaDB bağlantıları kullanılarak eklenir. içerik yayınlandığında, metadata konusuna eklenir ve daha sonra metadata bağlantıları aracılığıyla ScyllaDB Cloud'a eklenir. Srinivas, “Bu yeni mimari ile, DynamoDB, RDS, Redis ve Solr’dan ScyllaDB’ye çalışma yüklerini başarıyla taşıdık. ” 5x cost reduction, bringing our monthly expenses down from $62,000 to around $12,000. Tasarımın içine daha derin Jivesh, düşük seviyeli tasarımlarından daha fazlasını paylaştı... Gerçek Zamanlı Akış İşleme Pipeline Gerçek zamanlı akış işleme borusunda, kalp atışları düzenli aralıklarla ScyllaDB'ye gönderilir. Kalp atışları aralığı 60 saniye olarak ayarlanır, bu da kullanıcılar bir video izlerken her 60 saniyede bir kalp atışını gönderir.Bu kalp atışları oynatma akışı işleme sisteminden geçer, iş mantığı tüketiciler bu verileri gerekli biçime dönüştürür - işlenen veriler ScyllaDB'de depolanır. Scalable API Çerçeve Ölçülebilir API katmanının ilk bileşeni, büyük miktarda veri işleme sorumlusu olan heartbeat hizmetidir. Topics verileri işler, sonra bir konektör hizmeti üzerinden geçer ve ScyllaDB'de depolanır. Diğer önemli bir API katmanı hizmeti de Concurrent Viewership Count hizmetidir. Bu hizmet ScyllaDB'yi kullanarak kullanıcı başına veya varlık başına (örneğin, kimlik başına) eşzamanlı izleme verilerini almak için kullanır. örneğin, bir film yayınlanırsa, bu hizmet filmin herhangi bir zamanda kaç kullanıcının izlediğini söyleyebilir. Metadata Yönetimi Kullanımı ZEE5'in karşılaştığı ilk büyük zorluklardan biri, büyük OTT platformları için metadata yönetmekti. Başlangıçta, geniş metadata ihtiyaçlarını karşılamak için üç farklı veri tabanının bir kombinasyonuna güveniyorlardı - Solr, Redis ve Postgres. optimize etmek ve basitleştirmek için, veri modelini ScyllaDB ile çalışmak için yeniden tasarladılar - ID'yi bölünme anahtarı olarak kullanarak, materyalleşmiş görüntülerle birlikte. İşte metadata modeline bir göz atalım: create keyspace.meta_data ( id text, title text, show_id text, …, …, PRIMARY KEY((id),show_id) ) with compaction = {‘class’: ‘LeveledCompactionStrategy’ }; Bu tablo nispeten az yazma deneyimi (bir yazma yalnızca yeni bir varlık serbest bırakıldığında meydana gelir) ama önemli ölçüde daha fazla okuma olduğu için, performansını optimize etmek için Leveled Compaction Stratejisi kullandılar. Görüntüleme Sayısı Case Görüntü Sayısı, ScyllaDB'ye taşındıkları başka bir kullanım durumudur. Görüntü sayısı kullanıcıya veya varlık kimliğine göre izlenebilir. ZEE5, kullanıcı kimliğinin bölünme anahtarı ve varlık kimliğinin sıralama anahtarı olarak hizmet ettiği bir tablo tasarlamaya karar verdi. ScyllaDB'nin TTL'sini 60 saniyelik kalp atış aralığına eşleştirecek şekilde ayarladılar, böylece verilerin belirlenen süreden sonra otomatik olarak sona ermesini sağladılar. Jivesh, “Bu tablo sürekli olarak her ön ucundan ve her kullanıcıdan kalp atışları ile güncellenir. kalp atışları geldiğinde, izleyicilerin sayısı gerçek zamanlı olarak izlenir ve TTL'nin sona erdiğinde otomatik olarak temizlenir. İşte izleyiciler sayısı veri modeli: CREATE TABLE keyspace.USER_SESSION_STREAM ( USER_ID text, DEVICE_ID text, ASSET_ID text, TITLE text, …, PRIMARY KEY((USER_ID), ASSET_ID) ) WITH default_time_to_live = 60 and compaction = { 'class' : 'TimeWindowCompactionStrategy' }; ScyllaDB Sonuçları ve Öğrenilen Dersler Aşağıdaki yük test raporu saniyede 41.7K talebi göstermektedir.Bu referans, yüksek yük altında performans değerlendirmek için veritabanı seçim sürecinde gerçekleştirilmiştir. Jivesh, “Böyle yüksek bir geçişle bile, mikrosekundaki yazma gecikmesine ve ortalama mikrosekundaki okuma gecikmesine ulaşabiliriz. Daha sonra, ZEE5'in ScyllaDB dağıtımının ölçeğine ışık veren bazı gerçekleri paylaşmaya devam etti: “ScyllaDB’de yaklaşık 9 TB var. Bu kadar büyük bir veri hacmi olsa bile, mikrosekundaki gecikmeleri ve çok büyük olan tek rakamlı bir milisekundaki gecikmelerle başa çıkabiliyor. Her saniye, ScyllaDB'ye o kadar çok veri yazıyoruz ve o kadar çok veriyi çıkarıyoruz. Günde 100 milyardan fazla kalp atışını işleriz, bu oldukça büyük.” Konuşma aşağıdaki derslerle tamamlandı: Veri modelleme, tek rakamlı milisekundik latensiyel ulaşmada en kritik faktördür. Doğru kuorum ayarını ve sıkıştırma stratejisini seçin. örneğin, okuma yapılmadan önce her düğmeye bir kalp atışı yazılmalı mı, yoksa yerel kuorum yeterli mi? Doğru kuorum seçmek, gecikme ve SLA gereksinimleri arasında en iyi dengeyi sağlar. Bölüm ve Gruplama Anahtarları akıllıca seçin - onları daha sonra değiştirmek kolay değildir. Daha hızlı arama yapmak ve filtreleme sorularından kaçınmak için Madde Görüntüleri'ni kullanın. partisyonlar arası arama performansını azaltabilir. Verimliliği artırmak için hazırlanmış ifadeler kullanın. Örneğin, metadata modelinde, 20 eşzamanlı sorgu paralel olarak yürütüldü ve ScyllaDB bunları milisekunder içinde işledi. Zone-aware ScyllaDB müşterileri, cross-AZ (Availability Zone) ağ maliyetlerini azaltmaya yardımcı olur. aynı AZ içinde veri toplama, gecikmeyi en aza indirir ve ağ masraflarını önemli ölçüde azaltır.
