Grau ist alle Theorie ...

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

  • Grau ist alle Theorie ...

    Hallo an alle.

    Heute mal keine Frage nach PHP-Codes oder SQL-Querys. Einfach eine theoretische Frage, die mich schon seit längerem interessiert.

    Und bevor hier wieder öffentlich gefragt wird, warum man denn einen Auftrag annimmt, obwohl man nicht weiß, ob man diesen überhaupt bewältigen kann und die Antwort hier dann im Forum zu finden glaubt: NEIN, es ist kein Auftrag, sondern nur ein theoretisches Problem.

    Folgende Ausgangssituation:

    Es soll ein PHP-MySQL-System entstehen, mit dem eine unbestimmte Anzahl von Nutzern per Browser über das Internet arbeiten kann. Zu erwarten ist, dass pro Nutzer ca. 300 Einträge pro Monat entstehen (also bei ca. 50 Nutzern insgesamt 15.000 Einträge pro Monat). Das sind auf das Jahr hochgerechnet viele Einträge, nämlich 180.000 Stück.

    Die Fragen:

    1. Wie sieht es mit der Performance aus, wenn derart viele Datensätze erfasst werden? Ich kann mir vorstellen, dass das System sicher "einige Zeit" braucht, wenn beispielsweise schon 100.000 Einträge existieren, Nutzer Nr. 27 seine 3.600 Einträge einsehen möchte und das Skript diese 3.600 aus den bestehenden 100.000 erst einmal herausfiltern muss. Man sollte noch hinzufügen, dass dabei sicher auch Abfragen über 2 oder mehreren Tabellen stattfinden könnten.

    2. Wie sieht es mit der maximal zu sichernden Datenmenge aus? Das MySQL-Handbuch gibt für mich widersprüchliche Antworten. 4 Gigabyte? 8 Terabyte? "Non removable disk capacity" is the limit?

    3. Wie könnte / müsste man das Tabellensystem planen, welches die Datensätze der Kunden erfassen soll? Für jeden Buchstaben im Alphabet eine Tabelle anlegen, damit Kunde Auermann in der A-Tabelle landet und Kunde Mustermann in der M-Tabelle? Sicher keine gute Idee. Alle Kunden, deren Name von A-M reicht, in eine Tabelle, alle Kunden von N-Z in eine zweite Tabelle? Sicher auch keine gute Idee. Doch lieber alle Kundendatensätze in einer Tabelle lassen? Da sehe ich die Gefahr der "Langsamkeit".

    Bin für alle ernstgemeinten Anregungen, Tipps oder Hilfestellungen dankbar.

    Innuendo

  • #2
    2. http://www.mysql.com/doc/en/Table_size.html (vor allem die comments)

    1. und 3. daten gleicher struktur kommen in eine tabelle, wenn du da geschickt spalten indizierst, laufen auch selects angenehm schnell
    Ich denke, also bin ich. - Einige sind trotzdem...

    Kommentar


    • #3
      Zu 2.: Meine Aussage bezog sich auf die von Dir angegebene Seite. Also ist es system- und plattenabhängig?

      Wie darf ich Deine Antwort zu 1. und 3. verstehen?

      Kommentar


      • #4
        2.
        wenn ich die seite inklusive kommentare richtig verstehe, is die maximale dateigröße (jede tabelle in mysql is ja eine datei) vom betriebssystem abhängig
        da rein theoretisch eein betriebssystem aber dateien mit ner maximalen größe von elfundzwanzig terabyte verwalten kann, obwohl die vorhandene festplatte aber nur 800MB groß, ist das auch plattenabhängig


        1. und 3.
        überleg dir was für infos du brauchst, befass dich mit normalisierung (falls noch nicht geschehen) und fertig
        ganz einfach ausgedrückt soll meine aussage heißen:
        - mache eine tabelle für alle kunden, egal mit was für nem buchstabe ihr name beginnt
        - leg einen index auf die spalte die den namenenthält, dann is ein WHERE kundename LIKE 'A%' nämlich schneller als ohne index
        Ich denke, also bin ich. - Einige sind trotzdem...

        Kommentar


        • #5
          Original geschrieben von mrhappiness
          - leg einen index auf die spalte die den namenenthält, dann is ein WHERE kundename LIKE 'A%' nämlich schneller als ohne index
          Schön, dadurch würden alle A-Kunden ausgewählt. Das Problem wäre aber ein anderes. Wie ich weiter oben schon schrieb: Kunde Nr. 27 wählt seine 200 Dezember-Einträge aus über 100.000 Einträgen (von allen Kunden) aus. Das dauert doch sicher einiges an Zeit. Und wenn dann noch 20 Kunden gleichzeitig damit arbeiten, dürfte das die Performance noch weiter herunterdrücken. Jedenfalls vermute ich das.

          Kommentar


          • #6
            war doch nur ein beispiel. wenn es möglich ist, dass ein kunde seine beiträge ausliest, dann geht das ja über die spalte kundeid oder?
            spricht etwas dagegen, einfach auf diese spalte nen index zu setzen?

            mehr dazu hier: http://www.mysql.com/doc/de/Query_Speed.html (auch die unterseiten lesen)
            Ich denke, also bin ich. - Einige sind trotzdem...

            Kommentar


            • #7
              Nein, gar nichts. Wenn Du als Experte das sagst, wird das sicher Hand und Fuß haben. Man müsste sich nur dann etwas mit der Indizierung befassen, sprich: Belesen.

              Kommentar


              • #8
                derzeit habe ich auch eine tabelle in verwendung, in der monatlich 50.000 einträge hinzugefügt werden, und zu guten zeiten greifen ca. 50 leute darauf zu, und wählen bis zu 500 einträge aus (die abfrage greift auf 2 tabellen zu)
                es ist trotzdem schnell, wie von mrhappiness gesagt mit einem index auf die id des users

                Kommentar


                • #9
                  wobei das noch kleine Datenmengen sind...

                  auf ne Mysql schulung haben sie mal was erzählt von ner anwendungen, die mehrere millionen zeilen in einzelnen tabellen hält...

                  ist sehr stark vom entwickler abhängig, wie schnell das system läuft und von der verwendeten architektur (Serverhardware/anzahl).

                  Macht der Programmierer mist is die anwendung lahm! durch optimieren von query kann man immer was rausholen (es sei denn, sie sind optimal )

                  gruss

                  Kommentar


                  • #10
                    Lieber vorher fragen, bevor hinterher alles falsch läuft.

                    Kommentar

                    Lädt...
                    X