---

Er der konsensus om hvad det hurtigste open-source-agtige databasesoftware
er, når det drejer sig om meget simple operationer. Dataintegritet / SQL-92
understøttelse er mindre vigtige i denne sammenhæng.

Målet er, at det skal kunne lave et komplet tablescan på en tabel med
omtrent en mio. rækker, på kortest muligt tid. Rene rambaserede løsninger
eller snedig indeksering er nok mest interesante.

/A

---

"Anders Johannsen" <anders@ignition.dk> wrote in message
news:9eb404$t88$1@news.inet.tele.dk...

Jeg har desværre ikke selv nogen bud, men blot nogle kommentarer hvordan du
får et fornuftigt bud

> Er der konsensus om hvad det hurtigste open-source-agtige databasesoftware
> er, når det drejer sig om meget simple operationer. Dataintegritet /
SQL-92
> understøttelse er mindre vigtige i denne sammenhæng.
>
Du kan ikke snakke om hurtighed uden i samme åndedrag at nævne krav til
hardware - de to ting hænger uløseligt sammen
Hvis pris på hardware er underordnet, så er der mange ting der kan lade sig
gøre
Hvad hardware skal systemet arbejde på?
Og hvilket OS? - Jeg går ud fra at du tænker på noget Linux?

> Målet er, at det skal kunne lave et komplet tablescan på en tabel med
> omtrent en mio. rækker, på kortest muligt tid. Rene rambaserede løsninger
> eller snedig indeksering er nok mest interesante.
>
Hastigheden afhænger af antallet af rækker der skal hentes, men så sandelig
også hvor brede rækkerne er (antal atributter eller felter om du vil)
Vil du hente en million rækker i et hug, eller er det dele af tabellen du
vil hente?

Når et RDBMS udfører en tablescan så er det netop fordi at den ikke kan/vil
bruge de indexes der er oprettet - så snedig indeksering giver ikke megen
mening i dette tilfælde

En rambaseret løsning kunne være fin, men igen mangler der oplysninger om
datamængden
Hvor meget fylder den mio rækker Mb/Gb/Tb?

mvh/Peter Lykkegaard

---

> Hvad hardware skal systemet arbejde på?
> Og hvilket OS? - Jeg går ud fra at du tænker på noget Linux?

Systemet kommer til arbejde på standard intelbaseret hardware med et *nix
som OS -- sandsynligvis Linux.

> Hastigheden afhænger af antallet af rækker der skal hentes, men så
sandelig
> også hvor brede rækkerne er (antal atributter eller felter om du vil)
> Vil du hente en million rækker i et hug, eller er det dele af tabellen du
> vil hente?

Tabellen er kun 5-6 felter 'bred' -- og det felt jeg ønsker at søge på er i
det højeste 250 tegn langt. Det jeg søger at opnå, er basalt nedenstående:

SELECT id, field FROM table WHERE field LIKE '%query%'

> En rambaseret løsning kunne være fin, men igen mangler der oplysninger om
> datamængden
> Hvor meget fylder den mio rækker Mb/Gb/Tb?

De testdata jeg har i øjeblikket fylder ca . 100 MB uden indexes.

/A

---

Anders Johannsen wrote:
>
> Tabellen er kun 5-6 felter 'bred' -- og det felt jeg ønsker at
> søge på er i det højeste 250 tegn langt. Det jeg søger at opnå,
> er basalt nedenstående:
>
> SELECT id, field FROM table WHERE field LIKE '%query%'

Det lugter lidt af en fritekstsøgning. Hvis det er det, hvorfor så ikke
bare lave et index, der kan klare det? Sagt på en anden måde: Hvis du
laver dine forspørgsler med hovedet under armen, så kan du få en hver
database i knæ.

--
Lauritz

---

> Det lugter lidt af en fritekstsøgning. Hvis det er det, hvorfor så ikke
> bare lave et index, der kan klare det?

De indexes jeg har brugt indtil videre, har enten ikke haft en gavnlig
virkning på søgetiden eller er ikke blevet brugt. Jeg er dog altid
interesseret i at blive oplyst.

field er i denne sammenhæng een lang streng.

/A

---

Anders Johannsen wrote:
>
> > Det lugter lidt af en fritekstsøgning. Hvis det er det, hvorfor så ikke
> > bare lave et index, der kan klare det?
>
> De indexes jeg har brugt indtil videre, har enten ikke haft en gavnlig
> virkning på søgetiden eller er ikke blevet brugt. Jeg er dog altid
> interesseret i at blive oplyst.
>
> field er i denne sammenhæng een lang streng.

Jo, men har du brug et almidelig index? De databaser jeg kender, kan
ikke bruge et almindeligt index ved venstretrunkeringer (eks. '%bla').
Hvis du vil lave fritekstsøgning, skal du bruge indexer, der er designet
til det. MS Sql-server, oracle m.f. har det indbygget og moduler findes
til postgress og mysql
(http://www.mysql.com/doc/M/y/MySQL_full-text_search.html). Hvis dine
data ikke kan opdeles i ord, kan du jo kigge på n-grammer.

--
Lauritz

---

>> field er i denne sammenhæng een lang streng.
>
> Jo, men har du brug et almidelig index? De databaser jeg kender, kan
> ikke bruge et almindeligt index ved venstretrunkeringer (eks. '%bla').

Jeg har primært forsøgt mig med fulltext-indexes.

> Hvis dine data ikke kan opdeles i ord, kan du jo kigge på n-grammer.

Det lyder interessant. Jeg er ikke bekendt med det, og google ved
tilsyneladende heller ikke noget om emnet?

/A

---

Anders Johannsen wrote:
>
> > Hvis dine data ikke kan opdeles i ord, kan du jo kigge på n-grammer.
>
> Det lyder interessant. Jeg er ikke bekendt med det, og google ved
> tilsyneladende heller ikke noget om emnet?

Det her er en artikel jeg engang faldt over:
http://www.heise.de/ct/english/97/04/386/
Men nu ved jeg jo intet om, hvad du prøver at gøre.
--
Lauritz

---

"Anders Johannsen" <anders@ignition.dk> wrote in message
news:9eb8pg$gdm$1@news.inet.tele.dk...
> > Det lugter lidt af en fritekstsøgning. Hvis det er det, hvorfor så ikke
> > bare lave et index, der kan klare det?
>
> De indexes jeg har brugt indtil videre, har enten ikke haft en gavnlig
> virkning på søgetiden eller er ikke blevet brugt. Jeg er dog altid
> interesseret i at blive oplyst.
>
Du nævner ikke noget om hvilket database produkt du har forsøgt dig med
Men konstellationer ala '%a%' vil altid resulterer i tablescan ved brug af
alm indexes

Du skal have gang i noget fulltext search implementering

mvh/Peter Lykkegaard

---

> Du nævner ikke noget om hvilket database produkt du har forsøgt dig med

Postgres og mysql er testet, men ingen er optimale.

> Men konstellationer ala '%a%' vil altid resulterer i tablescan ved brug
> af alm indexes

Ja ... det tænker jeg.

> Du skal have gang i noget fulltext search implementering

Jeg er ikke sikker. Det felt jeg søger på indeholder en lang streng,
og søgeordet er en evt. matchende delstreng (heraf '%query%').

Efter hvad jeg har erfaret, er der ikke nogen indekse der kan klare det,
hvorfor jeg bliver nødt til at traverse hele tabellen -- og er egentligt
på udkig efter den hurtigste måde at gøre dette på.

/A

---

"Anders Johannsen" <anders@ignition.dk> wrote in message
news:20010521.182012.496987743.501@ignition.dk...

> > Du skal have gang i noget fulltext search implementering
>
> Jeg er ikke sikker. Det felt jeg søger på indeholder en lang streng,
> og søgeordet er en evt. matchende delstreng (heraf '%query%').
>
MSSQL arbejder fint med fulltext søgninger, men det jo desværre ikke
opensource

mvh/Peter Lykkegaard

---

"Peter Lykkegaard" <polonline@hot.mail.com> wrote in <aKnO6.28$Zc4.582
@news.get2net.dk>:

>
>"Anders Johannsen" <anders@ignition.dk> wrote in message
>news:20010521.182012.496987743.501@ignition.dk...
>
>> > Du skal have gang i noget fulltext search implementering
>>
>> Jeg er ikke sikker. Det felt jeg søger på indeholder en lang streng,
>> og søgeordet er en evt. matchende delstreng (heraf '%query%').
>>
>MSSQL arbejder fint med fulltext søgninger, men det jo desværre ikke
>opensource
>

endsige gratis ...

--
I wrote to George W. Bush - you should do the same
- http://stocholm.dk/emailgeorgewbush.asp

Jesper Stocholm - http://stocholm.dk