nicht angemeldet
Mysql-Bearbeitungszeit
moin!
bin grad mit der planung eines neuen projekts beschäftigt.
nun hat sich die frage gestellt, ob ich alle infos des portals in die selbe db stecken soll.
so habe ich also einmal eine 20MB große Tabelle, welche momentan bereits verwendet wird.
hier würden, wenn nichts dagegen spricht, noch 60MB hinzukommen;
jedoch weiß ich nicht, ob daraufhin noch die performance erhalten bleibt. schließlich will ja niemand auf den seitenaufbau warten und genausowenig auf die ermittlung der infos aus der DB.
die infos sind unterteilt in (viele) kategorien.
beim aufruf einer kategorie erfolgt also eine mysql-anfrage mit einem WHERE kategorie="$selected_cat" argument. ebeneso findet bei suchanfragen eine select where match against -anfrage für einen volltextindex statt. sind diese beiden zugriffe auch dann noch zeitlich akzeptabel zu verarbeiten oder zwingt das den server in die knie. hab nur ein webspace paket bei "http://ackermedia.de/technik.server.htm/633d8aebeae...AM" und muss mir wohl die ressourcen des server mit anderen webmastern teilen :( also zu viel ram stehen wohl nicht zur verfügung, falls das hierbei relevant sein sollte...
danke für tipps
ps: das ganze zu testen halte ich für relativ aufwändig, wenn von vornherein feststeht, dass es nicht/nur langsam geht!
-
yo,
ps: das ganze zu testen halte ich für relativ aufwändig, wenn von vornherein feststeht, dass es nicht/nur langsam geht!
das wird dir meiner meinung nicht ersparrt bleiben, da es keinen besseren weg als trial on error gibt, was die performance bei datenbanken betrifft. erfahrung und theorie können einem helfen, aber es kommt trotzdem immer wieder zu unerwarteten ergebnissen. es hängt halt einfach von zuvielen faktoren ab, ob der zugriff noch schnell genug erfolgt oder nicht. alles andere wäre "blonde locken quatschen".
Ilja
-
yo,
mir ist da noch ein stichwort "Partitionierung" eingefallen, glaube aber nicht, dass mysql das unterstützt. eventuell könntest du die tabelle von hand denormalisieren und die einzelnen kategorien in verschiedene tabellen aufteilen. aber das ist doch mit viel pflegeaufwand verbunden. und auch hier musst du es vorher ausprobieren.
Ilja
-
-
nicht die größe der db ist entscheidend! sondern deren struktur.
nur eine passende modellierung der entities mit beziehungen und art des zugriffs sorgt für einen zufriedenstellenden erfolg. schlüsselattribute werden natürlich indiziert.die konkreten zeilen findet das db system eh per halbschrittverfahren. da spielt es kaum eine rolle, ob eine tabelle hunderte oder millionen zeilen hat.
so kann die db hunderte von mb groß sein und die antwortzeiten liegen im kaum spürbaren bereich.
-
yo,
nicht die größe der db ist entscheidend! sondern deren struktur.
das ist schlicht weg falsch, die größe spielt eine sehr entscheidene rolle, sogar die inhalte, bzw. die kardinalität tut es. die struktur ist sicherlich auch ein wichtiger aspekt, aber nur einer unter vielen.
die konkreten zeilen findet das db system eh per halbschrittverfahren. da spielt es kaum eine rolle, ob eine tabelle hunderte oder millionen zeilen hat.
kannst du mal verraten, woher du diese information nimmst ? das ist nämlich nonsense
so kann die db hunderte von mb groß sein und die antwortzeiten liegen im kaum spürbaren bereich.
hast du schon mal mit so großen datenbanken gearbeitet ?
Ilja
-
was ist größe? die von dir vorgetragenen aspekte gelten sicherlich für lineare suche.
mit aussagen sollte man immer vorsichtig sein. besonders wenn diese persönlich werden.
gerade durch suche mit halbschrittverfahren ist es überhaupt möglich in großen datenbeständen sinnvolle antwortzeiten zu erhalten. hierin liegt die natur eines db-systemes. daher spielt die größe kaum eine rolle, da jede neue 2-potenz lediglich einen neuen suchschritt erfordert, aber die menge verdoppelt.ich habe in den jahrzehnten mit vielen, sehr sehr sehr sehr großen datenbeständen gearbeitet. du kannst dir sicherlich vorstellen wie groß stücklisten von automobilen sind, bis zur kleinsten schraube inklusiver der versionierung. hierzu gehörten neben den 'großen' oracle, db2, dl1, dbanswer ... auch die 'pc' basierten wie dbase, access, paradox ??? und viele nicht so bekannte 'eigenprodukte'. dl1 ist übrigens der urvater 'sortierter listen' für suche nach dem halbschrittverfahren.
-
yo,
also, ich bin sprachlos. unsere meinungen gehen einach zu sehr auseinander. wir können sicherlich über den begriff größe philosophieren und sie infrage stellen. aber ich weiß nicht so recht, ob beim einem fullscan über eine tabelle(n) mit 100 oder 10 millionen datensätze man behaupten kann, größe spielt keine rolle. mir fehlt da irgendwie die motivation dazu.
und das gemischt mit der aussage, daten-design wäre alles, wo doch die frage nach den qualitätsmerkmalen eines designs nicht nur die performance im vordergrund steht, sondern auch begriffe wie wartbarkeit und diese oftmals im widerspruch zur performance steht....
halbschrittverfahren in einer unsortierten menge....
Ilja
-
fullscan, unsortierte menge. da liegen schon die wurzeln des übels.
diese begriffe stehen für dateien und deren inhalte.
im gegensatz dazu sind datenbanken sehr wohl geordnet und konzeptionell durchdacht. das unterscheidet diesen datenbestand von einem chaotischen.wegen des geplanten und sinnvoll geordneten datenbestandes kann hier dann auch geplant und sinnvoll gezielt zugegriffen werden. das reduziert natürlich den aufwand deutlich.
der nachteil liegt hierbei selbstverständlich beim einfügen neuer daten, da diese erst im datenbestand entsprechend eingeordnet werden müssen, was natürlich kraft kostet.hier gibts dann auch oft konflikte mit der wartbarkeit und performance. da gehen die meinungen tatsächlich auseineinder, was normalisierung und redundanz betrifft. grundsätzlich sollte aber ein solcher 'rückbau' erst nach vollständig idealem modell erfolgen.
-
yo,
im gegensatz dazu sind datenbanken sehr wohl geordnet und konzeptionell durchdacht. das unterscheidet diesen datenbestand von einem chaotischen.
wir werden bei der unterschiedlichen auffassung von datenbanken auf keinen gemeinsamen nenner mehr kommen.
ich mach dir einen vorschlag. mache eine tabelle in oracle, die bietet dir sehr viele funktionalitäten. erstelle dort eine tabelle, mit einer id, vorname, nachname, straße, plz, ort, eben eine typische tabelle. gebe bitte zuerst 10 datensätze ein und gebe mir alle datensätze deren nachname mehr als einmal vorkommt mit deren anzahl und allen spaltenattributen. setze timing auf on und führe die abfrage aus.
das gleiche machst du mit einem datenbestand von 10 millionen, wobei du deine orndung nach belieben ansetzen kannst, und dann gebe das gleiche ergebnis aus und sage mir, ob beide ausführungszeiten gleich waren.
Ilja
-
die definition von 'datenbank' mag im volksmund zwar unterschiedlich sein, in der informationstechnik ist diese aber ziemlich eindeutig.
die strategischen vorgehensweisen nicht nur für count sind bei den datenbankherstellern allgemein bekannt. eine festlegung eines testes auf einen bestimmten db-hersteller ist daher sekundär. ausnahmen bilden hier nur db's, welche bestimmte stärken durch gezielte abstriche in der funktionalität gewollt erreichen.
ich habe nie die position vertreten, daß bei unterschiedlich großen datenbeständen die antwortzeiten gleich sind. das dies nonsens ist, brauche ich hier wohl nicht zu betonen.
es ist halt in der natur der sache, daß eine verdoppelung der datenmenge legiglich einen suchschritt mehr erfordert, wenn daten nicht chatotisch, sondern geordnet sind, und mit halbschrittverfahren darin gesucht wird. dies ist allgemein bekannt und kein patent eines speziellen db-herstellers.-
yo,
die definition von 'datenbank' mag im volksmund zwar unterschiedlich sein, in der informationstechnik ist diese aber ziemlich eindeutig.
was aber nicht heißt, dass jede datenbank auch "sortiert" ist. eine datenbank kann sehr wohl aus nur einer tabelle bestehen (systemobjekte mal ausgenommen) und diese sind nun mal bekanntlich unsortiert.
die strategischen vorgehensweisen nicht nur für count sind bei den datenbankherstellern allgemein bekannt. eine festlegung eines testes auf einen bestimmten db-hersteller ist daher sekundär.
suche dir das dbms aus, ich lasse dir da freie wahl.
ich habe nie die position vertreten, daß bei unterschiedlich großen datenbeständen die antwortzeiten gleich sind. das dies nonsens ist, brauche ich hier wohl nicht zu betonen.
zitat: "nicht die größe der db ist entscheidend! sondern deren struktur."
es ist halt in der natur der sache, daß eine verdoppelung der datenmenge legiglich einen suchschritt mehr erfordert, wenn daten nicht chatotisch, sondern geordnet sind, und mit halbschrittverfahren darin gesucht wird.
falsch, indizies sind kein allheilmittel. um einen performance-gewinn damit zu erzielen, müssen bestimmte bedingungen gegeben sein. eine faustregel besagt, fragt man über 10% des datenbestandes ab, so wird die benutzung eines entsprechenden indexes die abfrage eher verlangsamen als beschleunigen. auch spielt die kardinalität eine rolle. besteht die spalte zum beispiel nur aus zwei werten wie "m" oder "w" so können auch hier probleme auftreten, weobei dieses noch mit einem bitmap index lösen könnte, welchen aber nicht alle rdms unterstützen. mit anderen worten, ob man überhaupt einen index sinnvoll einsetzen kann, hängt von vielen faktoren ab. eine davon ist die menge der daten, die abgefragt werden soll. und die menge der daten, die abgefragt werden, stehen ohne zweifel im zusammenhabg damit, wiviele daten ich eigentlich in den tabellen zu stehen habe.
ich will es mal so ausdrücken. bei einer datenbank mit einem bestand von 100 datensätzen ist es für die performance schnuppe, wie dein datendesign aussieht. es wird immer schnell genug gehen. bei einem datenbestand von 10 millionen datensätzen werde ich immer eine abfrage finden, die dein wunder-design aus den nähten platzen läßt. und somit sind solche aussage, wie du sie gemacht hast falsch.
Ilja
-
hallo ilja,
worum geht es dir eigentlich? die tatsachen habe ich weder erfunden noch beeinflußt. ich gebe sie hier lediglich wieder.
aus wie vielen tabellen eine datenbank besteht ist kein wunschdenken, sondern das ergebnis einer analyse zum datendesign. ich gehe davon aus, daß dir dieses bekannt ist. begriffe wie relation, normalisierung usw. wollen wir hier ja nicht sinnlos ausdiskutieren. zwischen sortiert und organsiert besteht ein nicht zu verwechselnder unterschied.
wenn du eine abfrage findest, welche 'mein' wunder-design aus allen nähten platzen läßt, wurde diese anforderung bei der analyse vergessen, oder diese anforderung wurde nicht verlangt. um wie viele datensätze es konkret geht, spielt hierbei keine rolle.
zudem sollen hier keine wunder produziert werden.datenbanken sind organsiert. wie diese organisation im ergebnis aussieht, ist folge der analyse und designs. in der regel gibt es hier auch sortierungen.
in zeitgemäßen softwarearchitekturen ist die schnittstelle zur persistenzschicht eh nur als objektmodell vorhanden. wenn dort bspw. n:m beziehungen physisch durch eine zwischentabelle abgebildet werden, ist dies diesseits der schnittstelle völlig unbekannt. diese, natürlich zwangsläufig sortierte und indizierte, tabellen werden völlig automatisch von der persistenzschicht gemanaged. ein schönes beispiel hierfür ist die CMP (container managed persistenz) der entity-beans aus java enterprise.
-
yo,
worum geht es dir eigentlich? die tatsachen habe ich weder erfunden noch beeinflußt. ich gebe sie hier lediglich wieder.
du tut so, als wenn deine meinung gott-gegeben ist und man zu keinen anderen schlüßen kommen kann. sozusagen ein messias des daten-designs. worum es mir geht ist aufzuzeigen, dass solche pauschalen aussagen wie "größe ist nichts, daten-design ist alles" falsch sind. daten-desgin ist ein sehr wichtiger aspekt, aber sie ist nicht nur für die performance zuständig und damit kann man auch nicht alle probleme aus der welt schaffen. ein daten-design ist immer ein kompromiss von vielen faktoren. es gibt neben performance noch andere qualitätsmerkmale einer datenbank, wie bereits angesprochen ist die wartbarkeit eines davon und diese läuft oftmals kontrair zu der performance. und selbst wennn man es für die performance optimiert, stößt man immer noch auf probleme, die von sehr großen datenbeständen kommen und kaum lösbar sind.
aus wie vielen tabellen eine datenbank besteht ist kein wunschdenken, sondern das ergebnis einer analyse zum datendesign.
wäre dem so, würden die datenbanken, bzw. das design bei gleichen vorgaben immer gleich aussehen. dem ist aber nicht so, viele wege führen nach rom und so werden unterschiedliche menschen zu unterschiedlichen ergebnissen kommen.
zwischen sortiert und organsiert besteht ein nicht zu verwechselnder unterschied.
du machst die sache viel zu kompliziert. mir ist es egal, ob du deine datenbanken sortiert oder organisiert nennst, dass sind nur begriffe. mein angebot steht, du kannst walten und schalten wie du willst und ein daten-design nach deiner wahl aufbauen. ich sorge nur für einen kleinen datenbestand und einen sehr grpßen und gebe dir eine abfrage vor. dann sehen wir in der praxis, ob deine assuage stimmt. alles andere ist geschwafel.
Ilja
-
ich werde nun letztmals etwas hier äußern:
nochmal: ich bin kein 'messias' oder was du auch immer meinst. diese äußerung beinhaltet unterschwellig eine persönliche abwertung. dies hast du bereits schon vorher einmal gemacht. ich für meine person lege wert auf die lösung in der sache und nicht auf einen kampf zwischen personen, wo nur einer überlebt, oder um rechthaberei.
es geht hier nicht um meine meinung! ich habe die notwendigkeit einer analyse werder erfunden noch bin ich schuld daran. es ist halt in der natur der sache, daß wenn ich etwas neues erstellen möchte, zuvor die 'birne' einschalten muß und zu überlegen habe, wie dies gestaltet werden soll. wenn dir dies zu kompliziert ist, und du dich gleich ans werk machst, wird dies idr später zu schwierigkeiten führen, welche noch komplzierter sind und zu mehr kopfschmerzen führen.
wenn du für einen auftraggeber gegen geld eine lösung erstellst, möchte dieser mit sicherheit, daß du dir VORHER genügend gedanken darüber machst, wie die datenbank zu gestalten ist.und nochmal: schnelle suche besteht nicht darin, jede schachtel einzeln zu öffnen, sondern in einem system, dies zu vermeiden. hierfür hat sich das halbschrittverfahren etabliert, welches eine sortierung voraussetzt. diese erfindung und notwendigkeit ist weder meine meinung noch bin ich schuld an dieser tatsache. diese erkenntnisse werden doch schon im mathe-unterricht der schule vermittelt oder etwa nicht?
-
yo,
es geht hier nicht um meine meinung! ich habe die notwendigkeit einer analyse werder erfunden noch bin ich schuld daran.
dir ist aber schon klar, dass wir nicht um die notwendigkeit einer analyse diskutieren, sondern darum ob man jede datenmenge in einer datenbank durch geeignete strukturen so behandeln kann, dass durch die größe es zu keinen auswirkungen bei der verwendung der datenbank kommt.
und nochmal: schnelle suche besteht nicht darin, jede schachtel einzeln zu öffnen, sondern in einem system, dies zu vermeiden.
interessant, wie vermeidest du es, wenn jemand mal in jede schachtel schauen will oder sagen wir in 50% der schachteln. dann wird dir dein halbschrittverfahren nämlich nichts helfen. und das scheinst du nicht zu begreifen.
also, in der theorie werden wir uns nicht einig werden. deshalb habe ich dir das an gebot gemacht, dass in der praxis auszuprobieren. du kannst das abgebot annehmen oder aber du hast genug arsch in der hose, um einen rückzieher zu machen. alles andere ist nur blonde locken gequatsche.
Ilja
-
-
-
-
-
-
-
-
-
-
-
-
Hi,
die größte MySQL-Tabelle, die mir bisher unter die Finger kam hatte 500.000 Datensätze (vermutlich wird die demnächst aber noch größer).
Beim simplen Zugriff über SELECT * FROM irgendwas WHERE nochwas macht's keinen Unterschied her, ob du 100 oder 100.000 Einträge in der Tabelle hast. Sobald aber Dinge wie ORDER BY dazukommen, spürst du du den Unterschied deutlich, dann kommt's auch mal dass die Abfragezeiten > 1 Sekunde sind.
E7