"Mal bulmuş mağribi" gibi, buldunuz bi açığını geçin bakalım dalganızı.
Yalnız; dikkatli olun arkadaşlar. Olayı iftira boyutuna getirmeyin.
Tamam; MS-SQL'de TEXT alanları yavaştır. Yavaştır da SELECT TOP 10 deyince de tutup tabloyu baştan sona tarayıp sonra baştan 10 tanesini alın demez. İşte burası iftiraya kaçıyor. Gerçi PhoenixJedi böyle yapıyordur demiş. Üstüne herkes öyle yapıyor diye yorum yapmış.
Coderlord'un verdiği linkte zaten açıklanmış. Orada ORDER BY kullanılıyor. Yani ister istemez baştan sona taramak zorunda.
İyi çalışmalar.
SELECT TOP (SELECT FIRST) Performans farkı TEXT alanlarda
Selamlar Hakan Can,
Yazıları dikkatli okursan kimsenin kimseye iftira atmadığını görürsün
Phoenix de ben de aynı deneyi beraber yaptık. Sadece TEXT'lerde değil bir çok yerde de yavaş kalıyor, testlerle sabittir.
Ayrıca, yine dikkatli okursan ORDER BY kullanılmadı. Bunun dışında, ORDER BY Text'lerde kullanılamaz !!!
bkz err code from Query Analyzer
Görünen köy kılavuz istemez.
Bu arada bir ek daha, tek açık bu olduğunu düşünüyorsanız yanılıyorsunuz Ben kaç defa özel Servis Packler aldım M$'dan. Bulduğumuz BUG'ları düzelterek göndermişlerdi (Biz bildirim yapmamıştık ama karşılaştığımız tonla hata vardı) JOIN'leri şaşırıyordu daha ne ötesi mi var bu işin.
Biz burada delillerle konuşuyoruz, kimse atıp tutmuyor dikkatli olalım
Kolay Gelsin
Yazıları dikkatli okursan kimsenin kimseye iftira atmadığını görürsün
Phoenix de ben de aynı deneyi beraber yaptık. Sadece TEXT'lerde değil bir çok yerde de yavaş kalıyor, testlerle sabittir.
Ayrıca, yine dikkatli okursan ORDER BY kullanılmadı. Bunun dışında, ORDER BY Text'lerde kullanılamaz !!!
bkz err code from Query Analyzer
Bunun dışında M$ istediğigi atıp tutarken nasıl oluyor da Mazlumu oynuyor bunu bana kimse savunmasın lütfenServer: Msg 420, Level 16, State 1, Line 1
The text, ntext, and image data types cannot be used in an ORDER BY clause.
Görünen köy kılavuz istemez.
Bu arada bir ek daha, tek açık bu olduğunu düşünüyorsanız yanılıyorsunuz
Ben kaç defa özel Servis Packler aldım M$'dan. Bulduğumuz BUG'ları düzelterek göndermişlerdi (Biz bildirim yapmamıştık ama karşılaştığımız tonla hata vardı) JOIN'leri şaşırıyordu daha ne ötesi mi var bu işin.Biz burada delillerle konuşuyoruz, kimse atıp tutmuyor dikkatli olalım
Kolay Gelsin
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Kuri'nin SQL'nde ORDER BY yoktu Hakan Can.Hakan Can yazdı:Coderlord'un verdiği linkte zaten açıklanmış. Orada ORDER BY kullanılıyor. Yani ister istemez baştan sona taramak zorunda.
Ayrıca ORDER BY olsa bile yine de angutça. Sort'u baştan sona yapsın kabul. Ama bu bile bu kadar uzun sürmez ki..
Belki trilyon kayıtta. O da indekssiz ise.-
Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
order by da varchar sahayı kullanamıyorsan o zaman demek ki, indexli de olsa kullanamıyor??? breh breh breh!coderlord yazdı:Kuri'nin SQL'nde ORDER BY yoktu Hakan Can.Hakan Can yazdı:Coderlord'un verdiği linkte zaten açıklanmış. Orada ORDER BY kullanılıyor. Yani ister istemez baştan sona taramak zorunda.
Ayrıca ORDER BY olsa bile yine de angutça. Sort'u baştan sona yapsın kabul. Ama bu bile bu kadar uzun sürmez ki..
kaç para bu mssql? karşılığında bi de para istiyorlar he mi?
Firebird Foundation Member #208
http://www.firebirdsql.org
http://www.firebirdsql.org
Arkadaşlar bu tartışma sanırım M$-Sql Server in hatalarını ortaya çıkarmak için yaptırılmış sebil bir test ve araştırma durumunu almaya başladı. Malum m$ bazı ürünlerini test ettirmek için seçtiği kurum/birimlerden üstüne para da alıyor diye biliyorum. Dolaysıyla bu hata ve eksikleri tespit etmeniz bence çok işine yarıyacak 
En iyisi herkes bildiğini kullanmaya devam etsin, nasip olurda 3-5 sene sonra saç testi yaparız 
En iyisi herkes bildiğini kullanmaya devam etsin, nasip olurda 3-5 sene sonra saç testi yaparız Bilgiyi paylaşarak artıralım! Hayatı kolaylaştıralım!!
Selamlar Kuri_YJ,
Benim dediğim:
Sonuçta; SELECT TOP 10 * FROM URUN denildiğinde URUN tablosunun tamamını tarayıp sonra ilk 10 kaydı getiriyor gibisinden bir yorum yapıldı ve bununla dalga geçtiniz.
Sonuçta benim: "İşte burası iftiraya kaçıyor" dediğim konu da bu.
Yoksa: "Tamam; MS-SQL'de TEXT alanları yavaştır." diye zaten başta belirtmiştim.
ORDER BY’la ilgili olarak Coderlord:
Eğer hala baştan sona tarıyor diyorsanız, sırayla;
SELECT TOP 10
SELECT TOP 100
SELECT TOP 1000
diye test ederseniz zaten baştan sona taramadığını anlarsınız.
Diğer bir konu:
Bunun üstüne Terminatör:
Aslında benim vurgulamaya çalıştığım olay biraz da bu zaten.
Şimdi bu yazılanları doğru olarak algılayan bir arkadaş herhangi bir MS-SQL veya FIREBIRD seminerine iştirak etse ve seminerde:
"MS-SQL’de ORDER BY’da VARCHAR saha kullanılamaz hatta INDEX’li de olsa kullanılamaz ama FIREBIRD’de bu böyle değil vs. vs." dese arkadaş komik duruma düşmez mi?
Ayrıca; MS-SQL’de ORDER BY TEXT’lerde kullanılmaz. Ancak ORDER BY CAST(TEXT AS VARCHAR()) diyerek istediğinizi kısmen (8000 Byte’a kadar) yapabilirsiniz.
Diğer bir konu:
Bundan sonra yazacaklarım buna cevap niteliğinde fakat daha ziyade genel düşüncelerim.
Öncelikle 16 MB RAM, 2 MB büyüklük vs. yaklaşımlarından vazgeçin. Yıl 2006. DOS öleli nerdeyse 20 yıl oldu. DOS mantığından sıyrılın. 1 GB RAM’lerin, 100 GB Harddisklerin sıradan olduğu bir ortamdayız. FIREBIRD’ü de gidip üç kuruşluk PC’lere layık görmeyin. Bir veritabanı eğer gerçekten bir veritabanıysa onun yeri özel, müstakil ve adam gibi bir bilgisayardır (Veritabanının ciddi manada kullanıldığı programları ve/veya kuruluşları kastediyorum).
Yapılabilecek milyarlarca hatta sonsuz test var. Maalesef sizin yaptığınız test taraflı. Birkaç testle sonuca daha doğrusu istediğiniz sonuca varıyorsunuz. İşin kötüsü vardığınız sonuç korkunç. MS-SQL birçok konuda yavaş ve bunun delili var diyorsunuz. 20 km’lik yolu yarış pistinde bir-kaç dakikada giden bir yarış arabası, mesai günü sabah 8’de İstanbul-Kozyatağı’ndan FSM köprüsü üzerinden 4.Levent’e aynı mesafeyi 1 saatte gidemez. Ama olur mu böyle şey diyorsunuz.
Yarış arabası yarış pistinde test edilir.
Ayrıca testleri 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, 30, 40, 50, 75, 100, 200, 300, 500, 750, 1000, 1500, 2000, 3000, 5000, 7500, 10000 kullanıcılarda test ettiniz mi? Abartı gibi gelecek ama maalesef o vardığınız kesin sonuca ancak böyle varabilirsiniz. Yoksa FIREBIRD’ü PARADOX gibi görmüş oluyorsunuz.
Bir de mümkünse yaptığınız testi gerçek hayatla özdeşleştiriniz. Yani bu yaptığınız testteki tabloyu gerçek hayatta nerede kullanabilirsiniz? Kullanılabilirliği var mı?
Örneğin deyin ki benim şöyle bir tablom var ve bu tabloyu şu amaçla kullanıyorum ve ben bu testi işte bu tabloda yaptım.
Ben şahsen niye TEXT alan kullandığınızı da sorgularım o zaman. Niye VARCHAR kullanmadınız derim belki.
Çünkü TEXT bir alanın hızlı bir şekilde sorgulanması gerekiyorsa ben şahsen VARCHAR(8000) der bir de o alana INDEX oluştururum. Görün o zaman MS-SQL’le FIREBIRD’ün hızlarını.
Herkese iyi çalışmalar.
Benim dediğim:
PhoenixJedi ilk yazısında:"Yalnız; dikkatli olun arkadaşlar. Olayı iftira boyutuna getirmeyin.
Tamam; MS-SQL'de TEXT alanları yavaştır. Yavaştır da SELECT TOP 10 deyince de tutup tabloyu baştan sona tarayıp sonra baştan 10 tanesini alın demez. İşte burası iftiraya kaçıyor. Gerçi PhoenixJedi böyle yapıyordur demiş. Üstüne herkes öyle yapıyor diye yorum yapmış.
Coderlord'un verdiği linkte zaten açıklanmış. Orada ORDER BY kullanılıyor. Yani ister istemez baştan sona taramak zorunda."
Devamında SadettinPolat’ın, Terminatör’ün, CoderLord’un ve senin yaptığınız: "TOP 10, FIRST 10, Fetch All…" muhabbeti."SELECT cümleciğinde TOP 10 kullanıldğında M$ bütün kayıtları sorguluyo. Sonra ilk 10 kaydı getiriyo.
FB ise SELECT FIRST 10 dendiğinde sorqulama yapılırken kayıt sayısı 10 u buldumu sonucu anında dödürüyor.
Yani M$ yine bir mantık hatası yapmış gibi görünüyo... (Görüntü var Ses yok)"
Sonuçta; SELECT TOP 10 * FROM URUN denildiğinde URUN tablosunun tamamını tarayıp sonra ilk 10 kaydı getiriyor gibisinden bir yorum yapıldı ve bununla dalga geçtiniz.
Sonuçta benim: "İşte burası iftiraya kaçıyor" dediğim konu da bu.
Yoksa: "Tamam; MS-SQL'de TEXT alanları yavaştır." diye zaten başta belirtmiştim.
ORDER BY’la ilgili olarak Coderlord:
diyerek benim söylediğimin doğruluğunu (yani SELECT TOP 10 denilince tabloyu baştan sona taramadığını, ancak ORDER BY kullanıldığında taradığını ki bu FIREBIRD’de de böyledir) bir nevi teyid etmiş."Ayrıca ORDER BY olsa bile yine de angutça. Sort'u baştan sona yapsın kabul…"
Eğer hala baştan sona tarıyor diyorsanız, sırayla;
SELECT TOP 10
SELECT TOP 100
SELECT TOP 1000
diye test ederseniz zaten baştan sona taramadığını anlarsınız.
Diğer bir konu:
demişsin."Ayrıca, yine dikkatli okursan ORDER BY kullanılmadı. Bunun dışında, ORDER BY Text'lerde kullanılamaz !!!"
Bunun üstüne Terminatör:
demiş."order by da varchar sahayı kullanamıyorsan o zaman demek ki, indexli de olsa kullanamıyor??? breh breh breh!
kaç para bu mssql? karşılığında bi de para istiyorlar he mi?"
Aslında benim vurgulamaya çalıştığım olay biraz da bu zaten.
Şimdi bu yazılanları doğru olarak algılayan bir arkadaş herhangi bir MS-SQL veya FIREBIRD seminerine iştirak etse ve seminerde:
"MS-SQL’de ORDER BY’da VARCHAR saha kullanılamaz hatta INDEX’li de olsa kullanılamaz ama FIREBIRD’de bu böyle değil vs. vs." dese arkadaş komik duruma düşmez mi?
Ayrıca; MS-SQL’de ORDER BY TEXT’lerde kullanılmaz. Ancak ORDER BY CAST(TEXT AS VARCHAR()) diyerek istediğinizi kısmen (8000 Byte’a kadar) yapabilirsiniz.
Diğer bir konu:
demişsin."Biz burada delillerle konuşuyoruz, kimse atıp tutmuyor dikkatli olalım"
Bundan sonra yazacaklarım buna cevap niteliğinde fakat daha ziyade genel düşüncelerim.
Öncelikle 16 MB RAM, 2 MB büyüklük vs. yaklaşımlarından vazgeçin. Yıl 2006. DOS öleli nerdeyse 20 yıl oldu. DOS mantığından sıyrılın. 1 GB RAM’lerin, 100 GB Harddisklerin sıradan olduğu bir ortamdayız. FIREBIRD’ü de gidip üç kuruşluk PC’lere layık görmeyin. Bir veritabanı eğer gerçekten bir veritabanıysa onun yeri özel, müstakil ve adam gibi bir bilgisayardır (Veritabanının ciddi manada kullanıldığı programları ve/veya kuruluşları kastediyorum).
Yapılabilecek milyarlarca hatta sonsuz test var. Maalesef sizin yaptığınız test taraflı. Birkaç testle sonuca daha doğrusu istediğiniz sonuca varıyorsunuz. İşin kötüsü vardığınız sonuç korkunç. MS-SQL birçok konuda yavaş ve bunun delili var diyorsunuz. 20 km’lik yolu yarış pistinde bir-kaç dakikada giden bir yarış arabası, mesai günü sabah 8’de İstanbul-Kozyatağı’ndan FSM köprüsü üzerinden 4.Levent’e aynı mesafeyi 1 saatte gidemez. Ama olur mu böyle şey diyorsunuz.
Yarış arabası yarış pistinde test edilir.
Ayrıca testleri 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 15, 20, 30, 40, 50, 75, 100, 200, 300, 500, 750, 1000, 1500, 2000, 3000, 5000, 7500, 10000 kullanıcılarda test ettiniz mi? Abartı gibi gelecek ama maalesef o vardığınız kesin sonuca ancak böyle varabilirsiniz. Yoksa FIREBIRD’ü PARADOX gibi görmüş oluyorsunuz.
Bir de mümkünse yaptığınız testi gerçek hayatla özdeşleştiriniz. Yani bu yaptığınız testteki tabloyu gerçek hayatta nerede kullanabilirsiniz? Kullanılabilirliği var mı?
Örneğin deyin ki benim şöyle bir tablom var ve bu tabloyu şu amaçla kullanıyorum ve ben bu testi işte bu tabloda yaptım.
Ben şahsen niye TEXT alan kullandığınızı da sorgularım o zaman. Niye VARCHAR kullanmadınız derim belki.
Çünkü TEXT bir alanın hızlı bir şekilde sorgulanması gerekiyorsa ben şahsen VARCHAR(8000) der bir de o alana INDEX oluştururum. Görün o zaman MS-SQL’le FIREBIRD’ün hızlarını.
Herkese iyi çalışmalar.
-
doganzorlu
- Kıdemli Üye
- Mesajlar: 395
- Kayıt: 22 Tem 2004 09:15
- Konum: İzmir
- İletişim:
Selam,
bu gibi testlerde bu yöntem kullanılmaz. Açar db server a sorarsınız kardeşim bu işlem için kac phsical row aldın diskten, kaç tane row aldın cache den diye. Sonra karar veririsiniz cost un ne olduğuna. Bu şekilde hem orjinal yorumu yapan hem de siz aynı yanılgıya düşmüş oluyorsunuz. Bu tip testlerde "hissi kavlen vuku" (sanırım böyle deniyordu) sonuçlar üretilmez. Aynı query yi 3 kez çalıştırdığınızda her seferinde bir öncekinden farklı bir zaman çıkar eğer ölçeğiniz zaman ve db niz yaşayan bir db ise (cache/io yoğunluğu/simultane çalışan sql sayısı vs etkiler bunu).
Bu arada, byte larla uğraşmak zorundasınız. Zaten bu sizin yaklaşımınız yüzünden 100 mb tutmayacak db ler yüzlerce gigabyte yer tutmaya başladı. Kaynakların verimli kullanılması, en öncelikli iştir. Hiçbir zaman 100 karakter olmayacak alana 500 karakter verebilirsiniz. Nasılsa diskler ucuz. Peki bu slack alanın oluşturacağı performansa negatif etkiden nasıl sakınacaksınız. O zaman da çift çekirdek 64 bit CPU, hatta bunları da 4 tane takar ona göre işletim sistemi kullanabiliriz değil mi ? O da yetmezse olmayan ihtiyacımızı karşılamak üzere nasılsa yeni şeyler üretip bize satarlar değil mi ? Teknoloji açı bir ülke olarak alan memnun satan memnun.
Son cümlelerim israfın tanımı gibi oldu sanki... Her alanda bu böyle gidiyor maalesef. Çocuklarımızın bize olan emanetlerini hoyratça tüketmeye devam, "benden sonrası tufan" diyenler için problem yok, ama sorumluluk hissi taşıyan insanlar bunu bir daha düşünmeliler diyorum.
Kod: Tümünü seç
Eğer hala baştan sona tarıyor diyorsanız, sırayla;
SELECT TOP 10
SELECT TOP 100
SELECT TOP 1000
diye test ederseniz zaten baştan sona taramadığını anlarsınızBu arada, byte larla uğraşmak zorundasınız. Zaten bu sizin yaklaşımınız yüzünden 100 mb tutmayacak db ler yüzlerce gigabyte yer tutmaya başladı. Kaynakların verimli kullanılması, en öncelikli iştir. Hiçbir zaman 100 karakter olmayacak alana 500 karakter verebilirsiniz. Nasılsa diskler ucuz. Peki bu slack alanın oluşturacağı performansa negatif etkiden nasıl sakınacaksınız. O zaman da çift çekirdek 64 bit CPU, hatta bunları da 4 tane takar ona göre işletim sistemi kullanabiliriz değil mi ? O da yetmezse olmayan ihtiyacımızı karşılamak üzere nasılsa yeni şeyler üretip bize satarlar değil mi ? Teknoloji açı bir ülke olarak alan memnun satan memnun.
Son cümlelerim israfın tanımı gibi oldu sanki... Her alanda bu böyle gidiyor maalesef. Çocuklarımızın bize olan emanetlerini hoyratça tüketmeye devam, "benden sonrası tufan" diyenler için problem yok, ama sorumluluk hissi taşıyan insanlar bunu bir daha düşünmeliler diyorum.
Doğan Zorlu, İzmir
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)
------------------------
"Bu Kitap'ı sana yalnız şunun için indirdik: Hakkında ayrılığa düştükleri şeyi onlara iyice açıklayasın ve Kitap, iman eden bir topluluk için kılavuz ve rahmet olsun." (NAHL 64)
Yeniden Selamlar Hakan Can,
Evet testlerimizi olabildiğince reel yapmaya gayret gösteriyoruz. Öyle afaki yada olmayacak tarzda bir test gerçekleştirmiyoruz.
Yaptığımız Test, reel kullanıma hazırlanmakta olan bir program için yapıldı.
Bu programda (INDEX kullanamazsınız) çünkü dokumanlar 8K içine sığdırılabilir cinsten değil !... 5-15 sayfa bazıları 50-60 sayfa boyutuna varan dokumanlar.
Bu bahsettiğiniz yani çoklu kullanımdaki testleri de inşallah, işyerine yeni server geldiğinde min. 1000 Connection'lı testler yapıp deneme sonuçlarını burada yayınlayacağız.
Ayrıca, eğer M$-SQL'de bu tür yani textlerle uğraşıyorsanız, neden FullTextSearch Index'i açmıyorsunuz? Ben senin yerinde olsam, VARCHAR ındex kullanacağıma FTS'i açın derdim Bilmem anlatabildim mi?
Bu arada herhalde yazım hatası, DOS öleli 20 yıl olmadı 2000 senesine kadar canlı olarak kullanılmaktaydı, Win 2000'den sonra bir nevi emulasyona çevirdiler DOS'u. Öncesindeki kodlar he DOS tabanlı sürümlerdi (Windowslar) NT Tabanına çevirdikten sonra gerçek anlamda DOS kalktı diyebiliriz.
Kullanıcı ve connection konusunda da şundan eminim ki, FB sistem kaynaklarını kullanırken M$'dan çok daha dikkatli davranıyor ve sistem kaynaklarını har vurup harman savurmuyor.
Şimdi bir insanın yiyeceği yemek sınırı bellidir, sen hiç bir lokantaya girip 5 Porsiyon Döner, 10 Porsiyon Adana, 20 Porsiyon Urfa, 35 Tane Lahmacun, yarısı acılı, 40 Şişe Ayran 10 Şişe Kola der misin? Yoksa yiyebileceğin kadarını söyleyip hesabı öder misin? (Mübalalı bir örnek oldu ama böyle ifade edebildim)
Ben neden Server'ımın kapasitesi yeterli olabilecek bir araç varken, sistem kaynaklarını fütursuzca harcayan ve harcadığı kaynaklara göre orantısız işler yapabilen bir db server kullanayım ki? Şimdi evrensel manada da düşünürsek, hiçbir Arslan veya Kartal yemeyeceği avı öldürmez. Kainat bile bu sisteme en basit boyutlarda ve formlarda dahi özen gösterirken biz niye böyle savurgan olalım?
Sene 1998, Dayım İngiltere'deki IT manzarsından bahsetti (ziyaret ettiği İngiliz firmalarında) Biz o senelerde 486 için öldü düyorduk, pentiumlar var diyorduk. Ama adamlara Hala 8086 Makinalar ve eski işletim sistemleri ile çalışıyorlardı.
Şimdi Biz İngilizlerden Teknolojik olarak üstün müyüz ? Hayır, peki Milli Gelir düzeyi olarak üstün müyüz? Hayır. Peki biz bu kriterleri de göz önünde bulundurduğumuzda, tasarruflu davranmak gerekiyorken (ki bizden üstün teknolojilere sahip, bizden daha ileri medeniyetler) bu savurganlığı yapmazken, hangi Mantıkla biz bu savurganlığı yapabiliriz?
Bu işin daha bi evrensel yaklaşımıydı, gelelim bilişimci gözlüğüyle buna bakmaya.
Sistem kaynaklarını belirsizce kullanan, savurgan ve yatırım masrafı büyük bir sistem kuracağım ve diğerleri ile kıyaslamayacağım. Üstüne üstlük bu kadar kaynağa rağmen yetersiz performanla karşılaşacağım. Böyle bir DBAdmin'i veya bilgisayar sistem yöneticisini ben barındırmam. Bu yaptığı işe de yansır adamın. Bu kadar rahat davranan adam kodlarında da aynı şekilde davranır. Bu da hem sistemi hem de güvenliği riske atmaktır. Özellikle kesintisizi sistem felsefesi ile hareket edilmekte olduğu günümüzde buna olanak tanıyacak sistem kuran adamı kimse barındırmaz. (M$ Hariç) Onlar sistem harcamaları konusunda 1 numaradır.
100'lerge GB'ı geç, EXABYTE (1,073,741,824 GB) büyüklükte veri yöneten firmalar var dünya üzerinde, orada da sistem kaynaklarını fütursuzca harcatmazlar adama. 2-3 GB'lık bir DB için 2-3 GB Bellek kullanacaksam, TB seviyesinde veya EB seviyesinde veri büyüklükleri olan firmalarda bir o kadar da Bellek mi almalıyım?
Bu nasıl planlamadır? Esas savurganlığı az kullanıcılı sistemlerde yapabilirsiniz. Kullanıcı sayısı 10,000'leri bulan, 100'lerce server'ı olan firmalarda, Connection başına sen 100 K Fazla bir harcama yaparsan (Dikkat, burada verdiğim örnek connectionın kullanıcı başına harcadığı değil, dikkatsiz kullanımlarla ortalama 100 K belleğin gereksiz işgal edilmesinden bahsediyorum), 10,000 Kullanıcıda 1,000,000 MB yaklaşık 1,000 GB o da 1 TB belleğin savurganca kullanılması demektir. 5 Kullanıcıda yapsan bu savurganlığı 500 K o da 0,5 MB yapar kimse umursamaz bile.
Hesapları dikkatsiz yaparsan bir çok proje ölü doğar. Tıpkı M$'ın bir çok projesi gibi.
Her neyse, olaya biz sübjektif bakmıyoruz, Gerçekçi olarak bakıyoruz, sübjektif bakanlar M$ ve onun taraftarları.
Ben FB Testlerini yaptığımda, FB'nin performans farkını arttırıcı tedbirler de alabilirdim, yani DB Cachepage'i arttırabilirdim, veya CPU priority'sini de arttırabilirdim. Bunları yapsaydık, fark emin ol orada çıkandan daha da fazla olurdu.
İstediği gibi sonuç çıkmasını sağlayan testleri M$ iyi bilir ve iyi yapar. Çünkü onun kaybedeceği $'lar var ama bu testlerde bizim kaybedeceğimiz $'lar yok, kazanacağımız $'lar da yok.
Bir ek daha, Index yaptığınızda 8K'lık Varchar alanı indexkediniz diyelim.
LIKE dediğinizde Indexler kullanılmaz !!!!!!! O indexler gereksiz yaratılmış olur. Onu geç, diyelim index yarattınız ve indeksli bir sorgulama yapıyorsunuz. Bir dokuman aramasında, kimse aramasını Aradığı kelimeyi birebir yazarak (ve hatta öncesinde kullanılan kelimeleri yazarak aramaz) Realitiden ayrılmayın.
Örneğin,
"Ali bir gün bilgisayarcı olmuş ve Terminatör lakabını almış" diye giden bir dokumanım olsun, ben dokuman içinde arama yaparken. "Terminatör" kelimesini kalkıp kullanıcının
"Ali bir gün bilgisayarcı olmuş ve Terminatör" diye aramasını bekleme bekleyemem, bekleyen de abesle iştigal etmiş olur.
Orada Terminatör kelimesini aratırım
WHERE koşuluna
TEXT_ALANIM = 'Teminatör' yazarak ararsam, 8K'lık Varchar alanı indekslemem bana ne kazandırmış olur hız açısından? Hiçbir şey.
Her neyse, bunlar Madalyonun öbür yüzü. Burda inanmıyorum ki kimse kalkıp haksız yere birine bir şey desin, demeyiz dedirtmeyiz de, kimsa kalkıp burda ne M$'ın Ofis programlarına dil uzatmaz, uzatırsa başta beni karşısında bulur.
Biz çizgilerimizi çok iyi biliyoruz, bilmeyen ise M$.
Kolay Gelsin
Evet testlerimizi olabildiğince reel yapmaya gayret gösteriyoruz. Öyle afaki yada olmayacak tarzda bir test gerçekleştirmiyoruz.
Yaptığımız Test, reel kullanıma hazırlanmakta olan bir program için yapıldı.
Bu programda (INDEX kullanamazsınız) çünkü dokumanlar 8K içine sığdırılabilir cinsten değil !... 5-15 sayfa bazıları 50-60 sayfa boyutuna varan dokumanlar.
Bu bahsettiğiniz yani çoklu kullanımdaki testleri de inşallah, işyerine yeni server geldiğinde min. 1000 Connection'lı testler yapıp deneme sonuçlarını burada yayınlayacağız.
Ayrıca, eğer M$-SQL'de bu tür yani textlerle uğraşıyorsanız, neden FullTextSearch Index'i açmıyorsunuz? Ben senin yerinde olsam, VARCHAR ındex kullanacağıma FTS'i açın derdim
Bilmem anlatabildim mi?Bu arada herhalde yazım hatası, DOS öleli 20 yıl olmadı
2000 senesine kadar canlı olarak kullanılmaktaydı, Win 2000'den sonra bir nevi emulasyona çevirdiler DOS'u. Öncesindeki kodlar he DOS tabanlı sürümlerdi (Windowslar) NT Tabanına çevirdikten sonra gerçek anlamda DOS kalktı diyebiliriz.Kullanıcı ve connection konusunda da şundan eminim ki, FB sistem kaynaklarını kullanırken M$'dan çok daha dikkatli davranıyor ve sistem kaynaklarını har vurup harman savurmuyor.
Şimdi bir insanın yiyeceği yemek sınırı bellidir, sen hiç bir lokantaya girip 5 Porsiyon Döner, 10 Porsiyon Adana, 20 Porsiyon Urfa, 35 Tane Lahmacun, yarısı acılı, 40 Şişe Ayran 10 Şişe Kola der misin? Yoksa yiyebileceğin kadarını söyleyip hesabı öder misin? (Mübalalı bir örnek oldu ama böyle ifade edebildim)
Ben neden Server'ımın kapasitesi yeterli olabilecek bir araç varken, sistem kaynaklarını fütursuzca harcayan ve harcadığı kaynaklara göre orantısız işler yapabilen bir db server kullanayım ki? Şimdi evrensel manada da düşünürsek, hiçbir Arslan veya Kartal yemeyeceği avı öldürmez. Kainat bile bu sisteme en basit boyutlarda ve formlarda dahi özen gösterirken biz niye böyle savurgan olalım?
Sene 1998, Dayım İngiltere'deki IT manzarsından bahsetti (ziyaret ettiği İngiliz firmalarında) Biz o senelerde 486 için öldü düyorduk, pentiumlar var diyorduk. Ama adamlara Hala 8086 Makinalar ve eski işletim sistemleri ile çalışıyorlardı.
Şimdi Biz İngilizlerden Teknolojik olarak üstün müyüz ? Hayır, peki Milli Gelir düzeyi olarak üstün müyüz? Hayır. Peki biz bu kriterleri de göz önünde bulundurduğumuzda, tasarruflu davranmak gerekiyorken (ki bizden üstün teknolojilere sahip, bizden daha ileri medeniyetler) bu savurganlığı yapmazken, hangi Mantıkla biz bu savurganlığı yapabiliriz?
Bu işin daha bi evrensel yaklaşımıydı, gelelim bilişimci gözlüğüyle buna bakmaya.
Sistem kaynaklarını belirsizce kullanan, savurgan ve yatırım masrafı büyük bir sistem kuracağım ve diğerleri ile kıyaslamayacağım. Üstüne üstlük bu kadar kaynağa rağmen yetersiz performanla karşılaşacağım. Böyle bir DBAdmin'i veya bilgisayar sistem yöneticisini ben barındırmam. Bu yaptığı işe de yansır adamın. Bu kadar rahat davranan adam kodlarında da aynı şekilde davranır. Bu da hem sistemi hem de güvenliği riske atmaktır. Özellikle kesintisizi sistem felsefesi ile hareket edilmekte olduğu günümüzde buna olanak tanıyacak sistem kuran adamı kimse barındırmaz. (M$ Hariç) Onlar sistem harcamaları konusunda 1 numaradır.
100'lerge GB'ı geç, EXABYTE (1,073,741,824 GB) büyüklükte veri yöneten firmalar var dünya üzerinde, orada da sistem kaynaklarını fütursuzca harcatmazlar adama. 2-3 GB'lık bir DB için 2-3 GB Bellek kullanacaksam, TB seviyesinde veya EB seviyesinde veri büyüklükleri olan firmalarda bir o kadar da Bellek mi almalıyım?
Bu nasıl planlamadır? Esas savurganlığı az kullanıcılı sistemlerde yapabilirsiniz. Kullanıcı sayısı 10,000'leri bulan, 100'lerce server'ı olan firmalarda, Connection başına sen 100 K Fazla bir harcama yaparsan (Dikkat, burada verdiğim örnek connectionın kullanıcı başına harcadığı değil, dikkatsiz kullanımlarla ortalama 100 K belleğin gereksiz işgal edilmesinden bahsediyorum), 10,000 Kullanıcıda 1,000,000 MB yaklaşık 1,000 GB o da 1 TB belleğin savurganca kullanılması demektir. 5 Kullanıcıda yapsan bu savurganlığı 500 K o da 0,5 MB yapar kimse umursamaz bile.
Hesapları dikkatsiz yaparsan bir çok proje ölü doğar. Tıpkı M$'ın bir çok projesi gibi.
Her neyse, olaya biz sübjektif bakmıyoruz, Gerçekçi olarak bakıyoruz, sübjektif bakanlar M$ ve onun taraftarları.
Ben FB Testlerini yaptığımda, FB'nin performans farkını arttırıcı tedbirler de alabilirdim, yani DB Cachepage'i arttırabilirdim, veya CPU priority'sini de arttırabilirdim. Bunları yapsaydık, fark emin ol orada çıkandan daha da fazla olurdu.
İstediği gibi sonuç çıkmasını sağlayan testleri M$ iyi bilir ve iyi yapar. Çünkü onun kaybedeceği $'lar var ama bu testlerde bizim kaybedeceğimiz $'lar yok, kazanacağımız $'lar da yok.
Bir ek daha, Index yaptığınızda 8K'lık Varchar alanı indexkediniz diyelim.
LIKE dediğinizde Indexler kullanılmaz !!!!!!! O indexler gereksiz yaratılmış olur. Onu geç, diyelim index yarattınız ve indeksli bir sorgulama yapıyorsunuz. Bir dokuman aramasında, kimse aramasını Aradığı kelimeyi birebir yazarak (ve hatta öncesinde kullanılan kelimeleri yazarak aramaz) Realitiden ayrılmayın.
Örneğin,
"Ali bir gün bilgisayarcı olmuş ve Terminatör lakabını almış" diye giden bir dokumanım olsun, ben dokuman içinde arama yaparken. "Terminatör" kelimesini kalkıp kullanıcının
"Ali bir gün bilgisayarcı olmuş ve Terminatör" diye aramasını bekleme bekleyemem, bekleyen de abesle iştigal etmiş olur.
Orada Terminatör kelimesini aratırım
WHERE koşuluna
TEXT_ALANIM = 'Teminatör' yazarak ararsam, 8K'lık Varchar alanı indekslemem bana ne kazandırmış olur hız açısından? Hiçbir şey.
Her neyse, bunlar Madalyonun öbür yüzü. Burda inanmıyorum ki kimse kalkıp haksız yere birine bir şey desin, demeyiz dedirtmeyiz de, kimsa kalkıp burda ne M$'ın Ofis programlarına dil uzatmaz, uzatırsa başta beni karşısında bulur.
Biz çizgilerimizi çok iyi biliyoruz, bilmeyen ise M$.
Kolay Gelsin
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Bence atladığın nokta, Cache'dir. Ard arda verdiğin bu Query'ler öncelikli olarak (Eğer Win tabanlı bir işletim sistemindeysen) win tarafından Disk Cache'lemesine alınır, onun dışında DB'yi Cache'e çeker Database serverlar (eğer siz cachlemesine izin verirseniz) Bu sorguyu M$'a hiç bir ayar yapmadan ard arda sorgulatırsanız, ilk okumalarını diksten yapar ve git gide disk teması azalacağı için bellekte arama yapar. Ama arama sistemini değiştirmez, oradaki performans farkı Disk ile RAM arasındakidir, Database Server'ın performansı değildir.Hakan Can yazdı:Selamlar Kuri_YJ,
Eğer hala baştan sona tarıyor diyorsanız, sırayla;
SELECT TOP 10
SELECT TOP 100
SELECT TOP 1000
diye test ederseniz zaten baştan sona taramadığını anlarsınız.
Bu tür bir karşılaştırmada, Doğan'ın da dediği gibi Sistem Kaynaklarının Maliyetlerine bakılır, CPU zamanlarına bakılır vs. vs. Sadece Hıza bakmak reel anlamda doğru olmaz.
Ama bizim yaptığımız testlerde de insanlara bunun yansımasını gösterdik. O kadar derine inmeden. Gerekirse ineriz ve M$ için bu hüsranın da hüsranı olur FB karşısında emin olun !...
Kolay Gelsin
Kuri Yalnız Jedi
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
Harbi Özgürlük İçin Pisi http://www.pisilinux.org/
-
Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
>Örneğin,
>"Ali bir gün bilgisayarcı olmuş ve Terminatör lakabını almış" diye giden bir dokumanım olsun,
bidakka bidakkaa.. buna itiraz ederim, Terminator 1988 de gösterime girdi, Ali o zaman sadece medresede öğrenciydi, bilgisayarcı vesikası almadan önce yani.. Terminator lakabını da, o yıllarda başından geçen kazalara rağmen gebermemesi nedeniyle vermişlerdi.
hem üstelik daha eskiden de conan-herkül gibi yakıştırmalara(alias) maruz kalıyordu. dökümanı düzeltelim lütfen, FBü yanıltmayalım.
DOS 20 yıl önce ölmedi, 20 yıl önce doğdu.
ancak 1985 de çıkan DOS doğru dürüst kullanılabilir durumdaydı.
o zamanlar 80386 çıktı üstelik 32 bitlik. 1982 gibi 80286 çıkmıştı 24 bitlik.
(adres bus genişliği anlamında) 1978 lerde çıkan ilk PC işlemcisi ise 8086 20 bitlik adres kullanırdı, yani fiziksel 1MB la kesin sınırlıydı.
1985 i bırakın neredeyse 1995e kadar 1MBa hapsolmuş sistemler kullandık MS ve IBM tekeli yüzünden, ha bir de en önemlisi intelin uyuzluğu. O zamanlar mainframe ve middleframe satıp köşe olmaktan PC lere ilgi gösteremeyen dinazor firmalar, 90lardan sonra artan rekabet, serbestleşme, AMD ve iletişim yüzünden resmen ŞOK oldular, eskiden kalma serveti ve lisans gelirleri düşük olanlar resmen battı ya da birleşti ya da radikal küçüldü.
DOS öldü mü? ölmedi, ölmez de, çünkü intel işlemciler DOSu donanımsal olarak destekliyor Virtual CPU modu şeklinde. bir intel uyumlu işlemciyle raminiz yettiği kadar sanal işlemciler açıp DOS -real mode 16/20 bitlik uygulamaları çalıştırabilirsiniz. bu gayet hoş bir sistemdir.
Peki, 1985 de yazabileceği bir işletim sistemini neden taa 1995 lerde çıkarabildi MS? neden yıllarca EMS, XMS, gibi uyduruk modlarla boğuştuk flat memory varken?
bugün messenger neden 8 sene önce ICQ nunun yapabildiklerini bile yapamıyorsa, sebebi ondan işte...
8000 karakterlik bir sahayı FB indexlemez. hatta FB2 ancak 255 byteın üzerinde indexlemeye açıldı, o da çok bytelık karakterler yüzünden.
8000 karakterlik bir sahayı indexlemek gereği duyan kişi, indexlemenin nasıl çalıştığını bilmiyor demektir.
Aslında FB açısından 8000 karakteri indexlemenin pek maliyeti yok,
prefixini sıkıştırarak node oluşturan bir bitmap mimarisi var, ama yine de
böyle bişeye kimse hoş bakmaz.
mssqlin karakterler üzerinde yavaş çalışması, 20 tane kaydı geç getirmesini gerektirmez. sonuçta karakter compare işlemi bellekte yapılıyor, geri kalan diskten okuma işlemi hepsinde disk işlemi sonuçta.
>"Ali bir gün bilgisayarcı olmuş ve Terminatör lakabını almış" diye giden bir dokumanım olsun,
bidakka bidakkaa.. buna itiraz ederim, Terminator 1988 de gösterime girdi, Ali o zaman sadece medresede öğrenciydi, bilgisayarcı vesikası almadan önce yani.. Terminator lakabını da, o yıllarda başından geçen kazalara rağmen gebermemesi nedeniyle vermişlerdi.
hem üstelik daha eskiden de conan-herkül gibi yakıştırmalara(alias) maruz kalıyordu. dökümanı düzeltelim lütfen, FBü yanıltmayalım.
DOS 20 yıl önce ölmedi, 20 yıl önce doğdu.
ancak 1985 de çıkan DOS doğru dürüst kullanılabilir durumdaydı.
o zamanlar 80386 çıktı üstelik 32 bitlik. 1982 gibi 80286 çıkmıştı 24 bitlik.
(adres bus genişliği anlamında) 1978 lerde çıkan ilk PC işlemcisi ise 8086 20 bitlik adres kullanırdı, yani fiziksel 1MB la kesin sınırlıydı.
1985 i bırakın neredeyse 1995e kadar 1MBa hapsolmuş sistemler kullandık MS ve IBM tekeli yüzünden, ha bir de en önemlisi intelin uyuzluğu. O zamanlar mainframe ve middleframe satıp köşe olmaktan PC lere ilgi gösteremeyen dinazor firmalar, 90lardan sonra artan rekabet, serbestleşme, AMD ve iletişim yüzünden resmen ŞOK oldular, eskiden kalma serveti ve lisans gelirleri düşük olanlar resmen battı ya da birleşti ya da radikal küçüldü.
DOS öldü mü? ölmedi, ölmez de, çünkü intel işlemciler DOSu donanımsal olarak destekliyor Virtual CPU modu şeklinde. bir intel uyumlu işlemciyle raminiz yettiği kadar sanal işlemciler açıp DOS -real mode 16/20 bitlik uygulamaları çalıştırabilirsiniz. bu gayet hoş bir sistemdir.
Peki, 1985 de yazabileceği bir işletim sistemini neden taa 1995 lerde çıkarabildi MS? neden yıllarca EMS, XMS, gibi uyduruk modlarla boğuştuk flat memory varken?
bugün messenger neden 8 sene önce ICQ nunun yapabildiklerini bile yapamıyorsa, sebebi ondan işte...
8000 karakterlik bir sahayı FB indexlemez. hatta FB2 ancak 255 byteın üzerinde indexlemeye açıldı, o da çok bytelık karakterler yüzünden.
8000 karakterlik bir sahayı indexlemek gereği duyan kişi, indexlemenin nasıl çalıştığını bilmiyor demektir.
Aslında FB açısından 8000 karakteri indexlemenin pek maliyeti yok,
prefixini sıkıştırarak node oluşturan bir bitmap mimarisi var, ama yine de
böyle bişeye kimse hoş bakmaz.
mssqlin karakterler üzerinde yavaş çalışması, 20 tane kaydı geç getirmesini gerektirmez. sonuçta karakter compare işlemi bellekte yapılıyor, geri kalan diskten okuma işlemi hepsinde disk işlemi sonuçta.
Firebird Foundation Member #208
http://www.firebirdsql.org
http://www.firebirdsql.org
-
Terminator
- Üye
- Mesajlar: 313
- Kayıt: 13 Ara 2005 01:45
- Konum: İzmir, ama Aydın Efesi!
MSSQL neden string işlemlerinde yavaş..
sanırım MS, string işlemlerini WINDOWS sistem kütüphanelerini kullanarak
yapmayı tercih etmiş, her kayıtta sistem fonksiyonlarını çağırması baya pahalıya geliyor olmalı. EE napsın, ekonomik olacakya, MSSQLin kodunu küçültüp merkezi kütüphaneler kullanacakya.. ondandır. baya küçülmüş zaten, sanırım yakında 1 CD ile bile rahatlıkla dağıtılıp kullanılabilir.
Biz FB cüler ne yazıkki daha disketten kurtulamadık, 1.5 MB için CD yakmaya kıyamıyoz çok pintiyiz hahahahaa
sanırım MS, string işlemlerini WINDOWS sistem kütüphanelerini kullanarak
yapmayı tercih etmiş, her kayıtta sistem fonksiyonlarını çağırması baya pahalıya geliyor olmalı. EE napsın, ekonomik olacakya, MSSQLin kodunu küçültüp merkezi kütüphaneler kullanacakya.. ondandır. baya küçülmüş zaten, sanırım yakında 1 CD ile bile rahatlıkla dağıtılıp kullanılabilir.
Biz FB cüler ne yazıkki daha disketten kurtulamadık, 1.5 MB için CD yakmaya kıyamıyoz çok pintiyiz hahahahaa
Firebird Foundation Member #208
http://www.firebirdsql.org
http://www.firebirdsql.org
Re: SELECT TOP (SELECT FIRST) Performans farkı TEXT alanlard
Kuri_YJ yazdı:Selamlar,
Dün gece bir deneme yaptık (PhoenixJedi ile birlikte) ve sonuçlarını görünce dumur olduk.
M$-SQL için Sorgu,Firebird için Sorgu,Kod: Tümünü seç
SELECT TOP 20 * FROM TABLOM WHERE TEXT_ICERIK LIKE '%arananifade%'Şeklinde bir sorguyu karşılaştırdık. Min. 10 Kat ile 40 Kat arası performans farkı ile M$-2000 Server'ı yerden yere vurdu FBKod: Tümünü seç
SELECT FIRST 20 * FROM TABLOM WHERE TEXT_ICERIK LIKE '%arananifade%'
Yaklaşık 80,000 Kayıtlık Dokumanların olduğu bir tabloya uygulandı bu Query. Her iki DB'de de aynı kayıtlar var. Dokumanlar, Min. 1 Sayfa ile 10 Sayfa arasında değişen boyutlarda.
Ateşkuşu yaktı geçti M$'ı. Query'lerde yeri geldi, FB'nin 1-2 sn. içinde getirdiği sonuçları, M$-SQL Server 1 dakika, 1 Dakika 20 Saniye filan sürelerde getirebiliyordu.
Bu ne tekniktir, bu ne hız farkıdır böyle !....
Hehehehehehe, FB'ye devam arkadaşlar.
Sevgiler.
set rowcount 20
SELECT *
FROM TABLOM
WHERE TEXT_ICERIK LIKE '%arananifade%' order by id
bir farka bakarmısın...!
Aynı testi olmayan bir KULLANICIADI için yap bakalım kaç saniyede gelmiyor?kimene yazdı:arama yaparken gördüm testleri.
ben sql2000 üzerinde 2 milyonluk bir table da aynı işlemi yaptığımda
sonuç 1 saniye içinde geliyor.
"select TOP 20 * FROM VSTOKHAREKETLERI WHERE KULLANICIADI LIKE '%LOBİ%'"
Bir de o günleri hatırlattın ya bize. Of anam of, ne günlerdi o günler. FireBird'ün ve forumun en hararetli ve en hareketli günleriydi o günler. Kulakları çınlasın Terminatör'ün, CederLord'un tabi bir de Kuri_YJ'nin (Üçü ile hep ters düşerdim de o yüzden sadece üçünü belirttim).
İyi çalışmalar.