Hayatta her şeyin en az bir kez denemeye değer olduğunu söylüyorlar. Ve ilişkisel DBMS'lerle çalışmaya alışkınsanız, en azından genel gelişim için her şeyden önce pratikte NoSQL ile tanışmaya değer. Artık bu teknolojinin hızla gelişmesi nedeniyle, bu konu hakkında pek çok çelişkili görüş ve hararetli tartışma var ve bu da özellikle ilgiyi artırıyor.
Tüm bu anlaşmazlıkların özüne inerseniz, bunların yanlış yaklaşımdan kaynaklandığını görebilirsiniz. NoSQL veritabanlarını tam ihtiyaç duyulan yerde kullananlar bu çözümden memnun kalıyor ve tüm avantajlardan yararlanıyor. Ve hiçbir şekilde uygulanamadığı durumlarda bu teknolojiye her derde deva olarak güvenen deneyciler, önemli faydalar elde etmeden ilişkisel veritabanlarının gücünü kaybetmiş oldukları için hayal kırıklığına uğradılar.
Cassandra DBMS'ye dayalı bir çözümün uygulanmasındaki deneyimimizi size anlatacağım: Nelerle yüzleşmek zorunda kaldık, zor durumlardan nasıl çıktık, NoSQL kullanmanın faydasını görebildik mi ve nereye ek çaba/fon yatırımı yapmamız gerekiyordu? .
İlk görev, çağrıları bir tür depolama alanına kaydeden bir sistem oluşturmaktır.
Sistemin çalışma prensibi aşağıdaki gibidir. Giriş, çağrının yapısını tanımlayan belirli bir yapıya sahip dosyaları içerir. Uygulama daha sonra bu yapının uygun sütunlarda saklanmasını sağlar. Gelecekte kaydedilen çağrılar, abonelerin trafik tüketimine ilişkin bilgileri (ücretler, çağrılar, bakiye geçmişi) görüntülemek için kullanılacak.
Neden Cassandra'yı seçtikleri çok açık; makineli tüfek gibi yazıyor, kolayca ölçeklenebiliyor ve hataya dayanıklı.
İşte deneyimin bize kazandırdığı şey bu
Evet, başarısız bir düğüm bir trajedi değildir. Cassandra'nın hata toleransının özü budur. Ancak bir düğüm canlı olabilir ve aynı zamanda performansta sorun yaşamaya başlayabilir. Anlaşıldığı üzere, bu durum tüm kümenin performansını anında etkiliyor.
Oracle'ın sizi kısıtlamalarıyla kurtardığı yerde Cassandra sizi koruyamayacak. Başvurunun yazarı bunu önceden anlamadıysa, Cassandra'ya gelen ikili orijinalinden daha kötü değildir. Geldiğinde onu koyacağız.
IB, kutudan çıkan ücretsiz Cassandra'yı kesinlikle beğenmedi: Kullanıcı eylemlerinin günlüğe kaydedilmesi yok, hakların farklılaştırılması yok. Aramalarla ilgili bilgiler kişisel veri olarak kabul edilir; bu, herhangi bir şekilde bu bilgileri talep etmeye/değiştirmeye yönelik tüm girişimlerin daha sonra denetlenme olasılığıyla birlikte kaydedilmesi gerektiği anlamına gelir. Ayrıca, farklı kullanıcılar için farklı düzeylerdeki hakları ayırmanın gerekliliğinin bilincinde olmanız gerekir. Basit bir operasyon mühendisi ve anahtar alanının tamamını serbestçe silebilen bir süper yönetici, farklı roller, farklı sorumluluklar ve yeterliliklerdir. Erişim haklarında bu tür bir ayrım yapılmazsa, verilerin değeri ve bütünlüğü HERHANGİ bir tutarlılık seviyesinden daha hızlı bir şekilde sorgulanmaya başlayacaktır.
Çağrıların hem ciddi analizler hem de çeşitli koşullar için periyodik örnekleme gerektirdiğini hesaba katmadık. Seçilen kayıtların daha sonra silinmesi ve yeniden yazılması gerektiğinden (görevin bir parçası olarak, veriler döngümüze başlangıçta yanlış girdiğinde verileri güncelleme sürecini desteklemeliyiz), Cassandra burada bizim dostumuz değil. Cassandra bir kumbara gibidir - içine bir şeyler koymak kolaydır, ancak buna güvenemezsiniz.
Verileri test bölgelerine aktarırken bir sorunla karşılaştık (Testte 5 düğüme karşılık baloda 20 düğüm). Bu durumda döküm kullanılamaz.
Cassandra'ya yazan bir uygulamanın veri şemasını güncelleme sorunu. Geri alma işlemi çok sayıda mezar taşı oluşturacaktır ve bu da öngörülemeyen şekillerde üretkenlik kayıplarına yol açabilir.. Cassandra kayıt için optimize edilmiştir ve yazmadan önce fazla düşünmez.İçinde mevcut verilerle yapılan herhangi bir işlem aynı zamanda bir kayıttır. Yani, gereksiz olanları silerek, daha da fazla kayıt üreteceğiz ve bunların yalnızca bir kısmı mezar taşlarıyla işaretlenecek.
Ekleme sırasında zaman aşımları. Cassandra kayıtta çok güzel ama bazen gelen akış onu önemli ölçüde şaşırtabilir. Bu durum, uygulama herhangi bir nedenle eklenemeyen birden fazla kayıt arasında geçiş yapmaya başladığında meydana gelir. Ve yavaş sorgular için gc.log'u, sistemi ve hata ayıklama günlüklerini ve bekleyen sıkıştırma ölçümlerini izleyecek gerçek bir DBA'ya ihtiyacımız olacak.
Bir kümedeki birden fazla veri merkezi. Nereden okunmalı, nereye yazılmalı?
Belki okuma ve yazmaya ayrılmıştır? Ve eğer öyleyse, yazma veya okuma için uygulamaya daha yakın bir DC olmalı mı? Yanlış tutarlılık seviyesini seçersek gerçekten bölünmüş bir beyinle sonuçlanmaz mıyız? Gerçekten kurcalamak isteyeceğiniz pek çok soru, pek çok bilinmeyen ayar ve olasılık var.
Nasıl karar verdik
Düğümün batmasını önlemek için SWAP devre dışı bırakıldı. Ve şimdi, eğer bellek eksikliği varsa, düğümün aşağı inmesi ve büyük gc duraklamaları yaratmaması gerekir.
Yani artık veritabanındaki mantığa güvenmiyoruz. Uygulama geliştiricileri kendilerini yeniden eğitiyor ve kendi kodlarında aktif olarak önlem almaya başlıyorlar. Veri depolama ve işlemenin ideal ve net bir şekilde ayrılması.
DataStax'tan destek satın aldık. Kutulu Cassandra'nın geliştirilmesi zaten durduruldu (son taahhüt Şubat 2018'de yapıldı). Datastax aynı zamanda mükemmel hizmet ve mevcut IP çözümleri için çok sayıda değiştirilmiş ve uyarlanmış çözüm sunmaktadır.
Ayrıca Cassandra'nın seçim sorguları için pek uygun olmadığını da belirtmek isterim. Elbette CQL, kullanıcılar için ileriye doğru büyük bir adımdır (Trift'e kıyasla). Ancak bu tür uygun birleştirmelere, herhangi bir alana göre ücretsiz filtrelemeye ve sorgu optimizasyon yeteneklerine alışkın olan tüm departmanlarınız varsa ve bu departmanlar şikayetleri ve kazaları çözmek için çalışıyorsa, Cassandra'daki çözüm onlara düşmanca ve aptalca görünüyor. Ve meslektaşlarımızın numuneleri nasıl yapması gerektiğine karar vermeye başladık.
İki seçeneği değerlendirdik, ilk seçenekte çağrıları yalnızca C* dilinde değil, arşivlenmiş Oracle veritabanına da yazıyoruz. Yalnızca, C*'dan farklı olarak, bu veritabanı yalnızca geçerli aya ait çağrıları saklar (şarj durumları için yeterli çağrı depolama derinliği). Burada hemen şu sorunu gördük: Eğer eşzamanlı yazarsak, C*'nın hızlı eklemeyle ilgili tüm avantajlarını kaybederiz; eğer eşzamansız yazarsak, gerekli tüm çağrıların Oracle'a ulaştığının hiçbir garantisi yoktur. Bir artı vardı ama büyük bir artı: operasyon için aynı tanıdık PL/SQL Geliştiricisi kalıyor, yani pratikte "Cephe" modelini uyguluyoruz. Alternatif bir seçenek. Çağrıları C*'dan kaldıran, Oracle'daki ilgili tablolardan zenginleştirme için bazı verileri çeken, ortaya çıkan örnekleri birleştiren ve bize sonucu veren ve daha sonra bir şekilde kullandığımız (geri alma, tekrarlama, analiz etme, beğenme) bir mekanizma uyguluyoruz. Eksileri: Süreç oldukça çok adımlıdır ve ayrıca operasyon çalışanları için bir arayüz yoktur.
Sonunda ikinci seçeneğe karar verdik. Farklı kavanozlardan numune almak için Apache Spark kullanıldı. Mekanizmanın özü, belirtilen anahtarları (abone, çağrı süresi - bölüm anahtarları) kullanarak, C*'dan verileri ve ayrıca diğer herhangi bir veritabanından zenginleştirme için gerekli verileri çeken Java koduna indirgenmiştir. Daha sonra bunları hafızasında birleştirir ve sonucu sonuç tablosunda görüntüler. Kıvılcımın üzerine bir ağ yüzü çizdik ve oldukça kullanışlı olduğu ortaya çıktı.
Endüstriyel test verilerini güncelleme sorununu çözerken yine birkaç çözümü düşündük. Hem Sstloader aracılığıyla aktarım hem de test bölgesindeki kümeyi, her biri dönüşümlü olarak promosyon kümesiyle aynı kümeye ait olan ve dolayısıyla onun tarafından desteklenen iki parçaya bölme seçeneği. Testi güncellerken bunların değiştirilmesi planlandı: testte çalışan kısım temizlendi ve üretime alındı, diğeri ise verilerle ayrı olarak çalışmaya başladı. Ancak tekrar düşündükten sonra, aktarmaya değer verileri daha rasyonel bir şekilde değerlendirdik ve çağrıların, gerektiğinde hızlı bir şekilde oluşturulan, testler için tutarsız bir varlık olduğunu ve tanıtım veri kümesinin aktarılma açısından hiçbir değeri olmadığını fark ettik. Ölçek. Taşımaya değer birkaç depolama nesnesi var, ancak bunlar kelimenin tam anlamıyla birkaç masa ve çok ağır değil. Bu nedenle, biz Çözüm olarak Spark yine kurtarmaya geldi, bunun yardımıyla tablolar arasında veri aktarımı için bir komut dosyası, prom-test yazdık ve aktif olarak kullanmaya başladık.
Mevcut dağıtım politikamız geri alma olmadan çalışmamıza olanak sağlıyor. Promosyondan önce, bir hatanın çok pahalı olmadığı zorunlu bir test çalışması vardır. Başarısızlık durumunda, her zaman kasa alanını bırakabilir ve tüm şemayı baştan başlatabilirsiniz.
Cassandra'nın sürekli kullanılabilirliğini sağlamak için yalnızca ona değil, bir veritabanına da ihtiyacınız var. Uygulamayla çalışan herkesin mevcut duruma nereden ve nasıl bakacağını, sorunların zamanında nasıl teşhis edileceğini anlaması gerekiyor. Bunu yapmak için DataStax OpsCenter'ı (iş yüklerinin yönetimi ve izlenmesi), Cassandra Sürücü sistemi metriklerini (C*'ye yazmak için zaman aşımı sayısı, C*'dan okumak için zaman aşımı sayısı, maksimum gecikme vb.) aktif olarak kullanıyoruz, işlemi izliyoruz Uygulamanın kendisi Cassandra ile çalışıyor.
Bir önceki soruyu düşündüğümüzde asıl riskimizin nerede olabileceğini anladık. Bunlar, birkaç bağımsız sorgudan gelen verileri depolamaya görüntüleyen veri görüntüleme formlarıdır. Bu şekilde oldukça tutarsız bilgiler elde edebiliriz. Ancak bu sorun yalnızca tek bir veri merkeziyle çalışsaydık da aynı derecede geçerli olurdu. Dolayısıyla buradaki en makul şey elbette üçüncü taraf bir uygulamadaki verileri okumak için verilerin tek bir zaman diliminde alınmasını sağlayacak bir toplu iş işlevi oluşturmaktır. Performans açısından okuma ve yazma ayrımına gelince, burada DC'ler arasındaki bağlantının bir miktar kaybıyla birbiriyle tamamen tutarsız iki kümeyle sonuçlanma riski nedeniyle durdurulduk.
Sonuç olarak şimdilik EACH_QUORUM yazmak için, LOCAL_QUORUM okumak için tutarlılık düzeyinde durduruldu
Kısa izlenimler ve sonuçlar
Ortaya çıkan çözümü operasyonel destek ve daha fazla gelişme beklentileri açısından değerlendirmek için, böyle bir gelişmenin başka nerede uygulanabileceğini düşünmeye karar verdik.
Hemen ardından "Uygun olduğunda öde" gibi programlar için veri puanlama (bilgileri C*'ya yüklüyoruz, Spark komut dosyalarını kullanarak hesaplama yapıyoruz), alana göre toplama ile taleplerin muhasebeleştirilmesi, rollerin saklanması ve role göre kullanıcı erişim haklarının hesaplanması matris.
Gördüğünüz gibi repertuar geniş ve çeşitlidir. Ve NoSQL'in destekçileri/rakipleri kampını seçersek, avantajlarımızı aldığımız için ve tam olarak beklediğimiz yerde destekçilere katılacağız.
Kutudan çıkan Cassandra seçeneği bile gerçek zamanlı olarak yatay ölçeklendirmeye izin vererek sistemdeki artan veri sorununu kesinlikle acısız bir şekilde çözer. Çağrı toplamlarını hesaplamak için çok yüksek yüklü bir mekanizmayı ayrı bir devreye taşıyabildik ve ayrıca uygulama şemasını ve mantığını ayırarak özel işleri ve nesneleri veritabanının kendisine yazmanın kötü uygulamasından kurtulduk. Hangi DC'lerde hesaplama yapacağımızı, hangilerine veri kaydedeceğimizi seçme ve yapılandırma, hızlandırma fırsatına sahip olduk, hem bireysel düğümlerin hem de DC'nin tamamının çökmesine karşı kendimizi sigortaladık.
Mimarimizi yeni projelere uygulayarak ve zaten biraz deneyime sahip olarak, yukarıda açıklanan nüansları hemen dikkate almak, bazı hataları önlemek, başlangıçta kaçınılamayan bazı keskin köşeleri düzeltmek istiyorum.
Örneğin, Cassandra'nın güncellemelerini zamanında takip edinçünkü karşılaştığımız sorunlardan birçoğu zaten biliniyordu ve düzeltildi.
Hem veritabanını hem de Spark'ı aynı düğümlere koymayın (veya kesinlikle izin verilen kaynak kullanım miktarına bölün), çünkü Spark beklenenden daha fazla OP tüketebilir ve listemizden 1 numaralı sorunu hızla alacağız.
Proje test aşamasında izleme ve operasyonel yetkinliği geliştirin. Başlangıçta, çözümümüzün tüm potansiyel tüketicilerini mümkün olduğunca dikkate alın, çünkü veritabanı yapısı sonuçta buna bağlı olacaktır.
Olası optimizasyon için ortaya çıkan devreyi birkaç kez döndürün. Hangi alanların serileştirilebileceğini seçin. En doğru ve optimum şekilde dikkate almak için hangi ek tabloları yapmamız gerektiğini anlayın ve ardından istek üzerine gerekli bilgileri sağlayın (örneğin, aynı verileri farklı tablolarda saklayabileceğimizi varsayarak, farklı kırılımları dikkate alarak) farklı kriterleri kullanarak okuma istekleri için CPU zamanından önemli ölçüde tasarruf edebiliriz).
Fena değil Derhal TTL eklenmesini ve güncel olmayan verilerin temizlenmesini sağlayın.
Cassandra'dan veri indirirken Uygulama mantığı FETCH ilkesine göre çalışmalıdır, böylece tüm satırlar belleğe aynı anda yüklenmez, toplu olarak seçilir.
Projeyi açıklanan çözüme aktarmadan önce tavsiye edilir Bir dizi çarpışma testi gerçekleştirerek sistemin hata toleransını kontrol edinbir veri merkezinde veri kaybı olması, hasar gören verinin belli bir süre içerisinde onarılması, veri merkezleri arasında ağ kopması gibi. Bu tür testler yalnızca önerilen mimarinin artılarını ve eksilerini değerlendirmeye izin vermekle kalmayacak, aynı zamanda bunları yürüten mühendisler için iyi bir ısınma uygulaması sağlayacak ve sistem arızaları üretimde tekrarlanırsa kazanılan beceri gereksiz olmaktan uzak olacaktır.
Kritik bilgilerle (faturalandırma verileri, abone borcunun hesaplanması gibi) çalışıyorsak, DBMS'nin özelliklerinden dolayı ortaya çıkan riskleri azaltacak araçlara da dikkat etmekte fayda var. Örneğin, kullanımı için en uygun stratejiyi geliştiren nodesync yardımcı programını (Datastax) kullanın. tutarlılık adına Cassandra'ya aşırı yük oluşturmayın ve belirli bir dönemde yalnızca belirli tablolar için kullanın.
Altı aylık hayattan sonra Cassandra'ya ne olacak? Genel olarak çözülmemiş sorun yoktur. Ayrıca ciddi bir kazaya veya veri kaybına da izin vermedik. Evet, daha önce ortaya çıkmamış bazı sorunları telafi etmeyi düşünmek zorunda kaldık ama sonuçta bu, mimari çözümümüzü büyük ölçüde gölgelemedi. Yeni bir şey denemek istiyorsanız ve korkmuyorsanız ve aynı zamanda fazla hayal kırıklığına uğramak istemiyorsanız, hiçbir şeyin bedava olmadığı gerçeğine hazır olun. Eski eski çözümden daha fazlasını anlamanız, belgeleri incelemeniz ve kendi bireysel tırmığınızı oluşturmanız gerekecek ve hiçbir teori size hangi tırmığın sizi beklediğini önceden söyleyemez.
Kaynak: habr.com