Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte kom

Hallo!

Für ein mögliches Projekt brauche ich eine ungewöhnlich leistungsstarke DB
und möchte zuerst mal die Hardwarekosten abschätzen, die da auf mich
zukämen. Wie schon im Betreff geschrieben, umfasst die DB ca. 3 Mrd.
DB-Sätze. Jeder DB-Satz beinhaltet nur jeweils einen Eintrag, bestehend aus
jeweils 3 bis 15 Wörtern a 3 bis 15 Buchstaben (im Schnitt 10x10). Die DB
soll aus Performancegründen komplett im RAM gehalten werden. Es wird nur
gelesen, nicht geschrieben.

Frage: Wieviel RAM benötigte Das System bei Abfragen, in wievielen der
Datensätze z.B. das Wort x bzw. eine Phrase aus den beiden Worten "x y"
vorkommt? Wie sollte dieses System am besten aufgebaut werden? Wieviele
DB-Abfragen pro Sekunden sind damit realisierbar (Größenordnung)? Bin für
jeden Hinweis dankbar.

Viele Grüße
Marc

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

marc heiners schrieb:

> [...] umfasst die DB ca. 3 Mrd.
> DB-Sätze. Jeder DB-Satz beinhaltet nur jeweils einen Eintrag, bestehend aus
> jeweils 3 bis 15 Wörtern a 3 bis 15 Buchstaben (im Schnitt 10x10).

Im Schnitt also 100 Byte pro Datensatz, also 300 GB für die gesamte
Datenbank.

Aber wieso nur eine Spalte? Merkwürdiges Design.

> Die DB
> soll aus Performancegründen komplett im RAM gehalten werden.

Du willst 300 GB komplett im RAM halten? Sorry, aber dieses Anliegen
halte ich für ziemlich schwachsinnig. RAM ist richtig teuer und braucht
noch dazu richtig Strom. Außerdem dürfte die Suche nach Hardware, die
solche Riesenmengen ansteuern kann, ziemlich schwierig werden.

Performance erreichst Du außerdem eher durch ein vernünftiges
Datenbankdesign als durch überdimensioniertes RAM. Fehlende Qualität
durch Quantität ersetzen zu wollen, war noch nie der richtige Ansatz und
wird es auch nie sein.

Gruß. Claus

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte

> Im Schnitt also 100 Byte pro Datensatz, also 300 GB für die gesamte
> Datenbank.

Ja. Aber wie sieht es in Sachen Volltextsuche aus? Steigt der
DB-Speicherbedarf da nicht stark an?

> Du willst 300 GB komplett im RAM halten? Sorry, aber dieses Anliegen
> halte ich für ziemlich schwachsinnig.

Der Unterschied dürfte doch wohl in den Zugriffszeiten liegen, die beim RAM
um Dimensionen schneller sind als bei einer Festplatte. Ich glaube kaum,
dass man ein DB-Design nach oben offen optimieren kann. Wenn ich z.B. 30.000
DB-Abfragen/s benötige, wird es wohl kaum ohne RAM-Lösung gehen können.

> RAM ist richtig teuer und braucht
> noch dazu richtig Strom

Das wäre bei diesem Projekt sekundär. Auch einige TB RAM wären finanzierbar.

.. Außerdem dürfte die Suche nach Hardware, die
> solche Riesenmengen ansteuern kann, ziemlich schwierig werden.

Ja, das ist ein Punkt. Es wäre natürlich schöner, quasi eine RAM-"Einheit"
zu haben, statt das ganze auf einen ´zig-PC-Cluster zu verteilen. Weiß
jemand, ob es so eine Art "RAM-Strank" gibt?

>
> Performance erreichst Du außerdem eher durch ein vernünftiges
> Datenbankdesign als durch überdimensioniertes RAM. Fehlende Qualität
> durch Quantität ersetzen zu wollen, war noch nie der richtige Ansatz und
> wird es auch nie sein.

Das muß sich aber auch nicht zwangsläufig ausschliessen. ;-)

Gruß Marc

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

marc heiners wrote:

>> Im Schnitt also 100 Byte pro Datensatz, also 300 GB für die gesamte
>> Datenbank.
>
> Ja. Aber wie sieht es in Sachen Volltextsuche aus? Steigt der
> DB-Speicherbedarf da nicht stark an?

Klar, wenn du den gesamten Volltextindex im Speicher halten willst.

>> Du willst 300 GB komplett im RAM halten? Sorry, aber dieses Anliegen
>> halte ich für ziemlich schwachsinnig.
>
> Der Unterschied dürfte doch wohl in den Zugriffszeiten liegen, die beim
> RAM um Dimensionen schneller sind als bei einer Festplatte. Ich glaube
> kaum, dass man ein DB-Design nach oben offen optimieren kann. Wenn ich
> z.B. 30.000 DB-Abfragen/s benötige, wird es wohl kaum ohne RAM-Lösung
> gehen können.

Was soll das denn sein, wo 30000 Queries/s benötigt werden, vor allem,
wenn die Daten "nur gelesen, nicht geschrieben" werden.
Und warum kannst du die Daten dann nicht gleich ordentlich aufbereiten:
Mach aus einer Zeile mehrere und pack sie in eine spaltenbasierendes
DBMS, wie Sybase IQ.

>> RAM ist richtig teuer und braucht
>> noch dazu richtig Strom
>
> Das wäre bei diesem Projekt sekundär. Auch einige TB RAM wären
> finanzierbar.

Da du scheinbar mehrere Millionen für Hardware übrig hast, gehst du am
Besten zu IBM/HP o.ä. und fragst dort, die werden dir gerne behilflich
sein ;-)

>> Performance erreichst Du außerdem eher durch ein vernünftiges
>> Datenbankdesign als durch überdimensioniertes RAM. Fehlende Qualität
>> durch Quantität ersetzen zu wollen, war noch nie der richtige Ansatz und
>> wird es auch nie sein.
>
> Das muß sich aber auch nicht zwangsläufig ausschliessen. ;-)

Warum machen das eigentlich nicht Alle so, die große Datenbanken haben?
Das muss wohl einen Grund haben :-)

Dieter

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte

Hm. Mich dünkt, hier scheint eine gewisse Voreingenommenheit in der Luft zu
liegen...
Es geht um die statistische Auswertung genetischer Codes. Es geht nicht um
einen Webserver oder sonst was.
Daher das "merkwürdige" DB-Design und der Wunsch nach zig tausend
Abfragen/s. Mir ist auch nicht klar, warum ich Millionen Euro benötige, um
zwei TB RAM zu finanzieren.
War das mit den beiden bisherigen Antworten Zufall oder beschränkt sich
mySQL auf "normale" Anwendungebereiche? Dann wäre ich dankbar, wenn mir
jemand eine passendere NG nennen könnte.

Gruß Marc

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte

Okay sorry, das letzte Posting war vielleicht etwas schroff formuliert. Ich
würde vielleicht erst einmal genauso reagieren, wenn jemand mit zuerst
abstrus klingenden Performanceansprüchen ankommt. :-)

Gruß Marc


"marc heiners" schrieb im Newsbeitrag
news:f7ip9m$dhp$02$1@news.t-online.com...
> Hm. Mich dünkt, hier scheint eine gewisse Voreingenommenheit in der Luft
> zu liegen...
> Es geht um die statistische Auswertung genetischer Codes. Es geht nicht um
> einen Webserver oder sonst was.
> Daher das "merkwürdige" DB-Design und der Wunsch nach zig tausend
> Abfragen/s. Mir ist auch nicht klar, warum ich Millionen Euro benötige, um
> zwei TB RAM zu finanzieren.
> War das mit den beiden bisherigen Antworten Zufall oder beschränkt sich
> mySQL auf "normale" Anwendungebereiche? Dann wäre ich dankbar, wenn mir
> jemand eine passendere NG nennen könnte.
>
> Gruß Marc

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

marc heiners wrote:

> Hm. Mich dünkt, hier scheint eine gewisse Voreingenommenheit in der Luft
> zu liegen...
> Es geht um die statistische Auswertung genetischer Codes. Es geht nicht
> um einen Webserver oder sonst was.

Dann sag das doch.
Deshalb Milliarden Rows mit Worten: AAACGTT GCATT AAAGTCTA, wie
langweilig ;-)
Für Gendatenbanken wird man vermutlich keine "normalen" DBMSe nehmen.
Schau doch mal bei einschlägigen Webseiten der Genetikern, was die so
nehmen, die solltest du doch kennen.

> Daher das "merkwürdige" DB-Design und der Wunsch nach zig tausend
> Abfragen/s. Mir ist auch nicht klar, warum ich Millionen Euro benötige,
> um zwei TB RAM zu finanzieren.

Gerade waren es noch "einige" TB :-)
In den dicken Büchsen stecken mindestens 4GB ECC-Riegel und die kosten
um einiges mehr als "normales" RAM. Und außer Speicher brauchst du auch
noch die passenden Rechner.

Dieter

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte

> Für Gendatenbanken wird man vermutlich keine "normalen" DBMSe nehmen.
> Schau doch mal bei einschlägigen Webseiten der Genetikern, was die so
> nehmen, die solltest du doch kennen.

Jaaaa, ist schon richtig. Im Prinzip. Bei diesem Projekt geht es bei der
Analyse aber in eine andere Richtung. Es würde jetzt zu weit gehen, das zu
erklären. Die im erstenPosting beschriebene DB-Struktur ist schon (sehr
wahrscheinlich) die richtige.

>
>> Daher das "merkwürdige" DB-Design und der Wunsch nach zig tausend
>> Abfragen/s. Mir ist auch nicht klar, warum ich Millionen Euro benötige,
>> um zwei TB RAM zu finanzieren.
>
> Gerade waren es noch "einige" TB :-)

Ja. "zwei" sind (großzügig gesehen) "einige" ;-)

> In den dicken Büchsen stecken mindestens 4GB ECC-Riegel und die kosten um
> einiges mehr als "normales" RAM. Und außer Speicher brauchst du auch noch
> die passenden Rechner.

ECC-RAM ist hier nicht nötig. Es können ruhig Fehler auftreten. (ich weiß,
das klingt hart im Zusammenhang mit Genetik ;-) Es geht nur um statistische
Größenordnungen.

Gruß Marc

Re: Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

"marc heiners" wrote:

> Es geht um die statistische Auswertung genetischer Codes. Es geht nicht um
> einen Webserver oder sonst was.

Dann sind sowohl "SQL-Datenbank" als auch "Volltextsuche" die falschen
Stichwörter. "Worte" aus lediglich vier "Buchstaben" sind schon ein
gewisser Sonderfall.

> Daher das "merkwürdige" DB-Design und der Wunsch nach zig tausend
> Abfragen/s. Mir ist auch nicht klar, warum ich Millionen Euro benötige, um
> zwei TB RAM zu finanzieren.

Nur mal so als Größenvergleich. Eine Sunfire 15K ist ein richtig dicker
Rechner. Da bekommst du das nackte Gehäuse für ca. EUR 1 Mio. Im Voll-
ausbau dürftest du auch als guter Kunde so mit EUR 4 Mio dabei sein.

Und selbst da paßt nur gut ein gutes halbes TB RAM rein:
http://www.sun.com/servers/highend/sunfire15k/specs.xml

Oder HP Superdome: bis 1TB (aber nur 512GB pro Partition)
http://h18000.www1.hp.com/products/quickspecs/11721_div/1172 1_div.HTML

> War das mit den beiden bisherigen Antworten Zufall oder beschränkt sich
> mySQL auf "normale" Anwendungebereiche?

Naja, prinzipiell läuft MySQL auch auf dicken Hobeln. Vielleicht
möchtest du ja einen MySQL Cluster in ein paar Partitionen eines
Supercomputers betreiben?

> Dann wäre ich dankbar, wenn mir jemand eine passendere NG nennen könnte.

Genetiker sollten dir Tips geben können.


XL

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

marc heiners wrote:
> Hallo!
>
> Für ein mögliches Projekt brauche ich eine ungewöhnlich
> leistungsstarke DB und möchte zuerst mal die Hardwarekosten
> abschätzen, die da auf mich zukämen. Wie schon im Betreff
> geschrieben, umfasst die DB ca. 3 Mrd. DB-Sätze. Jeder DB-Satz
> beinhaltet nur jeweils einen Eintrag, bestehend aus jeweils 3 bis 15
> Wörtern a 3 bis 15 Buchstaben (im Schnitt 10x10). Die DB soll aus
> Performancegründen komplett im RAM gehalten werden. Es wird nur
> gelesen, nicht geschrieben.
>
> Frage: Wieviel RAM benötigte Das System bei Abfragen, in wievielen der
> Datensätze z.B. das Wort x bzw. eine Phrase aus den beiden Worten "x
> y" vorkommt? Wie sollte dieses System am besten aufgebaut werden?
> Wieviele DB-Abfragen pro Sekunden sind damit realisierbar
> (Größenordnung)? Bin für jeden Hinweis dankbar.
>
> Viele Grüße
> Marc

Hi,
irgendwie schwebt ja die Zahl 300 GB Ram im Raum. "Günstiger" kommst du doch
vielleicht mit ca. 10-15 Servern mit je 32 GB Ram klar und jeder Server hält
einen Teil der Daten. Vorgeschaltete Server haben die Infos welche Server
welche Daten enthalten und verteilen die Anfragen auf die entsprechenden
Server und führen Ergebnisse dann zusammen. Das Mysql Cluster braucht leider
horrenden Speicher, d.h. man baut sich lieber eine eigene Lösung. Also ich
würde da eher Intelligenz reinstecken als Millionen für eine fette Kiste.
Nach dem Google Prinzip eben => Google Bigtables

Christian

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

marc heiners schrieb:
>> Im Schnitt also 100 Byte pro Datensatz, also 300 GB für die gesamte
>> Datenbank.
>
> Ja. Aber wie sieht es in Sachen Volltextsuche aus? Steigt der
> DB-Speicherbedarf da nicht stark an?

Für Volltextsuchen nimmt man keine relationale Datenbank sondern Lucene
oder myDbSearcher[2]

[1]http://de.wikipedia.org/wiki/Lucene
http://lucene.apache.org/java
[2]http://www.stowasser.tv/mydbsearcher

>> Du willst 300 GB komplett im RAM halten? Sorry, aber dieses Anliegen
>> halte ich für ziemlich schwachsinnig.
>
> Der Unterschied dürfte doch wohl in den Zugriffszeiten liegen, die beim
> RAM um Dimensionen schneller sind als bei einer Festplatte. Ich glaube
> kaum, dass man ein DB-Design nach oben offen optimieren kann. Wenn ich
> z.B. 30.000 DB-Abfragen/s benötige, wird es wohl kaum ohne RAM-Lösung
> gehen können.

evtl hilft ein SSD[3] weiter um die mittlere zugriffszeit runter zu
kriegen. War heut auch n Artikel bei heise[4].

IBM 15.8GB 2.5" Solid State Drive = 399 Dollar.
20 Stück davon im SAN währen demnach nur knapp 8000 Dollar :-)
Brauchst nur ne SAN die 40 Platten ansprechen (wegen redundanz) kann.

Teil mal deine Erfahrungen damit mit, ich Spiel nämlich auch schon die
ganze Zeit mit dem Gedanken auf SSD zu wechseln.

[3]http://de.wikipedia.org/wiki/Solid_State_Disk
[4]http://www.heise.de/newsticker/meldung/92871

>> Performance erreichst Du außerdem eher durch ein vernünftiges
>> Datenbankdesign als durch überdimensioniertes RAM. Fehlende Qualität
>> durch Quantität ersetzen zu wollen, war noch nie der richtige Ansatz und
>> wird es auch nie sein.
>
> Das muß sich aber auch nicht zwangsläufig ausschliessen. ;-)

Schilder doch besser mal die Aufgabenstellung. Und lass mich dann was
vom Kuchen abhaben ;-)

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

Harald Stowasser wrote:
> marc heiners schrieb:

> Für Volltextsuchen nimmt man keine relationale Datenbank sondern Lucene
> oder myDbSearcher[2]

Im Prinzip ja. Aber eben nicht für DNS-Sequenzen.

> evtl hilft ein SSD[3] weiter um die mittlere zugriffszeit runter zu
> kriegen. War heut auch n Artikel bei heise[4].
>
> IBM 15.8GB 2.5" Solid State Drive = 399 Dollar.
> 20 Stück davon im SAN währen demnach nur knapp 8000 Dollar :-)
> Brauchst nur ne SAN die 40 Platten ansprechen (wegen redundanz) kann.

SAN + SSD ist IMHO rausgeschmissenes Geld. Gegen die Latenzzeiten hilft
schon die Tatsache, daß ein SAN den Traffic auf viele Spindeln verteilt.
Bei N Platten sinkt die mittlere Zugriffszeit auf ein N-tel der einer
einzelnen Platte. Bei 5ms und 100 Platten also 50µs. Da kommen wir
langsam an Zeiten von Frame-Latenzen. Ein 2KB Frame hat auf 1Gbps eine
Länge von 10*2K*1ns = 20µs.

> Teil mal deine Erfahrungen damit mit, ich Spiel nämlich auch schon die
> ganze Zeit mit dem Gedanken auf SSD zu wechseln.

Es könnte sicher was bringen, das REDO-Log da drauf zu legen. Aber
normal neige ich eher zu "Index im RAM und Daten auf fettem RAID".


XL

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

Harald Stowasser schrieb:

> 20 Stück davon im SAN währen demnach nur knapp 8000 Dollar :-)
> Brauchst nur ne SAN die 40 Platten ansprechen (wegen redundanz) kann.

21 Stück (RAID 5) tun's auch, so lange man nur liest und keine Platte
ausfällt.

Gruß. Claus

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

> Der Unterschied dürfte doch wohl in den Zugriffszeiten liegen, die beim
> RAM um Dimensionen schneller sind als bei einer Festplatte. Ich glaube
> kaum, dass man ein DB-Design nach oben offen optimieren kann. Wenn ich
> z.B. 30.000 DB-Abfragen/s benötige, wird es wohl kaum ohne RAM-Lösung
> gehen können.

Hm also 30000 Table-Scans auf 300GB, das macht ja
3*10^4*3*10^11=9*10^15 Bytes/Sekunde. Da son PC heutzutage etwa 9*10^9
Bytes/Sekunde schafft, brauchst Du größenordnungsmäßig 10^6 PCs. Aber
die einzelne Maschine braucht dann ja nicht so viel Ram - 512MB reichen
dicke (weniger kriegste ja kaum noch im Laden). Die einzelne Maschine
kriegst Du bestimmt für 400 Euro (gibt ja Mengenrabatt). Also könntest
du 400 Millionen Euro für PCs raushauen, dazu noch das Rechenzentrum
drumherum - oder doch lieber über Indizierung nachdenken?

Ciao

Tobi

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

On 17 Jul., 17:05, "marc heiners" wrote:
> Das wäre bei diesem Projekt sekundär. Auch einige TB RAM wären fina=
nzierbar.

Also wenn Geld keine Rolle spielt, würde ich doch bei den
einschlägigen Herstellern von Datenbanken die Consultants
konsultieren, anstatt hier in einer Newsgroup was zu suchen. Oder
wollt Ihr a la "SETI@home" per Trojaner einen Cluster-Betrieb
anwenden? ;-)

Gruß, Dirk

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

On 18 Jul., 20:36, Tobias Barth wrote:

> Hm also 30000 Table-Scans auf 300GB, das macht ja
> 3*10^4*3*10^11=3D9*10^15 Bytes/Sekunde. Da son PC heutzutage etwa 9*10^9
> Bytes/Sekunde schafft, brauchst Du größenordnungsmäßig 10^6 PCs. =
Aber
> die einzelne Maschine braucht dann ja nicht so viel Ram - 512MB reichen
> dicke (weniger kriegste ja kaum noch im Laden). Die einzelne Maschine
> kriegst Du bestimmt für 400 Euro (gibt ja Mengenrabatt). Also könntest
> du 400 Millionen Euro für PCs raushauen, dazu noch das Rechenzentrum
> drumherum - oder doch lieber über Indizierung nachdenken?

Danke, dass das noch mal jemand so schön vorgerechnet hat. Der OP
blieb ja bisher die Erklärung schuldig, was er da eigentlich vor hat.
In der Tat hört sich das aber schwer nach Indizierung an, mit ein
wenig Hirn kann man da einiges an Hardware sparen. Ein Beispiel für
die Indizierung von Genomsequenzen stellt zum Beispiel Blat (nicht
Blast) auf UCSC da (http://genome.ucsc.edu/). Damit spricht man auch
auf handelsüblichen PCs jede Stelle im Genom in Nullzeit an. Dahinter
steckt eine MySQL-Datenbank, ebenso wie bei vielen anderen grossen
Genomdatenbanken (z.B. http://www.ensembl.org/), die intern mit MySQL
arbeiten. Die Codes sind frei verfügbar... Aber schön, wer mit
Spezialisten zusammenarbeitet, bei denen Geld keine Rolle spielt,
warum dann über Optimierung nachdenken? ;-)

Ciao -- Boris

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

> Danke, dass das noch mal jemand so schön vorgerechnet hat. Der OP
> blieb ja bisher die Erklärung schuldig, was er da eigentlich vor hat.
> In der Tat hört sich das aber schwer nach Indizierung an, mit ein
> wenig Hirn kann man da einiges an Hardware sparen. Ein Beispiel für
> die Indizierung von Genomsequenzen stellt zum Beispiel Blat (nicht
> Blast) auf UCSC da (http://genome.ucsc.edu/). Damit spricht man auch
> auf handelsüblichen PCs jede Stelle im Genom in Nullzeit an. Dahinter
> steckt eine MySQL-Datenbank, ebenso wie bei vielen anderen grossen
> Genomdatenbanken (z.B. http://www.ensembl.org/), die intern mit MySQL
> arbeiten. Die Codes sind frei verfügbar... Aber schön, wer mit
> Spezialisten zusammenarbeitet, bei denen Geld keine Rolle spielt,
> warum dann über Optimierung nachdenken? ;-)

Ich hätte ja gesagt, wenns wirklich nur um die anfänglich genannte
Abfrage geht, könnte man ja jedes Wort bzw. Sequenz aus 2 Worten als
Schlüssel für eine Hashtable misbrauchen, deren Randdaten die Anzahl
angibt, wie oft das Wort bzw. die Sequenz auftritt. Dann bräuchte man
die Daten nur ein einziges Mal durchscannen, und der Speicherverbrauch
dürfte sich innerhalb weniger TB bewegen, wobei eben für jede Abfrage
nur noch ein Zugriff auf die Hashtable nötig wäre und nicht mehr auf
sämtliche Daten. Unter diesem Gesichtspunkt kann man immer noch
überlegen, ob man das ganz simpel auf Platten ablegt, oder es vielleicht
aufgeteilt auf ca. 40 PCs im Ram hält.

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

Axel Schwenke wrote:

> Es könnte sicher was bringen, das REDO-Log da drauf zu legen. Aber
> normal neige ich eher zu "Index im RAM und Daten auf fettem RAID".
>
Was bringt Dir ein Index auf eine Tabelle, die nur einen Feld hat?

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

Tobias Barth wrote:
> Also könntest
> du 400 Millionen Euro für PCs raushauen, dazu noch das Rechenzentrum
> drumherum - oder doch lieber über Indizierung nachdenken?
>
Eine Indizierung ist doch schon mehr oder wenig was er errichen will.
Die Datenbank hat nur einen Feld. Das Erstellen eines Indexes würde
genausoviel Rechenleistung in anspruch nehmen, wie seine statistische
Auswertung.

Laszlo

Re: Wieviel RAM für DB mit 3 Mrd. DB-Sätzen a 100 Byte komplett im RAM mit Volltextsuche

Lazlo Lebrun schrieb:
> Tobias Barth wrote:
>> Also könntest du 400 Millionen Euro für PCs raushauen, dazu noch das
>> Rechenzentrum drumherum - oder doch lieber über Indizierung nachdenken?
>>
> Eine Indizierung ist doch schon mehr oder wenig was er errichen will.
> Die Datenbank hat nur einen Feld. Das Erstellen eines Indexes würde
> genausoviel Rechenleistung in anspruch nehmen, wie seine statistische
> Auswertung.

Die Frage ist nur, ob er das einmal macht, oder 30000 mal pro Sekunde.