sonraki »

[programci42]

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.

[Alpyre]

Selam programci42

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.

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.

Şimdi okuduğum kadarıyla NoSQL de genelde anahtar ve değer şeklinde veriler kaydediliyor...

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

...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.

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.

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

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.

[egemur]

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.

[ilkerficicilar]

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.

[wizofwor]

Ç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.

[programci42]

Ç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.

[egemur]

@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).

[LW3D]

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.

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.

[wizofwor]

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

[programci42]

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

[emarti]

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.

[programci42]

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.

[Voltron]

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/

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.

[programci42]

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.)

[Altan Özdemir]

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.