Was kostet auf jeder Seitenseite mehr Geld - Datenbankschreibvorgänge oder Dateischreibvorgänge?

Question

Was ist die effizienteste Lösung, wenn Sie Daten auf jeder Seite in Ihrer Anwendung aufzeichnen müssen - sollten Sie in eine Datei schreiben oder in die Datenbank schreiben?

Oder vielleicht auch nicht - vielleicht sollten Sie die Daten im Speicher oder in einer Datei zwischenspeichern und nur gelegentlich in die Datenbank (oder in das Dateisystem, wenn Sie einen Speichercache verwenden) schreiben?

Answer 1

Wenn es nur eine kleine Menge von Daten ohne nachfolgende Nachschlagevorgänge aufzeichnet, ist der direkte Datei-I/O fast garantiert effizienter. Sie verlieren jedoch alle Vorteile eines DBMS - Indizierung, transaktionale Integrität (wirklich, ACID im Allgemeinen), gleichzeitigen Zugriff, etc.

Es klingt fast wie Sie reden über, was auf einfache Protokollierung ausmacht. Wenn dies der Fall ist und Sie häufig keine komplexen Abfragen für die resultierenden Daten durchführen müssen, sind Sie wahrscheinlich besser mit einfachen Datei-I/O-Operationen konfrontiert, wenn die Leistung ein ernsthaftes Problem darstellt. Achten Sie jedoch auf Probleme beim gleichzeitigen Schreiben.

Wenn die Eigenschaften eines RDBMS wünschenswert sind, können Sie SQLITE verwenden, was Ihnen bei vereinfachten Ladevorgängen eine höhere Leistung als die meisten RDBMS mit weniger Overhead bringt, was einige der Vorteile verursacht (hochgradig gleichzeitiger Zugriff und Verfügbarkeit) über das Netzwerk zu anderen Maschinen sind ein paar der "biggies"). Im allgemeinen Fall wäre es jedoch immer noch nicht so schnell wie bei einem einfachen Datei-I/O.

Ihre spätere Erwähnung, dass es sich um eine Seitenansicht handelt, veranlasst mich zu fragen: Erhöhen Sie einen Zähler, anstatt Daten über die Seitenansicht zu protokollieren? Wenn dem so ist, würde ich dringend vorschlagen, mit etwas wie SQLite zu gehen (etwas wie UPDATE tbl SET counter = counter + 1). Sie möchten wirklich nicht in die Timing-Probleme eingreifen, die dabei involviert sind - wenn Sie es nicht richtig machen, werden Sie anfangen, bei gleichzeitigem Zugriff zu verlieren (A liest "100", B liest "100") , A schreibt "101", B schreibt "101"; B hätte 102 schreiben sollen, aber das kann man nicht wissen).

Answer 2

Das hängt davon ab.

Und es wirklich tut: es hängt von dem DBMS und/oder dem OS + Dateisystem ab, das Sie verwenden. Mit anderen Worten: Ihre Laufleistung variiert.

Wenn Sie nur Daten irgendwo anfügen, sollten moderne DBMS/OS + Dateisysteme dies gleich gut und schnell handhaben. Probleme treten auf, wenn Sie Daten ändern möchten.

Caching - hängt auch davon ab, welche Art von Caching-Granularität Sie sich leisten können (müssen jeden Schritt protokolliert crash-sicher im Gegensatz zu potenziellen Einsparungen).

Answer 3

Das hängt stark von Ihren Anforderungen für die Datensicherheit ab. Wenn Sie es sich leisten können, im Falle eines Absturzes einige Daten zu verlieren, ist es sicher die effizienteste Methode, die Daten im Speicher zu behalten und sie regelmäßig in einen persistenten Speicher zu schreiben.

Bearbeiten: Sie erwähnten Seitenaufrufe. In diesem Fall würde ich die Zähler im Speicher behalten und periodisch eine Datenbanktabelle aktualisieren (wie jede Minute oder so).

Answer 4

Das Treffen der Datenbank ist wahrscheinlich teurer als das Schreiben in eine Datei.

Wenn Ihre Seitenaufrufe pro Sekunde hoch sind und die Daten nicht sofort in der Datenbank verfügbar sein müssen, ist das Schreiben in eine Datei und das regelmäßige Laden der Daten in die Datenbank eine optimale Lösung.

Es hängt jedoch alles von der Art der Daten ab, die Sie pro Seite aufzeichnen und wie wichtig sie für die jeweilige Geschäftsfunktion ist.

Answer 5

Vom Konzept her ist das Schreiben in die Datenbank immer langsamer als das Schreiben in eine Datei. Die Datenbank muss auch in eine Datei schreiben, mit dem zusätzlichen Overhead der Kommunikation, um die Daten in die Datenbank zu bekommen, damit sie sie in eine Datei schreiben kann. Daher muss es langsamer sein.

Das heißt, Datenbanken machen Disk I/O sehr gut, wahrscheinlich besser als Sie. Seien Sie nicht überrascht, wenn Sie herausfinden, dass ein einfacher Datei-Logger langsamer ist als das Schreiben in eine Datenbank. Die Datenbank hat viele I/O-Optimierungen und einige Tricks verfügbar, die Sie möglicherweise nicht haben (abhängig von Ihrer Web-Sprache und Umgebung).

Seien Sie nicht überrascht, wenn sich die Antwort im Laufe der Zeit ändert. Wenn Ihre Site klein ist, ist die Protokollierung in einer Datenbank sehr schnell. Wenn Ihre Site wächst, kann die Protokolltabelle zu einem großen Problem werden: Sie benötigt viel Speicherplatz, macht die Backups ewig und verbraucht alle I/O-Vorgänge, wenn Sie versuchen, sie abzufragen. Deshalb sollten Sie beide Methoden selbst benchmarken. Dann können Sie in Zukunft erneut testen, wenn sich die Bedingungen ändern.

Answer 6

eine Hybrid-Lösung wie redis seine Verwendung für diese Art von Sachen entworfen