nicht angemeldet
Frage zu Datenbankstruktur / akzeptabler Tabellengröße
Rolf BMahlzeit!
Meine Datenbank-Tabellenstruktur bereitet mir Kopfzerbrechen…
Im vorliegenden Fall geht es um [derzeit bis zu] vier Geschäftsfilialen, die alle auf die selben Ressourcen zurückgreifen (Standort A muss daher wissen ob eine Ressource in Standort B, C, D vorrätig, und wenn ja, auch verfügbar ist). Diese Ressource muss dann auch noch mit dem vorhandenen KundInnenportfolio aller Standorte abgeglichen werden.
Die Intuition meint, für jeden Standort eine eigene Tabelle aufzusetzen; - dann gestaltet sich aber jeder Query mit mehreren JOINs doch recht mühsam (und kapazitätenintensiv...?).
Lösung zwei wäre eine einzige große Tabelle, in der sozusagen ALLES gespeichert wird.
Nur - ab wann wird eine Tabelle ZU groß? Gibt es dazu entsprechende Erfahrungswerte? Traut sich jemand, dazu über den Daumen eine Schätzung abzugeben? Ich freue mich auch sehr über einen Verweis auf Blog-Artikel zu diesem Thema!
Danke, Konrad.
-
Die Intuition meint, für jeden Standort eine eigene Tabelle aufzusetzen; - dann gestaltet sich aber jeder Query mit mehreren JOINs doch recht mühsam (und kapazitätenintensiv...?).
Du wirst die Grenzen kaum reißen, selbst wenn Du den Server unter Windows betreibst (wozu ich definitiv nicht raten würde)
Falls Du aber Amazon bist kannst Du immer noch clustern, partionieren und mergen.
Was mir aber Sorgen macht: Wenn Du das nicht weißt, erscheint mir die Idee, sowas selbst programmieren zu wollen, als „extrem sportlich“. Gibt es kein fertiges ERP-System, das kann, was Du willst?
-
Du wirst die Grenzen kaum reißen, selbst wenn Du den Server unter Windows betreibst (wozu ich definitiv nicht raten würde)
Die Idee ist wohl, einen Server (/eine Partition) anzumieten und nicht selbst sozusagen zu betreiben - wahrscheinlich klassisch APACHE.
Die Frage, die mich da eher umtreibt: wie merkbar sind die Performanceverluste, wenn ich eine MySQLI Abfrage aus vier Tabellen zusammenstellen muss - im Benchmark Vergleich zu einer?
-
Du wirst die Grenzen kaum reißen, selbst wenn Du den Server unter Windows betreibst (wozu ich definitiv nicht raten würde)
Die Idee ist wohl, einen Server (/eine Partition) anzumieten und nicht selbst sozusagen zu betreiben - wahrscheinlich klassisch APACHE.
Die Frage, die mich da eher umtreibt: wie merkbar sind die Performanceverluste, wenn ich eine MySQLI Abfrage aus vier Tabellen zusammenstellen muss - im Benchmark Vergleich zu einer?
Was Du wohl dafür brauchst ist ein Union, kein Join. Und falsch machen kann man soviel, dass die Verzögerungen durch die Ergebnisvereinigung kaum spürbar sind, die liegen, geeignete Hardware vorausgesetzt, im Mllisekundebereich. Ansonsten wäre (wohl) allenfalls ein RANGE COLUMNS partitioning angebracht.
Aber ich glaube nicht, dass in der Firma so viele Daten anfallen, dass das notwendig sein könnte. Bei Milliardenumsätzen haben die Spezialisten für sowas…
Die Idee ist wohl, einen Server (/eine Partition) anzumieten und nicht selbst sozusagen zu betreiben - wahrscheinlich klassisch APACHE.
Du bringst mich echt ans Limit.
-
Danke Rolf, Danke Raketenwilli
@ Raketenwilli
Du bringst mich echt ans Limit.
Warum? Viele Hostingprovider bieten da doch mittlerweile vernünftige Lösungen an? Wird kaum auf einem 2 Euro Discount Webspace gehostet werden 😅
-
-
-
-
Hallo Konrad,
Wie Raketenwilli schrieb, ist es ein UNION, kein JOIN, der hier sinnvoll ist. Wenn du eine Artikelstammtabelle hast, kannst du natürlich 4 Standortquerys per LEFT JOIN dazupacken, aber dann hast du die Spalten für die Standorte vierfach und das ist mühsam in der Handhabung. Der UNION gibt Dir eine Row pro Artikel und Standort.
Die Standort ID musst du dann aber als Konstante in die Teilquerys einsetzen, sonst weißt du nicht, wo die Ressource ist. Und an dieser Stelle folgt die Erkenntnis, dass man alle Standorte in eine Tabelle packt und eine Spalte für die Standort-ID ergänzt.
Das Größenlimit der Tabelle hängt am DBMS und der verwendeten DB Engine (z.B. myisam/innodb). Solltest du es sprengen, kann Partitionierung helfen. Die erfolgt aber konfigurativ in der DB und nicht im Programm von dir.
Rolf
--
sumpsi - posui - obstruxi -
Technisch gesehen wird eine Tabelle zu groß, wenn der Primary-Key nicht mehr ausreicht.
Bis es aber soweit ist wird wohl eher die Usability dir sagen, dass es zu viel wird. Wenn eine Datenbankabfrage einfach zu lange dauert. Welche Zeitspanne das ist, hängt meiner Meinung nach von der Art und Weise der Verwendung ab und der Häufigkeit der Verwendung ab. Ich selbst bin genervt wenn ich schnell auf Informationen zugreifen will so z.B. News, Sport, Suchanfragen etc...
Bei anderen Webseiten wie Reise-Buchungsmaschinen oder Vergleichsseiten dulde ich auch eine Wartezeit von mehreren Sekunden.Ebenfalls wichtig ist die erwähnte Häufigkeit der Anwendung. Wie oft schaut ein User in die übermüllte Log-Datenbank? Wichtiger ist natürlich dass die täglich mehrfach benutzte Kundendatenbank schnell liefert.
Wenn eine Datenbank zu groß wird gibt es immer noch Möglichkeiten. Braucht es wirklich alle Datensätze? Wenn nein, kann man die Datensätze vielleicht einfach löschen? Wenn nicht, kann man sie dann unter umständen in eine Datawarehouse schieben? Oder Querys effizienter schreiben (gibt meistens immenses Potential).
Gruß
Testdatenbank-Rex-
Hallo T-Rex,
Technisch gesehen wird eine Tabelle zu groß, wenn der Primary-Key nicht mehr ausreicht.
An diese Grenze stößt Du vielleicht, wenn Du einen tinyint als Primary Key verwendest. Bei einem int-Key wird es schon mühsam, und im Zweifelsfall nimmst Du Bigint.
Danach kannst Du dich dann mit bis zu 1024 Tablespaces zu je 256TB totpartitionieren, bis InnoDB an seine technischen Grenzen stößt.
Und ich würde vermuten, dass diese Tabelle immer noch fix ist, solange die abgerufenen Datenmengen in Grenzen bleiben und die Indexe passen, so dass nicht versehentlich ein Tablescan anläuft.
Eine DB wird vor allem durch ungeschickte Querys oder unpassende Indexe langsam und nicht so sehr durch ihre Größe. Oder durch zu viele gleichzeitige Zugriffe, die sich auch mit Cache-Speicher nicht mehr erschlagen lassen. Aber dafür gibt's dann geclusterte Server. Mit Einwurf kleiner Münzen beim Serverhersteller ist hier vieles machbar. Irgendwie müssen Fratzenbuch und Google es ja schaffen, die ganze Welt zu bedienen.
Bei 4 Standorten würde ich jedenfalls nicht über eine Partitionierung nachdenken, nicht per DDL und schon gar nicht in der Software.
Rolf
--
sumpsi - posui - obstruxi
-