Datenbanken und ähnliches im Vergleich

[phil]

Hallo zusammen.

Man hat mich beauftragt eine Seite neu aufzubauen.
Die Herren haben einiges an Traffic und einiges Profiling hat ergeben das MySQL da nicht mehr mithalten kann und auch Queries gab es so gut wie nichts mehr zu optimieren.

Aus PHP hat man schon alles rausgeholt. Schnelles PHP 5.3, Module gespart wo es nur geht, APC + Output-Buffering. Gecached wird vom Server auch einiges gut. Es liegt wie gesagt an der Datenbank.

Plan war also die Last von MySQL runterzunehmen und Memcached dazwischen zu stellen. So könnte die Last ein wenig aufgeteilt werden. Memcached würde wesentlich mehr abspeisen und erst wenn es wirklich nötig ist auf MySQL zugreifen.

Nachteil wäre natürlich der Datenverlust der entsteht falls das gute Stück mal down gehen sollte, allerdings wäre das die erste Lösung für mehr Performance.

Ich fing dann darüber nachzudenken - rein provisorisch, man weiß ja nie wie etwas wächst, auf Cassandra umzusteigen. Memcached + Cassandra - das wäre wohl noch ein bisschen schneller. Ich habe mich also erst einmal ein bisschen mit NoSQL - Datenbanken auseinadner gesetzt und bin auf MongoDB gestoßen.

Die Benchmarks die auf MongoDB ausgewiesen sind, zeigen allerdings das MongoDB schneller sein soll als Memcached! (MongoDB basiert auf Document Storage) - allerdings ist hier doch die Frage - kann ich mir einen weitere Server sparen? Warum Memcached + Cassandra wenn es _nur_ MongoDB auch tun würde?

Meine weitere Suche nach Benchmarks und "versus" und sonstigem hat leider nicht anderes mehr ergeben und nun suche ich den Rat der Weisen ;)

Und bitte, bitte - versucht jetzt nicht mir MySQl neu zu verkaufen. Es geht wirdklich um Memcached und NoSQL-Datenbanken - hier können gerne noch andere Optionen mit eingebracht werden.

Beste Grüße,
Phil

[Erik]

Was wird denn an Hardware eingesetzt?

[phil]

Was wird denn an Hardware eingesetzt?

1xQuad-Core AMD Opteron
8GB RAM (DDR2)
3x250GB, 7.2K, SATA (RAID5)

Es wäre aber kein Problem zu erhöhen. Geld spielt da keine Rolle. Zunächst soll die Technik richtig gewählt sein. Und bevor ich anfange ist halt echt die Frage. Kann ich mir den memcache sparen wenn MongoDB so gut ist?

Cassandra
Cassandra + Memcache
MongoDB
MongoDB + Memcache

Das sind die vier Möglichkeiten in meinen Augen.

LG, Phil

[Erik]

Wenn nur ein Server für alles zusammen eingesetzt wird, könnte doch erst mal die Trennung eine Alternative sein. Sprich: MySQL und Web-Server auf verschiedene Server verteilen.

Wieviel Traffic fällt denn so pro Tag an?

Zu deinen genannten Alternativen kann ich keine Empfehlungen geben - aber was spricht denn gegen einen dedizierten MySQL-Server oder eine Load-Balancer-Lösung für MySQL?

Auf Seite von PHP gibt es noch die Möglichkeit, einen Cache wie beim ZendFramework zu benutzen. Damit kommen die Abfragen erst gar nicht bei MySQL an ;-)

Grüße

[phil]

Wenn nur ein Server für alles zusammen eingesetzt wird, könnte doch erst mal die Trennung eine Alternative sein. Sprich: MySQL und Web-Server auf verschiedene Server verteilen.

So ist es bereits. Hatte ich vergessen zu erwähnen sorry. Ist aber die selbe Server-Konfiguration

Wieviel Traffic fällt denn so pro Tag an?

Sorry da kann ich dir gerade keine Auskunft geben. Beim Profiling kam raus das wirklich die DB überlastet ist.

Zu deinen genannten Alternativen kann ich keine Empfehlungen geben - aber was spricht denn gegen einen dedizierten MySQL-Server oder eine Load-Balancer-Lösung für MySQL?

Dagegen spricht das MySQL überfüllt ist mit Funktionen - der selbe Grund warum leute Lighttpd anstatt Apache einsetzen. Andere Datenbanken sind nun einmal schneller. Wer braucht bitte 9999 Kodierungen wenn er eh nur UTF-8 nutzt.. usw. usw.

Auf Seite von PHP gibt es noch die Möglichkeit, einen Cache wie beim ZendFramework zu benutzen. Damit kommen die Abfragen erst gar nicht bei MySQL an ;-)

Oder ich spare mir das Framework und nutze Memcached.

[dedlfix]

Hi!

Beim Profiling kam raus das wirklich die DB überlastet ist.

Beim Optimieren geht es in der Regel darum, individuelle Performance-Probleme zu lösen, also muss man auch die Lösungen auf das individuelle Problem zuschneiden, wofür man recht detailliert das Problem kennen muss. Was genau bedeutet "überlastet" in dem Fall? Ist die Festplatte zu langsam, so dass die Daten nicht schnell genug ermittelt werden können, ist der Hauptspeicher zu klein, dass Daten nicht gecachet werden können? Stehen die Requests Schlange, weil die Anzahl der gleichzeitig abgearbeiteten zu niedrig konfiguriert ist, CPU und Festplatten selbst langweilen sich aber? Sind Schreibzugriffe oder Lesezugriffe das problematische Glied in der Verarbeitungskette? Es gibt noch eine Menge Szenarien, die sein können. Für manche kann eine Lastverteilung auf mehrere Server inklusive Replikation eine Lösung sein, für andere eine Hardwareaufrüstung, und der Wechsel des DBMS kann auch eine sein.

Zu deinen genannten Alternativen kann ich keine Empfehlungen geben - aber was spricht denn gegen einen dedizierten MySQL-Server oder eine Load-Balancer-Lösung für MySQL?
Dagegen spricht das MySQL überfüllt ist mit Funktionen

Und diese Überfüllung ist der bremsende Faktor? Das liest sich so, als ob MySQL die vielen Funktionen einfach so verwendet, weil sie da sind und sich sonst langweilen würden, und deshalb keine Zeit mehr für wichtiges ist. Das ist ziemlich unglaubwürdig.

Andere Datenbanken sind nun einmal schneller.

Und der Aufwand, die Anwendung darauf umzustellen ist billiger als beispielsweise eine Hardwareaufrüstung?

Wer braucht bitte 9999 Kodierungen wenn er eh nur UTF-8 nutzt.. usw. usw.

Und? Dann lass doch die anderen einfach liegen. Außer Plattenplatz geht doch da nichts verloren.

Auf Seite von PHP gibt es noch die Möglichkeit, einen Cache wie beim ZendFramework zu benutzen. Damit kommen die Abfragen erst gar nicht bei MySQL an ;-)
Oder ich spare mir das Framework und nutze Memcached.

Was du dir nicht sparen solltest sind Messungen. Und zwar vom aktuellen Zustand und nach jedem Optimierungsversuch. Diese Messungen sollten nicht nur Details messen, sondern auch das angestrebte Gesamtziel berücksichtigen, also auch die Anzahl der vollständigen Requests, die mehr abgearbeitet werden konnten.

Lo!

[phil]

Und der Aufwand, die Anwendung darauf umzustellen ist billiger als beispielsweise eine Hardwareaufrüstung?

Es muss eh neugecoded werden. Die Firma hatte das Ganze auf den philipinnen coden lassen. 300 Files prozedualen Code, nahezu unkommentiert. Weder wartbar, noch skalierbar.

Ich persnölich ziehe PostgreSQl MySQL vor. Allerdings ist es sehr wahrscheinlich das man später horizontal skalieren muss und da machen sich die NoSQL-Datenbanken doch schon einmal besser.

Was du dir nicht sparen solltest sind Messungen. Und zwar vom aktuellen Zustand und nach jedem Optimierungsversuch. Diese Messungen sollten nicht nur Details messen, sondern auch das angestrebte Gesamtziel berücksichtigen, also auch die Anzahl der vollständigen Requests, die mehr abgearbeitet werden konnten.

Da hast du auf jeden Fall Recht. Ich bin allerdings soweit das ich sagen kann das dass Gesamtkonzept schrott war. Kein Seitenaufruf wo nicht 50% der Datenbankabfragen umsonst waren. Es wurden nicht einmal Joins verwendet. Stattdessen 2 Abfragen. Da der Code 100% nicht wartbar war, muss ich alles neu machen. Ordentlich OOP, dokumentiert, MVC. Dazu kommt die Trennung von statischen und dynamischen Files, ein ordentliches Caching-System und vor allem die richtige Software.

Die Frage ist nun ob es sich neben MongoDB noch lohnt, Memcached laufen zu lassen.

lg

[Vinzenz Mai]

Hallo,

Es muss eh neugecoded werden. Die Firma hatte das Ganze auf den philipinnen coden lassen. 300 Files prozedualen Code, nahezu unkommentiert. Weder wartbar, noch skalierbar.

das kommt mir bekannt vor: </archiv/2010/6/t198168/#m1330312>, Toprica.

Ich persnölich ziehe PostgreSQl MySQL vor. Allerdings ist es sehr wahrscheinlich das man später horizontal skalieren muss und da machen sich die NoSQL-Datenbanken doch schon einmal besser.

Das irgendwie auch: https://forum.selfhtml.org/?t=198576&m=1333840, mamapa.

Was du dir nicht sparen solltest sind Messungen. Und zwar vom aktuellen Zustand und nach jedem Optimierungsversuch. Diese Messungen sollten nicht nur Details messen, sondern auch das angestrebte Gesamtziel berücksichtigen, also auch die Anzahl der vollständigen Requests, die mehr abgearbeitet werden konnten.

Ja, sowas schrieb ich auch mal: https://forum.selfhtml.org/?t=198475&m=1333023, phil.

Die Frage ist nun ob es sich neben MongoDB noch lohnt, Memcached laufen zu lassen.

hmm?

https://forum.selfhtml.org/?t=198618&m=1334093, Puki?
https://forum.selfhtml.org/?t=198576&m=1333840, mamapa?

Sockenpuppenjagende Grüße

Vinzenz

[phil]

Ich oute mich ;)
Ist mir nur peinlich soviele Fragen zu stellen, dabei lese ich echt schon extrem viel GOOGLE.

[dedlfix]

Hi!

Ich oute mich ;)
Ist mir nur peinlich soviele Fragen zu stellen, dabei lese ich echt schon extrem viel GOOGLE.

Ach weißt du, niemand kennt dich hier. Du brauchst dich nicht hinter verschiedenen Namen zu verstecken. Für die Antwortenden und damit letzlich für dein Problem ist es hilfreich, wenn sie deinen Fall leicht wiedererkennen können, damit sie auch Details berücksichtigen können, die du früher schon mal erwähnt hast, aber jetzt grad zu erwähnen vergessen hast. Denn jede Teil-Lösung sollte auch einigermaßen ins Gesamtkonzept passen.

Lo!

[Ilja]

moin,

ich glaube das erste, was du tun musst, dich von deinen vorstellungen lösen. die sind offenbar so hart in stein gemeißelt, da ist es fast egal, was man sagt. zweitens, wenn du alles ein wenig lockerer siehst, pauschale aussagen wie "es liegt an der datenbank" nicht mehr machst, dann solltest du anfagen den hinweisen nachzugehen. ich habe den eindruck, du willst von uns noch mal deine meinung bestätigt haben, dass man das dbms auf jedenfall auf eine nosql wechseln muss.

wenn laut deiner aussage geld keine rolle spielt, dann würde ich dir vorschlagen, kaufe dir das know how für eine ordentliche analyse des problems ein. so kann das nur in die hose gehen.

Ilja

[phil]

Nachdem ich noch einiges mehr gelesen habe komme ich irgendwie zu dem Schluss das ich mich entscheiden sollte:
RDBMS + memcached + APC oder MongoDB + APC

Memcached oder MongoDB?:
http://permalink.gmane.org/gmane.comp.db.mongodb.user/1591

Wann memcached und wann APC zeigt ziemlich gut:
http://www.slideshare.net/benramsey/caching-with-memcached-and-apc?src=related_normal&rel=1479207

[Ilja]

Moin,

Nachdem ich noch einiges mehr gelesen habe komme ich irgendwie zu dem

Schluss das ich mich entscheiden sollte:

RDBMS + memcached + APC oder MongoDB + APC

mal ganz ehrlich, willst du hier nur, das wir deine meinung bestätigen oder suchst du wirklich hilfe ? deine meinung "es liegt am dbms" ist so in stein gemeißelt, dass du gar nichts anderes mehr hören willst. mein tipp für dich, wenn geld wirklich keine rolle spielt, kaufe dir das know how für eine gute analyse ein, sonst geht es in die hose. weil das, was scheinbar bei euch jetzt passiert, ist keine gute analyse.

Ilja

[phil]

Hi

RDBMS + memcached + APC oder MongoDB + APC

mal ganz ehrlich, willst du hier nur, das wir deine meinung bestätigen oder suchst du wirklich hilfe ? deine meinung "es liegt am dbms" ist so in stein gemeißelt, dass du gar nichts anderes mehr hören willst. mein tipp für dich, wenn geld wirklich keine rolle spielt, kaufe dir das know how für eine gute analyse ein, sonst geht es in die hose. weil das, was scheinbar bei euch jetzt passiert, ist keine gute analyse.

Nein ich bin _wirklich_ offen für Hilfe. Es ist nicht so das meine Meinung da fest in Stein gemeißelt ist.
Ich frage mich dennoch was denn effizienter ist. Unabhängig ob ich dafür etwas neues lernen muss (was ich verdammt gerne tu und es macht sich sicher nicht schlecht seine Skills von RDBMS auf NoSQL zu erweitern) oder nicht.

Es geht nicht immer nur darum den einfachsten Weg zu nehmen. Und vor allem möchte ich die Frage beantwortet haben ob MongoDB alleine ein RDBMS mit memcached ersetzen kann, wenn es wirklich nur um einfache Datenbankabfragen geht. Auktionen werden gespeichert, Userdaten werden gespeichert - mehr nicht.

Normalerweise würde ich eine Auktion aufrufen und sie _komplett_ in memcached speichern. Inklusive dem Biete stand. In den letzten Sekunden wenn es mit den Requests richtig hart kommt, wird der memcached zugeballert. Das Auktionsobjekt im Memcached hat ein Array für die User mit ID und Bidcounter für die verballerten "Bid-Coins" und die Auktione hat ein zweites Array mit den letztn 15 Bietenden (diese sollen immer angezeigt werden). Zusätzlich ein 3. Array mit auktionsid, bidcounter (anzahl der gesamt verschossenen BIDs) und Endzeit.

Es werden also jedes mal die 3 Arrays geabarbeitet. Ist die EndZeit auf 0 - wird alles in die DB gesschrieben. Den Usern werden die Coins abgezogen, die Auktionen wird beendet, der Gewinner bekommt ne Mail - usw.

Das würde das alte Problem lösen - einfach ein ordentlicheres System(wie gesagt - das _muss_ gemacht werden) und dazwischen schalte ich Memcached - so nehme ich die Last von der DB.

Bessere Hardware ist da nicht nötig. Das Profiling hatte ergeben:
Vom RAM wurden lediglich 8-12%, genutzt von der Festplatte waren 10% belegt, Traffice waren gerade mal 12% ausgenutzt von der monatlichen Verfügbarkeit von 2TB.

Ich habe mir als 3. dann mal das ganze System angeschaut und erst einmal geschlagene 6 Stunden gebraucht um die Datei mit dem "ich klicke auf Biete" Query zu finden, bzw den Queries, es sind nämlich alleine 8 Queries die bei jedem Biete Klick abgefeuert werden - wie gesat, es geht gar nicht.

Der Hoster (Rackspace) welcher den Server wartet (Managed Hosting) schrieb ebenfalls:

Based on what you've told me and the tickets you posted on myrackspace,
the main bottleneck is the database. The code needs to be more efficient
and maybe the database design can be improved.

Gut da steht nichts von Software-Wechsel. Kann es denn Schaden? Ich denke nicht. Es sind wirklich verdammt einfache Daten und auch nicht viele. Ein besseres Datenbank-Design habe ich längst im Kopf. Dazu kommt das die Herren in Ausland wollen, ich muss also wenn es hart auf hart kommt horizontal skalieren. Dann stehe ich da mit MySQL und APC - brauche den Cache und die Datenbank aber mehrfach - NoSQL und Memcached machen da beides einfacher. Und da bin ich bei meiner Frage wieder - wenn MongoDB so schnell ist - lohnt es sich überhaupt noch memcached zwischen zu schalten? Sich einen Cache zu sparen heißt sich viel administrative Arbeit zu sparen und es ist leichter wartbar - sicherer für die Daten bei einem Absturz und und und.

Ich hoffe jetzt ist meine Position leichter zu verstehen.
Ich nehme gerne Hilfe an. Auf MongoDB zu verzichten und lieber PostgreSQL/MySQL und memcached + APC zu verwenden ist für mich einfacher. Aber wenn MongoDB wirklich effizienter ist, dann lerne ich gerne dazu und mache mir die Mühe - PHP unterstützt MongoDB hervorragend. Nicht nur die Frameworks sondern auch viele Hilfe-Klassen sind vorhanden.

Beste Grüße, Phil

[EKKi]

Mahlzeit phil,

Ich habe mir als 3. dann mal das ganze System angeschaut und erst einmal geschlagene 6 Stunden gebraucht um die Datei mit dem "ich klicke auf Biete" Query zu finden, bzw den Queries, es sind nämlich alleine 8 Queries die bei jedem Biete Klick abgefeuert werden - wie gesat, es geht gar nicht.

Der Hoster (Rackspace) welcher den Server wartet (Managed Hosting) schrieb ebenfalls:

Based on what you've told me and the tickets you posted on myrackspace,
the main bottleneck is the database. The code needs to be more efficient
and maybe the database design can be improved.

Allein dieser Abschnitt ist für mich ein ganz klares Zeichen, dass

1.) das Datenbankdesign überarbeitungswürdig ist und dass

2.) der Code vermutlich von Grund auf neu geschrieben werden sollte.

Zu einem anderen Datenbanksystem zu wechseln weil "die Datenbank das Problem ist", halte ich für extrem übertrieben - weil "die Datenbank" (im Sinne von "das verwendete rDBMS") nämlich eigentlich gar nicht das Problem zu sein scheint, sondern die Verwendung der Datenbank (also die Tabellenstrukturen, die Art und Menge der Abfragen sowie der Code, der diese erzeugt).

Setze also an der richtigen Stelle an und behebe erst einmal die ganz offensichtlich bestehenden, gravierenden Probleme.

Wenn die Struktur dann sauber ist und der Codee effizient und dann *immer noch* Performance-Probleme auftreten, kannst Du - bei einem sauberen Schichtenmodell - das darunterliegende Datenbanksystem einfach gegen eins austauschen, dass Deinen Ansprüchen besser genügt. Das sollte aber immer eher einer der letzten Schritte sein.

Pferde zäumt man normalerweise auch nicht von hinten auf ...

Gut da steht nichts von Software-Wechsel.

Richtig. Aus gutem Grund nicht.

Kann es denn Schaden? Ich denke nicht.

Ich denke schon. "Never change a running system" - und da Du ja eh umfangreiche Änderungen vor hast, solltest Du Dich vielleicht erst einmal darauf konzentrieren. Wenn Du diese Änderungen vernünftig umsetzt, kannst Du anschließend immer noch das DBMS austauschen, wenn es nötig sein sollte.

Ein besseres Datenbank-Design habe ich längst im Kopf.

Dann setze doch erst einmal das um. Und bereinige bzw. entsorge den alten Schrott-Code (ich darf den doch so bezeichnen - hast Du schließlich auch ungefähr?).

Ich nehme gerne Hilfe an. Auf MongoDB zu verzichten und lieber PostgreSQL/MySQL und memcached + APC zu verwenden ist für mich einfacher.

Dann mach erstmal das. Ein Schritt nach dem anderen.

Ich wette, dass allein durch ein vernünftiges Datenbankdesign und effizienten Code schon ein immenser Performancegewinn erzielbar ist.

MfG,
EKKi

[phil]

Allein dieser Abschnitt ist für mich ein ganz klares Zeichen, dass

1.) das Datenbankdesign überarbeitungswürdig ist und dass

Auf jeden Fall.

2.) der Code vermutlich von Grund auf neu geschrieben werden sollte.

Sowieso.

Zu einem anderen Datenbanksystem zu wechseln weil "die Datenbank das Problem ist", halte ich für extrem übertrieben - weil "die Datenbank" (im Sinne von "das verwendete rDBMS") nämlich eigentlich gar nicht das Problem zu sein scheint, sondern die Verwendung der Datenbank (also die Tabellenstrukturen, die Art und Menge der Abfragen sowie der Code, der diese erzeugt).

Ja, das habe ich ja auch entnehmen können.

Ich wette, dass allein durch ein vernünftiges Datenbankdesign und effizienten Code schon ein immenser Performancegewinn erzielbar ist.

Das denke ich auch. Gut mal sehen, dann werde ich denke ich die rDBMS, memcached Schiene nehmen.

LG, phil

[dedlfix]

Hi!

Und der Aufwand, die Anwendung darauf umzustellen ist billiger als beispielsweise eine Hardwareaufrüstung?
Es muss eh neugecoded werden. Die Firma hatte das Ganze auf den philipinnen coden lassen. 300 Files prozedualen Code, nahezu unkommentiert. Weder wartbar, noch skalierbar.

So langsam kommen die Details zum Vorschein. Erst war das DBMS das bremsende Glied. Nun ist im ganzen System der Wurm drin.

Ich persnölich ziehe PostgreSQl MySQL vor.

Persönliche Vorlieben spielen anscheinend auch eine stärkere Rolle als die Eigenschaften der Technik. Ist zwar verständlich, beeinflusst aber die Findung der optimalen Lösung.

Allerdings ist es sehr wahrscheinlich das man später horizontal skalieren muss und da machen sich die NoSQL-Datenbanken doch schon einmal besser.

Hast du schon einmal verglichen, welche Möglichkeiten die jeweiligen Systeme bieten und vor allem was sie nicht können? Für Datenquellen, für die es keine direkte Unterstützung in PHP gibt, müssen alle Zugriffsmethoden in PHP erstellt werden. In solchen Fällen hilft dir nicht, dass das MySQL-Client-Modul in schnellem C-Code geschrieben ist. Bevor du dich für eine grobe Richtung entscheidest, solltest du zumindest ein paar realitätsnahe Versuche machen und ein wenig Erfahrung sammeln. Besonders wenn dir unbekannte Technik vorschwebt, die du nur vom Hörensagen kennst.

Da hast du auf jeden Fall Recht. Ich bin allerdings soweit das ich sagen kann das dass Gesamtkonzept schrott war. Kein Seitenaufruf wo nicht 50% der Datenbankabfragen umsonst waren. Es wurden nicht einmal Joins verwendet. Stattdessen 2 Abfragen. Da der Code 100% nicht wartbar war, muss ich alles neu machen. Ordentlich OOP, dokumentiert, MVC. Dazu kommt die Trennung von statischen und dynamischen Files, ein ordentliches Caching-System und vor allem die richtige Software.

Jeder Code benötigt Abarbeitungszeit. OOP und MVC und derartige Strukturierphilosophien helfen vorwiegend bei der Übersichtlichkeit und Wartbarkeit von Code. Geschwindigkeit kommt jedoch nicht von mehr Code.

Wenn du von "ordentlich OOP" sprichst, könnte man auch annehmen, du möchtest Erfahrungen und best practices von OOP anderer Systeme mit übernehmen. Doch nicht immer ist das was in Java gut und üblich ist, performant in PHP. Getter und Setter beispielsweise helfen ohne Zweifel beim Kapseln. Der Preis dafür ist jedoch bei jedem Zugriff ein zusätzlicher Funktionsaufruf inklusive dem dabei nötigen Datenjonglieren. Selbst wenn PHP so clever ist, die eigentlichen Daten bei einer Variablen-Kopie im Hintergrund solange wie möglich unkopiert zu lassen und stattdessen eine Quasi-Referenz zu verwenden, bis beide Variableninhalte auseinander laufen, so ist zumindest die Verwaltung der Variablencontainer notwendig. Wenn nie mehr als ein direkter Zugriff auf die gekapselte private Eingenschaft vorgesehen ist, ist das nur Aufwand mit hinterfragungswürdigem Nutzen. - Andere Systeme kennen Datenverwaltungsobjekte wie Dictionarys und Collections. Diese ähnlich in PHP nachzubilden ist vor allem aufwendig. PHP hat mit seinem Datentyp Array eine einfache und zugleich vielfältig nutzbare Komponente. Hier heißt es, anderweitig gesammelte Erfahrungen nicht stur 1:1 umzusetzen sondern zu schauen, sondern die Lösung für eine Aufgabenstellung unter Berücksichtigung der individuellen Möglichkeiten des Zielsystems zu erarbeiten. - Das waren nur mal zwei Beispiele, wie man sich mit besten Absichten Performancebremsen einbauen kann. Strukturierung ist wichtig, aber der dafür zu bezahlende Preis ist auch betrachtenswert.

Die Frage ist nun ob es sich neben MongoDB noch lohnt, Memcached laufen zu lassen.

Individuell messen.

Lo!

[Vinzenz Mai]

Hallo,

Und bitte, bitte - versucht jetzt nicht mir MySQl neu zu verkaufen. Es geht wirdklich um Memcached und NoSQL-Datenbanken - hier können gerne noch andere Optionen mit eingebracht werden.

ich habe den Eindruck, das Leute, die sich Phil nennen, sich auf den Weg, den sie gefunden zu haben glauben, versteifen.

MySQL tuts für viele große, sehr große und auch trafficlastige Seiten, andere wechselten zu Microsoft :-)

Freundliche Grüße

Vinzenz