RDBMS modelinden HBase

Eğer uygulamanız için tasarım aşamasındaysanız ve HBase'in iyi bir yer olacağına inanıyorsanız, satır anahtarlarını ve şemasını HBase veri modeli ve mimarisine uyacak şekilde tasarlamak Doğru yaklaşım. Bununla birlikte, bazen başlangıçta bir RDBMS için tasarlanmış bir veritabanını HBase'ye taşımak anlamlıdır.

Bu yaklaşımın mantıklı olduğu ortak bir senaryo, ölçeklenebilirlik sınırlarına ulaşan bir MySQL veritabanı örneğidir. Bir MySQL örneğini yatay olarak ölçekleme teknikleri vardır (başka bir deyişle parçalama, ) ancak bu süreç genellikle hantaldır ve sorunludur, çünkü MySQL basitçe parçalanma için tasarlanmamıştır.

İlişkisel modelden HBase modeline geçmek nispeten yeni bir disiplindir. Bununla birlikte, belli belirlenmiş düşünce kalıpları ortaya çıkmakta ve bir geçişe yaklaşırken uyulması gereken üç temel prensibe uyumludur. Bu ilkeler denormalizasyon, çoğaltma, ve akıllı anahtarlar (DDI) 'dır.

• Denormalizasyon: İlişkisel veritabanı modeli a) normalleştirilmiş bir veritabanı şemasına ve b) SQL işlemlerine yanıt vermek için tablolar arasında birleşmelere bağlı. Veri tabanı normalizasyonu, veri kaybı, fazlalık ve diğer anormalliklere karşı veri güncelleştirildiğinde ve alınırken güvence altına alınan bir tekniktir.

  Uzmanların normalleştirilmiş bir veritabanı şemasına (ve veritabanı normalleştirme kendi başına bir çalışmaya) ulaşmaları için takip ettiği birkaç kural vardır, ancak süreç genelde daha büyük tabloları daha küçük tablolara bölerek ilişkileri tanımlamaktır onların arasında. Veritabanı denormalizasyonu, daha küçük, daha spesifik tabloların daha büyük, daha genel tablolara eklendiği normalleştirmenin tam tersidir.

  Bu, tablolarda birleşimler sağlanmadığı ve masraflı disk işlemleri gerektirdiği için birleşimlerin yavaş olabileceği için HBase'e geçilirken yaygın bir yöntemdir. Güncelleme ve alım anormalliklerine karşı koruma sağlamak artık HBase istemci uygulamanızın işidir, çünkü normalleştirme yoluyla sağlanan korumalar geçersiz ve geçersizdir.

• Çoğaltma: Veritabanı şemasını denormalize hale getirirken, büyük tablolarda maliyetli okuma işlemlerinden kaçınmanıza yardımcı olabileceğinden, verileri çoğaltabilirsiniz. Ekstra depolama konusunda endişe etmeyin (elbette ki sebeple); HBase'in otomatik ölçeklenebilirliğini avantajınıza kullanabilirsiniz.

  Bununla birlikte, istemci uygulamanız tarafından verilerin çoğaltılması ve doğal olarak HBase'in satır aralıklı olmayan (HBASE-5229 JIRA'da açıklanan istisna hariç) sıradan atomik işlemler sağladığını unutmayın veya çapraz tablo.

• Akıllı Tuşlar: HBase'de depolanan veriler satır tuşu ile sıralanır ve satır tuşu sistem tarafından sağlanan tek yerel dizin olduğundan, satır anahtarının dikkatli akıllı tasarımı büyük bir fark yaratabilir. Örneğin, satır anahtarınız servis siparişini ve servis siparişini veren müşterinin kimlik numarasını bir araya getirebilir.

  Bu satır tuşu tasarımı, servis siparişiyle ilgili verileri aramak veya aynı tabloda aynı satır tuşunu kullanarak müşteri ile ilgili verileri aramak için size yardımcı olacaktır. Bu teknik, bazı sorgular için daha hızlı olacak ve maliyetli tablo birleştirmelerini önleyecektir.

Bu belirli düşünce kalıplarını netleştirmek için bir Müşteri İletişim Bilgileri tablosunu alın ve onu tipik bir servis sipariş veritabanı bağlamında yerleştirin. Şekilde, normalleştirilmiş bir hizmet sipariş veritabanı şemasının nasıl göründüğü gösterilmektedir.

Hizmet siparişleri kapatıldığında ve muhtemelen silindiğinde müşteri verilerini kaybetmemek için, RDBMS normalleştirme kurallarını izleyerek müşteri Müşteri İletişim Bilgileri tablosunu servis sipariş tablosundan ayrı olacak şekilde ayarlayın. Ürünler tablosu için de aynı yaklaşımı kullanın; bu, hizmet siparişlerinden bağımsız olarak kurgusal şirket veritabanına yeni ürünler eklenebileceği anlamına gelir.

RDBMS birleştirme işlemlerine güvenerek, bu şema, belirli bir ürüne karşı açılan hizmet siparişlerinin sayısının yanı sıra müşterinin bulunduğu ürünün kullanım yerini gösteren sorguları da desteklemektedir.

Her şey güzel ve şık ama RDBM ile kullanacağınız bir şema. Bu şemayı bir HBase şemasına nasıl geçirebilirsiniz? Bir sonraki şekil olası bir HBase şemasını göstermektedir - biri DDI tasarım kalıbını takip etmektedir.

Müşteri İletişim Bilgileri tablosu, daha önce kullanılan yabancı anahtarların yerine müşteri adı ve iletişim bilgileri eklenerek standart dışı hale getirilmiştir. Ayrıca, Müşteri İletişim Bilgilerini olduğu gibi tutarak veriler çoğaltıldı. Artık Servis Siparişi tablosuna ve Müşteri İletişim Bilgileri tablosuna katılmanız gerekli değildir.

Buna ek olarak, servis sipariş numarasını oluşturmak için ürün numarasını müşteri numarası ile birleştiren akıllı bir sıra anahtarı dizaynı kullanılmıştır (örneğin A100 | 00001). Bu akıllı anahtar kullanılarak, servis sipariş tablosu, ürün eksiklikleri ve şu anda ürün sorunları yaşayan müşteriler hakkında hayati raporlar sağlayabilir.

Tüm bu sorgular HBase tarafından uygulama için atomik bir tarzda sıralı bir şekilde desteklenebilir. HBase'in satır anahtarlarını sipariş ettiğini ve bunları sözlük tarzında sıraladığını bildiğiniz için, uygulamanız raporlama için tarama yaparken veri yerelliği hakkında bazı eğitimli tahminler yapabilir. (Örneğin, tüm A * serisi ürün numaraları bir arada depolanacaktır.)

HBase şeması ile temsil edilen servis sipariş veritabanı göreceli olarak basit bir örnektir, ancak HBase'in bazı durumlarda RDBMS dünyasıyla nasıl kesiştirebileceğini göstermektedir ve önemli bir değer sağlamak. Kurgusal şirkette terabayt veya hatta petabaytlık servis çağrı verileri depolanırsa, HBase maliyet, güvenilirlik, performans ve ölçek bakımından büyük fark yaratacaktır.

Tabii ki hizmet siparişinizin HBase şemasını çeşitli şekillerde tasarlayabilirsiniz. Kuşkusuz tasarım, desteklenmesi gereken sorgulara bağlı, ancak bazı ilişkisel veritabanlarını, HBase mimarisi ve DDI tasarım kalıbı konusunda sağlam bir anlayıştan çalışırsanız, üretim için çok güçlü HBase uygulamalarına geçirebilirsiniz.

Bu örnek, sorguların HBase istemci API'lerinden yararlanan bir Java uygulaması tarafından ya da belki de Apache Thrift kullanan başka bir dil ile gerçekleştirildiğini varsaydı. Bu uygulama modeli, gereksinimleri iyi karşılayabilir ve hayali hizmet şirketi için yararlı performans ve özelleştirme seçenekleri sunabilir.