Bonjour,
Pour un banc de test, j’ai besoin de stocker et de partager à plusieurs process les états complets et cohérent de mon système simulé.
Pour cela, j’avais prévu d’utiliser une base de donnée transactionnelle en RAM avec un binding python.
Il y a trois mois, j’avais fait une recherche et trouvé un certain nombre de chose… il faut que je m’y re-penche et je n’ai pas sauvé mes bookmarks :'(
J’ai donc pensé à vous, pour m’aider à (re)trouver mon bonheur, voir à me faire une meilleure proposition.
Je voudrais éviter à avoir à gérer des mutex…
# ZODB
Posté par Anthony Jaguenaud . Évalué à 2.
J’avais trouvé ça. Quelqu’un l’a-t-il utilisé ?
Y-a-t-il mieux ?
# sqlite en RAM
Posté par goeb . Évalué à 2.
Je suppose qu'une base sqlite dans un tmpfs (en RAM) ferait l'affaire.
[^] # Re: sqlite en RAM
Posté par Anthony Jaguenaud . Évalué à 2.
Oui. Je me demandais juste s’il n’y avait pas mieux. Après l’avantage de cette solution, c’est que on peut avoir des process codé dans d’autres langages.
[^] # Re: sqlite en RAM
Posté par Kerro . Évalué à 3.
Ce n'est certes pas optimisé par défaut pour être stocké en mémoire (https://www.sqlite.org/inmemorydb.html), mais qu'est ce qui te pose problème avec SQLite ?
[^] # Re: sqlite en RAM
Posté par Anthony Jaguenaud . Évalué à 2.
Bah, mon besoin c’est surtout de partager les états de mon système qui sont des (clé—valeur)… Une base relationnel me semble un peu overkill.
[^] # Re: sqlite en RAM
Posté par lolop (site web personnel) . Évalué à 3. Dernière modification le 02 mai 2019 à 14:00.
Si tu n'as pas besoin de relationnel… TinyDB (la page liste d'autres DB clé/valeur du même genre).
Mais si c'est pour partager entre plusieurs processus, il faudra peut-être ajouter une couche de communication inter-process, par exemple avec Pyro. Voir la section "Why Not Use TinyDB" :-)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
[^] # Re: sqlite en RAM
Posté par Anthony Jaguenaud . Évalué à 2.
Merci pour les réponses. Par contre, je ne vois pas la section « Why Not Use TinyDB » :'(
[^] # Re: sqlite en RAM
Posté par lolop (site web personnel) . Évalué à 2.
Dans l'introduction, elle est juste après la section "Why Use TinyDB?" :-)
Votez les 30 juin et 7 juillet, en connaissance de cause. http://www.pointal.net/VotesDeputesRN
# Redis ?
Posté par gUI (Mastodon) . Évalué à 5.
C'est pas mon domaine, mais je sais que Redis est à la mode et en RAM.
En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.
[^] # Re: Redis ?
Posté par Anthony Jaguenaud . Évalué à 2.
Je vais regarder, merci.
# Transactionnel et en RAM sont incompatibles
Posté par paulez (site web personnel) . Évalué à 0.
Une transaction est une suite d'opérations atomique, cohérente, isolée et durable.
"En RAM" est donc incompatible avec la notion de transaction car non durable.
Par contre en non transactionnel en RAM tu as pas mal de trucs comme Memcache et Redis.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par wismerhill . Évalué à 4.
Donc, d'après ton raisonnement, si je crée une base de données avec PostgreSQL, je fais quelques opérations dedans, puis je supprime la base de données, mes opérations n'étaient pas transactionnelles car ma base de données n'était pas durable?
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par j_m . Évalué à 0.
Ton raisonnement est faux parce que tu donnes un mauvais sens au mot durable.
Voir wikipedia: Transaction_informatique
Donc dans ton cas, si tu effaces volontairement tes données, ta base de donnée peut toujours être considérée comme durable. Ton expérience ne dit rien de la durabilité de ta base de données.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par wismerhill . Évalué à 4.
Le disque dur sur lequel est enregistré la base de données n'est pas indestructible, ta définition est trop stricte pour être utilisable, aucun support de stockage n'est infaillible.
En quoi est-ce différent avec un ramdisk?
Quand le ramdisk est supprimé, la base de données l'est également, ça ne change pas le fait que, tant que le ramdisk (et donc la base de données qu'il contenait) existe, le fonctionnement de la base de données peut être transactionnel, tu n'aura pas des données à moitié enregistrées.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par _kaos_ . Évalué à 0.
Salut :)
Sauf qu'il peut l'être « involontairement ». Et on est très loin de la panne physique de disque ;)
Matricule 23415
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par Kerro . Évalué à 2.
Donc une base de données en RAM est durable, puisque c'est volontaire qu'elle soit effacée lorsque le programme est terminé.
Une base de données en mémoire, c'est 100 % volontaire, ça veut dire qu'on n'en a pas besoin au delà du temps d'utilisation. Crash compris (puisqu'un crash n'est pas important, sinon on ne stocke pas en mémoire).
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par paulez (site web personnel) . Évalué à -3.
C'est volontaire peut-être, mais il faut que la personne qui a cette volonté comprenne bien que ça n'est plus transactionnel. Utiliser MySQL par exemple dans un ramdisk c'est assez contre productif car il y a énormément de logique dans MySQL pour gérer la notion de durabilité (et dans n'importe quel SGBD transactionnel) qui devient inutile dans un ramdisk. Autant utiliser une base de donnée conçue pour tourner en mémoire (comme Redis ou les memory tables de Mysql).
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par j_m . Évalué à 1.
Je ne sais pas. Comme il y a des indications un peu ambigues il vaudrait mieux demander de quelle niveau de durabilité on a besoin et si il y en a besoin.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par Kerro . Évalué à 2.
Je ne pense pas que la définition d'une transaction inclue le fait que ce soit durable au delà du temps d'exécution d'un programme.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par _kaos_ . Évalué à 0.
Salut :)
Ah. Bin c'est ton banquier qui va être content : « Désolé, il vous reste 0€, on a rebooté les machines ».
Matricule 23415
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par paulez (site web personnel) . Évalué à 0.
La définition ne le spécifie peut-être pas, mais c'est une contrainte majeure à tout logiciel de base de donnée transactionnel. Le fait que ton MySQL ou équivalent puisse redémarrer dans un état cohérent est assez critique. Il faut noter qu'il est possible de configurer MySQL pour qu'il soit plus performant mais on perd la garantie de durabilité (en configurant innodb_flush_log_at_trx_commit=2 par exemple), ce qui généralement génère de mauvaises surprises pas mal de temps plus tard quand le serveur crashe et qu'une ou plusieurs transactions ont disparu :-)
[^] # Transactionnel et en RAM sont compatibles
Posté par Zenitram (site web personnel) . Évalué à 4. Dernière modification le 03 mai 2019 à 09:02.
Tu ne dis toujours pas en quoi passer de disque dur à RAM change le problème.
Un disque dur peut être détruit comme le contenu de la RAM.
le logiciel peut crasher, la RAM sera toujours la (mémoire partagée entre plusieurs processus) comme avec un disque dur et son état doit être cohérent comme sur le disque dur.
Bref, j'ai l'impression qu'il y a confusion, et un beau mélange sur la notion de "durabilité" sur un truc qui n'a rien à voir juste parce qu'on imagine que la RAM n'est pas durable et le disque dur durable, avec ses préjugés sur le sujet par ce qu'il se fait de nos jours, et avec "durable" pas vraiment la définition utilisée pour définir du transactionnel.
RAM et disque dur peuvent faire être durables, avec des contraintes extérieures différentes (alimentation qui doit être stable d'un côté, aimant qui ne doit pas passer dans le coin de l'autre) c'est tout.
Au final, "Transactionnel et en RAM" sont autant incompatibles que "Transactionnel et en disque dur", ou "toto et tata" du moment où deux peuvent durer plus longtemps qu'une transaction (ce qui est le cas de la RAM entre autre).
PS : je ne dis pas que sqlite est pertinent pour le besoin, juste que le conseil ne dépend pas vraiment de RAM ou disque dur, mais plutôt de l'usage et des performances adaptées aux caractéristiques de l'un ou l'autre (latence etc), tu parles toi-même plus bas d'efficacité (le fait que les disque soient des SSD ne change pas la caractéristique, même si l'outil pense avoir affaire à un disque magnétique comme tu l'as indiqué…), juste je tique sur le sujet du commentaire.
[^] # Re: Transactionnel et en RAM sont compatibles
Posté par paulez (site web personnel) . Évalué à -1.
La différence majeure entre un disque dur et de la RAM est la garantie d'écriture durable.
Avoir une écriture garantie durable dans un disque est très coûteux (il faut faire un fsync sur le fichier, qui s'assure que le fichier est physiquement écrit sur le disque et pas seulement dans un cache). Les bases de données transactionnelles ont tout un tas de techniques pour faire ça de manière efficace (redo log dans Oracle, WAL dans PostgreSQL).
Quand tu fais tourner ton PostgreSQL dans un ramdisk, il continue à gérer un WAL et toute la logique associée, alors que c'est complètement inutile.
Dans le cas de la mémoire, l'écriture ne peut pas être garantie durable donc ce genre de gestion n'a pas lieu d'être, ce qui change assez fondamentalement comment fonctionne une base de donnée qui fonctionne seulement en mémoire.
Concernant la définition de durabilité je trouve celle de Wikipedia assez bonne, pour résumer le résultat de la transaction survit même en cas de coupure d'électricité, ce que stocker uniquement en RAM ne garanti pas (d'où le titre).
[^] # Re: Transactionnel et en RAM sont compatibles
Posté par paulez (site web personnel) . Évalué à 0. Dernière modification le 03 mai 2019 à 23:04.
Quand tu dis qu'un disque dur peut-être détruit, en effet bon système transactionnel doit avoir de la redondance à ce niveau pour avoir un certain niveau de durabilité. 100% de durabilité n'existe pas.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par Anthony Jaguenaud . Évalué à 5.
La durabilité doit être le temps d’un test. La base sera réinitialisé pour le suivant.
Donc, la transaction sera durable dans mon environnement et mon besoin.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par Anthony Jaguenaud . Évalué à 2.
J’ai un système à simuler qui contient un certain nombre d’éléments. Plusieurs process qui accède aux données pour répondre aux messages à la place des vrais systèmes en temps réél.
Lorsqu’on change des données pour changer d’état, je veux que l’ensemble soit toujours cohérent.
D’où l’idée de faire du transactionnel. Mais je n’ai pas besoin de persistance, à la fin de mon test, je vais réinitialiser l’ensemble pour le suivant.
[^] # Re: Transactionnel et en RAM sont incompatibles
Posté par paulez (site web personnel) . Évalué à 1.
Utilise Redis alors, c'est un moteur de stockage clé/valeur en mémoire qui semble avoir un support des transactions. C'est populaire pour tout ce qui n'a pas besoin d'être persistant (cache, file d'attente, etc).
Ça sera bien plus efficace qu'un SGBD traditionnel qui pense devoir gérer un disque dur magnétique, avec tout le surcoût que ça implique.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.