Podlove sprengt die Datenbank

Moin allerseits,

ich hoste meinen Podcast über Podlove bei 1&1 und bin damit eigentlich seid über 3 Jahren sehr zufrieden. Im April ging’s los mit dem Problemen. Ich konnte keine neuen Episoden anlegen. Folgende Fehlermeldung:

  • Warning : Creating default object from empty value in /homepages/40/d311540574/htdocs/clickandbuilds/KackundSachgeschichten/wp-admin/includes/post.php on line 708*

Ich habe relativ schnell heraus gefunden woran es lag: Die SQL Datenbank ist voll.
1&1 stellt 1 GB zur Verfügung. Laut Support kann ich leider auch nicht mehr bekommen, es sei denn ich wechsle zu einem deutlich teureren Server Tarif.

Ein befreundeter Webentwickler hat damals drüber geguckt und ein wenig aufgeräumt. Die Datenbank ist mittlerweile aber wieder voll. Was wohl u.a. sehr viel Speicher benötigt sind die ANALYTICS.

Hatte jemand bereits dasselbe Problem? Kann man Podloves Datenbank-Hunger irgendwie eindämmen oder bleibt mir nichts anderes übrig, als zu upgraden?

Danke schon mal für jede Hilfe.

VG, Fred

1 Like

Nun die Ursache ist “klar”:

Podlove speichert jeden “download_intent”. Also jeder Versuch, einen Podcast herunterzuladen, jede Anfrage wird geloggt. Da gerade bei Stream der Files auch nur Chunks, also Teile geladen werden, kann der selbe Download mehrere Male bis hin zu erhebliche Male in der DB gespeichert werden.

Auf Basis dieser Rohdaten (man kann auch sagen “Datenschleuder”) wird dann regelmäßig die download_intent_clean generiert, die die Basis für Statististiken ist.

“Warum dann nicht die Rohdaten entfernen?”
It’s not a bug, it’s a feature: Die Statistik-Module werden stets erweitert, Messwerte und Korrelationen hinzugefügt oder neu modelliert. Gerade in der neusten Podlove-Version kann man einstellen, ob ein Download als ein Download zählen soll auf Basis eines Zeitfensters von einer Stunde oder einem Tag. Je nach Einstellung werden die Statistiken neu generiert.
Das wäre alles nicht möglich, wenn die Rohdaten nicht mehr vorliegen würden: Dann würden nur die verdichteten Daten vorliegen und man kann nicht neue Methoden oder flexiblere Methoden anwenden.

Das ist alles Sachebene: Auch meine DB besteht zu knapp 85% aus Podlove-Daten und ich missbillige das.
Ich verstehe jedoch den Ansatz/das Ziel dahinter und habe noch keine Lösung gefunden, wie man das Problem lösen kann, ohne auf die Flexibilität zu verzichten.

Zu deinem konkreten Problem: WordPress kann nur eine Datenbank ansprechen. Zwar kann man frickeln und zaubern, aber das ist eben frickeln und ohne Stabilitätsgarantie.

1 Like

Die einzige “Lösung” wäre vermutlich auf Analytics zu verzichten (IIRC kann man sie abschalten, dass auch nichts mehr geloggt wird) und dann die Altdaten löschen.
Mit diesem Ansatz kommst du vermutlich noch ziemlich lange mit 1GB Datenbank klar. - aber eben ohne die Idee davon, wie viele Menschen deinen Podcast laden und vermutlich zum großen teil auch hören…

Der andere wäre wohl tatsächlich zu einem anderen Hoster um zu ziehen, der nicht Separate DB-Server und damit separate Datenbank Speicherkontingente abrechnet.

Falls du Interesse am teilen eines größeren Servers hast, schreib mir ne DM, mein Server langweilt sich aktuell mit meinem kleinen Podcast und meiner Privaten Cloud etwas… (auch wenn ich aktuell nicht einschätzen kann, wie groß der Datenhunger deines Podcasts ist, aber das können wir ja persönlich klären)

Du hast noch eine andere Möglichkeit: Den Hoster wechseln. Das ist eine sehr ärgerliche Einschränkung, die 1&1 da vornimmt…

2 Like