Henryk Plötz: DBMSe -> prevayler

Beitrag lesen

Moin,

Was ich noch nicht ganz verstehe ist, wie Datenverlust effizient unterbunden wird, denn die Jobs werden ja vor der Ausfuehrung in eine Datei gespeichert. Dazu noch die regelmaessigen Speicherdumps.

Wie kann es sein, dass du etwas nicht verstehst was du im nächsten Halbsatz erklärst? Gespaltene Persönlichkeit?

Ja, in der voellig verhunzten Diskussion ist ja leider das Argument, dass es bei _einem_ Forum eben doch Entiateten gibt, die miteinander in Beziehung stehen (Nutzer, Sitzungen, Rechte, Relationentabelle_Nutzer_Rechte, Themenbereiche, Beitraege u.s.w.) und auf eine ganz flache Art und Weise zwar performant aber eben datenseitig nicht ganz richtig abgebildet werden.

Ach, jetzt auf einmal traust du dich Beispiele für Entitäten zu geben die du siehst und für relevant hältst? Na gut, dann kann ich dir ja jetzt endlich antworten und erklären warum ich da keine nutzbringend einzusetzenden Relationen sehe: Sitzungen gibt es (da HTTP) schonmal gar nicht, das war ein Brainfart deinerseits. Die Nutzer und die Beiträge stehen in keiner Beziehung (hier[tm], anderswo ist das anders). Rechte, gut, da sieht das fast ein bisschen anders aus, meinetwegen gibt es zwischen Nutzern und Rechten eine Beziehung, eine 1:1-Beziehung (ist das so?), man schreibt die Rechte also direkt dorthin wo man auch die Nutzerdaten stehen hat. Themenbereiche stehen hier ebenfalls nicht wirklich mit Beiträgen in einer Beziehung, das ist nur ein weiteres Textfeld in den Beiträgen. Es war sogar mal so dass da drinstehen konnte was will. Über die Beiträge und deren Beziehung untereinander hat Christian ja schon genug erzählt.

Der genannte Beitrag hat mir immerhin geholfen zu vestehen, was von Administratorenseite gemeint gewesen ist. I.p. Performance und so.

Du meinst http://forum.de.selfhtml.org/archiv/2004/9/89740/#m541766 hat dir dabei nicht geholfen? Hattest du nicht selbst wenigstens passiv anklingen lassen, dass du was davon verstündest? Solltest du tatsächlich mit einer einfachen Komplexitätsbetrachtung überfordert sein? Nagut, ich zeig's dir. Ist nicht schwer, du musst nur ein bisschen addieren und multiplizieren (das kannst du doch?):

Nehmen wir an, ein direkter Speicherzugriff würde 1 kosten, ein Speicherzugriff über einen Index kostet dann ca. 5 bis 10 (Hash berechnen, damit in den Index gehen, Element holen, vergleichen, ggbf. nächstes Element holen). Das Parsen und Optimieren einer SQL-Anfrage würde ich mit wenigstens 100 bis 1000 ansetzen (in Token zerlegen, auf die Grammatik matchen, beteiligte Feldnamen raussuchen, diverse Bedingungen überprüfen, Rechte überprüfen, Indices raussuchen, herausfinden wie die Query schnellstmöglich abgewickelt wird, etc.). Nehmen wir weiter an, der Thread würde n Beiträge enthalten (das ist eine Variable, damit kommst du doch klar?).

Für Datenstrukturen im RAM ergibt sich damit eine Zeitkomplexität[1] von ca. 5 + 1*n, für das RDBMS ca. 100 + 5*n[2]. Verstanden? (Preisfrage: Für welche n ist das RDMBS schneller?)

[1] Da sind noch Aktionen dazwischen die ich nicht berücksichtigt habe, wie das Kopieren aus dem Speicher in den Antwortbuffer. Das müssen aber beide Implementationen machen, würde sich also eh am Ende 'rauskürzen'.
[2] Man beachte dass ich hier zugunsten des RDBMS die jeweils kleineren Zeiten meiner Schätzung gewählt habe.

--
Henryk Plötz
Grüße aus Berlin
~~~~~~~~ Un-CDs, nein danke! http://www.heise.de/ct/cd-register/ ~~~~~~~~
~~ Help Microsoft fight software piracy: Give Linux to a friend today! ~~