nicht angemeldet
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!