Azure Storage Services – Part 3:Table Storage

Makale serimizin önceki bölümlerinde depolama hesaplarını ve blob depolama detaylarını inceledik. Bu makalemizde depolama hesabı içerisinde gelen hizmetlerden bir diğeri olan Table Storage’ı ve kullanım detaylarını inceleyeceğiz.

Table Storage detaylarına girmeden önce ayrı bir makale şeklinde planladığım ancak kısaca detaylarından bahsetmek istediğim farklı bir konu bulunuyor.

Verinin günümüzde ne kadar önemli olduğunu biliyoruz. Operasyonel ve analitik veriyi sahip olduğumuz araçlar ile işleyerek verimli hale getirebiliyoruz. Veriyi barındırmak için Azure üzerinde iki farklı teknoloji bulunuyor.

NoSQL ve SQL

Azure üzerinde ilişkisel veritabanlar ve ilişkisel analiz için kullanılabilen SQL teknolojileri bulunuyor. Bunlara örnek olarak SQL Server, Oracle, MySQL sanal makinelerini verebiliriz.

Aynı zamanda Azure NoSQL teknolojilerini de desteklemektedir. Bunlara örnek olarak:

  • Document Stores –> DocumentDB (Azure Hizmeti)
  • Document Stores –> MongoDB (Azure VM)
  • Key/Value Stores –> Tables (Azure Hizmeti)
  • Key/Value Stores –> Riak (Azure VM)
  • Column Family Stores –> HBase (Azure Hizmeti)
  • Column Family Stores –> Cassandra (Azure VM)
  • Big Data Analytics –> HDInsight (Azure Hizmeti)
  • Big Data Analytics –> Hadoop (Azure VM)

Görüldüğü gibi hem SQL hem NoSQL teknolojileri için Azure üzerinde gerek servis gerekse sanal makine içerisinde sunulan araçlar şeklinde seçeneklerimiz bulunuyor. İlişkisel veritabanları ile bugüne kadar daha yakın çalışmış olabilirsiniz, ancak günümüzde ilişkisel olmayan yani NoSQL veritabanları da oldukça popüler. İlişkisel veritabanlarında veritabanı yükü arttıkça hep scale-out amaçlı daha fazla, pahalı sunucu alımları tercih ediliyor. NoSQL bu noktada yeni node ların eklenmesi ile yatay büyümeyi destekleyerek önemli bir avantaj sunuyor. Bu faydalarından bir tanesi olmakla birlikte özellikle büyük verinin yönetimi ve maliyet konularında öne çıkan noktaları bulunuyor.

Burada bizim için önemli olan Azure’un bu teknolojileri desteklemesi ve bu makalemizin konusu olan Table Storage’ın da aslında bir NoSQL çözümü olması.

Azure Storage içerisinde bulunan Table ilişkisel olmayan key/value pair sistemini destekleyen ve çok fazla yapılandırılmamış veriyi barındırabilen bir teknolojidir.

İlişkisel veritabanı ile Key/Value Pair sistemi arasındaki farkın detayları için https://www.simple-talk.com/cloud/data-science/data-science-laboratory-system—keyvalue-pair-systems/ makalesini inceleyebilirsiniz.

Azure Storage içerisinde hem SQL Veritabanı hem de Table Storage hizmetleri sunulduğu için genel farklarından burada bahsetmekte fayda var.

SQL Veritabanı bize:

  • Geleneksel ilişkisel veritabanı oluşturmayı
  • Bunu SQL Server engine ile desteklemeyi
  • Stored procedures, joins, views gibi Server-side processleri
  • ACID transactionları
  • Tüm tablo için ortak şemayı

sunar.

Table Storage bize:

  • Herhangi bir şemaya bağımlı kalmadan hızlıca bulut uygulamaları oluşturmayı
  • Daha az server-side sorguları
  • Şemadan bağımsız yapıyı
  • Daha basit DR yapılandırmasını

sunar.

Günün sonunda uygulamanız eğer ilişkisel veritabanı modelinin nimetlerinden üst seviyede yararlanmıyorsa Table Storage sizin için daha efektif bir çözüm olabilir. Örneğin bir e-ticaret sitesi oluşturduğumuzu düşünelim. Bu e-ticaret sitesinde de barındırmamız gereken kritik bir veri var: Müşterinin almak istediği ürünler ile ilgili bilgi.

Her bir kullanıcı sepeti için özel bir anahtar kullanılarak read ve write işlemleri yapılması ilk aşamada yeterli gözüküyor.

Bu tarz bir senaryoda ilişkisel veritabanının sunduğu faydalar bizim ihtiyaçlarımızın çok üstünde kalabilir. Çok üstünde kalması da bize ek maliyet olarak dönecektir. İşte bu noktada veriyi key/value şeklinde tutan Azure Tables daha mantıklı bir seçim olacaktır.

Aşağıdaki diagram Azure Tables içerisindeki bileşenlerin detaylandırılması için oldukça faydalı.

image

Görüldüğü gibi Azure Table içerisinde partitionlar, partitionların içerisinde entity ler, bunların içerisinde de property ler bulunuyor. Görüldüğü gibi her partition için özel partition key bulunuyor. Bu yapıdan bir entity çekmek için partition key ve sıra/satır anahtarı kullanılması gerekiyor. Örneğin A2.

Bu sorgu sonucunda XML yada JSON şeklinde tüm propertyler elde edilir.

Yine yukarıdaki diagramda görüldüğü gibi ilişkisel veritabanlarında olduğu gibi uyulması gereken bir şema da bulunmuyor. A1 içerisinde name, country, age, date bilgisi varken diğerlerinde farklı veriler bulunabilir.

Yine farklı bir diagram ile göstermek gerekirse:

table1

Table aslında Entity gruplarının toplamıdır. Entity ise veritabanı satırlarına benzer şekilde propertylerin toplamıdır. Son olarak property ise name-value eşidir. Her entity 252 adet property verisi barındırabilir. Bunun dışında her bir entity 3 adet zorunlu “system property” sine sahiptir. Bunlar:

  • Partition Key: Table içerisindeki entityleri gruplandırır ve esneklik sağlar.
  • Row Key: Partition içerisindeki entity için benzersiz ID’dir.
  • Timestamp: Entity’nin en son modifiye edildiği tarih bilgisini tutar.

Oluşturulan table storage için blob storage’da olduğu gibi bir adres bilgisi bulunur.

http://anilstorage.table.core.windows.net/table1

Bu table içerisine veri yazma, silme, değiştirme ve sorgulama gibi işlemleri ilerleyen makalelerde inceliyor olacağız.

2 thoughts on “Azure Storage Services – Part 3:Table Storage

Leave a Reply

Your email address will not be published. Required fields are marked *

+ 67 = 71