14
Eine echt große Datenbank
Hallo,
ich habe einige ziemlich große Textfiles mit Daten bekommen.
insgesamt handelt es sich hier um rund 6mrd Datensätze.
die sollen jetzt in eine MYSQL Datenbank.
Dazu hätte ich einige Fragen:
1. Wenn ich ein VARCHAR(255) verwende wird dann für jeden Datensatz auch der Speicherplatz für 255 Zeichen benötigt oder nur die tatsächliche Länge?
2. Wenn ich ein INT als feld verwende sind das glaube ich 4 byte (64bit system) das wird wohl in dem Moment belegt, wo eine 0 in dem Feld steht?
3. Gehen wir davon aus, in den Varchar feldern soll ein kurzer Text stehen. Außerdem soll sichergestellt werden, dass dieser unique ist. Welchen Index lege ich auf das Feld um Abfragen auf dieses Feld möglichst schnell zu gestalten?
4. Ich nehme an, die indizies brauchen auch Platz... wie muss ich das kalkulieren?
Danke für eure Antworten ;)
ich habe einige ziemlich große Textfiles mit Daten bekommen.
insgesamt handelt es sich hier um rund 6mrd Datensätze.
die sollen jetzt in eine MYSQL Datenbank.
Dazu hätte ich einige Fragen:
1. Wenn ich ein VARCHAR(255) verwende wird dann für jeden Datensatz auch der Speicherplatz für 255 Zeichen benötigt oder nur die tatsächliche Länge?
2. Wenn ich ein INT als feld verwende sind das glaube ich 4 byte (64bit system) das wird wohl in dem Moment belegt, wo eine 0 in dem Feld steht?
3. Gehen wir davon aus, in den Varchar feldern soll ein kurzer Text stehen. Außerdem soll sichergestellt werden, dass dieser unique ist. Welchen Index lege ich auf das Feld um Abfragen auf dieses Feld möglichst schnell zu gestalten?
4. Ich nehme an, die indizies brauchen auch Platz... wie muss ich das kalkulieren?
Danke für eure Antworten ;)
Share on Facebook
Share on Twitter
Share on Reddit
Share on LinkedinPlease also mark the comments that contributed to the solution of the article
Content-Key: 382321
Url: https://administrator.de/contentid/382321
Printed on: April 25, 2024 at 13:04 o'clock
14 Comments
Latest comment
hi
Varchar braucht das, was du darin speuicherst. nicht immer alles. Das wäre bei char so
Normaler Index macht nur Sinn, wenn du nach "= BEGRIFF" oder "LIKE BEGRIFF%" suchst. Sobald du"like %BEGRIFF%" machst, wirds hässlich, weil dann ein Full Table Scan anfällt. Und der frisst wirklich Zeit.also % VOR dem Suchbegriff immer vermeiden
Geh mal von ~10% der Tabelle aus
ich habe einige ziemlich große Textfiles mit Daten bekommen.
insgesamt handelt es sich hier um rund 6mrd Datensätze.
die sollen jetzt in eine MYSQL Datenbank.
Dazu hätte ich einige Fragen:
1. Wenn ich ein VARCHAR(255) verwende wird dann für jeden Datensatz auch der Speicherplatz für 255 Zeichen benötigt oder nur die tatsächliche Länge?
https://dev.mysql.com/doc/refman/8.0/en/char.htmlinsgesamt handelt es sich hier um rund 6mrd Datensätze.
die sollen jetzt in eine MYSQL Datenbank.
Dazu hätte ich einige Fragen:
1. Wenn ich ein VARCHAR(255) verwende wird dann für jeden Datensatz auch der Speicherplatz für 255 Zeichen benötigt oder nur die tatsächliche Länge?
Varchar braucht das, was du darin speuicherst. nicht immer alles. Das wäre bei char so
2. Wenn ich ein INT als feld verwende sind das glaube ich 4 byte (64bit system) das wird wohl in dem Moment belegt, wo eine 0 in dem Feld steht?
Ja. INT ist aber 32bit und deshalb 4 byte. Bigint ist 64Bit und damit 8 Byte3. Gehen wir davon aus, in den Varchar feldern soll ein kurzer Text stehen. Außerdem soll sichergestellt werden, dass dieser unique ist. Welchen Index lege ich auf das Feld um Abfragen auf dieses Feld möglichst schnell zu gestalten?
kommt auf die Abfrage an. Wenn du nach Worten suchst, dann FullText Index verwenden und entsprechend dein Query gestaltenNormaler Index macht nur Sinn, wenn du nach "= BEGRIFF" oder "LIKE BEGRIFF%" suchst. Sobald du"like %BEGRIFF%" machst, wirds hässlich, weil dann ein Full Table Scan anfällt. Und der frisst wirklich Zeit.also % VOR dem Suchbegriff immer vermeiden
4. Ich nehme an, die indizies brauchen auch Platz... wie muss ich das kalkulieren?
Uff ... das lässt sich nur schwer sagen. Da gibt es zig Variablen. Clustered und Nonclustered INdexe, Included Columns usw.Geh mal von ~10% der Tabelle aus
Das hängt jetzt von deinem Aufbau ab... Generell ist das aber jetzt nicht unbedingt was wo ne DB grosse Kopfschmerzen bekommt, es sei denn du willst stringvergleiche später machen.... Dafür gibt es dann bessere Wege.
1) Sprichst du von RAM oder HDD? Da die DB in einem eigenen Format speichert kannst du davon ausgehen das die komprimiert werden. Ka. ob man das abschalten kann.
2) Nein, auch bei 64-Bit-Systemen sind 64 Bit immer noch 8 Byte... Aber auch da kommt die Frage auf - RAM, CPU oder Festplatte? Denn nur weil in nem Register in der CPU irgendwo ein Wert rumdümpelt muss der nicht auf der HDD dieselbe grösse haben, da können noch andere Daten dranhängen (und werden für gewöhnlich auch)
3) Das ist unique - fertig... "Schnell" geht nen String-Vergleich nicht, dafür musst du dir schon was anderes machen. Einfaches Beispiel: Um Rauszufinden ob
Wort = Wort ist musst du min 4 Vergleiche machen:
W = W ?
o = o ?
r = r ?
t = t?
Möchte ich dagegen rausfinden ob
123456789 = 123456789 ist brauche ich genau eine Rechnung:
123456789 - 123456789 = 0 ?
Das ganze haue ich dir in einem CPU-Takt durch (die Rechnung, nich das umhergewerfe in Register usw. natürlich!)
Es liegt jetzt an dir das du dir überlegst wie du von String auf Int kommst und ob sich der Aufwand lohnt....
4) Auch das hängt von deiner DB ab.... Du kannst ja diverse Dinge da einstellen - wie möchtest du da eine allgemeine Aussage haben?
{quote}
CREATE UNIQUE INDEX employee_pk
ON employees (employee_id, subsidiary_id)
{/quote}
Wenn du jetzt also deinen Index aus den 2 Spalten machst dann wird das sicher ne andere konsequenz haben als wenn du einen Index aus 200 Spalten machst bei der jede einzelne noch dazu nen 4GB-Text-Blob enthält...
Von daher - deine Fragestellung lässt leider so ziemlich alles zu - von "Hausaufgabenhilfe.de" bis hin zu lustigen Datenbanken zum Textvergleich. Und ohne zu wissen was du genau willst ist die Antwort halt schwer...
1) Sprichst du von RAM oder HDD? Da die DB in einem eigenen Format speichert kannst du davon ausgehen das die komprimiert werden. Ka. ob man das abschalten kann.
2) Nein, auch bei 64-Bit-Systemen sind 64 Bit immer noch 8 Byte... Aber auch da kommt die Frage auf - RAM, CPU oder Festplatte? Denn nur weil in nem Register in der CPU irgendwo ein Wert rumdümpelt muss der nicht auf der HDD dieselbe grösse haben, da können noch andere Daten dranhängen (und werden für gewöhnlich auch)
3) Das ist unique - fertig... "Schnell" geht nen String-Vergleich nicht, dafür musst du dir schon was anderes machen. Einfaches Beispiel: Um Rauszufinden ob
Wort = Wort ist musst du min 4 Vergleiche machen:
W = W ?
o = o ?
r = r ?
t = t?
Möchte ich dagegen rausfinden ob
123456789 = 123456789 ist brauche ich genau eine Rechnung:
123456789 - 123456789 = 0 ?
Das ganze haue ich dir in einem CPU-Takt durch (die Rechnung, nich das umhergewerfe in Register usw. natürlich!)
Es liegt jetzt an dir das du dir überlegst wie du von String auf Int kommst und ob sich der Aufwand lohnt....
4) Auch das hängt von deiner DB ab.... Du kannst ja diverse Dinge da einstellen - wie möchtest du da eine allgemeine Aussage haben?
{quote}
CREATE UNIQUE INDEX employee_pk
ON employees (employee_id, subsidiary_id)
{/quote}
Wenn du jetzt also deinen Index aus den 2 Spalten machst dann wird das sicher ne andere konsequenz haben als wenn du einen Index aus 200 Spalten machst bei der jede einzelne noch dazu nen 4GB-Text-Blob enthält...
Von daher - deine Fragestellung lässt leider so ziemlich alles zu - von "Hausaufgabenhilfe.de" bis hin zu lustigen Datenbanken zum Textvergleich. Und ohne zu wissen was du genau willst ist die Antwort halt schwer...
Eigentlich lautet die Abfrage nur Select * From table WHERE ts = 0 LIMIT X
Hallo,
6 Milliarden Datensätze?
Gruß,
Peter
6 Milliarden Datensätze?
die sollen jetzt in eine MYSQL Datenbank.
Der Aufbau und die importroutine stehet schon?Dazu hätte ich einige Fragen:
https://www.homeconstructor.net/de/mysql-datentypen4. Ich nehme an, die indizies brauchen auch Platz... wie muss ich das kalkulieren?
Klar, aber es hängt davon was und wie du die baust. Wenn der MySQL Rechner genug RAM hat, kann er das gar im RAM abfrühstücken...Gruß,
Peter
wenn so deine Abfragen lauten, dann sollte das mit 6 Milliarden gut gehen. Ich verwalte Datenbanken, die haben jeweils rund 600GB Daten, eine davon auch mit 3 Milliarden Zeilen in einer Tabelle. Ab einer gewissen Größe macht das kaum Unterschied, ob 100 Millionen, 3 Milliarden oder 6 Milliarden.
Grundsätzlich ist es hilfreich zu testen und vor allem die MySQL-Variebeln zu optimieren. Die Standardwerte sind für die Katz. Verwende Indexe sparsam und auch nur, wo du es wirklich brauchst, dann sparst du Fesplattenspeicher.
Ich vermute mal, deine Fragen zielen darauf ab, was für einen Server du brauchst. Pack einfach mal 1000 Zeilen in eine Datenbank, schau dir die Größe an, rechne das mal 6 Millionen, rechne noch mal ein paar GB oben drauf sowie noch Puffer und du hast deine Festplatten-Größe. SSD ist dabei aber meine Empfehlung. Abhängig davon wofür du das wie brauchst, solltest du entsprechend RAM reinpacken, sodass die meisten Daten im RAM liegen statt immer wieder von der Festplatte geholt zu werden.
Grundsätzlich ist es hilfreich zu testen und vor allem die MySQL-Variebeln zu optimieren. Die Standardwerte sind für die Katz. Verwende Indexe sparsam und auch nur, wo du es wirklich brauchst, dann sparst du Fesplattenspeicher.
Ich vermute mal, deine Fragen zielen darauf ab, was für einen Server du brauchst. Pack einfach mal 1000 Zeilen in eine Datenbank, schau dir die Größe an, rechne das mal 6 Millionen, rechne noch mal ein paar GB oben drauf sowie noch Puffer und du hast deine Festplatten-Größe. SSD ist dabei aber meine Empfehlung. Abhängig davon wofür du das wie brauchst, solltest du entsprechend RAM reinpacken, sodass die meisten Daten im RAM liegen statt immer wieder von der Festplatte geholt zu werden.
Abhängig davon was du brauchst, solltest du auf das * verzichten.
Keine Ahnung was da an Daten rumschwirrt, aber wenn du da nur einen Namen brauchst, dann solltest du auch nur den Namen abfragen.
Evtl. gibst du uns mal einen tieferen Einblick in die DB und den nötigen Abfragen
Keine Ahnung was da an Daten rumschwirrt, aber wenn du da nur einen Namen brauchst, dann solltest du auch nur den Namen abfragen.
Evtl. gibst du uns mal einen tieferen Einblick in die DB und den nötigen Abfragen
- ein varchar belegt nur den tatsächliche Länge, wenn du 10 Bytes schreibst werden nur 10 Bytes belegt.
- ein Byte sind 8 Bit , mit 4 byte hast du 32 bits und ~4,2 Milliarden Nummern. Du wirst als wohl oder übel 8Bytes (64Bits) benötigen.
beachte ....
- Varchar haben durch den internen Aufwand nicht die beste Performance.
- Es gibt auch den Feldtype Text und Blob, schau mal ob die nicht besser geeignet sind. z.b, sind dann auch Volltextsearch möglich.
- eine möglich Table könnte so ausschauen....
CREATE TABLE IF NOT EXISTS `t1` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`meine_daten` varchar(255) DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `meine_daten` (`meine_daten`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
du musst je nach wirklicher Datenlänge mit ~1,5 - 2TB kalkulieren müssen. Da stellt sich die Frage: "Wie viele Update hast du auf diese Table?" U.U. bist du mit einem Hash besser bedient, wenn du nur wissen willst ob der Datensatz vorhanden ist.
Ob du die 6 Milliarden Datensätze wirklich in einer Tabelle speichern willst/musst solltest du genau betrachten.
Ich würde überlegen mehrere Tabellen zu machen, oder wenn das nicht geht fixe Formate zu verwenden.
Genau rechnen kannst du es über
https://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html#data-t ...
Beachte aber in dieser Größenordnung auch die Positionierung der Schreibleseköpfe. Und wie viele Zugriffe du hast.
Die Latenzzeit ist üblicherweise zwischen 3 bis 7 ms.
Da kommt schnell etwas zusammen.
- ein Byte sind 8 Bit , mit 4 byte hast du 32 bits und ~4,2 Milliarden Nummern. Du wirst als wohl oder übel 8Bytes (64Bits) benötigen.
beachte ....
- Varchar haben durch den internen Aufwand nicht die beste Performance.
- Es gibt auch den Feldtype Text und Blob, schau mal ob die nicht besser geeignet sind. z.b, sind dann auch Volltextsearch möglich.
- eine möglich Table könnte so ausschauen....
CREATE TABLE IF NOT EXISTS `t1` (
`id` int(10) NOT NULL AUTO_INCREMENT,
`meine_daten` varchar(255) DEFAULT '0',
PRIMARY KEY (`id`),
UNIQUE KEY `meine_daten` (`meine_daten`)
) ENGINE=InnoDB AUTO_INCREMENT=4 DEFAULT CHARSET=utf8;
du musst je nach wirklicher Datenlänge mit ~1,5 - 2TB kalkulieren müssen. Da stellt sich die Frage: "Wie viele Update hast du auf diese Table?" U.U. bist du mit einem Hash besser bedient, wenn du nur wissen willst ob der Datensatz vorhanden ist.
Ob du die 6 Milliarden Datensätze wirklich in einer Tabelle speichern willst/musst solltest du genau betrachten.
Ich würde überlegen mehrere Tabellen zu machen, oder wenn das nicht geht fixe Formate zu verwenden.
Genau rechnen kannst du es über
https://dev.mysql.com/doc/refman/5.5/en/storage-requirements.html#data-t ...
Beachte aber in dieser Größenordnung auch die Positionierung der Schreibleseköpfe. Und wie viele Zugriffe du hast.
Die Latenzzeit ist üblicherweise zwischen 3 bis 7 ms.
Da kommt schnell etwas zusammen.
wie kommst du auf die 1,5-2TB?
Hallo,
Durch Mathematik
Wenn ein Datensatz (ohne Steuerzeichen usw.) 250 Byte hat dann sind das bei 6 Mrd Datensätze wie viele Bytes? Und wenn dieser Datensatz dann schon 333 Byte hat sind es bei 6 Mrd Datensätze dann wie viele Byte? Rechnen musst du in der IT schon können Und jetzt nehmen wir mal an dein Datensatz hat 1000 Byte, wie viele byte haben dann 6 Mrd Datensätze?
Gruß,
Peter
Durch Mathematik
Wenn ein Datensatz (ohne Steuerzeichen usw.) 250 Byte hat dann sind das bei 6 Mrd Datensätze wie viele Bytes? Und wenn dieser Datensatz dann schon 333 Byte hat sind es bei 6 Mrd Datensätze dann wie viele Byte? Rechnen musst du in der IT schon können Und jetzt nehmen wir mal an dein Datensatz hat 1000 Byte, wie viele byte haben dann 6 Mrd Datensätze?Gruß,
Peter
das ist schon klar, nur wie ist er jetzt auf die 250 / 333 / 1000 Byte gekommen? Habe dazu nichts in der Frage lesen können.
Eher mutmaße ich bei den Fragen (wegen 4Byte etc.) auf deutlich kleinere Werte
Eher mutmaße ich bei den Fragen (wegen 4Byte etc.) auf deutlich kleinere Werte
Hallo,
Schon mal etwas von annahme gehört?
Gruß,
Peter
Schon mal etwas von annahme gehört?
Gruß,
Peter
"1. Wenn ich ein VARCHAR(255) verwende ........."
Hier stand die Byteanzahl. Der Rest ist Taschenrechner.
Was mir nicht so ganz klar ist: Was mach ich mit so viel, langem Text?
Das ist mehr Text, als eine Sprache Wörter hat.
Hier stand die Byteanzahl. Der Rest ist Taschenrechner.
Was mir nicht so ganz klar ist: Was mach ich mit so viel, langem Text?
Das ist mehr Text, als eine Sprache Wörter hat.
VARCHAR(255) bedeutet (iirc) das ich darin 255 Zeichen speichern kann... Das ist jetzt nicht unbedingt "mehr Text als eine Sprache Wörter hat". Kann es sein das du das mit Text() verwechselt?
das nicht, aber 6 Milliarden Datensätze (Wörter, Phrasen)
