Ankündigung

Einklappen
Keine Ankündigung bisher.

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

Einklappen

Neue Werbung 2019

Einklappen
X
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

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

    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?

  • #2
    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.
    [URL="https://github.com/chrisandchris"]GitHub.com - ChrisAndChris[/URL] - [URL="https://github.com/chrisandchris/symfony-rowmapper"]RowMapper und QueryBuilder für MySQL-Datenbanken[/URL]

    Kommentar


    • #3
      Zitat von Condor93 Beitrag anzeigen
      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.
      PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

      Kommentar


      • #4
        Zitat von akretschmer Beitrag anzeigen
        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?



        Zitat von ChristianK Beitrag anzeigen
        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.

        Kommentar


        • #5
          Zitat von Condor93 Beitrag anzeigen
          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.

          Kommentar


          • #6
            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

            Kommentar


            • #7
              Ich partitioniere die Tabellen schon soweit es geht.

              Kommentar


              • #8
                Zitat von Condor93 Beitrag anzeigen
                Ich partitioniere die Tabellen schon soweit es geht.
                Sei ehrlich, Du bist die caroline aus dem anderen Forum, stimmt's?
                PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services

                Kommentar


                • #9
                  Wer ist Caroline?

                  Kommentar


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

                    Kommentar

                    Lädt...
                    X