Besserer Weg, Listen von Elementen zu erhalten: zwischengespeicherte serialisierte Daten vs Datenbankabfragen oder andere?
Ich habe viele Suchen zum Zwischenspeichern von Daten in Dateien durchgeführt ( serialisieren / unsialisieren vs json_encode / decode , var_export , igbonary ) und mysql-Abfragen (Optimierungen, gespeicherte Prozeduren , Abfrage-Cache ), aber in diesem Moment frage ich mich, was ist der beste Weg, einen konkreten Fall wie den folgenden zu optimieren.
Sorry im Voraus: Das ist ein langes Thema für eine kleine Antwort, denke ich, aber es ist notwendig, das Projekt zu verstehen. Und entschuldige mein schlechtes Englisch, das ist nicht meine Muttersprache.
Stellen wir uns vor, dass wir diese Datenbankbeziehungen haben.
Beschreibung der Datenbank (geschätzte Anzahl der Datensätze in Klammern):
- MODUL (10): ist die Art von Artikel, könnte Artikel, Forum Thema, Anzeige, Nachrichten ... sein
- ELEMENT (Millionen): jeder Typ mit einem Titel und etwas Text
- KATEGORIE (50): Kategorien (Tiere, Politik, Autos, Computer ...)
- TAG (Hunderttausende): Tags der Kategorie (zB für Politik: International, Frankreich, Barack Obama ...)
- ITEM_TAG (outch): Zuordnungen von Elementen und Tags
So haben wir mehrere Beziehungen, und jeder ist Recorder bei der ITEM Erstellung / Aktualisierung.
Ich habe bereits ITEM-Daten in Ordnern und Dateien im folgenden Beispiel zwischengespeichert:
%Vor% Und ich bekomme sie durch unserialize(file_get_contents($url)) , dieser Teil funktioniert wie ein Zauber!
Jetzt möchte ich die Listen der ITEMS optimieren, um sie mit verschiedenen Optionen anzuzeigen (zum Beispiel), für jede Anzeige mit einem Limit von 100 pro Paginierung:
- ALLE ARTIKEL
- ARTIKEL eines MODULS
- ARTIKEL einer KATEGORIE
- ARTIKEL einer KATEGORIE und eines MODULS
- ARTIKEL eines TAG
- ARTIKEL eines TAGs und einer KATEGORIE
- ARTIKEL eines TAGs und einer KATEGORIE und eines MODULS
Ich weiß bereits, wie man das in SQL macht und die Ergebnisse in einen Cache-Baum bringt.
Mein Problem mit diesen Cache-Dateien ist, dass wenn ein neues ITEM erstellt / aktualisiert wird, die Liste möglicherweise mit einer gewissen Strenge aktualisiert werden muss.
Erste Frage:
Was passiert also, wenn ITEs gleichzeitig erstellt / aktualisiert werden (also auch diese Listen)?
Tut der LOCK_EX von file_put_contents(); seine Arbeit, während er Dateien von file_get_contents(); holt?
Zweite Frage
Ich verstehe, dass mehr PHP funktioniert, weniger mySQL wird (und das andere), aber was ist der bessere (schneller anzuzeigen) Weg, diese Listen mit Paginierung zu tun, die jede Sekunde oder mehr angezeigt werden und nur modifiziert werden durch Hinzufügen / Aktualisieren eines neuen ITEM?
- Mein Cache-System (ich glaube nicht ...)
- Gespeicherte Prozeduren in mySQL
- Mehrere Datenbankserver und / oder mehrere Dateiserver
- Andere
Alle Ideen, Beispiele, Links sehr geschätzt.
P.S. : nur zum Spaß kann ich fragen "Wie funktioniert Facebook" und "Wie funktioniert stackoverflow"?
1 Antwort
Erste Frage :
Ihre Operationen sollten mit LOCK_EX in Ordnung sein. Die Dateien können gesperrt werden, wenn gleichzeitig auf sie zugegriffen wird, was die Vorgänge auf jeden Fall verlangsamen wird, aber alle Operationen sollten korrekt ausgeführt werden. Dies ist jedoch ein gutes Beispiel, warum Sie kein eigenes Cache-System implementieren sollten.
Zweite Frage :
MySQL wird auf jeden Fall schneller sein als Ihr Cache-System (es sei denn, Sie tun etwas ernsthafte Wicket-Programmierung und nicht in PHP). Datenbanken wie MySQL haben viel Arbeit bei der Optimierung ihrer Leistung geleistet.
Ich glaube nicht, dass gespeicherte Prozeduren in MySQL Ihnen in den obigen Beispielen einen wirklichen Vorteil gegenüber einfachen alten SELECT -Anfragen bieten.
Die Verwendung eines NoSQL-Ansatzes wie MongoDB kann Ihnen helfen, wenn Sie Sharding auf einem Server-Cluster verwenden. Dies ist schwieriger zu schreiben und mehr Server kosten mehr Geld. Es ist auch nicht klar aus Ihrer Frage, ob der Wechsel zu einem anderen Datenbanksystem eine Option ist.
Wenn Sie bei MySQL bleiben, ist es wahrscheinlich einfacher, Load-Balancing-Anwendungsserver als ein Datenbankservercluster zu implementieren. Aus diesem Grund wird mehr Arbeit von PHP bevorzugt, um mehr in MySQL zu arbeiten. Ich würde diesem Ansatz jedoch nicht folgen, weil Sie viel für nur einen kleinen Nutzen aufgeben.
Kurz gesagt, ich empfehle, dass Sie bei einfachen SELECT -Abfragen bleiben, um zu bekommen, was Sie brauchen. Führen Sie Ihre Anwendung und Datenbank auf separaten Servern aus und verwenden Sie den leistungsfähigeren Server für Ihren DB-Server.
PS. Facebook schreibt einen Pre-Compiler für PHP um den Code schneller laufen zu lassen. Meiner Meinung nach ist PHP keine sehr schnelle Sprache und Sie können bessere Ergebnisse von Python oder Node.js erhalten.
Stackoverflow verwendet ASP.NET MVC mit MS SQL Server. Sie haben einen einzigen großen leistungsfähigen Server für die Datenbank und verwenden DB-Abfragen anscheinend lieber wo sie können. Sie verwenden auch Lastenausgleich-Anwendungsserver, die von ihrem DB-Server getrennt sind.