nicht angemeldet
geeignetes System für riesige Datenmengen mit Index
0 
Struppi
0 0 0 0
geeignetes System für riesige Datenmengen mit Index
Schönen Tag
sicherlich gibt es nicht eine einzige und richtige Antwort auf die Frage. Doch was würdet ihr spontan antworten:
Welches DBMS eignet sich bei einem System, wo ausschließlich die SELECT-Geschwindigkeit im Vordergrund steht, Redundanz, Sicherheit, usw. sei alles nur zweitrangig. Bei der Datenmenge der relevanten Tabelle seien 5TB oder mehr anzunehmen. Die Tabelle verfügt über 2 unabhängige Indizes, wobei entweder anhand des einen oder anhand des zweiten Index' ein SELECT mit LIMIT 1 am Ende ausgeführt wird.
Es bestehen keine Verknüpfungen oder weitere Suchkriterien und das Ergebnis wird immer nur eine Zeile liefern.
Die einzelnen Datensätze würden bei MySQL nur Felder der Typen BOOL, INT, DOUBLE, VARCHAR(50) bestehen.
Die Frage ist etwas theoretisch, aber wer mit Datenmengen dieser Größenordnung erfahren ist, hat vielleicht eine Antwort parat, welche Datenbanksysteme sich hierfür eher eignen als andere.?
Betrieben werden sollte die DB letztendlich in einer Cloud, keinem Grid.
Bin schon gespannt...
-
sicherlich gibt es nicht eine einzige und richtige Antwort auf die Frage. Doch was würdet ihr spontan antworten:
http://de.wikipedia.org/wiki/NoSQL
Spontan, aber ohne jegliche Erfahrung auf dem Gebiet.
Struppi.
-
Hello,
Die einzelnen Datensätze würden bei MySQL nur Felder der Typen BOOL, INT, DOUBLE, VARCHAR(50) bestehen.
VarChar kostet Zeit, da dadurch die Satzlänge variant wird.
Wenn es um Geschwindigkeit geht, such Dir eine DBE aus, die ihre Tabellen direktgestreut oder zumindest mit fester Satzlänge anlegt. Zusätzlich kann man dann noch das ganze Kontrukt auf einer eigenen persistenten Speicherverwaltung montieren, die ebenfalls direktgestreut arbeitet.
Mehr ist mMn nicht rauszuholen.
Nachteile:
Ändert sich das Satzformat später, muss alles neu aufgebaut werden.
Platzverschwndung auf dem Datenträger ist i.d.R. sensationell hoch.Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
-
Hi,
wie hoch ist die Selektivität unter den Daten? Wie denormalisiert ist diese riesige Tabelle?
Ich würde vorschlagen: Ein Datenbanksystem mit "Datenpartitionierung" und ggf Optimierung für DataWarehousing, Read-Ahead usw.
Das ganze ist letztendlich noch abhängig davon wie oft und verteilt die Suchergebnisse sind. Was sind die Erwartungen an die Performance, wie lange dürfen die Suchergebnisse dauern?
Frank
-
Hi
wie hoch ist die Selektivität unter den Daten? Wie denormalisiert ist diese riesige Tabelle?
Falls sich diese Frage so beantworten lässt... Die zeitkritischen Anfragen werden alle dieser Art sein:
SELECT feld1,feld2,feld3 FROM bigtable WHERE ID=123 LIMIT 1
Also nur nach dem Index wird gesucht und immer nur 1 Treffer wird es geben.Das ganze ist letztendlich noch abhängig davon wie oft und verteilt die Suchergebnisse sind. Was sind die Erwartungen an die Performance, wie lange dürfen die Suchergebnisse dauern?
Da wüsste ich gerne, was denn realistisch wäre.
Erwünscht wäre, dass etwa 12k Anfragen pro Minute ausgeführt werden.Fjuri
-
Hallo,
hatte ich da nicht was von grosser Tabelle plus 2 Indizes gelesen? Also einer wäre quasi der Primäre Index (Primary Key)? Wozu brauchts dann noch einen?
Nun, meine Frage nach Selektivität der Daten und Ergebnisverteilung ging in folgende Richtung ..
5 TB = 5-000 GB = 5.000.000 MB = 5.000.000.000 kB = 5.000.000.000.000 Byte geteilt durch schätzungsweise 100 byte pro = 50.000.000.000 Records ...
Wie hoch ist die Wahrscheinlichkeit, dass bestimmte Bereiche der Id öfter abgefragt werden als andere. Z.b. es werden haupsächlich immer Records mit den "neuesten" Ids abgefragt etc ...
Vielleicht würde es dann Sinn machen, auf diese besonders hochfrequentierten Bereiche zu optimieren.
Wie ich dich verstanden habe, ist das Datenwachstum auch zu vernachlässigen. Richtig?
Was mich noch etwas Wunder nimmt, bei ca. 50 Mrd Records, wie kann man da mittels Id genau den gewünschten Datensatz erhalten? M.a.W. woher weiss der Benutzer, dass er genau ID=123 will? Woraus wird der Suchparameter ID bestimmt?
12.000 Anfragen pro Minute = 1200 aller 6 sekunden = 200 pro Sekunde mit jeweils 100 Byte an Rückgabedaten ... okay!
Was "realistisch" ist, hängt davon ab, wieviel du bereit bist zu investieren. Bottlenecks bei hoch frequentierten System sind (in eben dieser Reihenfolge)
- Netzwerk
- Disk
- CPU/Ram
Alle dieser 3 Bottlenecks kannst du durch entsprechende Hardware-Skalierung verkleinern aber nie völlig ausradieren.
Netzwerk -> der Server ist über mehrere Netzwerkadressen im gleichen oder mehreren Subnetzen parallel zu erreichen, ein NLB verteilt den Traffic gleichmässig.
Disk -> schnelle Disks im RAID Verbund, vorzugsweise RAID 10 / 101, also optimierung aufs Lesen oder SSDs (mit Datendurchsatz von ca. 1000MB/s) und viel Ram.
CPU/RAM -> viele CPUs/Cores und viel Ram in passender NUMA Konfiguration.
Gewisse Softwarefeatures des Datenbanksystems können da positiv wirken, eben Partitionierung wie bereits erwähnt. Es hängt aber eben nicht alles vom Datenbanksystem ab. Datenbanken von > 5TB in einer Cloud (public oder private?) zu betreiben, das dürfte aktuell ziemlich ins Geld gehen. Mit so all dem zugehörigen Zeugs zur Absicherung des Betriebs. Von 5TB kannst du nicht einfach mal schnell n Dump / Backup machen, nicht mal bei differentiellen Backups. Auf der Recoverseite genauso.
Cloud-DataWarehousing Systeme gibt es aktuell sehr stark gepusht von Microsoft (Stichwort Fasttrack DWH)
Wenn das Budget ausreichend gross ist, dann findest du sicherlich sehr schnell Interessenten in allen bedeutenden Lagern (Microsoft, Oracle, IBM).
Cheers, Frank
-
-
-
Hey,
http://code.google.com/apis/storage/
...falls du denen deine daten anvertrauen möchtest ;)Gruß,
Nick -
Hallo Fjuri,
ohne das genaue Umfeld zukennen macht es keinen Sinn einen konkreten Vorschlag zumachen.
Wie definierst Du zum Beispiel die SELECT-Geschwindigkeit genau?
Es gibt zuviele Möglichkeiten, was passen könnte.
Kay