---

Hej!

Jeg skal for en kunde lave et system der skal indeholde rigtig mange data,
hertil skal selvfølgelig bruges en database...

Mit spørgsmål går så lidt på hvilken database jeg skal anvende, jeg ville
gerne bruge MySQL, men synes før jeg har været ude for at denne går ned ved
+2 mill. Rows.

Kravene til databasen er at den skal kunne indeholde minimum 12 mill. Rows
og meget gerne være linux baseret, opensource, og mulig at bruge fra php.

Opensource er selvfølgelig ikke et ufravigeligt krav, jeg høre også meget
gerne om kommercielle produkter

Kender nogen noget til databaser som f.eks. MySQL Pro og Max DB? Og ved om
dette evt. kan klare opgaven.

Jeg høre gerne om alle erfaringer

/Peter.

---

On Wed, 18 Aug 2004 14:47:52 +0200, Peter wrote:

> Jeg skal for en kunde lave et system der skal indeholde rigtig mange data,
> hertil skal selvfølgelig bruges en database...
>
> Mit spørgsmål går så lidt på hvilken database jeg skal anvende, jeg
> ville gerne bruge MySQL, men synes før jeg har været ude for at denne
> går ned ved +2 mill. Rows.

Sært. 2 millioner rækker burde ikke være noget større problem for de
almindeligt udbredte RDBMSer, heller ikke MySQL.

Hvis jeg var dig, ville jeg overveje PostgreSQL, ud over de produkter, du
allerede tænker på.

--
Greetings from Troels Arvin, Copenhagen, Denmark

---

On 18/08/04 14:56, in article pan.2004.08.18.12.56.21.953990@arvin.dk,
"Troels Arvin" <troels@arvin.dk> wrote:
> Sært. 2 millioner rækker burde ikke være noget større problem for de
> almindeligt udbredte RDBMSer, heller ikke MySQL.

Jeg ved ikke om det kan have noget med længden af rækkerne at gøre? Men den
gik i hvert fald kold, det skal nævnes at det var udgaven far Debian Stable,
så den er næppe helt ny, måske en nyere vil klare det bedre.

> Hvis jeg var dig, ville jeg overveje PostgreSQL, ud over de produkter, du
> allerede tænker på.

Jeg har tænkt på PostgreSQL, har du nogen erfaringer med denne i forbindelse
med meget store datamængder?

/Peter.

---

> > Sært. 2 millioner rækker burde ikke være noget større problem for de
> > almindeligt udbredte RDBMSer, heller ikke MySQL.
>
> Jeg ved ikke om det kan have noget med længden af rækkerne at gøre? Men
den
> gik i hvert fald kold, det skal nævnes at det var udgaven far Debian
Stable,
> så den er næppe helt ny, måske en nyere vil klare det bedre.

Er du sikker på at det ikke var dine indexes der var sat forkert op eller
lignende?
Hvad mener du egentligt med at den gik kold?

---

On 18/08/04 16:16, in article 412364cd$0$184$edfadb0f@dread11.news.tele.dk,
> Er du sikker på at det ikke var dine indexes der var sat forkert op eller
> lignende?
> Hvad mener du egentligt med at den gik kold?

Det var ikke mig der havde sat den op, men det var ulog (hvis nogen kender
det) det fyldte den til randen og så kom den med en eller anden
fejlmeddelelse som desværre ikke kan huske da det er ved at være et stykke
tid siden. Men pga. Det troede jeg faktisk at det var et generelt problem
med MySQL at den ikke kunne klare så meget data.

/Peter.

---

> Det var ikke mig der havde sat den op, men det var ulog (hvis nogen kender
> det) det fyldte den til randen og så kom den med en eller anden
> fejlmeddelelse som desværre ikke kan huske da det er ved at være et stykke
> tid siden. Men pga. Det troede jeg faktisk at det var et generelt problem
> med MySQL at den ikke kunne klare så meget data.

Jeg kender mest til Oracle og PostgreSQL, men jeg ved da, at der i
Oracles 32-bit version er en begrænsning på 2 giga for en data fil.

Dvs. man skal tilføje flere datafiler til sit tablespace for at kunne
komme ud over den sag.

Mon det er den grænse du er stødt ind i?

- Nikolaj

---

On 2004-08-18, Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:
>
>> Det var ikke mig der havde sat den op, men det var ulog (hvis nogen kender
>> det) det fyldte den til randen og så kom den med en eller anden
>> fejlmeddelelse som desværre ikke kan huske da det er ved at være et stykke
>> tid siden. Men pga. Det troede jeg faktisk at det var et generelt problem
>> med MySQL at den ikke kunne klare så meget data.
>
> Jeg kender mest til Oracle og PostgreSQL, men jeg ved da, at der i
> Oracles 32-bit version er en begrænsning på 2 giga for en data fil.

Aha - kan du uddybe dette, platforme/os? Ja, selvfølgelig har du
problemet, hvis OS'et ikke supporter større filer, men hvilket moderne
OS gør ikke det?

--
Andreas Plesner Jacobsen | Conceit causes more conversation than wit.
|    -- LaRouchefoucauld

---

> Aha - kan du uddybe dette, platforme/os? Ja, selvfølgelig har du
> problemet, hvis OS'et ikke supporter større filer, men hvilket moderne
> OS gør ikke det?

Ved oracle er det i v8 alle 32 bit OS systemer, der sætter en grænse ved
32-bit data filer. Jeg ved ikke om de har lavet det om i 9i og 10g, men
det kunne jeg faktisk ikke forestille mig.

Men som sagt så kan det løses ved flere datafiler per tablespace i
Oracle. Så problemet er til at overse.

På 64 bit systemer som på SPARC/Solaris er der ikke denne begræsning.

Jeg aner ikke om det har en effekt på mySql, det var bare en tanke at
det kunne det have.

Men teoretisk set kan ingen 32 bit systemer komme over 2 gigabyte
grænsen. Hvis de gør det, så laver systemet mere end en fil i baggrunden
for dig og præsenterer det som en.

Derfor er det også på høje tid, at WinXP/Server kommer i en 64 bit
version til folket. Specielt på server siden.

---

On 2004-08-18, Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:
>
>> Aha - kan du uddybe dette, platforme/os? Ja, selvfølgelig har du
>> problemet, hvis OS'et ikke supporter større filer, men hvilket moderne
>> OS gør ikke det?
>
> Ved oracle er det i v8 alle 32 bit OS systemer, der sætter en grænse ved
> 32-bit data filer. Jeg ved ikke om de har lavet det om i 9i og 10g, men
> det kunne jeg faktisk ikke forestille mig.

Iflg. Oracle's egen dokumentation er grænserne (Oracle 8.1.7, der er den
ældste dokumentation jeg kan finde på Tahiti):
blocksize: 2-32k
Database file size: "Operating system dependent. Limited by maximum
operating system file size; typically 2^22 or 4M blocks"

Med 2k blokke er vi allerede over de 2G ved Oracle's "typiske" maksimum
filstørrelse.
På min laptop, der lige nu kører Debian på en almindelig (32-bit) P4 har
jeg følgende fil:
-rw-r--r-- 1 apj apj 7057238016 Aug 16 19:53 test
Altså ingen problemer med filer over 2G på hverken mit operativsystem
eller mit filsystem.

> Men som sagt så kan det løses ved flere datafiler per tablespace i
> Oracle. Så problemet er til at overse.

Nej, ikke på databaser i de store størrelser, så løber du ind i knaphed
i fildescriptors i stedet.

> På 64 bit systemer som på SPARC/Solaris er der ikke denne begræsning.

Det er der heller ikke på 32 bit systemer, så længe operativ- og
filsystemet ikke introducerer denne begrænsning.

> Men teoretisk set kan ingen 32 bit systemer komme over 2 gigabyte
> grænsen. Hvis de gør det, så laver systemet mere end en fil i baggrunden
> for dig og præsenterer det som en.

Beklager, men: "sludder" - der er ingen problemer i at arbejde med
større filer på moderne operativsystemer.

--
Andreas Plesner Jacobsen | Win95 is not a virus; a virus does something.
| -- unknown source

---

>
>>Men teoretisk set kan ingen 32 bit systemer komme over 2 gigabyte
>>grænsen. Hvis de gør det, så laver systemet mere end en fil i baggrunden
>>for dig og præsenterer det som en.
>
>
> Beklager, men: "sludder" - der er ingen problemer i at arbejde med
> større filer på moderne operativsystemer.
>

Nej, det er ikke sludder, jeg skrev teoretisk. Prøv engang at regne dig
frem til, hvor store adresse områder / filområder du kan adressere med
32 bit.

Som jeg skrev så håndterer systemet, sikkert NTFS, at bide filen over i
2 gigabyte filer for dig.

---

On 2004-08-18, Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:
>>
>>>Men teoretisk set kan ingen 32 bit systemer komme over 2 gigabyte
>>>grænsen. Hvis de gør det, så laver systemet mere end en fil i baggrunden
>>>for dig og præsenterer det som en.
>>
>> Beklager, men: "sludder" - der er ingen problemer i at arbejde med
>> større filer på moderne operativsystemer.
>
> Nej, det er ikke sludder, jeg skrev teoretisk. Prøv engang at regne dig
> frem til, hvor store adresse områder / filområder du kan adressere med
> 32 bit.

Hvorfor mener du at man nødvendigvis kun kan adressere hvad der ligger i
et enkelt register?

> Som jeg skrev så håndterer systemet, sikkert NTFS, at bide filen over i
> 2 gigabyte filer for dig.

Jeg ved ikke hvordan NTFS håndterer det, men EXT2/EXT3, som jeg kører
her, og UFS/FFS er jeg ganske sikker på ikke bider noget over i mindre
filer, men blot jonglerer lidt med registrerne for at opnå samme
resultater som man nåede før i tiden med paging.
Det er jo ikke noget nyt at man kan adressere større områder end man har
bits til i et enkelt register, det var også sådan man gjorde i "gamle"
dage, for at adressere de høje områder af RAM.

--
Andreas Plesner Jacobsen | The trouble with a kitten is that
| When it grows up, it's always a cat
|    -- Ogden Nash.

---

> Hvorfor mener du at man nødvendigvis kun kan adressere hvad der ligger i
> et enkelt register?

Ja, korrekt, men du taler stadig praksis og jeg stadig teori. Jeg ved
godt hvordan, det fungerer i linux. Der er en glimrende forklaring lige her:

http://www.linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html

I visse tilfælde kan det så få dig i uføre:

http://www.uwsg.iu.edu/hypermail/linux/kernel/9912.3/0009.html

Men som du kan se, så er der også her lavet fix fakserier i koden for
det kan lade sig gøre.

Hele humlen er, at de triks vil ikke være nødvendige i et 64 bit system.
Der er rigeligt med adresserings bredde til at nå adskillige terrabyte
uden alle disse ting.

---

On 2004-08-18, Nikolaj Hansen <barnabasdkSPAM@yahoo.dk> wrote:
>
>> Hvorfor mener du at man nødvendigvis kun kan adressere hvad der ligger i
>> et enkelt register?
>
> Ja, korrekt, men du taler stadig praksis og jeg stadig teori. Jeg ved
> godt hvordan, det fungerer i linux. Der er en glimrende forklaring lige her:
>
> http://www.linuxmafia.com/faq/VALinux-kb/2gb-filesize-limit.html

Der omtaler libc og kerner, der er over 3 år gamle?

> http://www.uwsg.iu.edu/hypermail/linux/kernel/9912.3/0009.html

Og en snart 5 år gammel artikel.
Ja, det kan jeg se, det er virkelig teori du taler, der er nemlig ingen
der i praksis bruger de gamle kerner længere.

> Men som du kan se, så er der også her lavet fix fakserier i koden for
> det kan lade sig gøre.

Og? Det var vel ikke det, der var emnet, oplægget var om det kunne eller
ikke kunne lade sig gøre at have datafiler større end 2GB i Oracle, og
svaret må være: Det kan sagtens lade sig gøre i alle supportede udgaver
af Oracle og også i nogle af de nu desupportede, så længe
operativsystemet kan klare det.

> Hele humlen er, at de triks vil ikke være nødvendige i et 64 bit system.
> Der er rigeligt med adresserings bredde til at nå adskillige terrabyte
> uden alle disse ting.

Og? Relevans?

--
Andreas Plesner Jacobsen | A day without sunshine is like night.

---

"Nikolaj Hansen" skrev

> Som jeg skrev så håndterer systemet, sikkert NTFS, at bide filen over i
> 2 gigabyte filer for dig.

Interessant
På min XP har jeg nogle > 10Gb filer liggende (Virtuelle diske)

- Peter

---

Peter <peter@invalid.invalif> wrote:

> On 18/08/04 14:56, in article pan.2004.08.18.12.56.21.953990@arvin.dk,
> "Troels Arvin" <troels@arvin.dk> wrote:

> > Hvis jeg var dig, ville jeg overveje PostgreSQL, ud over de produkter, du
> > allerede tænker på.

> Jeg har tænkt på PostgreSQL, har du nogen erfaringer med denne i forbindelse
> med meget store datamængder?

For mig at se er hovedproblemet med gratis databaser som PostgreSQL at
de mangler et udviklingsværktøj som SQL*Forms - til at udvikle
fornuftige brugergrænseflader med master-details.
--
Per Erik Rønne

---

> For mig at se er hovedproblemet med gratis databaser som PostgreSQL at
> de mangler et udviklingsværktøj som SQL*Forms - til at udvikle
> fornuftige brugergrænseflader med master-details.

Der er da både ODBC og JDBC drivers, det åbner op for:

- Microsoft værktøjer.
- Java værktøjer
- Borland værktøjer
- etc.

Så synes jeg nu nok man er dækket ret godt ind ang. værktøjer til sin
database.

- Nikolaj

---

On Wed, 18 Aug 2004 15:15:16 +0200, Peter <peter@invalid.invalif>
wrote:

>Jeg ved ikke om det kan have noget med længden af rækkerne at gøre? Men den
>gik i hvert fald kold, det skal nævnes at det var udgaven far Debian Stable,
>så den er næppe helt ny, måske en nyere vil klare det bedre.

Jeg sidder pt. og kigger på en MySQL 3.23 (dog ikke fra debian stable)
på en 2.4-kerne, ext3-filsystem.

Her har en enkelt tabel (MyISAM) en datafil på 15GB og en indexfil på
11GB. Der er over 300 mio. rækker i den, og ting virker stadigvæk. Så
at der er "meget" data i, behøver ikke at få ting til at gå i udu.


Dog, der er løbende mange inserts i den, så der blev skrællet
"unødvendige" indexes væk (hvilket ikke overraskende hjalp meget), og
applikationer, der laver inserts, blev ændret til at lave multiple-row
inserts med 100-200 rækker ad gangen (hvilket noget mere overraskende
ikke hjalp så meget). Der er tydeligvis et højt io-forbrug på
maskinen, hvorimod cpu'en keder sig lidt mere. Ideelt set bør tabellen
nok skiftes om til InnoDB, sådan som der foretages masser af inserts
og kun ret få selects.

--
- Peter Brodersen
php -r 'print floor(8.2-0.2);'
perl -le 'print 5-4.9;'

---

> applikationer, der laver inserts, blev ændret til at lave multiple-row
> inserts med 100-200 rækker ad gangen (hvilket noget mere overraskende

Hvordan gør man dét - multiple row inserts?

---

On Fri, 20 Aug 2004 10:23:26 +0200, "Joe Doe" <nowhere@invalid.xyz>
wrote:

>Hvordan gør man dét - multiple row inserts?

http://dev.mysql.com/doc/mysql/en/INSERT.html

Fx:

INSERT INTO tabelnavn (navn, postnr) VALUES
('Peter Brodersen', 2720), ('Ib Hansen', 8000), ('Jens Jensen', 9000),
('Søren Sørensen', 2640);

Dette indsætter fire rækker. Tjek dog dokumentationen, idet
uhensigtsmæssig brug kan lede til overraskelser, hvis ens værdier ikke
er i orden. Indsætter man en enkelt række, kan serveren brokke sig.
Her vælger den at køre alle igennem (for at være sikker på at alle
bliver behandlet, og ikke kun nogle af dem), hvilket - igen, hvis ens
værdier ikke er i orden - kan lede til uventede resultater.

Det skal ikke forveksles med en egentlig transaktion - men rent
hastighedsmæssigt er der god mening i at bulk-indsætte mange rækker i
én query.

--
- Peter Brodersen
php -r 'print floor(8.2-0.2);'
perl -le 'print 5-4.9;'

---

"Peter" == Peter <peter@invalid.invalif> writes:

> Hej!
> Jeg skal for en kunde lave et system der skal indeholde rigtig mange data,
> hertil skal selvfølgelig bruges en database...

> Mit spørgsmål går så lidt på hvilken database jeg skal anvende, jeg ville
> gerne bruge MySQL, men synes før jeg har været ude for at denne går ned ved
> +2 mill. Rows.

Tror du ikke det er et spørgsmål om performancetuning? Eller
eventuelt at normalisere databasen.

> Kravene til databasen er at den skal kunne indeholde minimum 12 mill. Rows
> og meget gerne være linux baseret, opensource, og mulig at bruge fra php.

Postgresql ville være det oplagte valg. Det er en meget stabil
platform. <http://www.postgresql.org>

--
/Wegge <http://outside.bakkelygaard.dk/~wegge/>
echo mail: !#^."<>"|tr "<> mail:" dk@wegge

---

On 18/08/04 17:03, in article m3hdr04hg7.fsf@obelix.wegge.dk, "Anders Wegge
Jakobsen" <wegge@bakkelygaard.dk> wrote:
> Tror du ikke det er et spørgsmål om performancetuning? Eller
> eventuelt at normalisere databasen.

Måske... Det var ikke mig der satte den op, men så vidt jeg lige husker
kunne der ikke normaliseres så voldsomt på den, det var en ulog database og
der var seriøst fart på inputtet, ca. 100 inserts i sekundet i primetime...
Ved ikke om det kan have noget at sige?

> Postgresql ville være det oplagte valg. Det er en meget stabil
> platform. <http://www.postgresql.org>

Ok, tror jeg vil smide den ind på en testserver og prøve at fylde den op med
50 mill. Rows eller lign, sådan for forsøgets skyld

Har nogen prøvet noget lign. altså så store datamængder i en database?
Normalt ville jeg dumpe indholdet en gang imellem, men det er der desværre
ikke mulighed for her, da skal kunne søges i det hele.

/Peter.

---

Peter wrote:

> Hej!

Hej.

> Jeg skal for en kunde lave et system der skal indeholde rigtig mange data,
> hertil skal selvfølgelig bruges en database...

Har kunden ikke en database i forvejen?

[snip 2 mill. rows..]

> Kender nogen noget til databaser som f.eks. MySQL Pro og Max DB? Og ved om
> dette evt. kan klare opgaven.

Jeg lavede, på et tidspunkt, noget overvågning og performancemeasurement for
en kunde, hvor resultaterne blev lagt i en SapDB (nu MaxDB). Der kom da en
del Mrows ud af det - uden problemer.

--
Med venlig hilsen
Stig Johansen

---

On 18/08/04 19:34, in article 4123937d$0$73939$14726298@news.sunsite.dk,
"Stig Johansen" <stig_johansen_it_at_=@hotmail.com> wrote:
> Jeg lavede, på et tidspunkt, noget overvågning og performancemeasurement for
> en kunde, hvor resultaterne blev lagt i en SapDB (nu MaxDB). Der kom da en
> del Mrows ud af det - uden problemer.

Jeg havde faktisk også tænkt lidt på MaxDB, men jeg fik dog lige løst til at
lave et lille forsøg her på min iBook så jeg har lavet et script der skal
indsætte 20 mill. Rækker med nogen data der minder lidt om det, nu stoppede
jeg den ved 3.2 mill. For jeg gider ik side ved den bærbare mere men
prøver at lade den løbe færdig i morgen og se hvad der sker...

Måske min dårlige erfaring fra tidligere havde helt andre årsager end
MySQL...

/Peter.

---

On 18/08/04 21:56, in article BD498128.2C1D%peter@invalid.invalif, "Peter" <
> Jeg havde faktisk også tænkt lidt på MaxDB, men jeg fik dog lige løst til at
> lave et lille forsøg her på min iBook så jeg har lavet et script der skal
> indsætte 20 mill. Rækker med nogen data der minder lidt om det, nu stoppede
> jeg den ved 3.2 mill. For jeg gider ik side ved den bærbare mere men
> prøver at lade den løbe færdig i morgen og se hvad der sker...

Jeg svarer lige på mit eget indlæg

Min test forløb fint med at sætte +12 mill. Rækker ind i en MySQL, så jeg er
nu overbevist om at min tidligere fejl må skyldes noget andet... Tror dog
jeg vil lave noget perfomence testing med bl.a. Postgre for at se hvad der
er bedst når der skal laves select's.

/Peter.

---

On Wed, 18 Aug 2004 14:47:52 +0200, Peter <peter@invalid.invalif>
wrote:

>Mit spørgsmål går så lidt på hvilken database jeg skal anvende, jeg ville
>gerne bruge MySQL, men synes før jeg har været ude for at denne går ned ved
>+2 mill. Rows.

Det har jeg ikke oplevet... Min pt. største MySQL tabel er på 69 mill.
rækker og jeg har mange andre tabeller på 20 mill.+ rækker.
Det fungerer uden problemer og hastigheden fejler heller intet.

Det er en alm. MySQL 4.0.20.

/Jesper