---

Hvad er den hurtigste database, som samtidig kan håndtere kolosale mængder
data og anvendes online?
Når man fx. ser på google er det jo hurtigt at finde et eller andet, noget
tilsvarende findes det, eller er det kun de proffesionelle der har sådanne
hjemmestrikkede systemer.
Ikke fordi jeg vil lave en søgemaskine, dem er der masser af.
Men det jeg har brug for, skal kunne håndtere mindst 3-4 millioner records
og søgning skal gå lynhurtigt.
Access kan ikke bruges til store mængder data.
Systemet må selvfølgelig gerne være gratis, men ikke nødvendigvis.
Om det er til Linux eller Windows er mindre væsentligt.

--
Med Venlig Hilsen

John Vedsegaard

---

"John V." <nyhedsgrupper.sparm@loveletters.dk> wrote in
news:4989cb21$0$56796$edfadb0f@dtext02.news.tele.dk:

> Men det jeg har brug for, skal kunne håndtere mindst 3-4 millioner
> records og søgning skal gå lynhurtigt.

Hvis du opbygger din database korrekt kan det sagtens lade sig gøre på alle
relationelle databaser (forbehold for om der findes en eller anden elendig
en et sted). Det handler primært om indexes og optimering af din SQL
sætning hvis du skal have hurtig søgning. 3-4 mio records er ikke voldsomt
mange.

> Access kan ikke bruges til store mængder data.

Access kan ikke bruges hvis det du skal have er en database. Access kan
bruges til mange ting men som decideret database er den elendig.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

"John V." skrev

> Hvad er den hurtigste database, som samtidig kan håndtere kolosale mængder
> data og anvendes online?

Der en del parametre der afgør svartider
Hardware (herunder disksystemer
Software (OS/DB system)
DB Implementering (hvordan den er installateret på server)
FE implementering (FE = Frontend)
Frekvens (antal brugere/kald pr bruger etc)
Kompleksiteten af søgninger

Nogen af parametrene kan været givet på forhånd og så man optimere på de
variable

- Peter

---

John V. wrote:
> Hvad er den hurtigste database, som samtidig kan håndtere kolosale mængder
> data og anvendes online?

Oracle DB og IBM DB2 er nok hvad der typisk bruges til very high end
databaser, men andre er også set brugt.

> Når man fx. ser på google er det jo hurtigt at finde et eller andet, noget
> tilsvarende findes det, eller er det kun de proffesionelle der har sådanne
> hjemmestrikkede systemer.

Google bruger ikke en relations databaser (til deres søge maskine).

> Men det jeg har brug for, skal kunne håndtere mindst 3-4 millioner records
> og søgning skal gå lynhurtigt.

3-4 millioner rækker er (forudsat vi ikke snakke rækker med LOB's)
ingenting.

Hvis databasen voksede med 3-4 millioner rækker om dagen, så ville
det kunne blive en stor database.

> Systemet må selvfølgelig gerne være gratis, men ikke nødvendigvis.
> Om det er til Linux eller Windows er mindre væsentligt.

Jeg tror at du kan bruge hvad seom helst.

MySQL, PostgreSQL, MS SQLServer, Sybase ASE, IBM DB2, Oracle DB - du
vælger bare.

(både MS SQLServer, Sybase ASE, IBM DB2 og Oracle DB har gratis
versioner som måske vil kunne klare dine behov)

Arne

---

Arne Vajhøj wrote:

> (både MS SQLServer, Sybase ASE, IBM DB2 og Oracle DB har gratis
> versioner som måske vil kunne klare dine behov)

Jeg har ikke lige fulgt med de sidste par år, men for en del år siden frigav
SAP deres SapDB som open source, og gratis hvis man _ikke_ kørte SAP.
Den blev senere 'overgivet' til mySQL under MaxDB, men jeg ved ikke rigtig
om den er røget tilbage i SAP regi.

Ud over den understøttede recovery til last committed transaction, som er
mit ufravigelige krav til enterprise class database, så var der squ meget
godt skralder på den på min Linux spand.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen wrote:
> Arne Vajhøj wrote:
>> (både MS SQLServer, Sybase ASE, IBM DB2 og Oracle DB har gratis
>> versioner som måske vil kunne klare dine behov)
>
> Jeg har ikke lige fulgt med de sidste par år, men for en del år siden frigav
> SAP deres SapDB som open source, og gratis hvis man _ikke_ kørte SAP.
> Den blev senere 'overgivet' til mySQL under MaxDB, men jeg ved ikke rigtig
> om den er røget tilbage i SAP regi.

Den er tilbage.

https://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/7514

> Ud over den understøttede recovery til last committed transaction, som er
> mit ufravigelige krav til enterprise class database, så var der squ meget
> godt skralder på den på min Linux spand.

Jeg kiggede kort på den engang. Den virkede lidt "speciel" på mig.

Arne

---

Arne Vajhøj <arne@vajhoej.dk> wrote in
news:498a2ede$0$90267$14726298@news.sunsite.dk:

>> Når man fx. ser på google er det jo hurtigt at finde et eller andet,
>> noget tilsvarende findes det, eller er det kun de proffesionelle der
>> har sådanne hjemmestrikkede systemer.

> Google bruger ikke en relations databaser (til deres søge maskine).

Ved du hvad de så bruger? evt. et link til hvor man kan læse mere om det?

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

"Henrik Stidsen" <inbox@henrikstidsen.dk> skrev i en meddelelse
news:Xns9BA9B9796ECBDhenrikstidsendk@130.225.247.90...
> Arne Vajhøj <arne@vajhoej.dk> wrote in
> news:498a2ede$0$90267$14726298@news.sunsite.dk:
>
>>> Når man fx. ser på google er det jo hurtigt at finde et eller andet,
>>> noget tilsvarende findes det, eller er det kun de proffesionelle der
>>> har sådanne hjemmestrikkede systemer.
>
>> Google bruger ikke en relations databaser (til deres søge maskine).
>
> Ved du hvad de så bruger? evt. et link til hvor man kan læse mere om det?
>
> --
> Henrik Stidsen - http://henrikstidsen.dk/

Ja, jeg har også svært ved at se hvad de så bruger..

John

---

John V. wrote:
> "Henrik Stidsen" <inbox@henrikstidsen.dk> skrev i en meddelelse
> news:Xns9BA9B9796ECBDhenrikstidsendk@130.225.247.90...
>> Arne Vajhøj <arne@vajhoej.dk> wrote in
>> news:498a2ede$0$90267$14726298@news.sunsite.dk:
>>
>>>> Når man fx. ser på google er det jo hurtigt at finde et eller andet,
>>>> noget tilsvarende findes det, eller er det kun de proffesionelle der
>>>> har sådanne hjemmestrikkede systemer.
>>> Google bruger ikke en relations databaser (til deres søge maskine).
>> Ved du hvad de så bruger? evt. et link til hvor man kan læse mere om det?
>
> Ja, jeg har også svært ved at se hvad de så bruger..

De bruger en egen udviklet skræddersyet løsning.

Jeg tvivler på at en COTS RDBMS løsning kunne klare
opgaven.

Arne

---

Henrik Stidsen wrote:
> Arne Vajhøj <arne@vajhoej.dk> wrote in
> news:498a2ede$0$90267$14726298@news.sunsite.dk:
>>> Når man fx. ser på google er det jo hurtigt at finde et eller andet,
>>> noget tilsvarende findes det, eller er det kun de proffesionelle der
>>> har sådanne hjemmestrikkede systemer.
>
>> Google bruger ikke en relations databaser (til deres søge maskine).
>
> Ved du hvad de så bruger? evt. et link til hvor man kan læse mere om det?

Google har aldrig publiceret deres hemmeligheder.

Men der cirkulerer visse rygter.

Og ifølge disse rygter, så bruger Google:
- alle data i memory, fordelt på hundredetusinder af standard
x86 maskiner kørende Linux (replikeret således at samme
data findes i mange kopier)
- en hjemme lavet web server og søge maskine som finder ud af hvor
data er og henter dem
- de persisterede data ligger i store slices på deres hjemmelavede
fil system
- crawleren er lavet i Python

Stort set alt over Linux er hjemmelavet. Af gode grunde. Google
har extreme performance krav og Google har pengene til at betale
for en skræddersyet løsning.

Arne

---

Arne Vajhøj wrote:

> Google har aldrig publiceret deres hemmeligheder.
>
> Men der cirkulerer visse rygter.

Ud over rygter, så mener jeg at Google startede med at de 2 stiftere
(universitets studerende(?) havde opfundet en ny metode til at
lagre/indexere/finde data, så det er nok en forretningshemmelighed.

Jeg må indrømme jeg gloede lidt da den kom, for jeg var vant til Alta Vista
Lycos m.v.

Både hastigheden, og det enkle 'look' betød enormt meget på mit 28.8K
dial-up.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen skrev:
> Ud over rygter, så mener jeg at Google startede med at de 2 stiftere
> (universitets studerende(?) havde opfundet en ny metode til at
> lagre/indexere/finde data, så det er nok en forretningshemmelighed.

Var det ikke en metode til at vurdere en sides relevans, de opfandt?

> Både hastigheden, og det enkle 'look' betød enormt meget på mit 28.8K
> dial-up.

Der hjælper fraværet af af en masse reklamer-billeder jo vældigt på
hastigheden.

--
Lars Kongshøj

---

Lars Kongshøj skrev:

> Var det ikke en metode til at vurdere en sides relevans, de opfandt?

De fik luft under sutterne fordi søgefunktionen var så hurtig.
Det var først senere de fik lucky-knappen på.

--
Bertel
http://bertel.lundhansen.dk/         FIDUSO: http://fiduso.dk/

---

Bertel Lund Hansen wrote:
> Lars Kongshøj skrev:
>> Var det ikke en metode til at vurdere en sides relevans, de opfandt?
>
> De fik luft under sutterne fordi søgefunktionen var så hurtig.
> Det var først senere de fik lucky-knappen på.

Det er muligt, at det var hastigheden som gav dem successen.

Men det research projekt som startede Google drejede sig
om at vurdere siders rank.

Kilde:
http://en.wikipedia.org/wiki/History_of_Google#Early_history

Arne

---

Lars Kongshøj <lars_kongshoj@hotmail.com> wrote in
news:498c3283$0$90262$14726298@news.sunsite.dk:

>> Ud over rygter, så mener jeg at Google startede med at de 2 stiftere
>> (universitets studerende(?) havde opfundet en ny metode til at
>> lagre/indexere/finde data, så det er nok en forretningshemmelighed.

> Var det ikke en metode til at vurdere en sides relevans, de opfandt?

Jo - PageRank - og jeg tror næsten at Yahoo stadig ærgrer sig over de ikke
købte deres søgemaskine da de fik den tilbudt af to ukendte
collegestuderende :)

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

Lars Kongshøj wrote:

> Stig Johansen skrev:
>> Ud over rygter, så mener jeg at Google startede med at de 2 stiftere
>> (universitets studerende(?) havde opfundet en ny metode til at
>> lagre/indexere/finde data, så det er nok en forretningshemmelighed.
>
> Var det ikke en metode til at vurdere en sides relevans, de opfandt?

Det er lige det med 'huskeren' :)
Det (Google) var rimeligt meget i medierne og så vidt jeg husker var det
'database strukturen', det startede med.

Jeg har prøvet at søge lidt i historien (via Google naturligvis), da den
organiske ram godt kan være lidt volatile.

Det er tilsyneladende ikke så lang tid siden, det har været nævnt i
Computerworld:
<http://www.computerworld.dk/art/47772/fra-garagekode-til-nettets-guldaeg-her-er-historien-om-google?a=related&i=48987&bottom>
Lidt afhængig af, om man tror på CW som autorativ kilde, så nævnes:
<http://www.computerworld.dk/art/47772?page=2>
....
Søgeteknologien, hvor PageRank kun var en blandt mange
....

Det viser sig også at 'PageRank' først blev patenteret i 2001:
<http://patft.uspto.gov/netacgi/nph-Parser?Sect1=PTO1&Sect2=HITOFF&d=PALL&p=1&u=%2Fnetahtml%2FPTO%2Fsrchnum.htm&r=1&f=G&l=50&s1=6285999.PN.&OS=PN/6285999&RS=PN/6285999>
Men under et andet emne:
....
Method for node ranking in a linked database
....

Det bringer spørgsmålet op: 'Hvad er en database'.
Her vil jeg forholde mig til den definition jeg fik dengang jeg arbejdede i
HP(start '80-erne), og var nogenlunde: "A database is a structured
collection of dataset's"
Altså en bred definition, som også kan dække over et sæt af filer i et
directory, og ikke nødvendigvis et givet produkt.

>> Både hastigheden, og det enkle 'look' betød enormt meget på mit 28.8K
>> dial-up.
>
> Der hjælper fraværet af af en masse reklamer-billeder jo vældigt på
> hastigheden.

Ja - URL blocking i min router er guld værd :)
Ikke bare reklamer, men også alle de sk*de javascript tracking ting (incl.
Google analytics), som qua deres opbygning ødelægger performance.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> wrote in
news:498c6a95$0$90272$14726298@news.sunsite.dk:

> Ikke bare reklamer, men også alle de sk*de javascript tracking ting
> (incl. Google analytics), som qua deres opbygning ødelægger
> performance.

Kan forstå du glæder dig til brugerbetaling indføres på alle interessante
hjemmeside? ;)

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

Henrik Stidsen wrote:

> Stig Johansen <wopr.dk@gmaill.com> wrote in
> news:498c6a95$0$90272$14726298@news.sunsite.dk:
>
>> Ikke bare reklamer, men også alle de sk*de javascript tracking ting
>> (incl. Google analytics), som qua deres opbygning ødelægger
>> performance.
>
> Kan forstå du glæder dig til brugerbetaling indføres på alle interessante
> hjemmeside? ;)

Nej, jeg ved godt at hvis man afliver reklamer, så afliver man
financieringen, men alt med måde.

Jeg tror alle har en 'smertetærskel', hvor reklamer bliver for belastende.
Billeder, tekster, osv, har jeg ikke noget imod, men jeg kan brække mig over
animerede reklamer, da de forstyrrer min læsning af (evt.) interessante
sider.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> wrote in
news:498c8bf8$0$90268$14726298@news.sunsite.dk:

>> Kan forstå du glæder dig til brugerbetaling indføres på alle
>> interessante hjemmeside? ;)

> Nej, jeg ved godt at hvis man afliver reklamer, så afliver man
> financieringen, men alt med måde.

Helt enig - reklamemarkedet er presset fordi der er så meget konkurrence om
kronerne og lige for tiden er køberne presset til at få så meget som muligt
ud af kronerne. Det giver lavere priser og dermed lavere indtjening til dem
der sælger reklamepladsen.

> Jeg tror alle har en 'smertetærskel', hvor reklamer bliver for
> belastende. Billeder, tekster, osv, har jeg ikke noget imod, men jeg
> kan brække mig over animerede reklamer, da de forstyrrer min læsning
> af (evt.) interessante sider.

Igen enig - reklamer skal ikke ødelægge sitet de er på. Det er en ting de
færreste aviser har lært, der er alt for mange reklamer på de fleste avis
sider.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

"John V." <nyhedsgrupper.sparm@loveletters.dk> writes:

> Hvad er den hurtigste database, som samtidig kan håndtere kolosale
> mængder data og anvendes online? Når man fx. ser på google er det
> jo hurtigt at finde et eller andet, noget tilsvarende findes det,
> eller er det kun de proffesionelle der har sådanne hjemmestrikkede
> systemer.

> Ikke fordi jeg vil lave en søgemaskine, dem er der masser af. Men
> det jeg har brug for, skal kunne håndtere mindst 3-4 millioner
> records og søgning skal gå lynhurtigt.

Definer lynhurtigt? 3-4 millioner records er på ingen måde kollosalt,
så det kunne være sjovt at vide hvilke forstillinger du har om
responstid, brugsmønster og antal samtidige brugere.

Wikipedia bruger mysql, og pt. er der 265 millioner records i en af
tabellerne bag den engelske version. Med en master og 3 eller 4
slaves, klarer den snildt en 1-2000 opslag i sekundet.

Så det er på ingen måde et spørgsmål om hvilket software du bruger,
men derimod hvor hardwaren der afgør det. Masser af hukommelse,
hurtige diske, og parallelisering af reads er de væsentlige parametre
at skrue på.

--
/Wegge

---

Anders Wegge Keller wrote:

> Definer lynhurtigt? 3-4 millioner records er på ingen måde kollosalt,

Enig, men der er mindst 2 slags lynhurtig - dem der er lynhurtige til
læsninger, og dem der er lynhurtige til transaktionshåndtering.

Derudover findes der findes lynhurtige databaser til keyed opslag, og andre
der er hurtige til generiske opslag.

Men OP skriver ikke hvad der menes med lynhurtig, ej heller behovet.

--
Med venlig hilsen
Stig Johansen

---

Anders Wegge Keller wrote:
> "John V." <nyhedsgrupper.sparm@loveletters.dk> writes:
>> Ikke fordi jeg vil lave en søgemaskine, dem er der masser af. Men
>> det jeg har brug for, skal kunne håndtere mindst 3-4 millioner
>> records og søgning skal gå lynhurtigt.
>
> Definer lynhurtigt? 3-4 millioner records er på ingen måde kollosalt,
> så det kunne være sjovt at vide hvilke forstillinger du har om
> responstid, brugsmønster og antal samtidige brugere.
>
> Wikipedia bruger mysql, og pt. er der 265 millioner records i en af
> tabellerne bag den engelske version. Med en master og 3 eller 4
> slaves, klarer den snildt en 1-2000 opslag i sekundet.
>
> Så det er på ingen måde et spørgsmål om hvilket software du bruger,
> men derimod hvor hardwaren der afgør det. Masser af hukommelse,
> hurtige diske, og parallelisering af reads er de væsentlige parametre
> at skrue på.

Softwaren betyder nu også lidt. Locking mekanismer, query optmizer,
caching politik etc..

Arne

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Anders Wegge Keller wrote:
>
>> Definer lynhurtigt? 3-4 millioner records er på ingen måde kollosalt,

> Enig, men der er mindst 2 slags lynhurtig - dem der er lynhurtige
> til læsninger, og dem der er lynhurtige til transaktionshåndtering.

Det var det spørgsmål der lå i det næste spørgsmål omkring
brugsmønster. Der er en verden til forskel på om man skriver få gange
og læser mange, eller det omvendte.

> Derudover findes der findes lynhurtige databaser til keyed opslag,
> og andre der er hurtige til generiske opslag.

3-4 millioner records uden en nøgle? Det lyder ikke som et helt
optimalt design.

--
/Wegge

---

Anders Wegge Keller wrote:

> Stig Johansen <wopr.dk@gmaill.com> writes:
>
>> Derudover findes der findes lynhurtige databaser til keyed opslag,
>> og andre der er hurtige til generiske opslag.
>
> 3-4 millioner records uden en nøgle? Det lyder ikke som et helt
> optimalt design.

Beklager hvis jeg bruger forkerte ord.
Image, som jeg har lavet en del til på større HP grej, har hashingen
liggende sammen med recorden, og kræver derfor typisk kun eet diskopslag
for at finde en given nøgle.

Med generiske nøgler mener jeg b-tree's, som typisk kræver 4 diskopslag, men
til gængæld kan man lave partielle søgninger.

Men som vi nok er enige om, så nævner OP ikke noget om i hvilken hensigt der
menes 'hurtigt'.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Anders Wegge Keller wrote:
>
>> Stig Johansen <wopr.dk@gmaill.com> writes:
>>
>>> Derudover findes der findes lynhurtige databaser til keyed opslag,
>>> og andre der er hurtige til generiske opslag.
>>
>> 3-4 millioner records uden en nøgle? Det lyder ikke som et helt
>> optimalt design.
>
> Beklager hvis jeg bruger forkerte ord.

Jeg er ikke DBA, så det kan også være at jeg ikke kender de tekniske
termer.

> Image, som jeg har lavet en del til på større HP grej, har hashingen
> liggende sammen med recorden, og kræver derfor typisk kun eet
> diskopslag for at finde en given nøgle.

> Med generiske nøgler mener jeg b-tree's, som typisk kræver 4
> diskopslag, men til gængæld kan man lave partielle søgninger.

OK, så blev jeg også klogere i dag :)

--
/Wegge

---

John V. wrote:
> Når man fx. ser på google er det jo hurtigt at finde et eller andet,
> noget tilsvarende findes det, eller er det kun de proffesionelle der har
> sådanne hjemmestrikkede systemer.

Googles søgemaskine er "hjemmestrikket", og bygger bl.a. på BigTable-
teknologi:
http://en.wikipedia.org/wiki/Bigtable
BigTable er ikke, hvad man normalt forstår ved en database. (En database
forstås nok oftest som et relationelt databasesystem.)

Som andre har nævnt, har du med de nævnte datamængder talrige gratis (og
nogle sågar open source) valgmuligheder. Men når det gælder Oracle's
gratis-DBMS, synes det at Oracle ikke rigtig udsender fixes til den,
hvilket jeg finder bekymrende. Oracle's gratis-database er vist den
eneste hvor dette er tilfældet.

Når du nævner google, er det så fordi du ønsker fuldtekst-indeksering? -
Altså effektiv søgning efter ord i større tekst-mængder, ordnet efter
match-"styrke"?
Hvis det er tilfældet, er vil det indsnævre valgmulighederne lidt. Fx
kunne jeg forestille mig, at én eller flere af gratis-udgaverne fra The
Big Three (Oracle, IBM, Microsoft) ikke nødvendigvis indeholder
fuldtekstindeksering.

--
Troels

---

Troels Arvin wrote:
> Når du nævner google, er det så fordi du ønsker fuldtekst-indeksering? -
> Altså effektiv søgning efter ord i større tekst-mængder, ordnet efter
> match-"styrke"?
> Hvis det er tilfældet, er vil det indsnævre valgmulighederne lidt. Fx
> kunne jeg forestille mig, at én eller flere af gratis-udgaverne fra The
> Big Three (Oracle, IBM, Microsoft) ikke nødvendigvis indeholder
> fuldtekstindeksering.

MS SQLServer Express har i Advanced
(http://msdn.microsoft.com/en-us/library/cc645993.aspx)
Oracle XE har
(http://www.oracle.com/technology/pub/articles/asplund-textsearch.html)
IBM DB2 Express-C har
(http://www.ibm.com/developerworks/data/library/techarticle/dm-0812chong/)

Arne

---

"Troels Arvin" <troels@arvin.dk> skrev i en meddelelse
news:gmfmns$bvp$1@news.net.uni-c.dk...
> John V. wrote:
>> Når man fx. ser på google er det jo hurtigt at finde et eller andet,
>> noget tilsvarende findes det, eller er det kun de proffesionelle der har
>> sådanne hjemmestrikkede systemer.
>
> Googles søgemaskine er "hjemmestrikket", og bygger bl.a. på BigTable-
> teknologi:
> http://en.wikipedia.org/wiki/Bigtable
> BigTable er ikke, hvad man normalt forstår ved en database. (En database
> forstås nok oftest som et relationelt databasesystem.)
>
> Som andre har nævnt, har du med de nævnte datamængder talrige gratis (og
> nogle sågar open source) valgmuligheder. Men når det gælder Oracle's
> gratis-DBMS, synes det at Oracle ikke rigtig udsender fixes til den,
> hvilket jeg finder bekymrende. Oracle's gratis-database er vist den
> eneste hvor dette er tilfældet.
>
> Når du nævner google, er det så fordi du ønsker fuldtekst-indeksering? -
> Altså effektiv søgning efter ord i større tekst-mængder, ordnet efter
> match-"styrke"?
> Hvis det er tilfældet, er vil det indsnævre valgmulighederne lidt. Fx
> kunne jeg forestille mig, at én eller flere af gratis-udgaverne fra The
> Big Three (Oracle, IBM, Microsoft) ikke nødvendigvis indeholder
> fuldtekstindeksering.

Ja, jeg foretiller mig både en delvis indexeret (på nogle records) og en
fuldtekst søgning på andre.
Finder jeg ikke noget anvendeligt, må jeg jo ned i programmerings kassen og
lave noget selv, men jeg er ikke meget for at opfinde den dybe tallerken
igen.

MVH John

>
> --
> Troels

---

John V. wrote:

> "Troels Arvin" <troels@arvin.dk> skrev i en meddelelse
> news:gmfmns$bvp$1@news.net.uni-c.dk...
>> Når du nævner google, er det så fordi du ønsker fuldtekst-indeksering? -
>> Altså effektiv søgning efter ord i større tekst-mængder, ordnet efter
>> match-"styrke"?
>> Hvis det er tilfældet, er vil det indsnævre valgmulighederne lidt. Fx
>> kunne jeg forestille mig, at én eller flere af gratis-udgaverne fra The
>> Big Three (Oracle, IBM, Microsoft) ikke nødvendigvis indeholder
>> fuldtekstindeksering.
>
> Ja, jeg foretiller mig både en delvis indexeret (på nogle records) og en
> fuldtekst søgning på andre.
> Finder jeg ikke noget anvendeligt, må jeg jo ned i programmerings kassen
> og lave noget selv, men jeg er ikke meget for at opfinde den dybe
> tallerken igen.

Undskyld hvis jeg er nysgerrig, men hvad er det egentlig du vil ?
Du startede med at skrive:
> Ikke fordi jeg vil lave en søgemaskine, dem er der masser af.

--
Med venlig hilsen
Stig Johansen

---

"Stig Johansen" <wopr.dk@gmaill.com> skrev i en meddelelse
news:498c6b4c$0$90272$14726298@news.sunsite.dk...
> John V. wrote:
>
>> "Troels Arvin" <troels@arvin.dk> skrev i en meddelelse
>> news:gmfmns$bvp$1@news.net.uni-c.dk...
>>> Når du nævner google, er det så fordi du ønsker fuldtekst-indeksering? -
>>> Altså effektiv søgning efter ord i større tekst-mængder, ordnet efter
>>> match-"styrke"?
>>> Hvis det er tilfældet, er vil det indsnævre valgmulighederne lidt. Fx
>>> kunne jeg forestille mig, at én eller flere af gratis-udgaverne fra The
>>> Big Three (Oracle, IBM, Microsoft) ikke nødvendigvis indeholder
>>> fuldtekstindeksering.
>>
>> Ja, jeg foretiller mig både en delvis indexeret (på nogle records) og en
>> fuldtekst søgning på andre.
>> Finder jeg ikke noget anvendeligt, må jeg jo ned i programmerings kassen
>> og lave noget selv, men jeg er ikke meget for at opfinde den dybe
>> tallerken igen.
>
> Undskyld hvis jeg er nysgerrig, men hvad er det egentlig du vil ?
> Du startede med at skrive:
>> Ikke fordi jeg vil lave en søgemaskine, dem er der masser af.
>
> --
> Med venlig hilsen
> Stig Johansen

Jeg vil selvfølgelig ikke fortælle dig hvad det er jeg vil lave, så havde
jeg gjort det allerede fra starten i første indlæg..

Men jeg kan fortælle dig at beslutningen nu er at jeg selv programmere hele
databasen fra bunden af, godt nok kommer det til at tage væsentligt meget
længere tid, men så kender jeg også det hele til bunds og kan optimere til
det særlige formål jeg skal bruge det til, samt til den hardware jeg har
tænkt mig at anvende.
Softwaren vil aldrig blive sat til salg, og kommer heller ikke til at egne
sig til salg da det vil være lavet til ét særligt formål, til gengæld kan
det jo så optimeres meget mere.

John

---

"Troels Arvin" <troels@arvin.dk> skrev i en meddelelse
news:gmfmns$bvp$1@news.net.uni-c.dk...
> John V. wrote:
>> Når man fx. ser på google er det jo hurtigt at finde et eller andet,
>> noget tilsvarende findes det, eller er det kun de proffesionelle der har
>> sådanne hjemmestrikkede systemer.
>
> Googles søgemaskine er "hjemmestrikket", og bygger bl.a. på BigTable-
> teknologi:
> http://en.wikipedia.org/wiki/Bigtable
> BigTable er ikke, hvad man normalt forstår ved en database. (En database
> forstås nok oftest som et relationelt databasesystem.)
>
> Som andre har nævnt, har du med de nævnte datamængder talrige gratis (og
> nogle sågar open source) valgmuligheder. Men når det gælder Oracle's
> gratis-DBMS, synes det at Oracle ikke rigtig udsender fixes til den,
> hvilket jeg finder bekymrende. Oracle's gratis-database er vist den
> eneste hvor dette er tilfældet.
>
> Når du nævner google, er det så fordi du ønsker fuldtekst-indeksering? -
Ja jeg får brug for fuldtekst indexering, men som jeg skriver i et senere
indlæg, agter jeg nu selv at programmere det hele incl. diverse
sikkerhedsfunktioner.

John

> Altså effektiv søgning efter ord i større tekst-mængder, ordnet efter
> match-"styrke"?
Det skal ikke være ordnet efter match-styrke.

John

> Hvis det er tilfældet, er vil det indsnævre valgmulighederne lidt. Fx
> kunne jeg forestille mig, at én eller flere af gratis-udgaverne fra The
> Big Three (Oracle, IBM, Microsoft) ikke nødvendigvis indeholder
> fuldtekstindeksering.
>
> --
> Troels

---

Arne Vajhøj <arne@vajhoej.dk> writes:

> Anders Wegge Keller wrote:

>> Så det er på ingen måde et spørgsmål om hvilket software du bruger,
>> men derimod hvor hardwaren der afgør det. Masser af hukommelse,
>> hurtige diske, og parallelisering af reads er de væsentlige parametre
>> at skrue på.

> Softwaren betyder nu også lidt. Locking mekanismer, query optmizer,
> caching politik etc..

Selv den bedste software fejler på underspeccet hardware. Det nytter
ikke noget at kunne optimere 10% a opslagene væk, hvis hardwaren kun
kan følge med til 50%, og caching uden hukommelse er heller ikke
synderligt virkningsfuldt.

--
/Wegge

---

Lars Kongshøj <lars_kongshoj@hotmail.com> writes:

> Anders Wegge Keller skrev:
>> Selv den bedste software fejler på underspeccet hardware.

> Underdimensioneret hardware får sjældent software, der skal finde et
> specifikt resultat til at fejle, det går bare langsommere. Man har
> selvfølgelig et problem, hvis man løbende hælder flere forespørgsler
> ind, en systemet kan nå at besvare.

Hvilket lynhurtigt medfører en fejl, når querybufferen løber fuld, og
der er 1000 opslag der står og spænder ben for hinanden ... Som når
kunden af uransagelige årsager låner en GB hukommelse fra
backupmaskinen til et andet formål, og så ikke kan forstå at softwaren
ikke kan følge med, når de skifter til den. Den adfærd kan faktisk få
en MS-SQL til at gå så meget i sort, at det tager 10 minutter bare at
lukke servicen pænt ned.

>> Det nytter ikke noget at kunne optimere 10% a opslagene væk, hvis
>> hardwaren kun kan følge med til 50%

> Optimering af queries handler ikke om at skære en procentdel af
> resultaterne væk, men om at vælge en fornuftige strategi for
> fremsøgning af data, herunder især hvilke indekser, der skal bruges.

For opslag, læs: backend access.

--
/Wegge

---

Lars Kongshøj <lars_kongshoj@hotmail.com> writes:


>> ikke kan følge med, når de skifter til den. Den adfærd kan faktisk få
>> en MS-SQL til at gå så meget i sort, at det tager 10 minutter bare at
>> lukke servicen pænt ned.

> Her må fejlens årsag så konstateres at være placeret udenfor serveren.

Ja, det er et eksempel på hvad der sker med underdimensioneret
hardware.

>> For opslag, læs: backend access.

> Øh? Med query mener man normalt en SQL select-sætning, det er vel
> det du kalder backend access?

Nej, jeg mener læsninger fra disk, cache, eller hvor det nu er indeks
og data befinder sig.

--
/Wegge

---

Stig Johansen <wopr.dk@gmaill.com> writes:

> Google analytics), som qua deres opbygning ødelægger performance.

Performance?

Jeg mener selv jeg har fundet en god løsning, som jeg bruger bla. på
wegge.dk Fortæl mig gerne hvad du mener der er forkert i den.

X-Fut til dk.edb.internet.webdesign.clientside

--
/Wegge

---

Anders Wegge Keller <wegge@wegge.dk> wrote in
news:87d4dvmoac.fsf@huddi.jernurt.dk:

>> Google analytics), som qua deres opbygning ødelægger performance.

> Performance?

Google Analytics har i perioder - i starten - ikke levet op til almindelige
svartider og pga. en dårlig vejledning blev koden til den sat ind i toppen
af de sider der brugte det. Når Google så svarede langsomt ventede
browseren med at hente resten af siden indtil Google havde svaret - og
dermed blev alle sider der brugte Google Analytics langsomme. Det var
specielt slemt når de slet ikke svarede og browseren skulle vente på
timeout.

Det problem er for længst løst - både hos Google og i deres vejledning, nu
anbefaler de at man sætter koden som det allersidste i HTML dokumentet, på
den måde vil et evt. delay ikke påvirke browseren.

Eller kort sagt: der er ikke performance problemer ved brugen af Google
Analytics hvis man bruger det korrekt.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

Henrik Stidsen wrote:

> Anders Wegge Keller <wegge@wegge.dk> wrote in
> news:87d4dvmoac.fsf@huddi.jernurt.dk:
>
>>> Google analytics), som qua deres opbygning ødelægger performance.
>
>> Performance?
>
> Google Analytics har i perioder - i starten - ikke levet op til
> almindelige svartider og pga. en dårlig vejledning blev koden til den sat
> ind i toppen af de sider der brugte det. Når Google så svarede langsomt
> ventede browseren med at hente resten af siden indtil Google havde svaret
> - og dermed blev alle sider der brugte Google Analytics langsomme. Det var
> specielt slemt når de slet ikke svarede og browseren skulle vente på
> timeout.

Det var lige præcis det jeg fik fnat af, og derfor spærrede for google
analytics.

> Det problem er for længst løst - både hos Google og i deres vejledning, nu
> anbefaler de at man sætter koden som det allersidste i HTML dokumentet, på
> den måde vil et evt. delay ikke påvirke browseren.

Så længe det er en del af <body>, og dermed rendering, vil det stadig være
et problem.

> Eller kort sagt: der er ikke performance problemer ved brugen af Google
> Analytics hvis man bruger det korrekt.

Det vil nok være korrekt at lægge det i en onload event, så man får vist
siden, og så kan svartider være svartider mht. alle de der countere/stats
osv. men da jeg generelt disabler javascript pga. unødigt overforbrug, har
jeg ikke undersøgt om det faktisk er tilfældet.

For at præcisere, jeg har intet mod javascript, men overforbrug.
Overforbrug, der gør siden tung at danse med, er at skyde sig selv i
fødderne.

--
Med venlig hilsen
Stig Johansen

---

Stig Johansen <wopr.dk@gmaill.com> wrote in
news:498c91f5$0$90274$14726298@news.sunsite.dk:

> Det var lige præcis det jeg fik fnat af, og derfor spærrede for google
> analytics.

Som sagt er det kun et problem hvis den der har indsat koden på siden har
gjort det forkert.

>> Det problem er for længst løst - både hos Google og i deres
>> vejledning, nu anbefaler de at man sætter koden som det allersidste i
>> HTML dokumentet, på den måde vil et evt. delay ikke påvirke
>> browseren.

> Så længe det er en del af <body>, og dermed rendering, vil det stadig
> være et problem.

Kun hvis du får stress af at se på loadbaren måske kører lidt længere tid
end det tog at vise sidens indhold.

>> Eller kort sagt: der er ikke performance problemer ved brugen af
>> Google Analytics hvis man bruger det korrekt.

> Det vil nok være korrekt at lægge det i en onload event, så man får
> vist siden, og så kan svartider være svartider mht. alle de der
> countere/stats osv. men da jeg generelt disabler javascript pga.
> unødigt overforbrug, har jeg ikke undersøgt om det faktisk er
> tilfældet.

Det har intet at gøre med de performanceproblemer Google Analytics havde i
starten. De handlede om svartid på at hente scriptet fra serveren.

> For at præcisere, jeg har intet mod javascript, men overforbrug.
> Overforbrug, der gør siden tung at danse med, er at skyde sig selv i
> fødderne.

Kun hvis det er lavet forkert - eller man har en computer der burde være
pensioneret for mange mange år siden.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

"Henrik Stidsen" <inbox@henrikstidsen.dk> skrev

> Det problem er for længst løst - både hos Google og i deres vejledning, nu
> anbefaler de at man sætter koden som det allersidste i HTML dokumentet, på
> den måde vil et evt. delay ikke påvirke browseren.

Vil det så ikke bare betyde at browseren hænger når den når til bunden af
siden i stedet, såfremt Google svarer langsomt eller slet ikke svarer?

Jeg får i hvert fald stress når den lille process-ting der viser hvor langt
siden er med at blive indlæst, ikke gør sig færdig, så snart indholdet er
indlæst.

---

"Philip Nunnegaard" <nunnenospam@hitsurf.dk> wrote in
news:498c9680$0$56781$edfadb0f@dtext02.news.tele.dk:

>> Det problem er for længst løst - både hos Google og i deres
>> vejledning, nu anbefaler de at man sætter koden som det allersidste i
>> HTML dokumentet, på den måde vil et evt. delay ikke påvirke
>> browseren.

> Vil det så ikke bare betyde at browseren hænger når den når til bunden
> af siden i stedet, såfremt Google svarer langsomt eller slet ikke
> svarer?

Jo - så den vil hænge lidt fra siden er indlæst og vist HVIS Google
arbejder langsomt - men Google Analytics er ligeså hurtig som resten af
Google nu til dags.

--
Henrik Stidsen - http://henrikstidsen.dk/
http://fuglemarkedet.dk/ - Danmarks online fuglemarked!

---

Anders Wegge Keller wrote:

> Stig Johansen <wopr.dk@gmaill.com> writes:
>
>> Google analytics), som qua deres opbygning ødelægger performance.
>
> Performance?
>
> Jeg mener selv jeg har fundet en god løsning, som jeg bruger bla. på
> wegge.dk Fortæl mig gerne hvad du mener der er forkert i den.

Der er ikke noget galt med din løsning.
Men jeg vil tro, at langt de fleste klasker scriptet ind i <body>-delen, og
dermed belaste 'svartiden'.


--
Med venlig hilsen
Stig Johansen