Téma: Közelben lévő pontok számítása ( Mysql )

Az lenne, a kérdésem, hogy tudna-e nekem valaki ajánlani ennél gyorsabb megoldást erre a feladatra.
Előre is köszönöm a segítségeteket.

Kód:

SELECT *, (ACOS((SIN($latitude_p/57.295) * SIN(latitude/57.295))+(COS($latitude_p/57.295) * COS(latitude/57.295) * COS(longitude/57.295 ($longitude_p)/57.295))))
*
3963 AS
distance
FROM 
tabla_name
WHERE (latitude >= $latitude_p - 0.5)AND(latitude <= $latitude_p + 0.5)AND(longitude >= ($longitude_p) - 0.5)AND (longitude <= ($longitude_p) +0.5)
ORDER BY distance ASC limit 100000

---

Hasonló témák:

• Képeken levő szöveg
• Zárójelben lévő adat törlése...
• Lejárófélben levő hu domainek vásárlása
• Statisztikák számítása
• blog.hu vs. saját tárhelyen lévő wordpress

Az ilyesmit tudtommal söprésnek nevezett algoritmusokkal szokták megoldani. Mivel feltételezem, nem áll módodban egy kiegészítést telepíteni az adatbázisszerverre - és mert egyébként sem lenne egyszerű - szerintem valamilyen gyorsítótárazás lehet a megoldás kulcsa. Viszont, ha van 1000 pontod, amik gondolom minden síkon legalább 1-1 bájtos koordinátával rendelkeznek - akkor egy egy távolság eltárolásához szükséged lesz legalább 2-2 bájtra, továbbá a távolság leírásához legalább egy bájtra(de inkább egy lebegőpontos számra, ha számít valamit is a pontosság - rendezés esetén biztosan.), tehát "kézfogásonként" minimum öt bájt. Mivel 1000 távolságot kell eltárolnod, ezért 1000 alatt a 2 sorra lesz szükséged. (azaz 499500 ha jól számoltam), ami már magában 2,38 megabájt(ha a lehető legoptimálisabb tárolási módszert nézzük - de annyira nem ástam megam bele a MySQL-be, hogy tudjam ez hogyan történik.). Viszont neked egész biztosan nem ilyen kis kiterjedésű és pontatlan értékekre lesz szükséged, vagyis ennek a többszörösével számolhatsz, ami a pontok számának növekedésvel csaknem exponenciálisan nő - tehát sem kicsi, sem gyors nem lesz az adatbázis. Százezer pont esetén sajnos már 23 gigabájtot emésztene fel ez a tábla.

Tehát nem javaslom, hogy ezt a módszert sok pont esetén használd. Biztos lehet még a bruteforce módszeren is javítani. Ha leírnád, hogy konkrétan milyen probléma megoldásához lenne erre szükség, akkor lehet hogy többet tudnánk segíteni. Mindenesetre amikor csak lehet, kerüld ennek a lekérdezének a lefuttatását. Amint már fentebb írták 1-2 művelet megspórolható a fenti módszer finomításával, de erre be kell áldozni némi tárhelyet, ami összeségében ugye megint egy kis sebességveszteség okozója lehet.

Azt mondjátok, hogy kénytelen vagyok eltárolni inkább a kiszámított adatot .
Nem nagyon szeretném, mert rengeteg helyet használna .

2.6 millió pont van.

nagysanyi eredeti hozzászólása

2.6 millió pont van.

Természetesen ebben az esetben szóba sem jöhet a kombinációk eltárolása. A fentebb említettmódszer segíthet valamit, néhány megabájt árán.

De tényleg jobb lenne, ha többet elmondanál a problémáról.

2 választási lehetőség van:

Vagy fizikailag növeled az adatbázist és külön oszlop lesz az eredményekhez,
Vagy cachelteded és a gép memóriáját használod fel tároláshoz.

A fizikai mentést támogatom, mivel ez a megoldás nem fogja annyira gyilkolni és lassítani. 2 milla adatot még teljesen tűrhető lekérdezni... főleg ha nem MsSQL -elt használsz hozzá

Több száz megabyte cacheltetése lelassítja az egész SQL servert, mivel memóriában tárolja... (főleg ha osztott serveren vagy, mert akkor pár 100 mega az, ami neked jut összesen...)

Cheers,