Millionen Datensätze von einer Tabelle in mehreren Tabellen verteilen?

[Condor93]

Hallo,

ich habe eine Tabelle mit 100 Millionen Datensätze. Wäre es Sinnvoll, wenn ich diese Datensätze über mehrere Tabellen verteile?

Beispiel: Soziales Netzwerk

User registriert sich, bekommt eine eindeutige ID die am Ende mit den Kürzel der Kontinente endet.

User ID = 0123456789EU (als Deutscher registriert, Deutschland liegt in Europa)

Damit der User beim Login mehr über sicht erfährt, werden noch zusätzliche Informationen geladen.
System filtert aus dieser ID die letzten 2 Zeichen. Anhand dieser Zeichen (EU) wird in der Tabelle user_information_eu gesucht und von dort aus die Daten geladen.

Hört sich ja ziemlich Praktisch an, weil ich dadurch die Datenbank etwas entlaste.

Aber... ein soziales Netzwerk hat noch Nachrichten (die in der MongoDB gespeichert werden), Beiträge, Bilder und und und.

Müsste man es dort auch so tun, damit man die Datenbank etwas entlastet?

[ChristianK]

Ich frage mich, wie du auf die 100 Millionen Datensätze kommst und damit noch keine Erfahrung hat - so wie es scheint.

Hast du also 2 Datenbanken, einmal eine relationelle und eine MongoDB? Wenn ja, in der relationellen Datenbank kannst du durchaus die Benutzerinformationen in eine separate Tabelle speichern. Wenn denn nicht gleich in die MongoDB auslagern.

Wobei sich auch durchaus die Frage stellt, wieso es dann zwei Datenbanken sein müssen.

Eine Aufteilung wie du schreibst mit "user_information_eu" und "user_information_usa" halte ich für daneben. Damit hast du eine dynamische Anzahl Tabellen. Mir sind jedoch keine Erfahrungswerte dazu bekannt, doch ich behaupte, mittels guter Indexes kannst du den Vorteil, den du dir durch die Aufteilung in solcher Tabellen erhoffst, wieder gut machen.

[akretschmer]

Hört sich ja ziemlich Praktisch an, weil ich dadurch die Datenbank etwas entlaste.

Nein, unpraktisch, weil Du aus dem WHERE erst einmal nicht die Kindtabelle (bei einem partitioniertem Schema) ermitteln kannst. Partitionierung großer Tabellen funktioniert anders.

[Condor93]

Nein, unpraktisch, weil Du aus dem WHERE erst einmal nicht die Kindtabelle (bei einem partitioniertem Schema) ermitteln kannst. Partitionierung großer Tabellen funktioniert anders.

Login Tabelle
user_hash_email | user_hash_password | user_hash_id

User_information Tabelle
user_hash_id | Vorname | Nachname | Alter | Geburtsdatum | ...

Also wäre das schon eine Partionierung, wenn ich mich soweit richtig belesen habe.

Wenn ich jetzt nach einen Namen suchen würde, müsste ich das ja so machen

User_name Tabelle
Vorname | Nachname | user_hash_id

User_Information
user_hash_id | Alter | Geburtsdatum

Dann hätte ich aber ein Problem mit dem Login, oder kann ich beruhigt Vorname und Nachname in der Tabelle hinzufügen?

Ich frage mich, wie du auf die 100 Millionen Datensätze kommst und damit noch keine Erfahrung hat - so wie es scheint.

Hast du also 2 Datenbanken, einmal eine relationelle und eine MongoDB? Wenn ja, in der relationellen Datenbank kannst du durchaus die Benutzerinformationen in eine separate Tabelle speichern. Wenn denn nicht gleich in die MongoDB auslagern.

Wobei sich auch durchaus die Frage stellt, wieso es dann zwei Datenbanken sein müssen.

Es ist nur ein Beispiel, sehe das bitte auch als solches. NoSQL wird bei sehr sehr großen Tabellen benutzt wie zum Beispiel ein Chat. Der Rest dagegen kann in einer relationalen DB bleiben. Wie du schon sagtest.

[erc]

ich habe eine Tabelle mit 100 Millionen Datensätze. Wäre es Sinnvoll, wenn ich diese Datensätze über mehrere Tabellen verteile?

"Der Himmel ist blau. Wäre es Sinnvoll wenn ich heute zum Friesur gehe?" So ungefährt liest sich das für mich. Die Anzahl der Datensätze hat nix mit der Struktur der Datenbank zu tun. Das wird erst zum Thema wenn du konkrete Dinge optimieren willst oder bereits Probleme hast. Wenn du solche "Optimierungen" ohne Plan machst, führt das eigentlich nur zum gegenteiligen Effekt. Also halt lieber die Beine still und schau was passiert. Optimieren kannst du immer noch wenn es soweit ist.
Mein Tipp: Die Datenbank in Normalform umsetzen, dort wo nötig denormalisieren. Die Anwendung so sturkturieren das möglichst unabhängige Komponenten entstehen.

[rkr]

Akretschmer hat es schon gepostet. Du kannst Tabellen partitionieren. Sowohl MongoDB (shards) als auch RDBMS (DDL-Partitioning). Alles in der Theorie sehr einfacher Stoff. Bei RDBMS kommt es dann ggf aber zum Wegfall einiger Funktionen wie Constraint-Checks, etc

[Condor93]

Ich partitioniere die Tabellen schon soweit es geht.

[akretschmer]

Ich partitioniere die Tabellen schon soweit es geht.

Sei ehrlich, Du bist die caroline aus dem anderen Forum, stimmt's?

[Condor93]

Wer ist Caroline?

[erc]

Ist das knuffig... Du fragst ernsthaft ob SELECTs auf den PK ein Problem werden? Das ist bestimmt DAS PROBLEM bei 100.000.000 Usern.