İstatistiksel Kavram Ve Yöntemler

İstatistik, veri analitiğin temellerini oluşturmaktadır. Bu yazıda bunu biraz daha somutlaştırmak amacıyla pratik hayattan örnek sunacağım.

İlk olarak bir alış-veriş sitesi veya mağazasını düşünelim. Örneğin firma erkekler ile kadınlar arasında veya bekar ile evliler arasında alış-veriş alışkanlıklarında farklılık olup olmadıklarını araştırmak istesin. Araştırma sonucunda, elindekileri verileri bilgiye dönüştürmüş olacaktır. Araştırma yapılacakken kullanılacak yöntemler istatistiğe dayanmaktadır. Örneğimizdeki araştırma için kullanılabilecek bir çok algoritma vardır. Algoritmaları kullanmadan önce verilerinizin böyle bir araştırmaya uygun olup olmadığını, verileriniz ne kadar güvenebileceğinizi test etmek gerekir ki; bu testlerde standart sapma, varyasyon, p değer gibi istatistiğe özel kavramlarla karşılaşırsınız.

analyticstraining.com

İkinci örneğimiz yine alış-veriş sitesinden olsun. A ürününü alanların beraberinde hangi ürünleri aldıklarını tespit etmek için de yine veri analitiği çalışması yapmak gerekir. Çalışmayı yaptınız ve genellikle A ürünü ile B ürününün birlikte sepette yer aldığını tespit ettiniz. İkisinin arasında bir ilişki olduğunu görünüyor ama bu ilişki bir nedensellik mi? Yani B’yi alanlar, A’yı aldıkları mı için mi alıyorlar? Bu durumlarda  regresyon ve korelasyon analizleri yapılmaktadır.

Analitik için sıklıkla kullanılan yöntemler için http://www.datasciencecentral.com/profiles/blogs/40-techniques-used-by-data-scientists adresine bakabilirsiniz.

Bir sonraki yazımda, değişken nedir, verilerden değişken nasıl elde edilir, veriler nasıl sınıflanır gibi konulardan bahsetmeyi düşünüyorum.

Analitik ve İstatistik

Önceki iki yazımda “R” dan bahsetmiştim. İki yazınında ana teması analitik idi. R nedir diye sorsanız istatistik dili olarak görürsünüz. İşte bu yazımda da veri analitiği ile istatistik arasındaki ilişkiyi anlatmaya çalışacağım.

Günümüzde veri, yeni petrol olarak tanımlanmakta. Elbetteki bu tanım verinin ne kadar kıymetli olduğunu vurgulamak için geliştirilmiş bir söylem. Unutmamak gerekir ki her ne kadar petrola bağımlı bir hayatımız olsa da, biz kullanıcılar için ham petrolun bir anlamı yoktur. Petrol, benzine, motorine ya da gaza dönüştürüldüğünde bizler için kullanılabilir, bu nedenle de para ödeyeceğimiz bir değere sahip olur.

indianexpress.com/about/brain/

Aynı analojiyi kullanmaya devam edelim; petrol veri ise, benzin-gaz ne? Bilgi bizim benzinimiz, gazımız. Peki bilgi ne? Yorumlanmış, işlenmiş, değer katılmış veridir bilgi. Veriyi işleyebilen, değer katabilen tek bir nesne var dünyada, o da beyin. Veriyi işlemek söz konusu olduğunda tüm insanoğlunun sahip olduğu beyinler üç aşağı beş yukarı aynı. 2 kere 2 dört eder herkes bilir ve söyler fakat iş yorumlamaya geldiğinde durum çok değişiyor. Aynı dersi aynı hocadan dinleyen öğrencilerin anladıkları neden birbirleri ile aynı değildir? Beyinleri farklı yorumlamıştır, farklı yorumlamıştır çünkü beyin duyularımızdan aldığı sinyalleri, kendi haznesinde bulunan önceki veriler ile ilişkilendirip, benzerleştirip veya daha farklı yöntemlerle, bilgiye dönüştürmüş ve daha sonraki durumlarda kullanmak üzere belleğe, haznesine atmıştır.

Beyin ile bilgi ile söylenebilecek daha çok şey varken, sıkmamak adına burada kesip özetliyorum; verilerimizi değerli kılabilmemiz için onları bilgiye dönüştürmeliyiz. Bilgiye dönüştürmeyi yaparken matematik biliminden faydalanıyoruz. Olay sadece toplama çıkarmadan ibaret değil. İş zekası denilince beyninizde rakamlardan oluşan raporlar canlanıyor olabilir, matematik dendiğinde de toplama-çıkarma. Kast edilen asla bunlar değil. 2 kere 2’nin dört ettiğini söyleyen herkese zeki insan diyemeyeceğiz gibi, verileri toplayıp özet rakamlarla rapor sunmaya dün belki iş zekası deniliyordu ama bugün diyemeyiz.

Akıllı diye adlandırdığımız sistemler, yorumlayabilen sistemlerdir. Yorumlarken de matematiksel modelleri kullanırlar. Matematik ile nelerin nasıl  modellendiği görmek gerçekten insanı hayrete düşürüyor. Hafızam beni yanıltmıyorsa, yıllar önce okuduğum kitabında, kaybettiğimiz değerli bilim adamı Oktay Sinanoğlu, yelkenlisiyle pasifikte kaybolduğunda, matematik kullanarak kurtulduğu anlatıyordu. Elbette daha farklı, bir çok enteresan örnekler de vardır.

Image Credit: Erin DeWalt

Son söz, eğer yazılımcı iseniz ve R diline ilgi gösteriyorsanız, en azından temel istatistik kavramlarını biliyor ve algoritmalar hakkında da az çok bilgi sahibi olmanız gerekir. Eğer veri analitiği ile ilgileniyorsanız, hiç kaçarınız yok, istatistik öğrenmelisiniz.

Yol Ayrımı; Data Science vs Big Data

Data Science veya  Analitik ve Big Data her ne kadar birlikte anılıyor olsa da, bunlar çok farklı uzmanlık gerektiren alanlar. Her ikisini birlikte aynı zaman diliminde öğrenmeniz olasılıklı değil. Hangisini önce öğreneceğinize karar verip oradan devam etmek daha sağlıklı bir yöntem. Ben Data Science'dan başlamaya karar verdim. Bu konuya geçmeden, önceki yazımın sonunda sorduğum sorulara kısa cevaplar verelim.

http://scraping.pro/nosql/

NoSQL
İlk aklımıza gelen elbette, NO SQL yani SQL olmayan demek. Bunun dışında "Not Only SQL" olarak adlandıranlar var. Tercih yapmayacağım fakat konunun anlaşılması açısından NOSQL
dendiğinde artık "Not Only SQL" olduğunu da bilmekte fayda var.

Unstructured Data
SQL dendiğinde ilk aklımızda canlanan öğe sanırım tablodur. Tablolar da kolonlardan oluşur. Yani bir kalıpları(structure) vardır. Unstructured data dediğimizde, tablo dışında kalan her veriyi anlayabiliriz. Döküman, video, XML, JSON, aklınıza ne gelirse. Bu veriler, tablo içinde tutulsa bile structured olduğu anlamına gelmez, unstructured veridir. Unstructured verinin konumuzla ne alakası var? Hemen cevabı geliyor.

Big Data

Boyutu büyük olan veriye, büyük veri denir. Eğer büyük veriyi yukarıdaki gibi tanımlarsanız, "Benim büyük verim yok, Oracle'da , MS SQL'de verilerimi tutuyorum ve sorgularım da hızlı cevap dönüyor. Ayrıca yeni storage satın aldık, bizi yıllarca götürür." şeklinde karşılık alabilirsiniz. Doğrudur, tekil ya da yeterince seçici numara, telefon gibi kriterler ile sorgulama yapıldığında ilişkisel veri tabanları çok hızlı cevap dönerler(Index'in var olduğunu kabul ediyoruz). Oysaki isim veya tanımın bir kaç karakterinden arama yapıldığında durum değişir.

Milyarlarca kayıttan oluşan bir tablodan sorgularken sorun yaşamazken, içinde bin - iki bin kayıt olan, örneğin ürün tablonuzdan sorgulama yaparken sonuç gelene kadar uzun süre beklemek zorunda kalırsınız. Bu durumda sizin ürün tablonuza büyük veri diyebiliriz. Bir önceki yazımda sorduğum sorunun cevabını verdik. Yani işleyemediğiniz veya işlemekte zorlandığınız veriye büyük veri diyelim, konu daha rahat anlaşılacaktır.

İlişkisel veri tabanlarında, unstructured verileri de tutabilirsiniz. Fakat iş bu verileri sorgulamaya geldiğinde, deveye hendek atlatmak kadar zor bir durumla karşı karşıya kalmışsınız demektir.O halde sorgulama yapacağınız, işlemek istediğiniz unstructured verilere de büyük veri diyebilirim.

R'a Giden Yol

Her firma ayakta kalabilmek için para kazanmalı, dolayısıyla parayı kazandığı müşterileri elinde tutmalı, hatta bunlara yenilerini eklemelidir.

www.simplicant.com

Yeni müşteri bulmak hiçte kolay bir iş değildir. Hele de giden bir müşteriyi geri getirmek en zorudur. Bu nedenle mevcut müşterilerin elde tutulması günümüzde daha büyük önem kazanmıştır.

Mevcut müşterinin elde tutulması yönündeki en büyük zorluk ise; gidecek müşterinin bilinememesidir. Giden müşteriyi, yeni müşteriyi, uzun zamandır sizinle olan müşteriyi verilerinizden sorgulayıp görebilirsiniz fakat hangilerinin gitme eğiliminde olduğunu size söyleyebilecek bir sorgulama mevcut değildir.

Buradan sonra devreye "analitik" girer. SPSS, SAS gibi yaygın analitik araçlarını düne kadar sık sık duyduk. Bu araçlar, verdiğimiz örnek üzerinden konuşursak, hangi müşterinin sizi terk edeceğini söyleyemez fakat gitme olasılığını tahminler ve gösterir. Gitmesini önlemek için gerekli aksiyonları almak iş birimindeki kişilere kalmıştır.

rhrv.r-forge.r-project.org

Analitik dünyası öylesine gelişti ki; Data scientist, R, BigData, NOSQL gibi yeni kavramlar duymaya başladık. SPSS, SAS kullananların, bölümde Data scientist(veri bilimciler) barındırmaya
başladıklarını gördük. R ile geliştirme yapılıyor, bu geliştirmeleri uygulamaların içine gömülüp kullanılıyordu.




İş birimleri ile BT birimleri iş birliği içine girmişti. Buna karşın talepler bitmiyor, R'ın yeterli olmadığını, Python kullanacaklarını, BigData ortamlarına, NOSQL'e ihtiyaçları olduğunu söylüyorlardı.

Neydi bu R-Python, BigData-NOSQL? SQL varken niye R veya Python? Trilyonluk kayıtları olan muhasebe verilerini işleyebilirken, milyonluk müşteri verisi neden işlenemiyordu? Diğer bir deyişle, trilyonluk muhasebe verisi "big" değilken, milyonluk müşteri nasıl "big" olabiliyordu?
Bu sorularla hayatımda yeni bir yolculuk başladı.

Data Lake

Film adını andıran Data Lake, veri ile uğraşanların duymaya başladıkları bir kavram. Türkçe karşılığını bilmediğimden dolayı kavrama yazı bozunca Data Lake demeye devam edeceğim ve diğer kavramların Türkçe karşılıkları olsa bile aynı patern'de olması için orjinal isimlerini kullanacağım.

Kimilerine göre Data Warehouse'ın güncel adı, kimilerine göre yeni versiyonu. Oysaki bunların farklı olduğunu görüyoruz. Ayrıldıkları noktalar kullanım yer ve amaçlarındaki farklılıklardan oluşmaktadır. Her ne kadar bu ifadeden Data Lake, Data Warehouse'ın yerini almayacak gibi görünse de kanaatime göre disruption(bozulma anlamında olsa da öldürücü demek daha doğru gibi) bir unsurdur.

Pentaho kurucusu James Dixon'ına göre eğer data mart'ları hijyenik hale getirilip paketlenerek kullanıma hazır hale getirilmiş su şişeleri olarak düşünürsek, Data Lake geniş hacimli doğal su gölleridir. Değişik su kaynaklarından beslenir ve isteyen istediği miktarda alıp kullanır.

Data Warehouse ve Data Mart'lar structured veya tabular tipindeki verilerden oluşurlar. Schema-On-Write olarak tasarlanmışlardır. Verileri önce işlenir sonra yüklenir. Data Lake'ler ise structured olsun olmasın her türlü veriyi tutabilir, yüklenmeden önce verinin işlenmesine, dönüştürülmesine gerek yoktur. Schema-On-Read olarak tasarlanırlar.

Verilerin işlenip kalıplara sokulmasından dolayı Data Warehouse sistemleri büyük veri depolama alanlarına ihtiyaç duyarken, aynı zamanda bu depolama alanları çok pahalı sistemlerdir. Data Lake sistemler ise çok daha ucuz ve verinin gerçek boyutu kadar depolama alanları ile yetinirler.

Çeviklik olarak Türkçe'ye tercüme ettiğimiz Agility, Data Lake sistemlerde hayli yüksekken, Data Warehouse sistemlerin tasarımlarının sabit olmasından dolayı çok düşüktür. Yeniden tasarlanıp konfigürasyonun yapılması gerekir. Oysaki Data Lake sistemler esnektir, istenildiği gibi yeniden konfigürasyonu yapılabilir.

Diğer taraftan Data Lake sistemlerin dezavantajlarını ele alacak olursak, henüz yeni sistemlerdir. Olgunlaşmamış olmasından dolayı pazardaki sektörler tarafından yeterince güvenilir bulunmaması yaygınlaşmasının önündeki en büyük engellerden biri olarak durmaktadır.

Tüm bunların yanında Data Warehouse sistemlerin hedef kitlesi iş birimleri iken Data Lake sistemler, veri birimciler için kullanışlıdır.

 

Schema-On-Write Schema-On-Read Kıyaslaması

İki yeni terim ile karşılaştım, yeni karşılaşmış olman bunların yeni türetildiği anlamına gelmiyor, ne zaman türetildiklerini bilmiyorum fakat bundan sonra daha çok karşılaşacağımızdan eminim. Bu nedenle  terimleri açıklamak ve kıyaslamak istedim, başucu kaynağı olarak dursun.

Schema-On-Write

SQL developer ve adminlerin veri tabanı ya da tablo dendiğinde zihinlerinde ilk canlandırdıkları olgudur. Biraz daha açarsak, önce bir çerçeve tanımlayıp şemanızı belirliyorsunuz, ardından verilerinizi yazıyor ve okuyorsunuz. E bunda ne var, bunu zaten biliyorduk. Aynen öyle. Peki schema-on-read ne?

Schema-On-Read

Bunda ise schema-on-write'da olandan farklı bir süreç işletiyorsunuz. Şemanızı tanımlamak yerine verilerinizi olduğu gibi yüklüyorsunuz. Sıra okumaya geldiğinde ise elinize merceğinizi alıyor ve ya gözlüğünüzü takıyorsunuz. Gözlük veya mercek diyorum çünkü veriyi olduğu gibi yüklediğinizden dolayı detaylara inebilmek için merceğe, uzaktan, yakından ya da  farklı açılardan farklı boyutlardan bakabilmek için gözlüğe ihtiyacınız oluyor. 3D gözlükleri düşünün.

Örnek ile somutlaştırmaya çalışalım. Elinizde bir anket formu var ve bunu veri tabına kaydetmek istiyorsunuz. Schema-on-write, tablo veya tablolar tasarlayıp verileri bunların içini yazarsanız, diğerinde ise formu olduğu gibi sisteme yüklersiniz. Örneğin JSON veya XML.  Peki niye buna ihtiyaç duyalım ki?

Neden Schema-On-Read

Yukarıdaki örneğimizi düşünelim; ankete yeni bir soru eklendi veya çıkartıldı, cevap seçenekleri değişti. Gidip şemanızı değiştirmek ve yeni yapıya uyarlamak zorunda kalırsınız. Oysaki ikinci seçenekte buna ihtiyaç olmaz. Fakat asıl sebep bu değil, gerçek fayda okuma yaparken ortaya çıkıyor. Terimin isminde "Read" geçiyor olmasının nedeni de bu olsa gerek.

Verilerimiz varlıklarımızdır ve varlıkları kullanan kişiler, kişilerin rolleri birbirlerinden çok farklıdır. Varlıklardan değer üretebilmek için kendi çerçevelerinden bakmaya ihtiyaç duyuyorlar. Biz bir şemaya oturttuğumuz zaman, kullanıcılar çerçeveleri ile uyuşmayabilir. Bazılarının çerçeveleri 10x15, bazılarının 15x20 bazılarının ki ise 20x30 boyutlarındadır.  Biz 15x20 seçtiğimizde diğerlerininkine uymayacaktır.

Uydurmak için tekrar tasarım , geliştirme ve devreye alma durumunda kalınır ki, bu da ekstra maliyet ve zaman demektir. Hepsine uyabilmesi için en büyük çerçeveyi seçtiğimizde ise fazladan yer tutmanın maliyeti gelir. Hepsi için ayrı ayrı çerçeveler oluştursanız, maliyetleri ve geliştirme sürelerini katlamış olursunuz.

Sadece bir örnek üzerinden konuştuk, farklı bir anket formu olduğunu düşünün. İkinci bir şema oluşturmak ve verileri yazacak benzer bir sistem geliştirmek zorunda kalırsınız.

Yukarıda verilen örnekleri düşündüğümüz de nasıl bir yük ile karşı karşıya olduğumuz gün yüzüne çıkmaktadır. Schema-On-Read'in asıl faydası burada ortaya çıkar. Veriyi olduğu gibi yüklediğinizden dolayı (yazmak değil, yüklemek tabirini özelikle kullanıyorum) proje sürelerinin kısalmasını, maliyetlerin azalmasını dolayısıyla projenin başarılı olarak kapatılması olasılığını yükseltmiş olursunuz.

Okuma Yapılması Engellenmiş Tablodan SP ile Okuma Yapılabilir mi?

Select yapabilmesi DENY ile engellenmiş kullanıcı SP kullanarak tablodan okuma yapabilir mi?
Bu sorunun cevabı evet ya da hayır şeklinde yanıtlayacağımız kadar basit değil. Okuma yapıp yapamayacağınızı belirleyen başka faktörler de var. Bu nedenle soruyu açıklayacak yazı yazma gereksinimi doğdu.
MS SQL serverda GRANT komutu içi kullanıcılara (Login veya User) yetki tanımlarken, tersine DENY ile yetkiler engellenir.
SALES isimli kullanıcıya  tablo üzerinde Select yetkisi tanımladıktan sonra ilgili kullanıcı tablodan okuma yapabilir.

DENY tanımlandığında ise daha önce SELECT yetkisi verilmiş olsa bile okuma yapamayacaktır.

Şimdi benzer işlemi yapacak stored procedure create edelim ve onunla okuma yapmaya çalışalım. Ne dersiniz okuma yapabilecek miyiz?

Create ettiğimiz SP'ye EXECUTE yetkisi tanımladıktan sonra, kullanıcının tablodan SELECT yapması engellenmiş olmasına rağmen SP'i çağrılıp istenilen kayıt okunabildi. MS SQL server SP'ler çağrıldığında, kullanıcının Execute yetkisi olup olmadığına bakıp eğer yetkisi var ise çalıştırmasını sağlıyor. SP içindeki nesneler üzerindeki yetki kontolünü ise aşamalı olarak yapıyor. Eğer içeride kullanılan nesneler ile SP'nin owner'ı aynı ise herhangi bir yetki kontolü yapmadan çalıştırıyor. Yukarıdaki örneğimiz bu şekilde gerçekleşti. Eğer owner'lar farklı ise alt nesneler için de yetki kontrolü yapıyor.
Create ettiğimiz SP'nin owner'ı değiştirip aynı işlemi tekrarlayalım.

Görüldüğü gibi select yetkisi DENY ile alındığından dolayı okuma yapılamadı ve Sp hata döndürdü.

SQL Server Sorgu Performanslarının İzlenmesi

Bu yazıda yazdığımız SQL sorgularının performansını nasıl kontrol edebileceğimizi anlatacağız. Performans dediğimizde aklımıza hız gelir. Bu nedenle hemen herkes yazdığı sorgunun çalışma süresini kıyaslayıp performanslı olup olmadığı karar vermeye çalışır. Oysaki süre çalıştığınız ortamların özelliklerinden etkilenir. Serverın CPU, Memory özellikleri, çalıştığınız bilgisayarın donanımsal özellikleri hatta aradaki network bile süreye etki etmektedir. Yazılım geliştirme ortamları ile üretim ortamları birbirinden çok farklı olmasından dolayı süre kıyaslamaları performans testleri için doğru bilgi vermez. Bu anlattıklarımızı demo ile gösterelim.

Sorgumuz 1796 ms. sürdü. Aynı sorguyu tekrar çalıştıracağız.

Sorgu aynı olmasına rağmen ikinci kez çalıştırdığımda 1 .21 0 ms. sürdü. Hiç bir değişiklik
yapılmamasına rağmen ikinci kez çalıştırdığımızda daha hızlı sonuç getirdi. Sizin de ilk
çalıştırdığınızda yavaş, sonrakilerde hızlı çalışan sorgularınız olmuştur. Bu fark neden
kaynaklanmaktadır?
Cevabı çok basit; ilk çalıştırdığımızda veriler diskte duruyordu. SQL server verileri diskten
okuyup önce server memorisine taşıdı sonra sonucu getirdi. Sonraki çalıştırmada ise doğrudan memoriden okuyup sonucu getirdi.
Bu nedenlerden dolayı SQL sorguları performansı kıyaslamak için süreye(Duration) değil,
sorgunun okuma(read) yaparken ne kadar IO yaptığına bakacağız. Sorgu ve tablolardaki kayıt sayıları aynı kalmak şartıyla, IO ortamlardan bağımsızdır ve her koşulda aynı sonucu verir.

IO İstatistik Bilgilerinin Gösterilmesi

IO miktarını görmek için sorgumuzdan önce aşağıdaki SQL komutunu çalıştırıyoruz.
set statistics io on

Aynı sorguyu tekrar pes peşine 2 kez çalıştırdım. Süreler daha öncekilere yakın değerlerde;
1733 ms. ve 1273 ms. olarak gerçekleşti. Sorgu sonucunda yapılan IO miktarlarını da
görebiliyoruz. Bizim için önemli olan yer “logical reads” yani memoriden okumaları gösteren  kısımdır. Her iki sorguda da 32.980 olarak görünüyor. İlk sorguda “physical reads” ve “readahead reads” değerleri de var. Bunlar yukarıda bahsettiğim gibi diskten okumaları
göstermektedir.
Peki, 32980 neyi ifade eder? Okunan page miktarıdır ve aslında bu OLTP sistemler için yüksek
bir değerdir.

3 numaralı sorguda tablodaki kayıt sayıları bulurken bile daha az IO yapıldığı görülmektedir.
Tablonun tamamının okunması ise yalnızca 3 kat fazla IO ya neden olmaktadır.
Eğer sorgumuz düzgün olarak index kullanılıyor olsa aşağıdaki gibi tek haneli veya 3 haneli IO
miktarları görmemiz beklenir

Yalnızca 3 adet IO ile sorgu sonucunu getirmektedir.

Serverın Harcadığı Süre ve CPU Kullanımının Gösterilmesi

IO ile birlikte SQL server işlemi yapabilmek için CPU da tüketir. Ne kadar CPU kullandığı
aşağıdaki komut ile görebiliriz.
set statistics time on

Bu sorguyu çalıştırırken CPU süresi 1203 ms. olmuştur. Core sayısı yüksek olan serverlarda
paralel execution yapılabilmesi durumunda “CPU time” ile “Elapsed time” arasında belirgin
farklar olmaktadır. Buradaki sorgumuz basit olmasından dolayı iki değer birbirine çok yakın
olmuştur.

Primary Key Kullanım Amaçları ve Tanımlanabileceği Durumlar

Üniversite veri yapılarını dersininde hocamız Primary Key ne işe yarar diye
sorduğunda, arkadaşımız “silme” işine diye cevap vermişti. 

Veri tabanında silme
işlemi neredeyse hiç yapmayız. İşi biten kayıtı silme yerine tabloya durum veya
aktif kolonu ekleyip, bu kolonlar üzerinden güncel ve eski kayıtları takip
ediyoruz. Silme işlemi yok denecek kadar az olduğuna göre yine olayı
basitleştirmek için diyebilirim ki; primary key “update” için kullanılır.

Primary key 

Tablodaki her bir kayıtın ayrıştırılmasını, tekilleştirilmesini sağlayan
bir kısıttır. Neden kayıtları tekilleştirmek isteriz? Bence bunun en önemli nedeni,
silme ve güncelleme işleminde sadece istediğimiz kayıt üzerinde işlem
yapmaktır. Örneğin yanlışlıkla aynı insert işlemini iki veya daha fazla
calıştırdığımızı düşünelim. Bu durumda sadece tek kayıtın kalmasını, diğerlerinisilmeyi isteriz. Bunu nasıl yapacağız? Primary key ile daha doğrusu primary key
kolonu ile. Kayıtların tek olmasının daha sık işimeze yaradığı husus ise, row bazlı
lock işlemi yapabilmektir. Lock ve row lock için yayınlanmış olan
“Lock, Blocking, Deadlock Nedir” konusuna bakılabilir.


Primary key için ikinci bir hususta, diğer bir tablodan bu tabloya referans verip
iki tablo arasında integratiyi korumaktır. Yani foreign key tanımlayabilmektir.
Primary key’in kullanım amaçlarını anlattıktan sonra diyebiliriz ki;

1. Bu tabloda delete veya update yapacak mıyım?
2. Bu tabloya başka tabloları bağlayacak mıyım, referans verecek miyim?

Eğer bu iki sorunun cevabıda hayır ise tabloya primary key tanımlamak
anlamsızdır. Bunun tersi doğru değildir, yani ikisinden birinin cevabı evet olsa
bile primary key tanımlamak gerekir anlamı çıkartılamaz. O halde diyebiliriz ki,
sadece insert ve select yapılan tablolar için primary key konulmaması daha
isabetlidir.

Primary key kolonları tekil(unique) olmak zorunda olduğundan dolayı, eğer
tabloda böyle bir kolon veya bir kaç kolonun birleşimi ile elde edilebilen tekillik
sağlanamıyorsa Unique bir kolon eklenmelidir ki; buna auto incremental veya
identity alan deriz.

Lock, Blocking, Deadlock Nedir?

Veri tabanları ACID(https://en.wikipedia.org/wiki/ACID) olmalıdır. Bu özellikleri sağlayabilmek için kullanılan mekanizmalardan bir tanesi de LOCK mekanizmasıdır. Birbirininden farklı lock tiplerini bulunur; okuma, yazma gibi. Lock tiplerini birbiri ile uyumlu ve ya uyumsuzdur. Örneğin okuma birbirlerini ile uyumlu iken yazma uyumsuz olabilir. Daha açık olması için, bir kaydı aynı anda iki proses okuyabilirken, aynı anda iki proses güncelleyemez. Buradan anlaşılabileceği gibi okuma işlemlerini yani select cümlelerini de sisteme lock koyar.

Lock konusunda diğer bir husus ise, lock seviyesidir. Seviyeden kasıtı, row, page veya tablo diye özetleyebiliriz. Örnek verelim, insert işlemi sadece o kayıtı locklar, bu sırada aynı kayıta okuma gelirse lock olduğundan dolayı insert işlemi tamamlanana kadar bekler. Yine tek bir kayıtı güncellediğinizi(update) düşünelim. Bu durumda sadece o kayıt mı locklanır? Bilemeyiz, eğer güncelleme işlemi index kullanmıyorsa tüm tabloyu bile locklamış olabilir. Buradan açıkca anlaşılacağı gibi, o tablodan okuma, yazma yapacak olan tüm prosesler güncelleme işleminin bitmesini bekleyecektir.

Lock işlemini anlatırken, bekleme konusu geçti. Veritabanında Wait dediğimiz beklemeler oluşur. Bekleme sebepleri farklı farklıdır, lock sadece bunlardan bir tanesinidir. Memory, CPU,disk hatta network gibi kaynaklar kullanımlarında dolayı beklemeler oluşabilir. Örneğin 20 core bir makinede aynı anda 20 den fazla proses işlem yapmak isterse ne olur? Yine okuma hızı düşük bir disk sisteminden büyük miktarda veri okursanız ne olur? Veri tabanı sistemi, okuma işlemi bitene kadar bekleyecektir. Bu tip beklemelere IO_wait denir.
Lock ve wait konularını açıkladıktan sonra blocking’i açıklayabiliriz. Her hangi bir sebepten
ötürü, bir proses başka bir prosesi bekliyorsa, bu işleme blocking denir. Aslında sistemde lock var yanlış bir terimdir. Sistemde her zaman lock olur, tehlikeli olan lock’ın blocking’e sebep olmasıdır.

Deadlock ise, karşılıklı iki prosesin birbirini beklemesidir. Basitce örnekleştirelim, 2 kayıtlı
tabloda ilk proses 1 nolu kayıtı güncellemiş 2. kayıtı güncelleyecek, diğer proses ise 2 nolu kayıtı güncellemiş 1 nolu kayıtı güncelleyecek. Bu durumda iki proses birbirini sonsuza kadar beklemesi gerekir. Bu durum oluştuğunda veri tabanı sistemi fark eder ve içlerinden birini kurban olarak seçip sonlandırır

Özetle blocking ve deadlock’ın sebebi lock’lardır.
CPU, memory vs gibi hususlardan kaynaklanan wait ve blocking’lere developerların müdahale sanşı yoktur. Developerlardan beklenen; locking süresini münkün olduğunca minimumda tutmaktır. Bu da kapsamı münkün olduğunca dar tutmak yani transaction bloğunu küçültmek ve doğru index kullanarak değdiğimiz(lock koyduğumuz) kayıtların sayısını minimumda tutmakla olur.