Kjapp og trygg hosting for Wordpress

Søke gjennom 160+mb data

Kenneth Dreyer

Well-Known Member
Hei,

Jeg jobber med å lage en reiseside som skal inneholde en masse destinasjoner, og for å fylle inn disse destinasjonene vurderer jeg å bruke geodataen for Google maps. Problemet er at denne inneholder bortimot 2 millioner destinasjoner og tar totalt 160mb plass når den ligger lagret i en zipfil. Jeg vet at det er mange av disse destinasjonene som er ganske bortkastet å ha der, men når det er over 2 millioner destinasjoner blir det liksom ikke sånn at du gidder å sitte å gå gjennom dem alle sammen for å huke ut de uviktige. Jeg har sett at mange av destinasjonene ikke er steder, men kordinater til f.eks firmaer og hoteller. Disse vil jeg ikke ha behov for i databasen, så jeg disse vil jeg automatisk filtere ut. Jeg har ikke kjært filtrering på filene enda (det er helvetes mye jobb bare det), men jeg tipper all informasjonen allikevel vil ligge godt over 100mb.

Jeg har to spørsmål:
- Hver eneste destinasjon har sin unike ID. Er det da likegyldig om databasen er på 1mb eller 100mb, så lenge man bare henter ut spesifikk destinasjon med en spesifikk ID?
- Når en bruker skal søke etter en destinasjon, vil dette da kreve utrolig mye av serveren? Sett at det er mellom 1000-5000 søk daglig når siden er på topps?
 

srm

Medlem
1) Jepp, dette vil gå helt fint. Så lenge ID er sortert på forhånd (indeks eller pirmary key)
2) Sett indeks på destinasjonsfeltet i databasen. Da vil det gå knirkefritt. Du kan også spesifisere hvor mange tegn/chars indeksen skal indeksere på, men dette er noe du kan justere etter hvert for optimalisere mest mulig. 1000 - 5000 søk går helt fint, ikke noe problem for serveren.

Følg med på server-variablene til mySQL. Dersom det dukker opp mange forekomster av Created_tmp_disk_tables eller Created_tmp_files, juster opp tmp_table_size i konfigurasjonen. Om ting gjøres i minnet eller på disk er himmel eller helvete for bruken av ressursene på serveren.
 
Sist redigert:

srm

Medlem
CREATE UNIQUE INDEX index_name ON table_name (column_name)

Denne er ikke bare nyttig med tanke på å finne riktig rad i databasen fort, men vil også være nyttig dersom du benytter ORDER BY mye. Da slipper serveren å sortere resultatet alfabetisk for hver spørring.

SQL Create Database, Table, and Index , avsnitt "Create Index"
MySQL AB :: MySQL 5.0 Reference Manual :: 12.1.4 CREATE INDEX Syntax

Om du lurer på hva dette _egentlig_ er, så stiller Wikipedia opp og foteller om B-trær.
B-tree - Wikipedia, the free encyclopedia
 

srm

Medlem
Haha, nei det er ikke bare deg. Temmelig nerdy, men jeg koser meg glugg i hjelp når jeg finner en dårlig SQL-string eller tabell. Optimalisering er rett og slett vanvittig morsomt. Og helt enkle grep kan ofte redusere tiden SQL-spørringer tar, ofte helt ned til en hundredel av det opprinnelige.

Og her en en fin lek: Optimaliseringsjakt! La oss si nettsiden din består av en topp, en venstremeny, et hovedfelt, høyrefelt og en bunn. Målet er å finne ut hva som tar tid for serveren å generere, altså finne de svake punktene som tar tid. Da går du frem slik:

Benytt microtime() til å notere "klokkeslettet" ned på mikrosekundnivå helt øverst (microtime: Return current Unix timestamp with microseconds). Ta tiden etter toppmeny. Ta tiden etter venstremeny. Ta tiden etter hovedfelt. Ta tiden etter høyrefelt. Ta tiden etter bunn.

Beregn differansen mellom tallene og finn ut hva som egentlig tar tid. Dersom du finner ut at for eksempel høyremeny tar tid, kan du lage flere rundertider internt for denne delen og finne ut akkurat hvilke spørringer som tar tid. Og så optimalisere den biten.

Ganske nerdy, og veldig morsomt :)

<?php
/**
* Simple function to replicate PHP 5 behaviour
*/
function microtime_float()
{
list($usec, $sec) = explode(" ", microtime());
return ((float)$usec + (float)$sec);
}

$time_start = microtime_float();

// Sleep for a while
usleep(100);

$time_end = microtime_float();
$time = $time_end - $time_start;

echo "Did nothing in $time seconds\n";
?>
 

Kenneth Dreyer

Well-Known Member
hm, meget interessant. Skal prøve å kjøre noen optimaliseringstester på siden når jeg har kommet litt lengre. Du kommer garantert til å se flere spørsmål ang optimalisering osv :D
 
Topp