commodore.gen.tr

Arkadaşlar merhaba kafama bir soru takıldı ve sizden bu konu hakkında bir fikir istiyorum.
Aslında soracağım soru çok teorik bir soru.

SQL ve NoSQL veritabanı sistemleri var biliyorsunuz ben bu güne kadar hep sql sistemleri üzerinde çalıştım ve uygulama geliştirdim vs, ama nosql sistemleri de araştırdım okudum biraz.
NOSQL sistemlerin sorgu cevap hızı sql sistemlere göre çok daha hızlıymış bunu öğrendim.

Ancak şöyle örnek vererek anlatayım.

Kişi Adı;Mail Adresi;Cep Tel;Doğum Tarihi
Hakkı;hakki@gmail.com;2131535;01.01.2001
Durmuş;durmus@gmail.com;2351535;01.01.2001
Aslı;asli@gmail.com;8454;05.05.20225

Mesela bunun gibi bu da bir veritabanı öyle değil mi genelde bunu .CSV olarak kaydederler.

Şimdi sql olsun veya nosql olsun diyelimki bu dosyayı baz almayın kendi dosyasında 1 milyon kayıt var ben bu kayıtları okumak için c# ta FileStream kullanıyoruz mesela File.ReadAllText dersek mesela tüm dosyayı komple okuyup bir değişkene atıp ordan gerekli işlemleri yaparak ekranda göstertebiliriz veya File.ReadLine diyerek örneğin satır satır okuyarak ta aynı işlemleri yapıp yine ekranda gösterebiliriz.

Benim anlamadığım bu veritabanı sistemleri dosyaları okurken bu şekilde okumuyor mu yani eğer bir dosyada 1000 kayıt varsa ekranda göstermek için bu 1000 kaydı okumak zorunda.

Ya da şöyle anlatayım bu 1000 kayıt arasında herhangi bir kaydı aramak için en baştan başlayıp tüm kayıtları teker teker okuyup bulduğu sonucu değişkene atıp göstermesi gerekir. Müneccim değil ya tüm kayıtları gezmesi gerekir mantık olarak.

Durum böyle olunca nasıl oluyorda SQL veya NOSQL birbirinden farklı hızlarda çalışabiliyor?

Şimdi okuduğum kadarıyla NoSQL de genelde anahtar ve değer şeklinde veriler kaydediliyor tablo, satır, sütun yapısı yok ancak yine de dediğim gibi veri yapısı nasıl olursa olsun senin veritabanında 1000 kaydın varsa bu 1000 kaydı da gezmen gerekir, ya da bir kayıt aramak için iç içe döngü kurup bu kaydı aratman lazım.

Cevaplarınızı bekliyorum.

Selam programci42


Hash table (veya hash map) adı verilen veri yapısı hakkında bilgin var mı? Bu yapı kullanılarak belli bir kayıda, tüm kayıtları gezmeksizin ulaşılabiliyor. SQL de, NoSQL de altyapısında bu yapıdan yararlanır.


Evet o okuduğun şey bir nevi hash table tarifi.


Hayır gerekmiyor. Zaten gerekmesin diye anahtar-değer ikilileri olarak kaydediliyor veri. Sen o konuyu biraz araştırırsan kafanda soru işareti kalmayacaktır.


Bu iki veri tabanı sisteminin arasındaki hız farkını, kullandıkları algoritmaların verimliliği, geliştirildikleri dil, kullandıkları derleyici, dosya sistemine erişimde kullandıkları dış kütüphanelerin optimizasyonu ve benzeri bir çok unsur belirler.

Selam programcı 42,
Alpyre’nin de belirttiği gibi ilişkisel veri tabanları hashtable benzeri bir yapı ile erişilecek dataları indexlerler. Hatta veri yapısını oluşturan kişi index’leri de ilişkileri verir. Bu nedenle hızlı bir şekilde tüm dataları dolaşmadan istenilen veriye ulaşır.

Tabi örneğin cinsiyet diye bir kolon olduğunu düşünelim Kadın ve Erkek olarak iki değer alabileceği için bu kolon indekslense bile tablonun yarısını dolaşması gerekecektir.

Bazı tablolar belirli kural setine göre partition’lta ayrılabilir. Örneğin yıl gibi.

NoSql ise ilişkisel veri yapısını kullanmamaktadır. Bu nedenle dataya erişim algoritmaları farklılık gösterir. Ayrıca belirli veri modelleri için tasarlanmış alt tipleri de vardır. NoSql Graph db gibi.

Elmasri / Navathe'nin Fundamentals'ını biz okumuştuk, siz de okuyun:

https://b-ok.asia/s/elmasri%20navathe

Tüm yanıtlar ve pek çok fikir uyandıracak çözümler bu ve benzeri kitaplarda.


Bu arada, evet bilgisayarlar müneccimdir. Yoksa niye onlarla her tür tahmin işini yürütelim öyle değil mi?

Bir de minik bir gereksiz bilgi: Bir zamanların meşhur dBase programının ilk versiyonu dBase II adını taşır, sonraki sürümler de dBase III ve dBase IV... Programcıları, profesyonel görünsün, hiç var olmamış I'den daha iyi bir versiyon izlenimi uyandırsın diye ilk sürümün numarasını II'den başlatmışlar.

Çok güzel cevaplar gelmiş. Ufak bir ekleme yapayım. NoSQL veri tabanlarına non-relational da denilmesi kafa karıştırmasın. Bu isim veri tabanının bağlantısal olmadığı anlamına değil veri yapısının klasik bağlantısal veri tabanı mantığında olmadığına işaret ediyor. Yani CSV gibi tutulmuyor. Ancak bağlantıları tanımlamak için alternatif yöntemler kullanılıyor. Big data, web uygulamaları gibi durumlarda klasik SQL veri tabanlarından hızlı çalışması da ölçeklenebilirlik, bölünebilirlik gibi avantajlardan geliyor.

CSV dosya teknik olarak bir veri dosyasıdır ama ancak primitif bir veri tabanı olarak düşünebilirsin. Bağlantısal olmadığı için içinden istediğin kaydı bulmak istediğinde bütün satırları okumak gerekir. Veri tabanı ise veriler arasında kurduğu bağlantıları kullanarak bu işi bütün veriyi okumadan çok daha hızlı yapabilir.

Çok teşekkür ederim cevaplarınız için yalnız bu arada ilkerficiciların verdiği link çalışmıyor.

Hash table yapısını inceledim ve örnek kodlara baktım ve bunu anladım.

Fakat hala anlamadığım bazı noktalar var mesela bu indexleme meselesi tam olarak ne yapıyor orda index yaparken.

Şu satırda şu veri var diye kaydetmiyor değil mi o şekilde çalıştığını düşünmüyorum.

Şimdi tabloda Primary Key olarak tanımladığımız alan clustered index mi oluyor?

Bu ifadeleri de okudum ama yine de tam anladığımı söyleyemem.

C# ta mesela list türünde değişken tanımlayabiliyoruz bu dizide mesela arama fonksiyonları olarak .indexof veya .contains gibi fonksiyonları söyleyebiliriz. Ama mesela Contains yazdığımızda nasıl bir işlem yapıyor orasını bilmiyorum sadece listede aradığım değer varsa true yoksa false döndürüyor. Bu fonksiyonda da sanırım o zaman listeyi teker teker dolaşmıyor.
Çünkü liste ne kadar büyük olursa olsun çok kısa bir sürede cevap veriyor.

@Programcı42  merhaba,

İlişkisel veri tabanları örneğin Oracle bir dataya erişirken, index, tablolardaki kayıt sayısı, veri tipleri vs birçok parametreye göre bir execution plan oluşturur. Bu plana göre de datayı çeker. Tabloların istatistik değerlerinin bulk data silme ya da ekleme durumunda yeniden oluşturulması gerekir. Çünkü örneğin  500 kayıt içeren bir tablo bir anda 1 milyon kayıt içerir hale gelirse execution planın da bu yeni kayıt sayılarına göre oluşması gerekir. Bu planı oracle kendi içerisinde otomatik olarak çıkarır. Bazen de özellikle bir plan set edilebilir. Şu index’i kullan vb.

C# tarafında ise list, linked list, dictionary gibi veri yapıları ile veriler tutulur. Arama sırasında belirli bir algoritmaya göre arama yapılır. Dataya erişirken maliyetinin(coplexity) ne kadar olduğu O(n),  O(n²) vb formuller ile belirtilir.

List için, C#’daki contains  O(n) karmaşıklığındadır ve primitive data tipleri için hızlı çalışır. Örneğin int. Ancak  bir obje listesi varsa elinde referans type olduğu için devreye heap girecektir ve karşılaştırma daha uzun sürecektir.

Fakat dictionary veri yapısı örneğin datayı key, value çiftleri ile tuttuğu için karmaşıklığı O(1) olcaktır ve key üzerinden dataya direk erişecektir.

Özetle veri yapıları ( data structures) konusudur bahsettiklerim. İhtiyacımıza göre ilgili veri yapısını seçerek kullanmak gerekmektedir.

Veri tabanı tarafında ise dataya erişim hızı önemlidir ancak özellikle finansal işlemlerde daha da önemli olan veri bütünlüğü (transaction) yapısıdır. Bir havale işlemi sırasında uygulama hata alırsa geriye dönük olarak yaptığı tüm işlemleri geri almalı(rollback) ya da hatasız sonlandıysa tüm işlemleri bir bütün olarak yansıtmalıdır(commit).

Kaypro II'nin de benzer bir hikayesi var... İlk Kaypro olmasına rağmen zamanın en popüler sistemi Apple II olduğu için ve Rakip Osborne'un ilk sürümde olmasından dolayı, Kaypro II olarak isimlendirip, avantaj elde etmeyi istemişler. Sonuçta başarılı da olmuşlar.

Bunun üzerine Commodore 64 ile ilgili bir espri yapmak istedim ama çok kötü olacağını düşünerek vazgeçiyorum.

Yoksa Gora filmindeki karışık var mı var karışık yükle sahnesini mi diyecektin  :D.

Ben de henüz yeni yeni başladım araştırmaya NOSQL olayını. Veritabanına bulut taraflı tüm platformlardan erişilebilirlik benim için daha önem kazanmaya başladı. MongoDB ile giriş yaptım.

Lakin bu hız konusu (SQL vs NOSQL) kullanıcı taraflı pek farkedilir olduğunu düşünmüyorum.

Yok ya farkediyor yani farkediyor derken mongodb kullanmadım hiç ama bizim şirketin veritabanında bir tablo var SQL server 2012 üzerinde 12 milyon satır kayıt var bı select çekiyorum 30 sn bekliyorum.

Öncelikle bütün indexleri eğer varsa yeniden oluştur ve defragment et.

Şuradaki script işini görecektir.

https://www.mssqltips.com/sqlservertip/1367/sql-server-script-to-rebuild-all-indexes-for-all-tables-and-all-databases/ (https://www.mssqltips.com/sqlservertip/1367/sql-server-script-to-rebuild-all-indexes-for-all-tables-and-all-databases/)

Index yoksa, sorgundaki sıraya göre önce select alanları ve ardından where deki alanları içeren bir index yarat. Yani,

select Id,Adi,Soyadi,Uyruk from Uye where Cinsiyet=E, BabaAdi like "%MAHMUT%'

buna göre index şu şekilde olsun,

ID (PK),ADI,SOYADI,UYRUK,CINSIYET,BABADI

Tabloyu o an bir çok kişinin kullandığını varsayıyorum, bir de NOLOCK kullanmayı dene. Tablolar çoğu zaman üzerinde bir client işlem yaparken
ikinci bir clientin işlemini tabloyu kilitleyerek bekletir. Bunu da çok tavsiye edilmese de, dirty read ile yani NOLOCK hint'i kullanarak beklemeden tabloyu okuyabilirsin. Sorgunu şu şekilde yaz ve öyle dene.

select Id,Adi,Soyadi,Uyruk from Uye WITH (NOLOCK) where Cinsiyet=E, BabaAdi like "%MAHMUT%'

Bu şekilde tablonun o anki kilitli halini beklemeden okursun. Pis okumadır çünkü henüz son kullanıcının işlemi (INSERT-UPDATE-DELETE) bitmemiştir.

Ondan sonra bir bak hız ne kadar farkedecek. Her yoğun sorgu için bu şekilde index yarat ama kullanmadığın ve yarattığın her index boşuna veritabanını şişirecektir.

Abi okumanın pisini temizini bilmem ama senin dediğin NoLock komutunu kullanınca sorgunun gelme süresi 2 katına çıktı  :).

Bir arkadaşım bana index rebuild komutunu kullanmamı önerdi ancak onda da bir performans artışı sağladığını görmedim.

Sunucumuzun genel özellikleri:
Intel Xeon E2640 V3 2.60 GHZ 6 çekirdekli işlemci
9,5 GB Ram
Windows Server 2016 X64 bit işletim sistemi
SQL Server 2012 R2 sql sunucu kurulu


Ayrıca sunucuda çalışan 3 - 4 tane sanal makine var bildiğim, sunucuya yapılan client bağlantı sayısı günlük 200 cihazı bulabiliyor. (Bunlara Bilgisayarlar, telefonlar, tabletler ve diğer cihazlar da dahildir.)

Indeksleri verirken çok dikkat etmelisiniz günde 1 kere kullanılacak bir sorgu için index atamak select kazanımı olsa dahi insert,update,delete kaybı olarak size geri gelecektir. Bu yüzden attığınız taş ürküttüğünüz kurbağaya değmeli, gerekmiyorsa bırakın 30sn olarak kalsın onu azaltmak için ek index oluşturma işine girişmeyin. Bunun dışında * lı sorgular performans kaybı yaratır , sebebi sorguda dönen ama kullanmadığımız alanlarda yer alan verilerin  yoğunluğu . İhtiyacınız olmayan alanları sorgudan düşmek genel sorgu hızınızı çoğu senaryoda artıracaktır.

Tam olarak anlayabilmek adına soruyorum;
9.5gb ram i olan sunucuda 3 veya 4 adet sanal makine var, bunlardan biriside SQL Server olarak hizmet veriyor ve siz içinde 12 milyon kayıt olan bir tablodaki select i mi optimize etmeye çalışıyorsunuz?

Yok hayır ana fiziksel sunucuda SQL server var bu bahsettiğim 12 milyon kayıtlı tablo fiziksel sunucuda diğer sanal makineler de de başka programlar ve SQL serverlar kurulu bunun dışında sunucuda ASP.net web sunucu mongodb veritabanı iis, FTP gibi servislerde var RAM yaklaşık %80 dululuk oranı ile işlemci de yaklaşık %75 i kullanılıyor.

Sunucunun fiziksel özelliklerini artırmayı teklif ettim ancak benden daha önce de sanırım bir kaç kez yapılmış daha fazla ısrar edemiyorum alt tarafı bi rapor çekecez uzaya roket mi gönderiyoruz niye bu kadar çok yavaş ve sıkıntı çıkarıyor diyorlar haklı olarak ben de sunucu iyi sunamıyor çok çalışıyormuş diyorum  :).

Yani sizin fikriniz nedir sunucunun özellikleri bence gayet iyi şahsen hayatımda böyle güçlü bir bilgisayara bile sahip olmadım yani 12 milyoncuk kayıt görünce bayılmaması lazım bana göre.

Tabi içinde çalışan sanal makineler onun performansını düşürür biliyorum her an cevap vermesi gereken ona bağlı cihazlar var vs zaten onun kullanım amacı o o sunucu her şeyi sunması lazım anında bekletmeden Google da bir şey arıyorsunuz bilemem kaç miltar kayıt bulundu 0.678 sn re diyor mesela tabi Google süper bilgisayarlar kullanıyor ama neyse yani öyle işte...

Sunucunuzun kapasitesi bana göre sistem kaynağı canavarı olan SQL server için hiç yeterli değil. Bu tür sunucularda kaynak planlaması yapmak için bir çok faktör hesaba katılır. Ne kadar transaction olduğu, verinin büyüklüğü, ne tür raporlar çekileceği vb. bunlara bakılarak sistem kaynaklarının olması gereken değerlerine karar verilir. Diyebilirim ki sizin sunucunuz şu anki teknolojilere göre çok geride, özellikle RAM çok az, hele hele verilen roller ve üzerinde başkaca sanal makineler olması performansı oldukça olumsuz etkiliyordur. Disk hızlarını, SQL sunucu ayarlarını vs hiç sormuyorum bile. Örneğin sunucu bir storage a bağlı ise sorun aradaki bağlantı hızı bile olabilir. Veya sunucu eski ise write cache in pili bitmiş ve artık disklere yazmayı cacheleyemediği için performansı gözle görülür azalmış olabilir. Kısacası donanım tarafında bakılması gereken bir çok nokta var.
Donanım haricinde ise veritabanı üzerindeki transaction yükü raporunuzun geç gelmesine sebep oluyor olabilir. Sorgunuzun içindeki joinlerin fazlalığı, sunucuyu veri okumaya veyahut istenen verileri aramaya itecek her türlü istekler rapor süresini uzatacaktır.
Ancak yine de eldeki imkanlarla devam etmek durumunda iseniz tavsiyem yazdıgınız sorgunun planını iyice inceleyip cost oluşturan yerlere bakın, index vs eksiklerini tamamlayın. Cost u iyice dibe indirmenize rağmen sorgu halen yavaşsa örnekleminizi küçülterek deneme yapın. Yani mevcut tablolarınızın birer kopyalarını oluşturun, içlerindeki kayıt sayılarını iyice düşürün. Bu şekilde geriye doğru giderek sisteminizdeki darboğaz nerede bulabilirsiniz diye düşünüyorum.

skonac teşekkür ederim tavsiyelerin için şu an mevcut imkanlarla ilerlemek durumundayız gibi görünüyor.
Bunun dışında  yine hem bu konu ile alakalı hem de bu konudan bağımsız bir sorum daha var.

Yine bu sunucu içinde çalışan sanal makine içinde kurulu bir sql server 2012 içinde bulunan stokhr isminde stok hareketlerinin tutulduğu bir tablom var.

Bunun haricinde sadece stoğa ait isim ve bilgilerin bulunduğu bir de Stoklar tablom var.

Örnek kayıtlar şöyledir.

id  stok_id  Miktar  islem
1   10       15      Giriş
2   10        5      Çıkış
3   11        7      Giriş
4   11        4      Giriş
5   11        2      Çıkış

Şeklinde tabi tabloda bu kadar sütun yok sadece örnek olarak bunları yazdım tarih, kişi, açıklama kaydeden, değiştiren gibi sütunlarda var.

Şimdi 2 tane SQL kodu göstereceğim bunlardan hangisi daha performanslı çalışır sizce
şu an tabloda en fazla 300 kayıt olduğu için ikisini de çalıştırdım ancak tabi çok fazla kayıt olmadığı için hiç bir fark oluşturmadı ikisi de 1 sn alında yanıt verdi.

Bunlardan ilk sorguyu bir view haline getirdim ve o şekilde kullanıyorum.
Bu view i aslında Sorgu 2 olarak ALTER leyebilirim programsal açıdan da bir sorun oluşturmaz aynı sütun isimleri var zaten.

SORGU 1
SELECT        dbo.Stoklar.id, dbo.Stoklar.Stok_Adi, dbo.Stoklar.Cinsi, dbo.Stoklar.Eb_Bilgi, T1.Giren, T2.Cikan, CONVERT(int, T1.Giren) - CONVERT(int, T2.Cikan) AS Mevcut
FROM            dbo.Stoklar INNER JOIN
                             (SELECT        Stok_id, SUM(Miktar) AS Giren
                               FROM            dbo.StokHR
                               WHERE        (islem = 'Giriş')
                               GROUP BY Stok_id) AS T1 ON dbo.Stoklar.id = T1.Stok_id INNER JOIN
                             (SELECT        Stok_id, SUM(Miktar) AS Cikan
                               FROM            dbo.StokHR
                               WHERE        (islem = 'Çıkış')
                               GROUP BY Stok_id) AS T2 ON dbo.Stoklar.id = T2.Stok_id AND T1.Stok_id = T2.Stok_id


SORGU 2
Select tbl.Stok_id, Stoklar.Stok_Adi, stoklar.Cinsi, CONVERT(varchar, Stoklar.Eb_Bilgi) As Ek_Bilgi, (Select SUM(Miktar) From StokHR WHERE islem = 'Giriş' And StokHR.Stok_id = tbl.Stok_id) As Giren,
(Select SUM(Miktar) From StokHR WHERE islem = 'Çıkış' And StokHR.Stok_id = tbl.Stok_id) As Cikan,
(Select SUM(Miktar) From StokHR WHERE islem = 'Giriş' And StokHR.Stok_id = tbl.Stok_id)  -
(Select SUM(Miktar) From StokHR WHERE islem = 'Çıkış' And StokHR.Stok_id = tbl.Stok_id) As Sonuc
From StokHR As tbl, Stoklar WHERE tbl.Stok_id = Stoklar.id
Group By tbl.Stok_id, Stoklar.Stok_Adi, Stoklar.Cinsi, CONVERT(varchar, Stoklar.Eb_Bilgi)     

SQL Server 2012 de ki Execution Plan ı inceledim fakat hangisi daha çok kaynak tüketiyor tam olarak anlayamadım.

Sorgu 1 de çok daha az işlem yapmış ama yüzde oranları fazla, Sorgu 2 de ise çok iş yapmış ama yüzde oranları düşük.

Ekte Sorgu1.Jpg ve Sorgu2.Jpg Execution Plan ı görebilirsiniz.