2008/4/6 Anıl KARADAĞ <anil.karadag_at_gmail.com>:

> Bir sorum daha olacaktı tabloma gunluk yaklasık 1500 yeni kayıt
> girmektedir. select sayısı insert/updated den cok fazla bu yuzden yeni
> bir index ekleyebilirim.
>
> Ancak innodb onerisi uzerine
>
> http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/
>
> deki sonucu inceledim. insert işlemi için Myisam a gore daha hızlı ama
> myisam da read işleminde daha hızlı.

The second goal of benchmark was a popular "*myth*" that MyISAM is faster
than InnoDB in reads, as InnoDB is transactional, supports Foreign Key and
has an operational overhead. *As you will see it is not always true*.

Ben myisam'a pek fazla sicak bakmayanlardanim. Mysql uzerindeki is yuku
arttiginda benim gozlerimlerime ve internetteki kaynaklara dayanarak
innodb'nin daha etkin bir cozum olacagini dusunuyorum. Sahsen myisam
kullanmamaya ozen gosteriyorum.

>
>
> tablom read işlemi için daha cok kullnılıyor ama insert işlemindeki bir
> gecikme 1 saatlik periyod ile kayıt alan bir sistemde kayt alımlarını
> birbirine yaklaştırıyor.

verdiginiz rakamlardan saatte yaklasik 100 kayit insert ettiginizi
dusunursek bu oldukca kotu bir zaman gibi gorunuyor. Bence kullandiginiz
makinaya ve mysql ayarlarina bakmakta fayda var.

>
>
> Ek bir soru diyelim ki myisam ile yoluma devam ettim suan 4 tane index
> im oldu. her yeni kayıtta bu indexler yeniden oluşuyor bu ciddi bir
> gecikmeye yol açmaz mı?
>

>
> Paz, 2008-04-06 tarihinde 21:52 +0300 saatinde, Ismail ASCI yazdı:
> > Merhabalar,
> >
> > 2008/4/6 Anıl KARADAĞ <anil.karadag_at_gmail.com>:
> > harflendirme yapayım derken hatalar yapmısım. indeks kullanmak
> > insert
> > islemlerinde sorun yaratmıyor mu? Yani suan 3 tane indexli
> > alanım var
> > bunu arttırmak mantıklı mı?
> >
> > index kullanmak tabiki daha fazla io ve daha fazla cpu anlamina
> > geliyor. Ancak burada verilmesi gereken stratejik karari kullandiginiz
> > uygulamaniza gore siz vermelisiniz. Mesela toplam insert/update ve
> > select sayilarinin birbirlerine oranlarina bakarak karari
> > verebilirsiniz. Eger select'lerin orani insert/update'lere gore daha
> > fazlaysa daha fazla index kulllamanin pek sakincasi olmaz diye
> > dusunuyorum. Yine index'lerinizi uygulamanizda en sik kullanilan
> > sorgulara gore olusturmaniz faydali olacaktir.
> >
> >
> >
> > "KEY 'e' USING BTREE ('e')"
> >
> >
> > ben sorgularda arama yaptıgım 3 alanda index kullnıyorum.
> > datetime
> > alanında index yok. O kısmını yanlış göstermisim.
> >
> > yardımlarınız icin tesekkurler ancak 350.000 habere mysql in
> > bu kadar
> > yavas tepki vereceÄŸini tahmin edemezdim.
> >
> > Birazda olayin dogasi geregi boyle oluyor. Uzerinde index olmayan
> > alanlarda sorgu yaptiginizda biraz kacilinilmaz oluyor bu durum.
> > Deneyerek ve explain komutunu yaninizdan ayirmadan yasayarak efektif
> > cozumler uretebilirsiniz bence...
> > Ayrica su [1] adresteki cozum onerilerini deneyebilirsiniz.
> >
> > [1]
> >
> http://www.mysqlperformanceblog.com/2006/06/09/why-mysql-could-be-slow-with-large-tables/
> >
> > Kolay gelsin.
> >
> >
> >
> >
> > Cts, 2008-04-05 tarihinde 22:40 +0300 saatinde, Ismail ASCI
> > yazdı:
> >
> > > tekrar merhabalar,
> > > gonderdiginiz tablo yapisinda mysql olusturdugunuz
> > index'leri
> > > kullanmayacaktir. yani onlari olusturmus olmanizin bir
> > faydasi yok.
> > > basitce f ve e alanlari uzerinde key yeni (f, e) seklinde
> > bir index
> > > olusturmaniz oldukca faydali olacaktir diye dusunuyorum.
> > > bu asamadan sonra
> > > 1. sorgunuzda order by random() yerine
> > > select a, b, c, random() as x ......order by x seklinde
> > deneyebilir
> > > misiniz?
> > > 2. ve 3. sorgular da ise benim aklima gelen pek birsey yok
> > acikcasi
> > > esit degil ve not null pek hos durmuyorlar orada :)
> > >
> > > kolay gelsin.
> > >
> > > 2008/4/4 Anıl KARADAĞ <anil.karadag_at_gmail.com>:
> > > harflendirmeleri duzenledim
> > >
> > > tablo1:
> > >
> > > 'a' mediumint(11) NOT NULL auto_increment,
> > > 'b' text
> > > 'c' text
> > > 'd' text
> > > 'e' datetime,
> > > 'f' varchar(20) ,
> > > 'g' varchar(20) ,
> > > PRIMARY KEY ('a'),
> > > KEY 'e' USING BTREE ('e'),
> > > KEY 'b' ('b'(50),'c'(250))
> > > ) ENGINE=MyISAM
> > >
> > > SELECT a,b,c FROM tablo1 WHERE f='x' AND
> > > > cast(e as date)= '".$date."' ORDER BY
> > rand() LIMIT
> > > 10
> > > >
> > > > 2-SELECT COUNT(*) FROM tablo1 WHERE f='x'
> > and
> > > > cast(e as date)= '".$date."' and (c != ''
> > or c is
> > > not null)
> > > >
> > > > 3-SELECT MAX(a) FROM tablo WHERE f=
> > '".$cat." ' and
> > > > cast(e as date)= '".$date."' and (c != ''
> > or c is
> > > not null)
> > >
> > > Sorgu cıktıları ile ilgili ne gibi bir acıklama
> > koyabilirim
> > > anlayamadım
> > > tam olarak?
> > >
> > > Cum, 2008-04-04 tarihinde 23:39 +0300 saatinde,
> > Ismail ASCI
> > > yazdı:
> > >
> > > > Merhaba,
> > > > index'ler hangi alanlarda tanimlilar?
> > > > cast(b as date) kullanmanizin nedeni nedir?
> > > > ayrica ORDER BY rand() pek efektif sonuclar
> > doguracak gibi
> > > gorunmuyor.
> > > > tablonuzun yapisini ve bu uc sorgunun explain
> > ciktisini
> > > > gonderebilirseniz daha fazla yardimci olmaya
> > calisabilirim.
> > > > kolay gelsin..
> > > >
> > > > 2008/4/4 Anıl KARADAĞ <anil.karadag_at_gmail.com>:
> > > > Herkese iyi aksamlar MySQL kullanan ve
> > tablolarında
> > > 300.000
> > > > satir ve
> > > > uzeri veriye sahip ve veritabanindan
> > sorumlu
> > > uyelerimizin
> > > > dikkatine
> > > >
> > > > Suan 350.000 satır veri iceren bir tablom
> > > bulunmaktadır. 1
> > > > primary key
> > > > ve 2 tane normal index içermekte. Arama
> > yaptigim
> > > diger bircok
> > > > kolonda
> > > > index bulunmuyor.
> > > >
> > > > 1-SELECT a,b,c FROM tablo1 WHERE a='x' AND
> > > > cast(b as date)= '".$date."' ORDER BY
> > rand() LIMIT
> > > 10
> > > >
> > > > 2-SELECT COUNT(*) FROM tablo1 WHERE a='x'
> > and
> > > > cast(b as date)= '".$date."' and (c != ''
> > or c is
> > > not null)
> > > >
> > > > 3-SELECT MAX(e) FROM tablo WHERE a=
> > '".$cat." ' and
> > > > cast(b as date)= '".$date."' and (c != ''
> > or c is
> > > not null)
> > > >
> > > > ve benzeri sorgulari calistirdigim php
> > sayfasi cok
> > > gec
> > > > yukleniyor. Bu
> > > > duruma nasıl cozum bulabilirim. Belirtmen
> > gereken
> > > bir nokta
> > > > tablonun
> > > > dinamik olusudur. Gunluk ortalama bir
> > sayida kayit
> > > > girilmektedir.
> > > >
> > > > Kayit girilirken db uzerinde cesitli
> > sorgular
> > > yapilmaktadir.
> > > > Kisacasi
> > > > sistemde veri girisi sorgusu ve
> > goruntuleme
> > > sorguları ayni
> > > > zaman
> > > > diliminde gerceklesmektedir gunun belirli
> > bir
> > > diliminde.
> > > >
> > > > Cluster konusuna bakiyorum. Onerilerinizi
> > > bekliyorum.
> > > >
> > > >
> > _______________________________________________
> > > > Linux-programlama mailing list
> > > > Linux-programlama_at_liste.linux.org.tr
> > > >
> > >
> > http://liste.linux.org.tr/mailman/listinfo/linux-programlama
> > > >
> > > >
> > > >
> > > > --
> > > > Ismail ASCI
> > > > Pozitim Technology
> > > > www.pozitim.com
> > > >
> > > > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > > > Version: GnuPG v1.4.2.2 (GNU/Linux)
> > > >
> > > >
> > >
> > iFQEIBECABQFAkRIDJMNHQBiYWNrdXAgY29weQAKCRBgYvyi4RxNdcnIAJ9vweb8
> > > >
> > vUH9m3a2aQHyAfeo0oJtlACfQiqcbHvdBtrxylRh42G2xea7gFM=
> > > > =Xy4T
> > > > -----END PGP PUBLIC KEY BLOCK-----
> > > > _______________________________________________
> > > > Linux-programlama mailing list
> > > > Linux-programlama_at_liste.linux.org.tr
> > > >
> > http://liste.linux.org.tr/mailman/listinfo/linux-programlama
> > >
> > > _______________________________________________
> > > Linux-programlama mailing list
> > > Linux-programlama_at_liste.linux.org.tr
> > >
> > http://liste.linux.org.tr/mailman/listinfo/linux-programlama
> > >
> > >
> > >
> > >
> > > --
> > > Ismail ASCI
> > > Pozitim Technology
> > > www.pozitim.com
> > >
> > > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > > Version: GnuPG v1.4.2.2 (GNU/Linux)
> > >
> > >
> > iFQEIBECABQFAkRIDJMNHQBiYWNrdXAgY29weQAKCRBgYvyi4RxNdcnIAJ9vweb8
> > > vUH9m3a2aQHyAfeo0oJtlACfQiqcbHvdBtrxylRh42G2xea7gFM=
> > > =Xy4T
> > > -----END PGP PUBLIC KEY BLOCK-----
> > > _______________________________________________
> > > Linux-programlama mailing list
> > > Linux-programlama_at_liste.linux.org.tr
> > > http://liste.linux.org.tr/mailman/listinfo/linux-programlama
> >
> > _______________________________________________
> > Linux-programlama mailing list
> > Linux-programlama_at_liste.linux.org.tr
> > http://liste.linux.org.tr/mailman/listinfo/linux-programlama
> >
> >
> >
> >
> > --
> > Ismail ASCI
> > Pozitim Technology
> > www.pozitim.com
> >
> > -----BEGIN PGP PUBLIC KEY BLOCK-----
> > Version: GnuPG v1.4.2.2 (GNU/Linux)
> >
> > iFQEIBECABQFAkRIDJMNHQBiYWNrdXAgY29weQAKCRBgYvyi4RxNdcnIAJ9vweb8
> > vUH9m3a2aQHyAfeo0oJtlACfQiqcbHvdBtrxylRh42G2xea7gFM=
> > =Xy4T
> > -----END PGP PUBLIC KEY BLOCK-----
> > _______________________________________________
> > Linux-programlama mailing list
> > Linux-programlama_at_liste.linux.org.tr
> > http://liste.linux.org.tr/mailman/listinfo/linux-programlama
>
> _______________________________________________
> Linux-programlama mailing list
> Linux-programlama_at_liste.linux.org.tr
> http://liste.linux.org.tr/mailman/listinfo/linux-programlama
>

-- 
Ismail ASCI
Pozitim Technology
www.pozitim.com
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
iFQEIBECABQFAkRIDJMNHQBiYWNrdXAgY29weQAKCRBgYvyi4RxNdcnIAJ9vweb8
vUH9m3a2aQHyAfeo0oJtlACfQiqcbHvdBtrxylRh42G2xea7gFM=
=Xy4T
-----END PGP PUBLIC KEY BLOCK-----

_______________________________________________
Linux-programlama mailing list
Linux-programlama_at_liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama
Received on Sun 06 Apr 2008 - 22:40:48 EEST