Jeg og Gordon Gekko driver for tiden å lager en "pay per click"
søkemotor. Vi har hatt suksess med en slik funksjon på 4u.no og tror
markedet nå er modent for en slik tjeneste, i en større skala
(skandinavisk/internasjonalt). Dette vil bli lansert under navnet
Boitho.com
Til dette trenger vi nå hjelp av en designer, som kan lage designet til
siden. Og annet grafisk arbeid som logo og noen knapper. Gjerne en
jente, fordi jenter er flinke på design.
En programmerer som helst har erfaring med en eller flere ting av
følgende; Perl, mod_perl, DBM databaser, hasheing, XML, cashing
teknikker, opptimalisering av Linux minne og disk bruk. Eventuelt andre
ting som kan være nyttig.
Med de rette folkene og entusiasme og pågangsmot kan vi veie opp for
mangelende ressurser og erfaring.
Vi kan ikke tilby noen lønn hverken til dere eller til oss, men
når/hvis dette tar av vil alle selvfølgelig ta del i utbytte.
Folk som har sett beta versjonen er henrykt.
Vi håper noen har tid og krefter til skape noe virkelig stort.
Det er også en diskusjon om teknologien og ideen på skitX her
Om teknologien vi har utvikklet:
Det som for brukeren fremstår som en søkemotor er i virkeligheten 2
søkemotorer integrert. Først har vi betalingslinkene som presenteres
først, deretter vi har rippet fra Dmoz og indeksert selv.
De fleste søkemotorene på Internett i dag baserer seg på såkalt
"paralle søk", det vil si at et søke query sent til søkemotoren blir
sent til en enkel datamaskin (eller i hvertfall ikke så veldig mange),
etter det skalte Round-Robin prinsippet. Så at de har 500 servere betyr
bare at de kan ta i mot 500 ganger flere søk en noen med 1 server, da
all søking uansett bare skjer på en server. Så de små med bare en
server kan konkurrere ved å begynne med en server å kjøpe flere etter
hvert som man motar flere søk. Det er heller ikke nødvendig å indeksere
så mange sider at du har millioner av treff på hvert ord, da få folk
uansett går forby side 3.
Det ble tidlig klart at vi trengte en vanlig søkemotor i bunnen slik at
vi hadde noen resultater å vise brukerene inntil vi fikk mange
annonsører, og brukere som søkte på mindre kommersielle emner. Bygging
av en vanlig søkemotor byr på en del problemer forbundet med at vi
jobber med store datamengder, så for eksempel bruk av en standard
databasen som MySQL var utelokket da ytelsen faller dramatisk nor
tabellene blir større en tilgjengelig minne (ram). I steden lagde jeg
mitt egent database system med fil hashing. Denne metoden er ideell da
det ikke er noen ytelsesforskjell om vi har en database på 50 MB eller
50 GB.
For å redusere mengden av data vi må lagre om hver side brukes Zipf's
lov. Dette er en matematisk formel som finner de 20% av ordene i en
tekst som står for 70% av meningen, hvis vi har et stort nok
datagrunnlag. Enkelt forklart ser man da på hvor ofte et ord fins i
mengden ut fra hvor stor mengden er.
For eksempel i test oppsetet vårt med 116 078 unike søkeord for 8890
sider er dette ti på topp:
For eksempel "for" fins på 4547 sider, altså på 51%, så "for" kan
forkastes da det ikke gir noen mening å søke på det da du får så mange
treff.
Det virkelige vanskelige i å bygge en søkemotor er å skille sider med
kvalitet fra de som ikke er det, for dette fins det en rekke metoder,
ingen av de er gode.
Vår metode var å gjøre dette ved å begynne med å indeksere de norske
sidene i dmoz og i katalogen på 4u.no. Disse sidene er gjennomgått og
godkjent av mennesker så de typisk er store og av en hvis kvalitet,
deretter indekserte vi alle sidene som disse linker til, da hvis dmoz
og 4u.no sidene er av kvalitet så bør de de linker til også være det.
Indeksereren vekter også sidene ut fra en rekke kriterier for å sørge
for at de mest relevante kommer først.
Følgende gjenstår:
Steming; For å øke brukervennligheten og minske datamengden vi må lagre
kan man tenke seg at søk på "bil" og "biler" er det samme. Problemet er
at systemer som finner dette ut kan fort mene at "hus" og "hustru" også
er likt, og "biler" og "bilder". Derfor er det vanskelig å gjøre
automatisk.
For tiden ser jeg på flere alternativer. Det beste vil være å bruke en
ferdig "stemme" liste som lister slike synonymer, og bruke n-gram eller
three-gram (automatiske matematiske modeller for formålet) til å
håndtere det som ikke er i listen.
Affilant program; vi er ikke helt ferdig med det.
Klient; vi har en klient i Perl folk kan bruke på sin side for å koble
seg til søkemotoren å integrere den på sin side. Planen er å også lage
klienter i PHP, ASP og JavaScript. I hvertfal JavaScript kan by på
utfordringer.
I tillegg jobber vi med andre måter som folk kan bruke for å integrere
søkemotoren på sin side. Detter er blant annet: enkel søkebokser som
bare sender brukeren til oss, avanserte søkebokser som viser svaret med
egen hedder/footer og en XML interface.
Følgende er planlagt for fremtiden:
I dag foregår selve søkingen av et Perl script. Man må lage en ny
prosses for hver gang, noe som tar tid, og man kan ikke cashe i minnet
mellom hver gang. Planen er å skrive en daemon som pre-forker nye
prosseser på forhond, slik at brukeren ikke trenger å vente på dette.
I tillegg vil disse prosessene ha et felles minne område hvor side data
for de siste 100 K sidene som er lest fra disken blir cashet, slik at
man skjellden må hente nye.
Jeg har allerede et slikt eksperimentelt system oppe å kjører, men det
gjenstår mye arbeid.
søkemotor. Vi har hatt suksess med en slik funksjon på 4u.no og tror
markedet nå er modent for en slik tjeneste, i en større skala
(skandinavisk/internasjonalt). Dette vil bli lansert under navnet
Boitho.com
Til dette trenger vi nå hjelp av en designer, som kan lage designet til
siden. Og annet grafisk arbeid som logo og noen knapper. Gjerne en
jente, fordi jenter er flinke på design.
En programmerer som helst har erfaring med en eller flere ting av
følgende; Perl, mod_perl, DBM databaser, hasheing, XML, cashing
teknikker, opptimalisering av Linux minne og disk bruk. Eventuelt andre
ting som kan være nyttig.
Med de rette folkene og entusiasme og pågangsmot kan vi veie opp for
mangelende ressurser og erfaring.
Vi kan ikke tilby noen lønn hverken til dere eller til oss, men
når/hvis dette tar av vil alle selvfølgelig ta del i utbytte.
Folk som har sett beta versjonen er henrykt.
Vi håper noen har tid og krefter til skape noe virkelig stort.
Det er også en diskusjon om teknologien og ideen på skitX her
Om teknologien vi har utvikklet:
Det som for brukeren fremstår som en søkemotor er i virkeligheten 2
søkemotorer integrert. Først har vi betalingslinkene som presenteres
først, deretter vi har rippet fra Dmoz og indeksert selv.
De fleste søkemotorene på Internett i dag baserer seg på såkalt
"paralle søk", det vil si at et søke query sent til søkemotoren blir
sent til en enkel datamaskin (eller i hvertfall ikke så veldig mange),
etter det skalte Round-Robin prinsippet. Så at de har 500 servere betyr
bare at de kan ta i mot 500 ganger flere søk en noen med 1 server, da
all søking uansett bare skjer på en server. Så de små med bare en
server kan konkurrere ved å begynne med en server å kjøpe flere etter
hvert som man motar flere søk. Det er heller ikke nødvendig å indeksere
så mange sider at du har millioner av treff på hvert ord, da få folk
uansett går forby side 3.
Det ble tidlig klart at vi trengte en vanlig søkemotor i bunnen slik at
vi hadde noen resultater å vise brukerene inntil vi fikk mange
annonsører, og brukere som søkte på mindre kommersielle emner. Bygging
av en vanlig søkemotor byr på en del problemer forbundet med at vi
jobber med store datamengder, så for eksempel bruk av en standard
databasen som MySQL var utelokket da ytelsen faller dramatisk nor
tabellene blir større en tilgjengelig minne (ram). I steden lagde jeg
mitt egent database system med fil hashing. Denne metoden er ideell da
det ikke er noen ytelsesforskjell om vi har en database på 50 MB eller
50 GB.
For å redusere mengden av data vi må lagre om hver side brukes Zipf's
lov. Dette er en matematisk formel som finner de 20% av ordene i en
tekst som står for 70% av meningen, hvis vi har et stort nok
datagrunnlag. Enkelt forklart ser man da på hvor ofte et ord fins i
mengden ut fra hvor stor mengden er.
For eksempel i test oppsetet vårt med 116 078 unike søkeord for 8890
sider er dette ti på topp:
Kode
| ORD | SIDER | | ikke | 1259 | | kan | 1404 | | det | 2030 | | fra | 2078 | | har | 2226 | | som | 2987 | | med | 3307 | | informasjon | 3354 | | til | 4157 | | for | 4547 |
forkastes da det ikke gir noen mening å søke på det da du får så mange
treff.
Det virkelige vanskelige i å bygge en søkemotor er å skille sider med
kvalitet fra de som ikke er det, for dette fins det en rekke metoder,
ingen av de er gode.
Vår metode var å gjøre dette ved å begynne med å indeksere de norske
sidene i dmoz og i katalogen på 4u.no. Disse sidene er gjennomgått og
godkjent av mennesker så de typisk er store og av en hvis kvalitet,
deretter indekserte vi alle sidene som disse linker til, da hvis dmoz
og 4u.no sidene er av kvalitet så bør de de linker til også være det.
Indeksereren vekter også sidene ut fra en rekke kriterier for å sørge
for at de mest relevante kommer først.
Følgende gjenstår:
Steming; For å øke brukervennligheten og minske datamengden vi må lagre
kan man tenke seg at søk på "bil" og "biler" er det samme. Problemet er
at systemer som finner dette ut kan fort mene at "hus" og "hustru" også
er likt, og "biler" og "bilder". Derfor er det vanskelig å gjøre
automatisk.
For tiden ser jeg på flere alternativer. Det beste vil være å bruke en
ferdig "stemme" liste som lister slike synonymer, og bruke n-gram eller
three-gram (automatiske matematiske modeller for formålet) til å
håndtere det som ikke er i listen.
Affilant program; vi er ikke helt ferdig med det.
Klient; vi har en klient i Perl folk kan bruke på sin side for å koble
seg til søkemotoren å integrere den på sin side. Planen er å også lage
klienter i PHP, ASP og JavaScript. I hvertfal JavaScript kan by på
utfordringer.
I tillegg jobber vi med andre måter som folk kan bruke for å integrere
søkemotoren på sin side. Detter er blant annet: enkel søkebokser som
bare sender brukeren til oss, avanserte søkebokser som viser svaret med
egen hedder/footer og en XML interface.
Følgende er planlagt for fremtiden:
I dag foregår selve søkingen av et Perl script. Man må lage en ny
prosses for hver gang, noe som tar tid, og man kan ikke cashe i minnet
mellom hver gang. Planen er å skrive en daemon som pre-forker nye
prosseser på forhond, slik at brukeren ikke trenger å vente på dette.
I tillegg vil disse prosessene ha et felles minne område hvor side data
for de siste 100 K sidene som er lest fra disken blir cashet, slik at
man skjellden må hente nye.
Jeg har allerede et slikt eksperimentelt system oppe å kjører, men det
gjenstår mye arbeid.
