Forum Programmation.autre moteur de persistance

Posté par  . Licence CC By‑SA.
Étiquettes :
0
4
fév.
2014

Bonjour,

Je suis en manque d'inspiration.
Je voudrais écrire une petite application et je ne sais pas quoi choisir comme mécanisme de persistance.

Mon application doit stocker des listes d'objets tous semblables mais pas forcément simples (ie: avec des compositions et des listes comme attributs).

Mes critères sont :
- embarqué (ie: pas de client serveur)
- utilisable en python et si possible avec d'autres langages (java, shell (donc cli))
- pérenne (ie: que je puisse continuer à lire les données dans quelques temps)

J'ai envisagé :
- SQLite, je suis assez fan du logiciel mais pas trop envie de me coller du SQL (requête, connection, statement, curseur pfff)
- Fichier texte plat (csv ou json, ou autre) : j'aime bien l'aspect interopérable mais pas très scalable et pas vraiment robuste si je veux plusieurs processus écrivain
- CouchDB mais je crois que c'est client serveur et il faut écrire du JS
- MongoDB mais ça me paraît un peu lourd ET client/server
- Redis et j'avais lu ici même que ça existait en embarqué (http://vedis.symisc.net/) mais je ne sais pas ce que ça vaut

Quels sont vos suggestions (argumentées si possibles) ?

Merci de vos lumières

  • # Fichier plat ou presque

    Posté par  (site web personnel) . Évalué à 3.

    Salut,

    Si tu peux sérialiser tes données, tu peux utiliser un format genre BDB, assez universel…

    Fichier texte plat […] pas vraiment robuste si je veux plusieurs processus écrivain

    À la limite tu peux mettre un lockfile, à toi après de vérifier l'absence du lockfile avant de modifier les données dans chacun des processus.

    De toute manière, si tu ne veux pas faire du client-serveur, tu n'as pas le choix : il faut un stockage dans un fichier et un moyen de vérifier qu'un autre processus n'a pas déjà ouvert le fichier. Même avec SQLite, il faut une gestion dans ce genre (http://www.sqlite.org/lockingv3.html).

  • # Sergent évidemment.

    Posté par  . Évalué à 1. Dernière modification le 04 février 2014 à 23:31.

    Tu connais sqlite, tu en es fan, tu sais que ça marche, tu sais que tu peux le faire, et tu te poses la question ?
    N'aie pas peur d'être vieux, sois vieux.

    Pour un sextumvirat ! Zenitram, Tanguy Ortolo, Maclag, xaccrocheur, arnaudus et alenvers présidents !

    • [^] # Re: Sergent évidemment.

      Posté par  (site web personnel) . Évalué à 2.

      sqlite sans SQL => sqlalchemy l'orm pour python!

      • [^] # Re: Sergent évidemment.

        Posté par  (site web personnel) . Évalué à 1. Dernière modification le 05 février 2014 à 17:44.

        edit mais trop tard alors je me répond: oups il faut argumenter:

        avec sqlalchemy, tu décris tes objets (et leurs relations) en python, puis tu indique ton backend (sqlite par exemple).

        Après dans le code ça donne un truc comme:

        monobjet = MonObjet.query.filter_by(moncriter="monchoix").first() 
monobjet.unattribut += 1
db.session.commit()

  • # Redis

    Posté par  . Évalué à 0.

    Ptet essayer : http://redis.io/

    • [^] # Re: Redis

      Posté par  . Évalué à 2.

      Redis, j'aime bien le concept et l'api par contre, client/serveur. C'est pour ça que je voulais savoir si qqun avait testé la version embarquée, vedis.

  • # pistes

    Posté par  . Évalué à 2. Dernière modification le 18 février 2014 à 17:55.

    Pour l'instant, je suis parti sur des fichiers json à plat. Pour un prototype, ça fonctionne pas mal et ça simplifie l'infrastructure à mettre en place.

    Si je poursuis le développement, je suis très tenté d'utiliser elasticsearch car : json, scalable, api assez riches, wrappers dans plein de langages. Inconvénients : une jvm à démarrer, mode client serveur.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.