---

Hejsa. Vi er ved at diskuttere en db struktur på en ny db som bygger på
gammel data.

Den mest optimale (design mæssigt) løsning er at lave en tabel med 1.5 mio
entries i. Nu har vi aldrig for prøvet at have så mange rows i en tabel. Så
vi vil høre om i har erfaringer med performance når på dette.

tabellen bruges blot ved Select * from tabel where X, y, z, så ikke noget
fancy union eller ligende.

Vil man med en en MS SQL 2000 server på en moderne PC kunne få repsonce
tiden ned på < 1 sek mon? Dette vil ca. være kravet. Der vil naturligvis
blive lavet index på X, y, z.

Ser frem til en vurdering. (Selv følgelig svært at udtale sig præcis om)

Anders

---

Anders Jacobsen skrev:

> tabellen bruges blot ved Select * from tabel where X, y, z, så
> ikke noget fancy union eller ligende.

Hvad er X, y og z?

Der er stor forskel på:

....WHERE x LIKE '%foo%' AND y IN (2,3,5,8,11) AND z LIKE '%bar'

og

....WHERE x = 42 AND y = 7 AND z = 'foo'


> Vil man med en en MS SQL 2000 server på en moderne PC kunne få
> repsonce tiden ned på < 1 sek mon?

Prøv det. Hvis I ikke har MSSQL (men overvejer at anskaffe den),
kan man hente en gratis prøveversion på Microsofts hjemmeside (det
kunne man i hvert fald tidligere).
--
Jens Gyldenkærne Clausen
Svar venligst under det du citerer, og citer kun det der er
nødvendigt for at forstå dit svar i sammenhængen. Se hvorfor og
hvordan på http://usenet.dk/netikette/citatteknik.html

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jens Gyldenkærne Clausen <jens@gyros.invalid> writes:

>> tabellen bruges blot ved Select * from tabel where X, y, z, så
>> ikke noget fancy union eller ligende.
>
> Hvad er X, y og z?
>
> Der er stor forskel på:
>
> ...WHERE x LIKE '%foo%' AND y IN (2,3,5,8,11) AND z LIKE '%bar'
>
> og
>
> ...WHERE x = 42 AND y = 7 AND z = 'foo'

Jeg mener, at MS SQL understøtter fuldtekstindeksering out-of-the-box,
så hvis foo og bar i dit eksempel er ord eller dele af ord, behøver
det ikke at betyde det helt store... hvis altså der bliver indekseret
ordenligt.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkHv8acACgkQYu1fMmOQldVXCwCeNdQlK5XmOxxf0SPkey2a0oNw
MhEAoJcpKl+uDflzri0ZSc/TnH9RfHAQ
=H/yS
-----END PGP SIGNATURE-----

---

> Jeg mener, at MS SQL understøtter fuldtekstindeksering out-of-the-box,
> så hvis foo og bar i dit eksempel er ord eller dele af ord, behøver
> det ikke at betyde det helt store... hvis altså der bliver indekseret
> ordenligt.

Ahh, det ville vel nok betyde en hel del - 1,5 million records, med lad os
sige i gennemsnit 10 ord i hver - det bliver alligevel et ret stort indeks
:)

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Casper Bang" <webmaster_fjerndette@fjerndette_secretsofwar.net> writes:

>> Jeg mener, at MS SQL understøtter fuldtekstindeksering
>> out-of-the-box, så hvis foo og bar i dit eksempel er ord eller dele
>> af ord, behøver det ikke at betyde det helt store... hvis altså der
>> bliver indekseret ordenligt.
>
> Ahh, det ville vel nok betyde en hel del - 1,5 million records, med
> lad os sige i gennemsnit 10 ord i hver - det bliver alligevel et ret
> stort indeks :)

10 unike ord? Der er vist nok kun omkring 150.000 ord i det danske
sprog (jeg ved ikke, hvor jeg har det tal fra). Tag et meget større
sprog som engelsk, og der vil stadig være langt under en million for
langt, langt de fleste anvendelser. Desuden behøver det ikke at være
et problem. Et indeks er jo trods alt en ordnet størrelse, så det
bliver nok sjældent nødvendigt at søge det hele igennem.

Mere avancerede fuldtekstindekser kan dele et indeks op i to dele: en
meget almindelige ord og en til mindre almindelige. Afhængigt af
hvordan indekset er lavet og/eller bliver brugt, kan du udskifte
'almindelige' med 'efterspurgte'. Det betyder, at man ofte kun skal
søge et lille indeks igennem, mens det store står i reserve. Om denne
type indeks er tilgængeligt i en hvermands-RDBMS som MS SQL, skal jeg
ikke kunne sige, men hvis det er kritisk for ens applikation, kan man
sikkert sagtens udvilke et selv. Den bagvedliggende teori er jo ikke
voldsomt kompliceret, og kan bygges oven på den type indeks, man nu
mener, passer bedst til formålet.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkHwG/MACgkQYu1fMmOQldVkpwCg6Ns7dTPwAkVlUcGK0vYiNSYO
QkMAoJKrwypSWsy29+GF2/W71o5wMGfl
=7SBK
-----END PGP SIGNATURE-----

---

>> Ahh, det ville vel nok betyde en hel del - 1,5 million records, med
>> lad os sige i gennemsnit 10 ord i hver - det bliver alligevel et ret
>> stort indeks :)
>
> 10 unike ord? Der er vist nok kun omkring 150.000 ord i det danske
> sprog (jeg ved ikke, hvor jeg har det tal fra). Tag et meget større
> sprog som engelsk, og der vil stadig være langt under en million for
> langt, langt de fleste anvendelser. Desuden behøver det ikke at være
> et problem. Et indeks er jo trods alt en ordnet størrelse, så det
> bliver nok sjældent nødvendigt at søge det hele igennem.

Min fejl, troede det indeks ville blive med "multiple keys" (kan ikke huske
det rigtige ord).
Hvis det er et unikt indeks vil det ikke være et problem - klart nok.

---

> Hvad er X, y og z?

Det er simple big intværdier. Intet andet. Så relativt simpel. Ingen LIKE
eller deslige.

Anders

---

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

"Anders Jacobsen" <none@nope.dk> writes:

> Den mest optimale (design mæssigt) løsning er at lave en tabel med
> 1.5 mio entries i. Nu har vi aldrig for prøvet at have så mange rows
> i en tabel. Så vi vil høre om i har erfaringer med performance når
> på dette.
[...]
> Vil man med en en MS SQL 2000 server på en moderne PC kunne få
> repsonce tiden ned på < 1 sek mon? Dette vil ca. være kravet. Der
> vil naturligvis blive lavet index på X, y, z.

Det afhænger selvfølgeligt af, om maskinen samtidigt laver andet, men
I _burde_, med fornuftig indeksering, kunne få den slags responstider.
Du kunne jo prøve at generere en tilpas stor TPC-H database til at
eksperimentere med, blot for at have noget at sammenligne med på jeres
egen maskine. Et værktøj til generering af sådanne databaser kan
findes fra http://www.tpc.org/tpch/default.asp.

Håber det hjælper.

Martin

- --
Homepage: http://www.cs.auc.dk/~factotum/
GPG public key: http://www.cs.auc.dk/~factotum/gpgkey.txt
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using Mailcrypt+GnuPG <http://www.gnupg.org>

iEYEARECAAYFAkHv3UsACgkQYu1fMmOQldVO9ACghcK6PrtXH6Pnt+C68pyWMs+u
Wo4AnjsyNHXLzsNwxXHqADibZx1BHZDK
=G+rp
-----END PGP SIGNATURE-----

---

Anders Jacobsen skrev:
> Den mest optimale (design mæssigt) løsning er at lave en tabel med 1.5 mio
> entries i...
> Vil man med en en MS SQL 2000 server på en moderne PC kunne få repsonce
> tiden ned på < 1 sek mon?

Jeg tror at langt de fleste databaser - næsten helt nede fra de mindste og
op til de største - vil kunne klare en response-tid (ikke "repsonce" på
mindre end 1 sekund for afvikling af en simpel forespørgsel med blot tre
enkle klare betingelser, som alle bruger et (eller flere) indeks(er)
optimalt. Det er der ingen ben i!

Det sjove kommer når man kigger på hvor ofte databasen skal gøre dette, hvor
mange opdateringer den skal foretage samtidig og hvor store datamængder den
skal returnere. Dér hvor de mindre databaser ofte kommer til kort, er når
der kommer mange brugere på systemet, og den lige pludselig får travlt med
at skulle servicere mange på samme tid, holde styr på opdateringer, låse,
halvfulde buffere osv. Hardware-valget og -konfigurationen kan også have en
markant indflydelse på hvor stor en grad af samtidighed databasen kan klare,
men måske kun have en lille indflydelse på svartiderne i et enkeltbruger
system.

-------
Tomas