Frage zu Datenbankaufbau.

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

  • Frage zu Datenbankaufbau.

    Moin Leute,

    ich arbeite an einem Projekt, das relativ umfangreiche Datenbanken benötigt. Ich will das mal kurz in einigen Worten erläutern, ehe ich auf meine Frage komme.

    Es gibt eine theorethisch unbegrenzte Zahl von Gruppen, die jeweils mindestens 1000 Datensätze ( Also Content, keine Account-Sachen ) speichern müssen. Tendenz ist aber eher steigend, also mehrere Tausend.

    Nun müssen für JEDEN Benutzer Statistiken erstellt werden, in Verbindung mit den Datensätzen der Gruppen.

    Die Frage ist nun ab wann es sich lohnt für jede Gruppe, oder gar für jeden User eine eigene Tabelle zu erstellen.

    Ich meine, wenn ich die Datensätze aller Gruppen in eine Tabelle schreibe, dann sind da nachher mehrere 10.000 Datensätze drin, und das dürfte doch schon eine relativ große Performance-Belastung darstellen, da die User bei Benutzung der Seite ständig auf diese Tabelle zugreifen müssten. Oder ?

    Dann die Statistiken,... Pro Gruppen-Datensatz hat jeder User nochmal einen Datensatz mit seinen STatistiken, d.h. pro User auch mehrere Tausend Datensätze. Eine Tabelle für alle User/Datensätze würde auch ziemlich überdimensionale Ausmaße annehmen.

    Die eigentliche Frage ist nun wo denn die Grenze liegt. So Pi mal Daumen, ab wievielen Datensätzen lohnt es sich eine Tabelle in mehrere aufzusplitten, um optimale Performance zu gewährleisten?

    Nachteil wäre dann wieder, wenn man alle Gruppen-Datensätze nach etwas durchsuchen möchte, dann muss man natürlich wieder auf alle Tabellen zugreifen.

    Hat da jemand Erfahrungen ? Ich habe noch nie mit so etwas Großem zu tun gehabt und wollte mir gern vorher ein paar Tips holen, als dann direkt auf die Schnauze zu fallen und alles nochmal neu machen zu müssen.

    Greetz,
    Nohfreak
    Zuletzt geändert von nohfreak; 30.12.2007, 12:37.
    Mein aktuelles Projekt: Hausaufgaben Datenbank für kostenlose Hausaufgaben

  • #2
    Es lohnt sich überhaupt nicht die Tabelle zu zerstückeln.
    Wenn du die richtige Indexen gesetzt hast, dann dauert eine suche bei 10.000 datensetzen ein Bruchteil schneller als bei 1000.000.
    Sonnst gibtes auch die möglichkeit die Tabelle Partitionieren um die Geschwindigkeit zu gewinnen http://dev.mysql.com/doc/refman/5.1/...titioning.html
    Slava
    bituniverse.com

    Kommentar


    • #3
      Naja, jeder Datensatz hat dann halt ne eigenständige ID und würde dann mit einem Feld den jeweiligen Gruppen zugewiesen.

      Bei den User-STatistiken zu den Objekten wär das dann halt genauso.

      Macht das wirklich so wenig Unterschied, ob da 1k, 10k oder 100k drin sind ? Mir scheint ich unterschätze die Rechenleistung doch deutlich

      Meine Überlegung war halt, dass wenn 100 User gleichzeitig auf ne 100k-Tabelle zugreifen die Performance schlechter is, als wenn jeder User ne eigene Tabelle hat mit 1k
      Zuletzt geändert von nohfreak; 30.12.2007, 13:10.
      Mein aktuelles Projekt: Hausaufgaben Datenbank für kostenlose Hausaufgaben

      Kommentar


      • #4
        ich habe schon mehr mals über diese Thema gesprochen.
        bei Indexierter suche verwendet ein Datenbank eine binäre suche und braucht bei einer 10.000 datensatz Tabelle maximal 12 Zeiger-Bewegungen um der erster Datensatz zu finden.
        Die suche nach den weiteren Datensätzen braucht nur maximal 2 Zeiger-Bewegungen.
        In Vergleich zu einer 1000.000 datensatz Tabelle, die eigentlich 100-mal mehr datensätze hat, wird maximal 24 Zeiger-Bewegungen für erster Datensatz und maximal 2 für die folgende Datensätze gebraucht.

        Also wenn du merkst liegt der Unterschied in 12 Zeiger-Bewegungen die wirklich keine Bedeutung für Performance als auch Speicherverbrauch haben.
        Slava
        bituniverse.com

        Kommentar


        • #5
          Original geschrieben von nohfreak
          Meine Überlegung war halt, dass wenn 100 User gleichzeitig auf ne 100k-Tabelle zugreifen die Performance schlechter is, als wenn jeder User ne eigene Tabelle hat mit 1k
          Gleichzeitig ist logisch schon mal gar nicht möglich. Die Zugriffe werden in Schlange gesetzt und abgearbeitet. Das geht allerdings so schnell, dass man als Mensch keine spürbare Wartezeit hat. Was anderes ist es bei Schreibzugriffen, da die Tabelle dafür erst gelockt wird und nachdem die Daten geschrieben werden wieder entlockt wird. Ich nehme allerdings an, dass das für deine Anwendung ebenfalls kein Problem sein wird, denn selbst bei täglich 5 Million Datensätzen kommt man noch mit bezahlbarer Hardware hin (allerdings stößt man dann auch laaaaaangsam an die Grenzen ).
          [FONT="Helvetica"]twitter.com/unset[/FONT]

          Shitstorm Podcast – Wöchentliches Auskotzen

          Kommentar


          • #6
            Es macht durchaus Sinn große Tabelle in kleine aufzuteilen.
            Allein ein ALTER auf eine 500 MB Tabelle braucht auf einer 64Bit-Maschine mit 16 Gig Ram im laufenden Betrieb fast 20 Minuten und selbst bei null-sonstigem-Betrieb noch 5 Minuten.

            Wenn ich mir vorstelle, dass das eine von dreißig Tabellen ist, aus denen das Teilprojekt besteht... wenn das alles in einer Tabelle wäre - na dann gute Nacht.

            Das Partitioning in 5.1 ist zwar eine gute Idee, aber ich glaube das mit den ALTER-Befehl deckt das auch nicht besser ab (und abgesehen davon muss man halt erstmal 5.1 haben und die ist aktuell ja nicht mal stable).

            Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

            bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
            Wie man Fragen richtig stellt

            Kommentar


            • #7
              ALTER ist kein Standardbefehl um mit DB zu arbeiten.
              Wir sprechen eigentlich mehr über insert, update und select.
              Bei einer riesiger Tabelle wird jede veränderung von Tabellenstruktur kritisch und braucht sehr viel zeit.
              Also, man überlegt schon vorher, wie eine Tabellenstruktur aussehen muss und erst danach fühlt man das mit den werten.
              Im fall, dass wir bei den Tabellen ziemlich oft die Update von 100000 Datensätzen brauchen, würde ich auch für die mehrere Tabellen aussagen.
              sonnst, wenn man update auf einer Zeile macht oder select von übersichtbaren Datensätzen, dann sehe ich kein Sinn die Tabelle zu zerteilen.
              Zuletzt geändert von Slava; 30.12.2007, 19:03.
              Slava
              bituniverse.com

              Kommentar


              • #8
                Im live-Betrieb eine einzige von 30 Tabellen für 20 Minuten offline zu nehmen, ist weniger schlimm, als ein komplettes Teilprojekt für eventuell Tage offline zu nehmen.

                Mir auch egal, mach was du willst, ich stütze mich auf Erfahrung von mir und anderen Leuten, die deutlich Ahnung von MySQL haben:
                http://www.mysqlperformanceblog.com/...gs-are-better/

                Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                Wie man Fragen richtig stellt

                Kommentar


                • #9
                  Original geschrieben von Slava
                  ich habe schon mehr mals über diese Thema gesprochen.
                  bei Indexierter suche verwendet ein Datenbank eine binäre suche und braucht bei einer 10.000 datensatz Tabelle maximal 12 Zeiger-Bewegungen um der erster Datensatz zu finden.
                  Die suche nach den weiteren Datensätzen braucht nur maximal 2 Zeiger-Bewegungen.
                  In Vergleich zu einer 1000.000 datensatz Tabelle, die eigentlich 100-mal mehr datensätze hat, wird maximal 24 Zeiger-Bewegungen für erster Datensatz und maximal 2 für die folgende Datensätze gebraucht.

                  Also wenn du merkst liegt der Unterschied in 12 Zeiger-Bewegungen die wirklich keine Bedeutung für Performance als auch Speicherverbrauch haben.
                  Das kann man so nicht stehen lassen.
                  Neben B-Baumen gibt es in fast allen Datenbanken mehrere Indizierungsverfahren, die leicht über einiges schneller sein können als eine binäre Suche. Die Wahl des Indexes muss IMMER davon abhängen, welche Queries die Benutzer stellen bzw. wonach gesucht wird, sonst läufst du mit deiner Binären Suche schneller gegen die Wand als du gucken kannst.

                  Kommentar


                  • #10
                    bla$ter sorry es gibt immer wieder die Fälle, wo eine oder andere Technik versagt.
                    In jedem Fall die suche nach einem Zahl oder nach einen String mit like bringt bei normaler indexierung die Vorteile, die ich schon angesprochen habe. Ausserdem scheint es bei dem @nohfreak genau der Fall sei, da es um die Gruppen und dazu gehörige Datensätze handelt.
                    Ich würde doch vorschlagen alles in eine Tabelle zu schreiben, da die Möglichkeit die Tabelle zu zerstückeln bleibt weiterhin machbar.
                    Ab einer bestimmtem Anzahl von Tabellen, wird die Performance von DB auch schnell sinken, da die suche nach Tabelle selbst nimmt auch Performance in Anspruch.

                    die schnellere suchverfahren kenne ich nicht und würde mich freuen wenn du mir ein Algorithmus bzw ein Hinweis gibst wo ich das nachschlagen könnte.
                    Slava
                    bituniverse.com

                    Kommentar


                    • #11
                      Fast jeder Such-Algorithmus wird unter Umständen suboptimal ... man spricht in diesem Falle von Degeneration oder degernerativem Verhalten eines Algorithmus (egal ob Suchen oder Sortieren). Allerdings ist das eher ein Problem für DB-Server-Entwickler.

                      Die Aufgabe des Programmierers ist es die beste Methode zu finden Daten zu speichern. Das Spliten von Tabellen (Entitäten) ist dieses indes jedenfalls nicht (weil dieses den Pradigmen eines relationalen Datenbankmodells wiederspricht).

                      Die beim orginären Problem benannten Datenmengen sollten im Normalfall kein Problem darstellen (vernünftige Indizierung vorausgesetz).

                      Wenn allerdings Datenmengen in solchen Größen (500GB und mehr) anfallen, ist die Frage welche Information ich speichern will und ob in diesem Falle eine Datenbank das richtige Mittel ist.

                      Große Datenmenge fallen im Normalfall z.B. durch Protokollierungen an. In solchen Fällen und wenn Daten nicht in alle möglichen Richtungen und häufig ausgewertet werden müssen, sollte man sich überlegen ob nicht vielleicht ein simples Logfile mit entsprechenden Auswertungstools sinnvoller ist.

                      Alternativ oder zusätzlich dazu läßt sich prüfen welche Informationen in Wirklichkeit gespeichert werden sollen oder welche Informaitonen in Wirklichkeit verwendet werden. Oft lassen sich so Informationen komprimieren und die erfassten Datenbestände können wieder reduziert werden.

                      Im Übrigen. Wenn ein ALTER TABLE für ein laufendes System ein Problem darstellt, liegt das Problem eigentlich nicht im ALTER TABLE sondern im Datenbank Entwurf. Ein ALTER TABLE ist eigentlich ein DDL-Befehl der also im Zuge der Entwicklung oder während UPDATE/UPGRADE Prozessen eine Rolle spielt nicht jedoch während des laufenden Betriebs einer Software. Da UPDATES/UPGRADES eigentlich sehr selten im laufenden Betrieb durchgeführt werden ist dieses eher zu vernachlässigen.
                      carpe noctem

                      [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
                      [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

                      Kommentar


                      • #12
                        Original geschrieben von goth
                        Im Übrigen. Wenn ein ALTER TABLE für ein laufendes System ein Problem darstellt, liegt das Problem eigentlich nicht im ALTER TABLE sondern im Datenbank Entwurf. Ein ALTER TABLE ist eigentlich ein DDL-Befehl der also im Zuge der Entwicklung oder während UPDATE/UPGRADE Prozessen eine Rolle spielt nicht jedoch während des laufenden Betriebs einer Software. Da UPDATES/UPGRADES eigentlich sehr selten im laufenden Betrieb durchgeführt werden ist dieses eher zu vernachlässigen.
                        Erklär das mal den Benutzern, die 24-Stunden-Erreichbarkeit wollen.
                        Da kann man für ein Update der Software die Website nicht mal eben für ein paar Stunden vom Netz nehmen... dann rennen die uns das Mail-Postfach und Forum ein.

                        Ein netter Guide zum übersichtlichen Schreiben von PHP/MySQL-Code!

                        bei Klammersetzung bevorzuge ich jedoch die JavaCoding-Standards
                        Wie man Fragen richtig stellt

                        Kommentar


                        • #13
                          Hui, da bin ich ja überwältigt, was ich da für Diskussionen losgetreten habe. Auf jeden Fall danke ich allen, die eine Antwort geschrieben haben.

                          Ich denke für mein Problem ist es dann schon ok alles in eine Tabelle zu stecken.

                          Denn im Prinzip sollen innerhalb einer Gruppen Objekte erstellt werden. Mit diesen Objekten können die Benutzer diverse Aktionen durchführen und die Ergibnisse davon sollen dann für jeden User und jedes benutzte Objekt immer in der DB gespeichert werden.

                          Ich benutze also im Regelfall nur SELECT, UPDATE und INSERT auf einzelne oder einige wenige Datensätze.

                          Also hau ich alles in eine Tabelle. Sollten irgendwie Probleme auftreten werde ich mich weider melden.

                          Danke nochmals.
                          Mein aktuelles Projekt: Hausaufgaben Datenbank für kostenlose Hausaufgaben

                          Kommentar


                          • #14
                            Original geschrieben von ghostgambler
                            Erklär das mal den Benutzern, die 24-Stunden-Erreichbarkeit wollen.
                            Da kann man für ein Update der Software die Website nicht mal eben für ein paar Stunden vom Netz nehmen... dann rennen die uns das Mail-Postfach und Forum ein.
                            Dann hast Du wenig Ahnung davon wie man UPGRADES einspielt ... ....

                            Im übrigen ist einem Kunden der kein vollkommener Vollidiot ist eine solche Problematik vollkommen klar ... selbst bei großen Systemen (Amazon, Bahn, Post, ...) kommt es durch Software Updates zu geplanten ausfällen. Meinstens sind's die Trolle die 100% Verfügbarkeit verlangen oder diese versprechen.
                            Zuletzt geändert von goth; 31.12.2007, 17:10.
                            carpe noctem

                            [color=blue]Bitte keine Fragen per EMail ... im Forum haben alle was davon ... und ich beantworte EMail-Fragen von Foren-Mitgliedern in der Regel eh nicht![/color]
                            [color=red]Hinweis: Ich bin weder Mitglied noch Angestellter von ebiz-consult! Alles was ich hier von mir gebe tue ich in eigener Verantwortung![/color]

                            Kommentar


                            • #15
                              Dort wo ich an solchen Änderungen beteiligt war bzw. sie selbst durchgeführt habe, wurden solche Updates allerdings immer partiell eingespielt. D.h. dass man nicht das "komplette System" offline nimmt, sondern nur die Teile, die Betroffen sind.

                              Will heißen, wenn ich eine Tabelle mit Adressdatensätzen ändere, so muss ich nicht das gesamte System ausschalten, sondern lediglich die Teilbereiche, die auf diese Tabelle zugreifen (schreibend wie lesend). Das minimiert den subjektiven Ausfall, und wenn man das zeitlich geschickt plaziert, merken lediglich eine Handvoll Benutzer etwas (Übrigens ist heute Nacht so ein geschickter Zeitpunkt ).
                              [FONT="Helvetica"]twitter.com/unset[/FONT]

                              Shitstorm Podcast – Wöchentliches Auskotzen

                              Kommentar

                              Lädt...
                              X