Posté par trancheX .
En réponse au journal Lollypop 1.0 est sorti.
Évalué à 1.
Dernière modification le 08 avril 2019 à 10:47.
La limite de SQlite va être le nombre d’accès en écriture concurrents bien avant que la taille de la base ne devienne le problème.
Pour avoir joué un peu avec le format mbtile permettant de stoker des tuiles de cartographie (d'openstreetmap par exemple), j'ai découvert que SQlite est étonnamment performant en lecture.
J'avais un export "planet" d'openstreetmap (~60Go) après avoir codé le petit serveur web qui permet l'affichage et je pensais que j'aurai besoins d'importer l'équivalent le la base dans un postgres pour mettre en prod ... et bas non : après tests de charge pas de problème avec SQlite. Car la base mbtile n'est utilisé qu'en lecture, ce qui devrait être le cas aussi pour lollypop pour 99% des accès j'imagine (?).
Il y a peut être le cas du Vacuum (nécessaire de temps en temps sur une base éditable) qui peut avoir de mauvaise perf avec un gros fichiers.
[^] # Re: Merci!
Posté par trancheX . En réponse au journal Lollypop 1.0 est sorti. Évalué à 1. Dernière modification le 08 avril 2019 à 10:47.
La limite de SQlite va être le nombre d’accès en écriture concurrents bien avant que la taille de la base ne devienne le problème.
Pour avoir joué un peu avec le format mbtile permettant de stoker des tuiles de cartographie (d'openstreetmap par exemple), j'ai découvert que SQlite est étonnamment performant en lecture.
J'avais un export "planet" d'openstreetmap (~60Go) après avoir codé le petit serveur web qui permet l'affichage et je pensais que j'aurai besoins d'importer l'équivalent le la base dans un postgres pour mettre en prod ... et bas non : après tests de charge pas de problème avec SQlite. Car la base mbtile n'est utilisé qu'en lecture, ce qui devrait être le cas aussi pour lollypop pour 99% des accès j'imagine (?).
Il y a peut être le cas du Vacuum (nécessaire de temps en temps sur une base éditable) qui peut avoir de mauvaise perf avec un gros fichiers.