Struktur einer sehr sehr großen Tabelle

Question

Hallo, bin mir unsicher mit der Planung einer Datenbank.

Die Anforderung ist im Grunde sehr einfach.

Ich möchte Referenzen auf ein Ablagesystem speichern.

Das sind im Wesentlichen eine DocId (32ByteHexString), eine KomponentenID (text string)und MetaInformationen dazu. Es wird primär über die DocId gesucht, die Docid ist nicht eindeutig.

[docid] [char](32) NOT NULL,

[compid] [nchar](32) NOT NULL,

[iorfile] [nchar](255) NOT NULL,

[offset] [bigint] NOT NULL,

[length] [bigint] NOT NULL,

[arcdate] [datetime] NOT NULL,

[status] [int] NOT NULL

Meine Sorge ist die Größe der Tabelle. Sie wird in kurzer Zeit schnell wachsen, bis auf viele 100 Millionen Zeilen.

Installiert ist ein SQL 2005 Standard. Das alles soll hochverfügbar sein und läuft in einem WindowsCluster (2 Nodes) im SAN.

Wenn ich alles in eine Tabelle packe befürchte ich Backup- und Wartungsprobleme. Meine Idee ist es 255 identische Datenbanken anzulegen, non Group Index auf die DocId. Bei einem Request wird eine 8Bit Quersumme der DocId gebildet. Mein Programm verteilt die Requests anhand der Quersumme auf die einzelnen DBs. Vorteil: beim Bachup bzw reorganisieren ist nur ein kleiner Teil  des Systems betroffen.

Ist das totaler Käse, oder okay? Was meint ihr?

Danke

Gruß

Thorsten

Answer 1

Eh du eine eigene Lösung zum Verteilen der Daten auf mehrer Datenbanken/Tabellen/Partitionen in Erwägung ziehst, schau dir die Partitionierung von Tabellen im SQL Server an. Ich denke, das könnte eine Lösung für dein Problem sein.

---

Beste Grüße,
Andreas Richter
http://www.anrichter.net

Answer 2

@Andreas, Thorsten schrieb das die Standard Edition zum Einsatz kommt, von daher fällt Partioning aus.

Hallo Thorsten,

bei 100 Mio Zeilen kommt es hochgerechnet ohne Index auf 63,4 GB Speicherplatz, das ist noch nicht so wirklich sehr groß; aber groß genug um sich frühzeitig Gedanken zu machen.

Was Du angedacht hast nennt sich Data Sharding. Das macht nur dann wirklich Sinn, wenn die Datenbank Größe beschränkt ist, wie es bei SQL Azure oder SQL Server Express Edition der Fall ist. Ansonsten kannst Du alles in einer Datenbank belassen, da gibt es andere Strategien.

Du könntest es auf mehrere Tabellen aufteilen und dann eine "partitionierte Sicht", hier macht es auch nur Sinn, wenn immer auf die Partition-ID gefiltert wird, sonst ist es inperformanter, als wenn man auf die einzelnen Tabellen selektiert. Siehe auch:
http://msdn.microsoft.com/de-de/library/ms188299.aspx
http://msdn.microsoft.com/de-de/library/ms187067.aspx

Ansonsten wäre es zu überlegen, ob man für die DocID einen besseren Datentyp verwenden könnte, sofern man bequem umrechnen kann, nicht auf einen ungleichen Datentypen joinen und damit jedesmal umrechnen muss, etc.

---

Olaf Helper
* cogito ergo sum * errare humanum est * quote erat demonstrandum *
Wenn ich denke, ist das ein Fehler und das beweise ich täglich
Blog Xing

Answer 3

Hallo Thorsten,

 

Haben die Antwortendeine Situation abgeklärt? Können wir den Thread schließen?

 

Viele Grüße,

Alex