Google kereső működése?
Azon töröm a fejem, hogy létezik-e hatékony, PHP-ben előállítható megoldás arra, amit a google keresője művel: minden beírt karakter után feldobja a lehetséges találatokat.
Ezt jelen ismereteim birtokában valami ajaxos megoldással tudnám elképzelni, de... ez azt jelentené, hogy minden bill. leütéskor bemegy egy kérés a szerverre, ott megnyílik egy adatbázis kapcsolat, lekéri a lehetséges találatok listáját, majd visszaküldi a böngészőbe.
Hát ez így nem túl hatékony...
OK, valamivel jobb lehetne, ha bevezetnék egy cache-t a szerver oldalon és az első karakter érkezésekor kigyűjteném az összes találatokat, majd a cache-ből válogatnék, de annak meg olyan memória igénye lenne, hogy amiatt halna el az egész. Ha pedig nem memóriába pakolom a cache-t, akkor meg szinte felesleges, hiszen minimum fájlokat kell nyitogatni karakterenként, ami ugyan gyorsabb, mint egy adatbázis kapcsolat felépítése, de még mindig lassú.
Gondolom, valami alapvető technológiai ismeret hiányzik, de nem igazán tudom, mit keressek.
(félreértéseket kerülendő: nem akarok új google-t írni, csak elméleti szinten, nagy vonalakban érdekelne)
■ Ezt jelen ismereteim birtokában valami ajaxos megoldással tudnám elképzelni, de... ez azt jelentené, hogy minden bill. leütéskor bemegy egy kérés a szerverre, ott megnyílik egy adatbázis kapcsolat, lekéri a lehetséges találatok listáját, majd visszaküldi a böngészőbe.
Hát ez így nem túl hatékony...
OK, valamivel jobb lehetne, ha bevezetnék egy cache-t a szerver oldalon és az első karakter érkezésekor kigyűjteném az összes találatokat, majd a cache-ből válogatnék, de annak meg olyan memória igénye lenne, hogy amiatt halna el az egész. Ha pedig nem memóriába pakolom a cache-t, akkor meg szinte felesleges, hiszen minimum fájlokat kell nyitogatni karakterenként, ami ugyan gyorsabb, mint egy adatbázis kapcsolat felépítése, de még mindig lassú.
Gondolom, valami alapvető technológiai ismeret hiányzik, de nem igazán tudom, mit keressek.
(félreértéseket kerülendő: nem akarok új google-t írni, csak elméleti szinten, nagy vonalakban érdekelne)
Hát ez így nem túl
Egyetlen lehetőséget látok a felsorolt lépések csökkentésére, olyan adatbázis szervert használni amely HTTP kapcsolaton keresztül közvetlenül lekérdezhető és JSON formátumban adja vissza az eredményeket. Mivel ezzel szó szerint nyilvánossá teszed az adatbázist illetve mivel csak NoSQL adatbázisok esetében hallottam ilyen elérhetőségről, 2 adatbázisod kellene legyen:
- a korlátozott elérésű, amelyben a féltett adatok vannak
- a nyilvánosan elérhető NoSQL, amelyben kizárólag az autocomplete-el is elérhető adatok vannak
Ebből adódna egy kis plusz munka a két adatbázis összhangban tartásával.Ami a NoSQL adatbázist illeti, konkrétan az Apache CouchDB-re gondoltam.
Köszi
Csak annyi a gond, hogy ehhez mindenképpen saját szervert kell üzemeltetni, minimum egy VPS kell hozzá.
----
Két adatbázissal egy nagy gondom van: konzisztencia... Üzemeltetési szempontból egy agyrém.
Holott megoldható lenne egy
atw, uw, freebase...
Kivágnak
Nem biztos... :)
bootstrap
Amint látszik itt a kliens oldalon is elég sok logika van, úgyhogy talán érdemesebb egy erre kidolgozott kész megoldást választani. jQuery esetén van erre az autocomplete plugin, de biztosan vannak masszívabb kliens oldali megvalósítások is.
Köszi!
kuka javaslatát
1.) Ha a CouchDB nem telepíthető a célkörnyezetre, akkor azt javaslom, használj helyette SQLite-ot és írj a lekérések átadásához egy totál primitív gateway-t PHP-ben. Az SQLite-tal egy hagyományos DB-hez képest mindenképp fogsz időtnyerni, mivel hálózatot nem igényel, ugyanakkor hatékonyabb mint egy TXT/CSV állományban turizás mert lehet vele indexelni. A PHP-SQLite gateway-ed összes feladata pedig kimerülne abbam hogy a GET/POST-ban kapott SQL lekérést megfuttatja és JSON-ban visszaadja a visszatérést vagy a hibakódot (erre javasolt struktúra: {success:true/false, data: null/array[objects], errmsg: string} - success true esetén data tartalmazza a resultset-et, success false esetén errmsg a hibaüzenetet). A két adatbázist persze így sem úsznád meg.
2.) Keresési gyakoriságot count-old minden kereshető tétel esetén, erre rendezzél az első karakter leütésekor és add vissza az összes lehetséges találatok mondjuk 20%-át (tehát 100 lehetséges találat esetén az első 20-at). A további leütések esetén elsőként a visszaadott listából próbáljon találatot felszedni a JS, így elképzelhető, hogy sikerül további AJAX kéréseket spórolni. Ezen a gondolatmeneten tovább lehet menni egyéb intelligens(-nek mondható) optimalizálási trükkökön is, például ha egy keresett kifejezés levenshtein távolsága nagyon kicsi egy gyakrabban használt kifejezéshez képest, akkor a már létező, ahhoz hasonló de gyakori kifejezést adja vissza. Ezt mondjuk egész szavak határán van értelme használni (tehát nem [a-z; 1-9] karakterek bevitele esetén, azaz szóhatáron). Ha aztán a felhasználó mégsem a feldobott tooltip-et akarja használni, akkor a keresett kifejezés bekerülhet az adatbázisba (vagy kaphat +1 count-ot a használat gyakoriságára).
Csak ötleteltem.
(Ja és: előny, ha a szerveren fut mondjuk APC, csökkenni fog a PHP bootstrap ideje [amit mondjuk bootstrap csökkentés esetén érdemes megtenni: session_autostart kikapcs, ha van gpc_magic_quotes akkor kikapcs, INI beállítást ha megoldható felülírni hogy semmit ne include-oljon automatice, stb])
Sok, nagyon sok adat esetén
Kezelhető mennyiségű adatnál, ajaxos autocomplete mezőnél én erre olyan megoldást láttam, hogy 2-3 begépelt karakter után adja vissza a találatot, de ekkor az összeset (pl: LIKE 'ABC%'), ez helyzettől függően lecsökkenti a találati listát pár száz elemre, amit gond nélkül át lehet küldeni ajaxon json-el. Plusz karakterek beírásánál ezt a listát csökkenti az autocompleter.
OK, de én épp azon méláztam,
Apache Solr