Veri Tabanını Küçültecek Algoritma

[gaus]

Merhabalar bir fikrim var abilerim arkadaşlarım sizinle paylaşmak istedim.Fikir alışverişi olsun.
Şimdi biliyorsunuz ki veritabanlarımızda bir çoğumuz Master ve Detail yapıları kullanırız.İşte Sipariş SiparişKalem gibi...
SiparişKalem tablosunu neden neden tek tek satır ekleyelim.
Bunun yerine Siparis tablosuna bir alan açıp sipariş kalem tablosunu Xml yada json olarak kaydetsek nasıl olur ?
Eeee o zaman nasıl düzenleyeceğiz.Her seferinde o xmli yada jsonu çağırıp memtable yapıp düzenlendikten sonra yeniden kaydederiz.
Haa bu arada her bir satırı ayrı işlem olan veritabnlarında olmaz.Örnek Cari ve Cari Hareket gibi tablolarda olmaz

[fesiharslan]

Merhaba;
1- Özellikle sık kullanılan ve kayıt sayısı fazla olan bir tabloda belirtmiş olduğunuz yapıyı uygulamak çok da mantıklı olmayacaktır.
2- Detay tabloda indexleme yapamayacaksınız.
3- Detay tabloda çerik araması yapamayacaksınız. Bazı veri tabanlarında fullText Search olmasına rağmen veri tabanı yönetimi (her kayıt işlemi sonucunda indexlerin ReBuild edilmesi gibi.) son derece zor olacaktır.
4- Text alanlarını son kullanıcılara biçimlendirerek göstermemiz gerekecektir. Bu işlem uygulamanın bellek tüketimini artıracaktır.
5- Ek işlemler yapmak zorunda kalacaksınız. (Parse işlemine tabi tutmak, sanal bir tabloda kayıtları göstermek gibi.)

[gaus]

Merhabalar dediğim gibi bu cok fazla isleme tabi tutulmayacak olan detay vb.isler için geçerli
Arama mevzuna gelirsek ElastikSearch mantığıyla yapilamaz mi

[Lord_Ares]

Aslında düşüncenize birde şunu ekleyip fikrin olumlu olumsuz yönlerini görmeli diye düşünüyorum.
1) Programınız çalışacağı sistem ve durumları nedir ? ( local mi? , local network mü ?, remote network mü gibi..)
2) Çok kullanıcılı mı , tek kullanıcılı mı ?

Sizin dediğiniz ilk düşündüğüm de , veritabanın da boyuttan yer kazanmış olabilirsiniz ama söz ettiğiniz işlemleri yaparken bilgisayarın işlem hacminden kaybettiniz. Araya ek bir uygulama giriyor, belleğinizde, veritabanının işlem yaparken ayırdığı alandan daha fazla alan ayırmış oluyorsunuz (cash bellek veya ram ). Eğer arada network varsa network trafiğinede ek yük geliyor.
İşte burada bana göre işler biraz değişiyor )) Hangisi daha kötü olduğu tartışılır. Benim şahsi fikrim bırakın data büyüsün , bence diğer işlemlere göre daha karlı olacaksınızdır. Bunu birde üstadlarımıza sormalı belkide düşüncem yanlış olabilir. Sadece şahsi fikrimdir, herhangi bir iddam yoktur.

[greenegitim]

Uygulama ile ne yapılcağına ne kadar bilgi tutulacağını bağlı txt dosyasının da yeterli olacağı yer var ama bir yere kadar tutulacak veri büyüdükçe RDBMS araçları kullanmak kaçınılmaz oluyor daha sonra bu bilgilerden rapor çekmek gerekiyor bunun için çok verisi olan firmalar veriambarını oluşturuyorlar yanlış hatırlamıyorsam bddk nın bir uygulamasın da bilgi değiştirilemez gibi bir ibare vardı bu tür isteklerinde karşılanması hali hazırda bu kadar gelişmiş rdbms ler ile mümkün iken dosyalarla bu işlemi yapmak çok zor olacaktır.

[gaus]

Evet ram yeme özelliği var ama normal sqli adolara adotabllelara verdigimizde oluşan datasetlerde ram yemiyor mu ? Ayni durum
Bu bir proje icint değil tartışmak olsun diye ekledim
Bu arada basit bir storeced prosedürle tüm xml kayitlarindaki herhangi bir bilgiye ulaşabiliriz

[freeman35]

Evet ram yeme özelliği var ama normal sqli adolara adotabllelara verdigimizde oluşan datasetlerde ram yemiyor mu ? Ayni durum
Bu bir proje icint değil tartışmak olsun diye ekledim
Bu arada basit bir storeced prosedürle tüm xml kayitlarindaki herhangi bir bilgiye ulaşabiliriz

Ozaman gereksiz bir konu. sequantial ve random dosyalarla uğraşmadığım belli şu db nin boyutu neden bukadar dert ediyorsunuz ? optimize edeceksiniz db mantığınızı, table larınızı optimize edin. Size ne zararı veriyor db nin büyüklüğü ? gereksiz bilgimi var içinde? ozaman neden kaydediyorsun? az kullanıyorum yada ayda yılda bir bakacaksan bile bilgi bir yere yazılmak zorunda değil mi? xml e yazınca buna o saçma tag vs stringler eklenmiyecek mi? 10char bir string i db ye yazmak ile xml yazmak daha az mı yer kaplıyacak ? diskin cluster mantığınıda bir düşünün, üzerine bunun erişimi için gerekcek disk hareketinden olacak gecikmeyi hesaplayın. ssd bile olsa. sonrada bunun parse edeceksin, sonrada buna gerekli yere eklemek için kod yazacaksın, bunu değişkenlere alacaksın, bunlar hafızadan kaybedecek. memtable diyenlere aynı örneği vereyim, 10char bir string için memtable da 10byte mı kullanıyorsunuz? eminim ki çoğunuz classlar için ayrılan memory yi hesaba katmıyorsunuz, yada bilmiyorsunuz.
Daha devam ederdimde sanırım gerek kalmadı bu konu projeye göre değişir, okullarda eğitim vermek için yapılan projelerde, class öğretmek, kullandırmak, pratik yaptırmak için olabilir.
Gereksiz yere forum un db sinde yer işgal etmiyelim meseala

[gaus]

Gereksiz yere forum un db sinde yer işgal etmiyelim meseala
sevgili freeman35 bu söyleminizden hoşnut olmadım ki konuya yaklaşımınızda hoşuma gitmedi gereksiz vb. birşey demek.
Öncelikle benim burada yapmak istediğim şey,sormak istediğim asıl konu veritabanını küçültmek.Hiç her bir tablosu 5 6 milyon kaydı bulunduran ve iki bini aşkın tablo yapısıyla mücadele etmek zorunda kaldığınız bir projede çalıştınız mı ?
Veritabanı yönetimi o kadar da kolay olmuyor.Datanın büyüklüğü , hızı o kadar önemli oluyor ki ? Sanırım buradaki herkesi business programları yazar gibi düşünüyorsunuz o yüzden. Bigtable gibi mevzularda ki ben mongodb vs. kullanmadığım için buna benzer bir yapıyı getirebilir miyiz diye sormak istiyorum.Yani xml ya da json göm çek.Nasıl olur bunun tartışmasını yapmak istiyorum.Belkide kötü bir fikir bunu paylaşmakdaki hatam nerede onu anlayamadım.

[gaus]

Uygulama ile ne yapılcağına ne kadar bilgi tutulacağını bağlı txt dosyasının da yeterli olacağı yer var ama bir yere kadar tutulacak veri büyüdükçe RDBMS araçları kullanmak kaçınılmaz oluyor daha sonra bu bilgilerden rapor çekmek gerekiyor bunun için çok verisi olan firmalar veriambarını oluşturuyorlar yanlış hatırlamıyorsam bddk nın bir uygulamasın da bilgi değiştirilemez gibi bir ibare vardı bu tür isteklerinde karşılanması hali hazırda bu kadar gelişmiş rdbms ler ile mümkün iken dosyalarla bu işlemi yapmak çok zor olacaktır.

@greenegitim bir text dosyasında tutmayacağız bunu mastertablo da bir alanda tutacağız

[greenegitim]

Hocam o zaman belki hadoop cassandra gibi bir şeyler işinizi görecektir bunları bir inceleyin google amazon nasıl baş ediyor bunları incelemek lazım

[Opt2000]

Merhaba,

Sorulan soru aslında ilişkisel veri tabanlarını sorguluyor. Benim kişisel görüşüm şu: Bir hücre bir veri tutar. @gaus'un dediği benim görüşüme ters, çünkü bir hücrede XML/JSON/Text vs formatında birden fazla veri tutmak istiyor. Buradaki amaç veri tabanında daha az yer tutması ise iyi bir fikir değil. Çünkü XML/JSON formatının getirdiği ek karakter maliyeti ve "12345" CHAR veri tipi göre "12345" INT veri tipinin daha az yer tutacağı gibi detaylara bakılınca çok ciddi bir kazanç olur mu bilmiyorum. Bu durum tarih/saat formatlarında daha dramatik olabilir. Üstelik de elde ettiğiniz küçük bir kazanç uğruna ödediğiniz ağır programlama ve sorgulayamama bedeli var.

Programlama bedeli var, çünkü artık veriyi sadece veri tabanından çekmeniz yetmiyor. Bunu bir de kullandığınız formata göre (XML/JSON/Text) açmanız ve kullanıcıya anlamlı bir hale getirmeniz gerekiyor. Tabii bir de kaydetme kısmı var. Buradaki ek programlama maliyetini herkes görüyordur herhalde.

ElastikSearch veya FullTextSearch gibi işlere bulaşınca durum daha kötü bir hale geliyor. Bu tür sorgulamalar ya normal sorgulamaya göre daha yavaş çalışıyor ya da index oluşturuyor. Index oluşturunca veri tabanında daha fazla yer tutuyor. Yani kazancımızı başka bir yerde heba ettik Hadi index oluşturmadı diyelim, bu sefer sorgulama standart sorgulara göre yavaş oluyor. Normal olarak veri tabanı büyüdükçe bu sorun daha da artacaktır. Belki diskten biraz yer kazandınız (4 TB diskler ne kadar, 100$ mı?) ama bunun için sunucunuzun yükünü ve bütün müşterilerinizin bekleme süresini arttırdınız.

Sonuç olarak verilerin JSON/XML vs gibi formatlarla tek bir hücreye kaydedilmesi iyi bir fikir değil. Benim tavsiyem her hücreye sadece bir değer kaydedilmesi.

İyi çalışmalar

[vkamadan]

merhaba ,
"MongoDB" ye bir göz atabilirsiniz.

[gaus]

@Opt2000 sanırım herşeyi özetlediniz.Böylece konunun kısırlığını görmüş oldum.
@volkan BEY MongoDb olayını araştırdım.Tamamiyle Json gönderip Json alınıyor.Kodlamaya da başladım ki bundna osnra büyük verili işlerde hadoop mongodb vb. işleri kullacağım.Fakat elimdeki hali hazırdaki proje için sanırım @Opt2000 dediği gibi bu şekilde kalması daha mantıklı olacak.
ama konu açıktır.Dediğime ek olarak şöyle de yapılsa muazzam olur fikirleri olan olursa yazabilir buraya.

[gaus]

Hocam o zaman belki hadoop cassandra gibi bir şeyler işinizi görecektir bunları bir inceleyin google amazon nasıl baş ediyor bunları incelemek lazım

Benimde amacım bunu bulabilmek sanırım.Çünkü dakikada bine yakın veri geliyor.
Bu satır olarak adlandırılmasın.Satırxsutun sayısı gibi yani 50 satır 20 sutünlük veri gibi düşünün

[freeman35]

Gereksiz yere forum un db sinde yer işgal etmiyelim meseala
sevgili freeman35 bu söyleminizden hoşnut olmadım ki konuya yaklaşımınızda hoşuma gitmedi gereksiz vb. birşey demek.

Mümkündür, keşke son cümlemi yanlış anlamak yerine, diğer yazdıklarımı anlamaya çalışsaydın. Belkide yazdıklarımın kişiye değilde genele yönelik olduklarını da görebilirdin.
Kim icat ettiyse şu 3.çoğul konuşmayı kibarlık adledenin Allah tepesinden baksın. gavurlar "you" deyip geçiyor, tercüme eden kibarlıktır diye bir kişiye edilen hitabı siz diye çeviriyor.
Neyse, bu benimde arada sırada yaptığım hatadır, yani yazılarda mimik ve jest olmadığından yazarın söylediğini, kendi kafamızda kurguladığımız şekilde algılarız.
opt2000 in yazdıkları ile benim son cümle hariç yazdıklarım arasında kavram farkı var mı? bence yok.