[bgul]

MySQL'in veriyapısı linked list midir yoksa array gibi her satıra ulaşmak mümkün müdür?

Sorunun kaynağını açıklayayım: yüzlerce mesaj girdisi olan bir sistemde, mesajları heap olarak tutmak istiyorum ki en iyi mesaja doğrudan ulaşabileyim. Kullanıcıları da HashMap içinde tutmayı planlıyorum. Ancak şöyle bir sorun var ki, bunların kayıtlarını bir text dosyasında tutarsam; yanlış anlamadıysam siteye giriş yapan herkes bu text dosyasını yüklemek zorunda kalır ki böyle bir şeyi istemeyiz (bir süre sonra dosyanın boyutları epey bi büyük olacağından). Yok dosyada değil de MySQL'de tutarsak bu sefer her kullanıcı siteye girdiğinde tüm verileri MySQL'den bir defaya mahsus olmak üzere alacaktır ki bunu her siteye giren kullanıcının yapacağını düşünürsek, server'ın göçmesi an meselesi olur. Peki ben napıcam? Heap ve hashmap'i yok sayıp doğrudan MySQL'in kollarına mı bırakayım kendimi, yoksa ne var ne yoksa bi text dosyasına kaydedip bi istek yapıldığında en başından başlayaraktan tek tek kontrol mü ettireyim? Ya da bu işin başka bir oluru var mıdır?

NOT: aslında MySQL'i bir şekilde limitleyip, liste oluşturulabilir sanırım. sonra her objeyi birbirine bağlayaraktan bir hashmap oluşturmayı planladım. Ancak burda da sorun şu ki, ne olursa olsun, tablodaki 28. sırada bulunan objeye ulaşmak için ben yine 0'dan başlayarak tek tek takip edeceksem bunun bana pek bi yararı dokunmaz (hatta liste uzadıkça zararı büyük olur...) Kısacası doğrudan 28. objeye ulaşmak mümkün mü (ya da başka bi sıradaki...)?

Saygılar

[s5prin]

Anladığım kadarıyla probleminin çözümü çok basit ama öncelikle Heap ve hashmap nedir bir açıklar mısın?
Ayrıca ne yapmak istediğini özet bir tabloyla örneklersen daha kolay yardımcı olabiliriz.

[bgul]

SQL caching başlığı altında epey bi yardım buldum zaten. çok saolasın.

heap, priority queue. Yani bi sıra var; ancak sırayı önemli nesneler için değiştirebiliyosun. Normalde önce girenin önce çıkması gerekirken, eğer sonradan daha önemli bir nesne girmişse sıraya, onu diğerlerinin önüne geçiriyo.
Tablo olarak açıklarsak, 3 nesnemiz olsun, sayı önemi belirtsin..

Ahmet 5
Mehmet 3
Cemal 2

Şimdi bu sıradan bir nesne alacak olursak doğrudan Ahmet'i alırız çünkü en önemli olduğundan sıranın önüne o geçmiş bulunuyor. Ancak sıraya sonradan "Hasan 9" girecek olursa sıra

Hasan 9
Ahmet 5
Mehmet 3
Cemal 2

şeklinde değişecektir.
Yeni bir tablo oluşturup sonradan eklenenleri sadece en üsttekilerle karşılaştırırsam, onlarca mesajı yüklemekten kurtulurum. Bu ilk ihtiyacım olan çözümdü... Caching eminim çok işime yarayacaktır burada.

HashMap'e gelecek olursak. Onu da şöyle planlıyordum: kullanıcı bilgilerini tutmak için en sağlam ve hızlı yol olarak alfabetik olarak kullanıcıları ayırmayı düşündüm. İlk karakterleri düşünürsek (sadece yabancı karakterler) Tablodaki ilk 26 sıra a, b, c, d... , ile başlayan isimleri tutacak. Daha sonra bunlar sonradan eklenen, aynı karakterle başlayan kişilerle ilişkilendirilecek. Şöyle ki;

0->ahmet
1->basar
2->ceyhun
...

Sonradan ayse diye bir kullanıcı eklendi diyelim. Tablo şu hale gelecek

0->ahmet->ayse
1->basar
2->ceyhun
...

Bu kullanıcının bilgilerine ulaşmak için ilk 26 kişinin bilgilerini tek tek alıp kontrol etmek istemiyorum ben. çünkü bu kullanıcı eklendiği zaman ben diyeceğim ki, ayse "a" harfiyle başlıyo. O zaman kesin bu "0"la ilişkilendirilmiştir. Yani ya ahmet'in bu kullanıcıya bağı vardır, ya ahmet'ten sonra gelen herhangi bir kişinin. Şu durum için konuşacak olursak, ahmet'e bağlı olacaktır.

0->26
1
2
...

Burdaki rakamlar bu kişilerin MySQL'deki sıra numaralarını belirtmektedir. Benim istediğim 26. sıraya doğrudan ulaşmak. Yani sırasıyla 0, 1, 2, 3..., 26 değil de doğrudan 26'yı almak. Böylece liste uzadığı zaman tekrar tekrar aynı kişiler üzerinden geçilmesin.

Bunun çözümünü de şöyle düşündüm, ayrı bir tablo yaratıp "a" ile başlayanların tablosu, "b" ile başlayanların tablosu gibi bu arama işini istediğim gibi kısaltabilirim...

Yardımların için çok teşekkürler...

[s5prin]

Biz bu "heap, priority queue" tekniğini SQL'deki ORDER BY parametresi ile yapıyoruz Yani tablonun ilk kolonuna "rid" gibi bir isim verip Primary Key ve auto-increment özelliğini atıyoruz. Böylece her eklediğin satırın otomatik olarak bir numarası oluyor. Örnek tablo:
"rid" ; "Name" ;
"1" ; "Veysel"
"2" ; "Muzaffer"
"3" ; "Ali"
"4" ; "Tarkan"
"5" ; "Ahmet"
"6" ; "Faruk"
...

Bu veriyi nasıl aldım:

PHP Code:

$SQL = "SELECT * FROM tablo ORDER BY rid" 


Tersten sıralamak için (6'dan ... 1'e):

PHP Code:

$SQL = "SELECT * FROM tablo ORDER BY rid DESC" 


Sadece 'a' ile başlayan isimleri almak:

PHP Code:

$SQL = "SELECT * FROM tablo WHERE Name LIKE 'a%'" 


Sadece 'a' ile başlayan isimleri rid diziliminde tersten almak:

PHP Code:

$SQL = "SELECT * FROM tablo WHERE Name LIKE 'a%' ORDER BY rid DESC" 


Sadece 5. kaydı almak:

PHP Code:

$SQL = "SELECT * FROM tablo WHERE rid='5'" 


Yanlış anlamada bunlar en basit SQL sorgularıdır...

[bgul]

iyide server o rid'lerin 1 ile 6 arasında olup olmadığını nası anlıyo? yani tek tek tüm satırların rid değerlerini kontrol etmesi gerek, yoksa arada atlar.. ya da sadece a ile başlayanları alırken LIKE a% kullanırsan bu bütün satırlardaki Name sütun'unu kontrol edip sadece a ile başlayan ları geri döndürmek. Ben diyorum ki, diğer satırları kontrol etmesin bile. Çünkü binlerce girdi olduğu zaman senin söylediğin şekilde her satırı kontrol eder; sadece "a" ile başlayanları geri döndürür. Bir satırı kontrol etmesi lafın gelişi 1sn alıyorsa, 1000'ini kontrol edip sorgunun geri gelmesi 1000sn alır. ama bunu benim söylediğim şekilde bölerse (isimlerin eşit dağildiğini varsayarsak) 1000/26sn sürer ki bu da epey bi zaman kazandırıyo, bilmem anlatabildim mi...?

[s5prin]

bgul tarafından gönderilen mesaj:

iyide server o rid'lerin 1 ile 6 arasında olup olmadığını nası anlıyo? yani tek tek tüm satırların rid değerlerini kontrol etmesi gerek, yoksa arada atlar.. ya da sadece a ile başlayanları alırken LIKE a% kullanırsan bu bütün satırlardaki Name sütun'unu kontrol edip sadece a ile başlayan ları geri döndürmek. Ben diyorum ki, diğer satırları kontrol etmesin bile. Çünkü binlerce girdi olduğu zaman senin söylediğin şekilde her satırı kontrol eder; sadece "a" ile başlayanları geri döndürür. Bir satırı kontrol etmesi lafın gelişi 1sn alıyorsa, 1000'ini kontrol edip sorgunun geri gelmesi 1000sn alır. ama bunu benim söylediğim şekilde bölerse (isimlerin eşit dağildiğini varsayarsak) 1000/26sn sürer ki bu da epey bi zaman kazandırıyo, bilmem anlatabildim mi...?

Üzgünüm ki sen veritabanı mantığını baştan yaratmaya çalışıyorsun Bırak 1000'lerce ya da 100 binlerce kayıt arasından bizim istediğimiz sonucu SQL server bulup getirsin. Kaldı ki (nasıl yaptığı pek de umrumda değil) tabloda değil 1 milyon 1 milyar kayıt dahi olsa WHERE rid = '99986543' satırını bulup getirmesi 1 saniyeden çok çok daha az sürer:

The famous Internet news site Slashdot.org runs on InnoDB. Mytrix, Inc. stores over 1TB of data in InnoDB, and another site handles an average load of 800 inserts/updates per second in InnoDB.

Direk MySQL sitesinden alıntıdır. Der ki; Slashdot.org isimli site 1TeraByte'dan fazla bilgiyi MySQL InnoDB yöntemiyle saklamaktadır ve saniyede 800 satır ekleme/güncelleme yapmaktadır.

[bgul]

teşekkür ederim, bu kadar sağlam olduğunu tahmin etmiyordum..