2009-04-21 4 views
5

J'utilise la base de données sqlite dans ma plate-forme linux embarquée arm9. Je veux réduire les écritures sur la base de données de disque parce que mon disque est une mémoire flash et il a besoin de cycles d'écriture minimum. J'ai donc essayé d'incrémenter SQLITE_DEFAULT_CACHE_SIZE en tant que 5000. Mon objectif était d'écrire des données dans le cache et lorsque le cache est rempli, vider automatiquement sur le disque. Mais en incrémentant SQLITE_DEFAULT_CACHE_SIZE, je ne peux pas confirmer si cela fonctionne ou non. Je ne vois aucun changement dans les opérations! Est-ce que mon chemin est correct? Quelqu'un peut-il me donner des suggestions? Merci AneeshComment limiter le vidage de la base de données sur le disque?

+0

Je ne suis pas sûr si je comprends votre exigence. Habituellement, les bases de données sont utilisées pour garantir les garanties transactionnelles. Pour ce faire, la base de données doit écrire sur le disque. Si vous avez des changements d'état qui ne sont pas importants, pourquoi prenez-vous la peine de mettre à jour la base de données? Vous pouvez simplement garder les changements d'état en mémoire et ne mettre à jour la base de données que lorsque vous devez persister vos modifications. – lothar

+1

Normalement, cela ne signifie pas toujours. sqlite est utilisé dans de nombreux environnements exotiques comme mécanisme de stockage temporaire. Caches de données à distance sur un téléphone, par exemple - si le cache disparaît, il peut toujours être reconstruit, c'est juste plus lent. Dans ce cas, je veux que ce soit rapide, et je veux savoir si c'est corrompu. Mais la corruption est OK, aussi longtemps que je sais que mon magasin est invalide. Je peux le jeter de temps en temps. –

Répondre

2

Le dernier SQLite has a feature for backing up hot databases il est encore au stade expérimental, mais ma recommandation serait d'utiliser une base de données sur la mémoire et la fusion avec la base de données du disque lorsque vous pensez est approprié.

+0

Oui Robert vous avez raison, mais le problème est que je dois vider la base de données périodiquement, cela semble être trop risqué. Mon intention est de savoir si Sqlite supporte tout type de vidage par défaut basé sur Cache plein? J'ai fait quelques expériences basées sur le scénario ci-dessus en réglant PRAGMA journal_mode = MEMOIRE, PRAGMA SQLITE_DEFAULT_CACHE_SIZE = 5000 et PRAGMA synchrone = FULL, Mais le taux de rinçage semble être similaire sur la taille du cache de 2000 (par défaut) et 5000.Cela me fait me demander.please aide? –

+0

Malheureusement ces options n'affecteront pas la vitesse à laquelle il va frapper le disque –

+0

Tout d'abord merci pour vos suggestions valeur, vous dites que, le cache complet ne peut pas être utilisé comme un critère pour rincer les données de Ram à fichier disque? Si c'est le cas, alors mon problème peut résoudre sans aucun facteur de risque. Vous avez une autre option à proposer? Avancé merci, Aneesh –

-1

Vous avez le code source SQLite - pourquoi ne pas simplement l'instrument pour enregistrer les informations que vous êtes intéressé par

+0

Ouais ... c'est aussi simple que ça! – tylerl

+0

S'il vous plaît élaborer, je n'ai pas compris votre suggestion !!!! –

+0

Mmm, cette réponse est totalement sans rapport pour autant que je comprenne ... –

0

Ok Neil .Si le « SQLite utilise une forme de mise en cache d'écriture à travers », puis sur la. débordement de cache, il va essayer de vider les données à un fichier temporaire ou un fichier disque. C'est le même point que j'essaie d'expérimenter en augmentant la taille du cache et ainsi acquérir le contrôle sur le taux de rinçage mais il ne se passe pas. .

+0

Tout d'abord, vous devriez probablement modifier votre question originale pour demander cela. Deuxièmement, la mise en cache à écriture immédiate signifie que toutes les écritures sont immédiatement validées sur le disque, mais les données écrites sont également conservées dans le cache. La taille du cache a donc peu ou pas d'effet sur la fréquence d'écriture sur disque. Comme je l'ai dit, je ne peux pas être sûr à 100% que cela se passe - regardez le code vous-même. –

2

SQLite doit être ACID db flushes à chaque validation OU à chaque insertion/suppression/mise à jour non encapsulée avec transaction. Utilisez les transactions pour regrouper les opérations OU désactivez ACIDity et réglez PRAGMA synchrone = OFF.

"PRAGMA synchrone = OFF" et SQLite ne seront pas données à chasse d'eau du tout (en laissant effectivement que pour OS Cache)

SQLITE_DEFAULT_CACHE_SIZE est seulement pour la taille du cache. Et le cache est utilisé UNIQUEMENT pour lire les données.

Il existe une autre option: vous pouvez implémenter votre propre couche VFS et empêcher l'enregistrement de la page avant que votre propre tampon ne soit plein. Mais je suis sûr que sync = off (ou beaucoup mieux d'utiliser les transactions) fera le travail assez bien (tout en ayant une bonne chance de corrompre votre db en cas de coupures de courant ou hard reset pour sync = off) .

Une autre indication est de mettre JOURNAL en mémoire ou de l'éteindre complètement. Encore une fois - il est en train de désactiver l'acidité, mais cela supprime également certaines touches du disque.

+0

Je suis d'accord; structure de transaction est probablement où le plus grand avantage pourrait être trouvé. –

Questions connexes