Bu cok ciddi bir soru/sorun olarak benim de basımda. Benim acımdan soyle bi gerceklik mevcut.

Select oranı %80'lerden fazla olan bir ilan yayınlama sitemde, myisam bence en verimli sonucu veriyor. Burda insert yapılırken olusan table lock dolayısıyla gerceklesen fazla bekleme sureci bence goz ardı edilebilir.

Ancak diger taraftan yine myisam kullandııgm bir community sitem mevcut. Burda insert sorgular select ile neredeyse basa bas. Myisam burda cok basarısız. Oyle ki ortalam gunluk 100.000 sayfa gosterimi asla asamıyorum. 80-90 bilerden sonra mysql ciddi bir limite dayanıyor. InnoDB bir alternatif olarak karsımda duruyor ancak innoDB ile olusturulmamıs bir DB yi innodb yapmak urkutuyor biraz. Local'de bir kac deneme yaptım. Veritabanı innodb yapılamadı! cok ilginc, 2milyon kayıtlı bir tablo bir turlu inndb formatında insert edilemedi. Bu belki tablo yaısında, belki ayarlardan kaynaklandı ancak, inndb ile calismak ne goturur kestiremedim.

Onumde tahm,nen yaklasık %30 insert/update olacak bir proje duruyor. Mysql kullanıcam ama tablo yapısına karar veremedim bir turlu. Burdaki gorusleri merakla takip ediyorum
  ----- Original Message -----
  From: Ismail ASCI
  To: linux-programlama_at_liste.linux.org.tr
  Sent: Sunday, April 06, 2008 11:13 PM
  Subject: [Linux-programlama] Re: MySQL: sorgu analizi

  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

_______________________________________________
Linux-programlama mailing list
Linux-programlama_at_liste.linux.org.tr
http://liste.linux.org.tr/mailman/listinfo/linux-programlama
Received on Tue 08 Apr 2008 - 04:14:45 EEST