sqlite Datenbank auf Speicherkarte - viele Zugriffe

Klappstuhl · Donnerstag 27. Mai 2010, 07:37

Hallo allerseits,

nachdem ich auch Dank dieses Forums doch sehr gut und schnell mit Python zurechtgekommen bin, stehe ich nun vor einem etwas allgemeinerem Problem (und hoffe, dass ich hier in der richtigen Kategorie bin). Folgendes Szenario:

Das Betriebssystem und somit auch Python 2.5 und sqlite3 laufen auf einer Speicherkarte.
Da nun pro Sekunde zwischen 1 und 10 Schreibvorgänge auf die Datenbank erfolgen, mache ich mir natürlich Sorgen um die Haltbarkeit der Karte, das ganze soll jetzt optimiert werden.
Dazu fallen mir 2 Szenarien ein:
1. Die Änderungen an der Datenbank (es sind in 99 % der Fälle keine neuen Einträge, sondern Änderungen an bereits bestehenden) sammeln und dann nur etwa alle 30 - 60 Sekunden tatsächlich schreiben.
2. Die Datenbank parallel im Arbeitsspeicher halten und ebenfalls etwa alle 30 - 60 Sekunden mit der Speicherkarte synchronisieren.

Persönlich würde ich Variante 2 bevorzugen, jedoch ist mir noch nicht so klar, wie man das am besten bewerkstelligt. Mit der (:memory:)-Funktion kann man ja eine Datenbank im RAM halten. Allerdings sehe ich keine Option, wie ich eine Datenbank von der Speicherkarte in den Arbeitsspeicher laden kann, Änderungen dann in der "RAM-Kopie" vornehme und dann letztenendes diese Kopie synchron halte mit dem Original auf der Karte.
Hat da vielleicht jemand den entscheidenden Hinweis?

Vielen Dank und viele Grüße!

BlackJack · Donnerstag 27. Mai 2010, 08:13

@Klappstuhl: ':memory:' muss ja nicht zwangsläufig bedeuten, dass im Speicher etwas existiert, dass einem Abbild der Datei auf dem Hintergrundspeicher entspricht. Die Daten können im Speicher ja anders organisiert sein. Also würde es wohl darauf hinauslaufen, dass man die Daten im Speicher per SQL abfragt und in eine DB auf der Speicherkarte per SQL schreibt. Da macht es keinen Sinn immer den gesamten Datenbestand rüberzukopieren. Das sollte man auf die neuen Einträge beschränken. Und schon wären wir wieder bei Szenario 1.

Klappstuhl · Donnerstag 27. Mai 2010, 08:41

@BlackJack:
Danke für die schnelle Antwort. Dann werde ich wohl Szenario 1 implementieren. Ich hatte insgeheim gehofft, dass jemand ein ähnliches Problem hatte und versucht hat, das mit dem gleichen Ansatz zu lösen

"Kompletter Datenbestand" heißt in dem Fall übrigens, dass die Datenbank etwa 1 MB groß ist und sich innerhalb einer Minute so grob alle Einträge etwas geändert haben.

lunar · Donnerstag 27. Mai 2010, 09:27

Ist nicht die Backup API genau das, was Du suchst?

Leonidas · Donnerstag 27. Mai 2010, 11:06

Alternativ könnte man auch so Späße wie LogFS ausprobieren, inzwischen solls ja sogar halbwegs brauchbar mit FTL (siehe hier) funktionieren.

Klappstuhl · Donnerstag 27. Mai 2010, 11:50

Danke für eure Antworten!

LogFS klingt interessant, aber es zielt wohl eher auf andere Anwendungsgebiete ab.
Die Backup API werde ich nun mal genauer unter die Lupe nehmen

noisefloor · Mittwoch 2. Juni 2010, 11:53

Hallo,

noch eine Alternative: Redis. Gut, ist ein Key-Value Store. Macht aber genau das, was die brauchst: hält Änderungen im Speicher und schreibt asynchron (konfigurierbar) die Daten auf die Platte.

Gruß, noisefloor

noisefloor · Donnerstag 3. Juni 2010, 18:29

Hallo,

es ist doch eigentlich Quatsch, zeitversetzt zu schreiben. Die Menge der Daten ist doch trotzdem gleich. Dann kann man auch sofort schreiben...

Und noch was anderes: Das Thema "Haltbarkeit von Flash-Speicher" ist ja ein wunderbares Theman für endlose Meta-Diskussionen

Was mir dazu eingefallen ist: in der c't haben die mal vor ca. 9 Monaten versucht, eine handelsübliche SD-Karte "tot" zu schreiben. Das hat _nicht_ funktioniert, jedenfalls nicht in einem "vernünftigen" Zeitraum...

BTW, wie wäre es mit einem RAID-Verbund aus 2 SD-Karten?

Gruß, noisefloor

BlackJack · Donnerstag 3. Juni 2010, 18:45

@noisefloor: In der Analyse stand, dass im groben immer wieder die selben Schlüssel mit anderen Werten belegt werden, also die Datenbank an sich nicht oder nur geringfügig wächst. Daten sind auf Massenspeichern blockweise organisiert und auch wenn nur ein Teil eines Blockes mit neuen Daten versehen wird, so muss trotzdem der ganze Block neu geschrieben werden. Wenn ich also zehn kleine Änderungen schreibe, kann es durchaus sein, dass die weniger als zehn Blöcke betreffen, aber wenn sie einzeln rausgeschrieben werden, trotzdem zehn mal ein Block geschrieben wird. Wenn alle Änderungen auf einmal rausgeschrieben werden, müssen nur so viele Blöcke geschrieben werden wie wirklich betroffen sind.

Zusätzlich kann es passieren dass zwischen zwei Schreibintervallen ein Datum mehrfach geändert wird. Hier spart man auch Schreibzugriffe ein.

noisefloor · Donnerstag 3. Juni 2010, 19:10

Hallo,

@BlackJack: Klar, stimmt.

Wobei der 1. IMHO eine ziemlich hohen Anteil Spekulation hat

. Oder andersrum: ob man da _wirklich_ bei SD-Karten Lebensdauer "herausschindet" ist fraglich. Zumal SD-Karten und SSD ja Schreibvorgänge systematisch auf den gesamten Speicher verteilen.

Punkt 2 ist da schon wichtig: Werden die gleichen Schlüssel immer wieder geändert bringt jede Sekunde im Speicher was (was BTW wieder für Redis statt SQLite spricht

)

Gruß, noisefloor

veers · Donnerstag 3. Juni 2010, 21:05

Kannst du nicht einfach die Kernel Parameter (unter Linux) so tunen das pdflush nur noch selten aktiv wird? Fragt sich natürlich noch ob sqlite nicht manuell syncs erzwingt. Aber abgesehen davon verträgt guter Flash speicher ja gegen 100'000 schreib Zyklen. Wenn das wear levelling da halbwegs mitspielt dürfte das für eine halbe Ewigkeit reichen.

Gruss,
Jonas