Nehmen wir an, Sie erstellen eine Datenbank zum Speichern von Nachrichten für eine Chat-Room-Anwendung. Es gibt eine unbegrenzte Anzahl von Chatrooms (sie werden zur Laufzeit bei Bedarf erstellt) und alle Nachrichten müssen in der Datenbank gespeichert werden.
Wäre es falsch, eine riesige Tabelle zu erstellen, um Nachrichten für alle Chatrooms zu speichern, in dem Wissen, dass es in dieser einen Tabelle möglicherweise Milliarden von Datensätzen geben könnte?
Wäre es sinnvoller, eine Tabelle für jeden erstellten Raum dynamisch zu erstellen und die Nachrichten dieses Raums nur in dieser Tabelle zu speichern?
Es wäre angemessen, eine einzige Tabelle zu haben. Wenn Sie n Tabellen haben, die nach Anwendungsnutzung wachsen, beschreiben Sie, dass Sie die Datenbank selbst als eine Tabelle von Tabellen verwenden. Dies ist nicht so, wie ein RDBMS funktionieren soll. Milliarden von Datensätzen in einer einzigen Tabelle sind in einer modernen Datenbank trivial. Auf dieser Ebene sind Ihre einzigen Leistungsbedenken gute Indizes und wie Sie Verknüpfungen herstellen.
Milliarden von Datensätzen?
Angenommen, Sie haben ständig 1000 aktive Benutzer mit einer Nachricht pro Minute, so ergeben sich 1,5 Millionen Nachrichten pro Tag und ca. 500 Millionen Nachrichten pro Jahr.
Wenn Sie noch mehrere Jahre alte Chat-Nachrichten speichern müssen (wofür?), können Sie sie in jahresbasierten Tabellen archivieren.
Ich würde definitiv gegen die dynamische Erstellung von raumbasierten Tabellen argumentieren.
Obwohl eine Tabelle pro Chatroom ausgeführt werden kann, hat jede Datenbank Beschränkungen hinsichtlich der Anzahl der Tabellen, die erstellt werden können. Bei einer unbegrenzten Anzahl von Chatrooms müssen Sie daher eine unendliche Anzahl von Tabellen erstellen, was nicht möglich ist zur Arbeit gehen.
Sie können auf der anderen Seite Milliarden von Datenzeilen speichern, Speicher ist normalerweise nicht das Problem angesichts des Speicherplatzes - das Abrufen der Informationen innerhalb eines vernünftigen Zeitrahmens ist jedoch und erfordert eine sorgfältige Planung.
Sie können die Nachrichten nach einem Datumsbereich partitionieren. Wenn Sie dies planen, können Sie mit der LUN-Migration ältere Daten auf langsameren Speicher verschieben, während aktuellere Daten auf dem schnelleren Speicher verbleiben.
Genau genommen ist Ihr Entwurf richtig, ein einzelner Tisch. Felder mit niedriger Entropie {z. B. 'Benutzer-ID' - Sie möchten von ID-Tabellen verknüpfen, d. h. normalen Normalisierungsmustern der Datenbank folgen}
möchten Sie vielleicht über die bereichsbasierte Partitionierung nachdenken. z. B. "Kopien" Ihrer Tabelle mit einem Jahrespräfix. Oder vielleicht sogar nur eine 'aktuelle' und Archiv-Tabelle
Diese beiden Ansätze bedeuten, dass Ihre Abfragesemantik komplexer ist {wenn jemand eine mehrjährige Suche durchgeführt hat}, müssten Sie mehrere Tabellen abfragen.
Der Vorteil ist jedoch, dass Ihre aktuelle Tabelle ungefähr gleich bleibt und die Archivierung einfacher ist. - {Sie können die Tabelle 2005_Chat einfach löschen, wenn Sie 2005 Daten archivieren wollen}
-Ace
Tags und Links database