Nedir bu NoSQL?

Günümüzde yazılımla uğraşıp, SQL (Structured Query Language) bilmeyen ve duymayan kalmamıştır herhalde. Nasıl yabancı dil eğitimi İlkokullara kadar indiyse, SQL’in temellerinin de İlköğretim Eğitim Programı içine alıp, gençleri erken yaşta veritabanı ve onun küresel dili olan SQL ile tanıştırmanın zamanı geldi de geçiyor. Buradan Milli Eğitim Bakanlığı’na bir mesaj vermiş de olayım.

Ama bu yazının temel konusu SQL değil, NoSQL!

SQL kullanan veritabanlarının geleneksel nimetlerini anlatmayacağım. 1970’lerde IBM için çalışan iki bilim insanı, Donald D. Chamberlin ve Raymond F. Boyce tarafından tasarlanan bu veri işleme dili, bütün ilişkisel veri tabanları için neredeyse standart hale geldi ve günümüze kadar ulaştı.

Öncelikle şu fark ile başlayalım.

SQL; ilişkisel veri tabanlarında, saklanan verileri yönetmek için kullandığımız, veritbanı bağımsız bir dil.

NoSQL ise yeni bir veritabanı sistemi veya modeli olarak adlandırılabilir.

Geleneksel veri tabanı üreticileri (IBM, Oracle, Microsoft vb.) geliştirdikleri veritabanlarıyla (DB2, Oracle, SQLServer) geleneksel veri tiplerini saklamak, yönetmek üzerine tasarlanmış, verinin doğruluğunu, herzaman tutarlı ve kararlı olarak saklanabilmesini, ulaşılabilir olmasını temel kriterleri olarak önceliklendirmişler ve bunlara göre çok sağlam motorlar geliştirmişlerdir. Bu veritabanları yıllar boyunca öncelikle “mission-critical” veri saklanmasını gerektiren bütün alanlarda görevlerini yapmaya devam etmektedirler.

NoSQL olarak adlandırılan model, yukarıdaki geleneksel modelin dışında, veri saklama, veriye ulaşma ve tutarlılığının ikinci planda kaldığı ihtiyaçların daha öne çıkması ile gözüktü. Bıg Data ihtiyaçları, Web ve Mobile uygulamaların ciddi derecede artması NoSQL olgusunu çok geliştirdi. Bu modelde saklanan veriler “yapısal olmayan” verilerden oluşuyor ve “mission-critical” ihtiyaçlar genel olarak yok. Böyle beklentilerin olmadığı NoSQL veritabanları bu anlamda yatay ölçeklemeye daha yatkın olarak düşünülebilir. Daha çok iş yükünü çalıştırmak için daha güçlü sunucular kullanarak dikey büyüme yöntemi yerine, daha ucuz sunucular ile yatay büyümenin tercih edildiği, “High Availability” çözümlerinin veritabanı olanaklarından çok, yazılım geliştirme teknolojileri ile sağlandığı yeni bir dünya burası. Bu dünyada merkezi veritabanından çok, dağıtık veritabanı özendirilir. Geleneksel veritabanlarının olmazsa olmazı ACID (Atomicy, Consistency, Isolation, Durability) kuralları NoSQL dünyasında sağlanmayabilir.

NoSQL veritabanlarında, SQL dili kullanılmıyor anlamı çıkmasın. Bazı yazarlar bunu “Not Only SQL” olarak da tanımlıyorlar yani bir nevi SQL’de kullanabildiğiniz ilişkisel model olmayan veritabanı gibi.

NoSQL veritabanları veriyi saklama metodlarından dolayı “çok büyük” veriyi, ilişkisel olarak saklama ihtiyacının olmadığı, bu veriyi daha hızlı getirmek ön koşulu  üzerine tasarlanmışlardır. Yani geleneksel veritabanlarındaki gibi birbiri ile ilişkili tablolar arasındaki verileri bulup, filtreleyip, işleyip getirmek gibi ihtiyaçlara burada cevap bulmak zordur. İlişkisel Model, veriyi alır birbiri ile ilişkili tablolarda kolon/satır şeklinde saklar. Örneğin “Document Store” modelini kullanan bir NoSQL veritabanı, JSON formatında gelen verilerin her bir kümesini ayrı bir veritabanı nesnesi gibi saklar.

Istatistik Hesaplar, Gerçek-Zamanlı Analizler, sürekli, hızlı ve kontrolsüz büyüyen verilerin saklanması (Twitter) gibi alanlar en yoğun kullanım şekilleridir. Özellikle Twitter gibi uygulamalar, “extreme scale” diyebileceğimiz şekilde büyük ve ucuz ölçekleme ihtiyacı göstermektedir. NoSQL bu alanı adreslemektedir.

Günümüz uygulama geliştirme süreçleri çok hızlı beklentiler içinde olduğundan (rapid application development) ve DBA gereksinimini en aza indirmek içinde NoSQL veritabanları ilgi görmektedir.

Klasik veritabanı API’lerinin veri erişimindeki göreceli olarak “overhead”leri daha fazla olduğundan ve NoSQL API’leri bu anlamda uygulama geliştiriciler tarafından daha revaçta olmaktadır.

Şu günlerde 122’den fazla kendini NoSQL sınıfına koyan veritabanı bulunmaktadır. Daha derin teknik detayları bir başka yazı konusuna bırakarak, kendini NoSQL veritabanı olarak tarifleyenlerin 4 ana grubundan bahsedeyim. 122 ününün yaklaşık %65’i bu 4 modelden birini benimsiyor.

Key Value Stores: Key değerleri, hash olarak tutuluyor. Key kısmındaki veri kısmı ise binary olarak saklanıyor. MemcacheD, REDIS, WebSphere eXtreme Scale bu modele uyan örnekler.

Document Stores: Saklanan veriler/dökümanlar tagged elementler gibi tutuluyor. MongoDB, couchDB bu modeli kullanan NoSQL veritabanları

Column Family: Her Storage bloğunda sadece bir kolon veya kolon kümesine ait veriler saklanıyor. Hbase, Cassandra güzel iki örnek

Graph Store: Key değerleri “graph yapısı” denen bir modelleme ile ilişkilendirilip saklanıyor. Jena, Sesame iki örnek.

Öyleki, en yukarıda örneklerini verdiğim klasik veritabanları da, mevcut motorlarına yukarıdaki dört modelden birisini seçerek, ek “NoSQL” özellikleri ekliyor.

Örneğin Oracle, Key Value Stores, kullanarak, NoSQL desteği verirken, IBM – DB2 ise  Graph Storemodelini kullanarak yollarına devam edeceklerini açıkladılar. Bunun anlamı, JSON dökümanlarına, SQL ile erişilebilecek olması çok yakında. Bu olanak geldiğinde yılların SQL bilgisine sahiplik yok olup gitmeyecek ve aynı becerileri kullanarak NoSQL veritabanlarını kullanabileceğiz.

Şimdilik görünen bunlar ama bu alanda o kadar hızlı gelişmeler oluyor ki siz bu satırları okurken bile bazı şeyler değişmiş olacak.

Kaynak : http://datawarehouse.gen.tr/nedir-bu-nosql/

Yazar Hakkında
Cüneyt Göksu 
        Bilgisayar Yüksek Mühendisi olan Cüneyt Göksu, 20 yıldan fazla Bilgi Sistemleri Uzmanı olarak çalışıyor. 1990 - 2000 yılları arasında Kurumsal Müşterilerde Teknik Uzman ve Yönetici olarak görev yapan Cüneyt, 2000'den 2013'e kadar Vizyon Bilgi Teknolojileri bünyesinde Bilgi Sistemleri Danışmanı, Veri Mimarı, Eğitmen ve Profesyonel Hizmetler Direktörü olarak kurumsal projelerde görev aldı. 2013 Ekim'den beri IBM'de Bilgi Sistemleri konusunda, Teknik Satış Uzmanı olarak görev yapıyor.

PL/SQL: Parametre Modları

PL/SQL prosedürlerinde veya programlarında parametreler 3 tipte olabilirler. Bunlar;

1-IN
2-OUT
3-IN OUT

IN: parametre tipi programımıza bir değer göndermektedir. Standart parametre modudur.. Parametre tipi herhangi bir ifade, değer veya sabit olabilir.

OUT: parametre tipi programımızdan bir değeri ortama geri döndürmektedir.  Özellikle belirtilmesi gerekir. Bir değişken olmalıdır.

IN OUT: parametre tipi programa bir değer gönderirken bu değerin değiştirilme ihtimali ve geri döndürülme ihtimali bulunur.  Özellikle belirtilmesi gerekir. Bir değişken tipinde olmalıdır.

Prosedürler çağırılırken içerisindeki değerler direk in tipi parametre olarak kabul edilirler. Eğer prosedürümüzün bir değer döndüreceğini belirtmek istiyorsak özellikle out veya in out diye belirtmemiz gerekir.

Standart bir PL/SQL blok örneği :

1->Veri seti olusturulması;

CREATE TABLE STUDENT
(
ID NUMBER,
NAME VARCHAR2(10),
SNAME VARCHAR2(10)
);

insert into STUDENT values(1,'TEST','TEST1');
insert into STUDENT values(2,'TESTA','TESTA1');
insert into STUDENT values(3,'TESTB','TESTB1');
COMMIT;

2->IN /OUT Paremetleri standart PL/SQL paketinin olusturulması;

CREATE OR REPLACE PROCEDURE find_sname 
(
i_student_id IN NUMBER, 
o_first_name OUT VARCHAR2,
o_last_name OUT VARCHAR2
)
AS
BEGIN
   SELECT name, Sname
   INTO o_first_name, o_last_name
  FROM student
 WHERE id = i_student_id;
EXCEPTION
  WHEN TOO_MANY_ROWS
      THEN
      DBMS_OUTPUT.PUT_LINE('More than one finding student_id:'||i_student_id);
  WHEN OTHERS
     THEN
     DBMS_OUTPUT.PUT_LINE('Error in finding student_id:'||i_student_id);
END find_sname;


3->PL/SQL paketinin calıstırılması;

DECLARE
v_local_first_name student.name%TYPE;
v_local_last_name student.Sname%TYPE;
BEGIN
find_sname (2, v_local_first_name, v_local_last_name);
DBMS_OUTPUT.PUT_LINE ('Student 2 is: '||v_local_first_name||' '|| v_local_last_name||'.');
END;

4->Output;

Reclaiming Wasted Space

       Fazladan kullanılmış olarak belirlenen yerler zaman içinde çok fazla update, delete, insert ifadeleriyle birlikte oluşan boş bloklardır. Bu bloklar tekrar yerleştirilirse daha önceden boş olarak gözükmeyen yerler veritabanı tarafından görülmeye başlanacaktır. Bu boşluklar fragmante edilmiş boş alanlar olarak tanımlanmaktadırlar.

Boş Bloklar Nasıl Oluşmaktadırlar?

Tabloya gelen transaction'lar datafile'lara kayıt ekledikçe bloklar bunlara göre arka arkaya düzenlenirler. Bu düzenleme sırasında bazı bloklar silinip, tabloya yeni ve daha büyük kayıtlar geldiğinde bu bloklar kullanılamazlar. 

Bu bloklar kullanılamamalarına rağmen boş durumdadırlar. Tablonun bu parçalanmış durumu hem harcanmış disk alanına hemde veritabanında performans kaybına yol açmaktadır.

Nasıl Düzeltililir?

Bu durumu düzeltmek için "online segment shrink"  işlemi gerçekleştirilir. Bu işlem ile boş alanlar birleştirilir ve kayıtların yazılacağı blok sınırını düşürür. Yani aynı extent içine daha fazla kayıt eklenebilir, daha fazla yer kazanılır.

Boş Alanlar Nasıl Bulunur?

Kullanılamayan boş alanları bulmak için "Segment Advisor" kullanılır. Bu araç hem Enterprise Manager'dan, hem veritabanından çalıştırılabilinir. Segment Advisor daha önceden çalıştıysa aşağıdaki sorgu bize Segment Advisor'ın bakıp bulduğu tablolardan hangisinde ne kadar yer kazanılabileceği ya da o tablolarda ne yapılması gerektiğini gösterir.

/* Formatted on 1/8/2015 2:46:48 PM (QP5 v5.149.1003.31008) */

SELECT segment_name,

       segment_owner,

       SEGMENT_TYPE,

       ROUND (allocated_space / 1024 / 1024, 1) alloc_mb,

       ROUND (used_space / 1024 / 1024, 1) used_mb,

       ROUND (reclaimable_space / 1024 / 1024) reclaim_mb,

       '%'||ROUND (reclaimable_space / allocated_space * 100, 0) pctsave,

       recommendations

  FROM TABLE (DBMS_SPACE.ASA_RECOMMENDATIONS ())

 WHERE segment_owner = 'BI_DWH'

Segment Advisor Nedir?

"Automatic Segment Advisor" bir maintanence task'idir. Yani maintenance aralıklarında çalışan bir işlemdir. Bu işlem bazı veritabanı objelerini inceler. Bu objeler seçilmeden önce belirli kriterlere bakılır.

Bu kriterler:
-Tablespace'in belirli bir seviyeyi geçmiş olması
-Çok fazla aktif olan segment'ler(Yukarıda belirttiğimiz gibi update,delete,insert ifadeleri çok gerçekleşen tablolar)
-En fazla büyüyen segment'ler

Buna göre seçilen objeler maintenance aralıkları boyunca incelenirler.

Elle Segment Advisor'ı Çalıştırmak:

Segment Advisor maintenance aralıklıklarında otomatik olarak çalıştırdığımız için bazen elle çalıştırmamız gerekebilir. Merak ettiğimiz bir tablespace'i incelemek istiyorsak, elle çalıştırmamız gerekir.

Elle çalıştırabilmek için 2 yöntem vardır. Bir tanesi "Enterprise Manager"'dan "Segment Advisor Wizard"'a gidip istediğimiz tablespace'i veya tabloyu seçip "Run Segment Advisor"'ı seçebiliriz. 

Diğer yöntem de PL\SQL job'ı çalıştırmak olacaktır.

PL\SQL ile Segment Advisor çalıştırılması örneği:

create or replace procedure segment_advisor_calistirmak  
   authid current_user  
  as  
    obj_id number;  
   begin  
    dbms_advisor.create_task (  
     advisor_name   => 'Segment Advisor',  
     task_name    => 'segment_advisor' );  
    
    dbms_advisor.create_object (  
     task_name    => 'segment_advisor',  
     object_type   => 'TABLE',  
     attr1      =>  EALTUNKAYNAK,           --SEGMENT_OWNER
     attr2      => 'AGG_F_BALANCE',   --SEGMENT_NAME
     attr3      => NULL,  
     attr4      => NULL,  
     attr5      => NULL,  
     object_id    => obj_id);  
    
    dbms_advisor.set_task_parameter(  
     task_name    => 'segment_advisor',  
     parameter    => 'recommend_all',  
     value      => 'TRUE');  
    
    dbms_advisor.execute_task('segment_advisor');  
   end;  
   /  

       Yukarıdaki örnekte PL\SQL ile bir procedure oluşturmuş oluyoruz. Bu procedure'de belirli bir tablo ismi ve kullanıcı ismi vermiş bulunuyoruz. Bu şekilde her seferinde bu procedure'ı çağırdığımızda aynı tabloyla ilgili segment tavsiyeleri almış oluruz. Bu procedure'ı parametreli hale getirirsek de istediğimiz tabloyu veya tablespace'i inceleyecek hale getirmiş oluruz. Sonrasında aşağıdaki gibi çalıştırabiliriz.

exec segment_advisor_test;

Bu procedure çalıştırıldıktan sonra bunların sonuçlarını görmek için 3 tane yöntem vardır.

-Enterprise Manager ile
-DBA_ADVISOR_* view'ları ile
-DBMS_SPACE.ASA_RECOMMANDATIONS prosedürü ile

Shrink Etme İfadesi Nedir?

Tablolar için genel olarak küçültme ifadesini vermeden önce o tablo için "row movement" özelliği açık olmalıdır.

 "alter table tablo_adı enable row movement;"  

Sonrasında ise

"alter table tablo_adı shrink space compact;"  

ve

  "alter table tablo_adı shrink space;"  

Shrink İşleminin Sonuçlarını Nasıl Görebilirim?

Shrink edeceğimiz dosyanın boyutunu görmek için dba_tables tablosu sorgulanır.

 select blocks from dba_tables where table_name='TABLO_ADI';  

Bu şekilde tablomuzun şu an kapsadığı boyutu görebiliriz.

Shrink işlemini gerçekleştirdikten sonra da aşağıdaki gibi şu anki istatistikleri görebiliriz.

 analyze table tablo_adı compute statistics;  
   
 analyze table tablo_adı estimate statistics sample 10 percent;

O istatistikleri güncelledikten sonra tekrar aynı sorguyu çektiğimizde tablonun küçülme seviyesini görebiliriz.

 select blocks from dba_tables where table_name='TABLO_ADI';  

Buna istinaden dba_segments'den tablo boyutunu da inceleyebiliriz.

select bytes/1024/1024 as 'MB' from dba_segments where segment_name='tablo_adı';