Base de données p2p

Bonjour à tous,

Il y a déjà pas mal de temps j’avais ouvert un sujet dans lequel je me demandais s’il serai possible de réaliser un site web dynamique¹ sans avoir besoin d’un serveur.
Je pensais cela théoriquement possible à l’époque et depuis l’idée est restée en sommeil n’ayant pas les outils ni le temps de trouver une solution à cette question.
Depuis j’ai appris, et il y a peu cette idée m’est remontée à l’espris et je peux répondre que oui, cette idée est techniquement réalisable.

J’ai réfléchit aux différents cas de figure que l’on peu rencontrer, et je pense très sérieusement qu’il est possible de développer une base de données qui serait distribuée sur le réseau non pas via un serveur central mais via l’ensemble des nœuds le constituant.
Le plus beau dans tout cela c’est que cela peut se faire uniquement via le navigateur, donc aucun besoin d’installer de plugin ou de programme spécifique pour les visiteurs.

Evidemment entre l’idée théorique et la réalisation de celle-ci il y a un fossé et honnêtement j’aurai bien besoin d’aide pour mener à bien ce projet.

J’aimerai réaliser cette base de données dans l’objectif de diffuser cet outil via npm pour nodeJS et browser.

Je recherche des personnes qui seraient intéressé de développer ce projet s’y connaissant bien en javascript.
Pour vous donner une idée je cale pour le moment sur la partie communication p2p. Il existe l’excellent composant webtorrent mais j’aimerai bien l’adapter à ma sauce puisque je ne souhaite pas diffuser des fichiers comme le fait un client torrent classique. Et j’avoue que l’analyse du code de ce projet me parait compliquer.

Tu peux stp décrire précisément comment cette base de données fonctionnerait ? En quoi est-elle différente d’une blockchain ?

Salut,

Dans les grandes lignes, le principe que tu présentes me semble très intéressant. Mais cela amène pas mal de questions qui trouveront sûrement leur réponse au fil du développement

En vrac, comme ça me vient :

• Comment s’assurer que la base de données restera bien disponible dans son entièreté ? Bien que cela soit (très) rare, il peut arriver le cas extrême où un morceau d’un Torrent devienne indisponible car personne ne l’a à disposition.
• Quid de la place prise sur le PC du client ?
• Comment s’assurer de l’intégrité et, surtout, de la sécurité des données (en particulier, comment être sûr qu’un client ne s’est pas amusé à modifier des données, ou même qu’il ne puisse pas accéder auxdites données) ?

Malheureusement, je ne peux pas à l’heure actuelle contribuer à un tel projet, mais je vais suivre son évolution pour voir ce que ça donne

Cela me plairait de contribuer à ce genre de projet  !

Comment s’assurer que la base de données restera bien disponible dans son entièreté ? Bien que cela soit (très) rare, il peut arriver le cas extrême où un morceau d’un Torrent devienne indisponible car personne ne l’a à disposition.

On pourrait imaginer un système où quand il est détecté que peu de gens ont un morceaux, ils soit demandé à d’autre de le récupérer.

Comment s’assurer de l’intégrité et, surtout, de la sécurité des données (en particulier, comment être sûr qu’un client ne s’est pas amusé à modifier des données, ou même qu’il ne puisse pas accéder auxdites données) ?

L’encryptage (asymétrique ?) peut être un début de piste, pour la signature des données comme pour l’accès

Le problème de la blockchain est qu’elle ne fait que grandir dans le temps, pour un "petit" site cela ne poserai probablement pas trop de problème mais pour des applications atteignant un certain volume cela poserai problème¹.

Dans une BDD on doit pouvoir faire un CRUD complet.

Concrètement je souhaite me servir de plusieurs technologies, tout d’abord la cryptographie aura évidement un rôle central pour garantir l’intégrité des données ainsi que leur confidentialité s’ils s’agit de messages privé par exemple.

Pour éviter que chaque nœuds n’aie à supporter l’ensemble de la BDD, elle sera constituée de deux parties, d’un coté l'index étant partagé dans son intégralité par l’ensemble des nœuds. De l’autre coté on aura les données qui elles seraient partagée via le réseau torrent.
Aussi chaque nœud n’aurai pas l’intégralité de la BDD en sa possession mais uniquement les données dont il à besoin ainsi qu’un morceau des données plus ancienne afin de garder ces données disponible pour ceux qui en auraient besoin.

Il reste encore quelques petites zone d’ombre, pas plus tard qu’hier je me suis rendu compte en décrivant l’interface de la bibliothèque que je dépendais de la notion de transaction pour toutes modification dans la BDD (afin de permettre aux autres nœud de valider que les changements soient cohérent et valide) hors finalement l’état de la BDD à un instant T n’est en fait que l’ensemble des transactions ayant été réalisée depuis le début… et effectivement avec sa on est finalement assez proche de la blockchain.
Je me rappelle m’être déjà posé la question en substance et y avoir répondu de façon à ce qu’un utilisateur n’aie nullement besoin de récupérer l’intégralité de l’historique ou de la BDD afin de pouvoir commencer à consulter et modifier la BDD, sauf que là sur le coup je ne me rappelle plus de la réponse. Je devrai consulter mes notes.

Il est évident que c’est un projet ambitieux, si c’était quelque chose de trivial sa existerai déjà

D’accord mais comment tu veux implémenter ton truc si t’as pas de spécification ?

Je t’avoue que je suis extrêmement sceptique. J’ai un peu l’impression d’avoir affaire à un alchimiste.

L’API de ta lib on s’en fiche un peu, ce qui est intéressant c’est comment ton système est censé fonctionner. Tu fais une croix sur quoi, la disponibilité des données en tout temps ? La possibilité qu’un nœud soit indisponible ? La cohérence des données ?

J’ai fais une croix sur la disponibilité immédiate.

Une informations sera toujours présente plusieurs fois au sein de réseau afin de palier à l’indisponibilité d’un nœud.

Les données seront toujours cohérentes. Garanti par le système de transaction justement.

Les données seront toujours disponible, mais pas forcément immédiatement disponible. Etant donné que chaque nœud ne détiens pas l’ensemble de la BDD il est possible que l’informations qu’il souhaite récupérer ne soie pas en local. Si tel est le cas l’informations sera rapatriée par la BDD via le réseau P2P ce qui pourrai prendre quelques secondes au total.

J’ai écris un billet (privé) dans lequel j’ai écris l’ensemble des questions que je me suis posée ainsi que de leur solution; même si ce n’est pas formellement décris finalement c’est dans ce billet que se retrouve l’ensemble des spécifications.

Peut-être ai-je fais des erreurs, je peux donner l’accès à ce billet à qui le souhaite, je serai ravis d’avoir de l’aide. Ne fusse que pour me montrer là où je me serai trompé.

Dans le cas ou X nœuds quittent ton réseau, vu que seul l’index est partagé par tous les nœuds, si seulement les X nœuds possédaient une information, et qu’ils ne se reconnectent jamais, alors tes données sont perdues. Le fait d’avoir l’index de complètement partagé ne te protège absolument pas de ce cas de figure.

Avant de t’intéresser à cette problématique, tu devrais regarder plus en détails quels sont les problèmes adressés par les BDD classiques et typiquement comment elles font de la haute disponibilité.

@JuDePom: Tu as parfaitement raison, si l’ensemble des nœuds détenant une informations se déconnecte avant que cette informations n’aie pu être copier autre par alors l’information est perdue.

Je n’ai pas de solution face à ce problème. Si ce n’est que pour un petit site qui par exemple aurai des périodes avec 0 utilisateurs connecté aura exactement le même problème mais pour 100% de sa base de données.

Du coup ma solution face à ce problème est d’avoir un nœud serveur restant en permanence connecté pour justement pouvoir distribuer les informations à un nouvel utilisateur arrivant alors que personne ne peu lui transmettre les données.

En deçà d’une certaine taille le système ne peu se passer de serveur malheureusement, bien que le serveur ne serai qu’un nœud comme un autre, il n’aurai aucune fonctionnalité en plus ou en moins, il sera là dans le seul but de rendre l’informations disponible en permanence.

@unidan: Tu aurai des références à me conseiller ?

@unidan: Tu aurai des références à me conseiller ?

https://www.postgresql.org/docs/9.2/static/high-availability.html Les chapitres avant/après te permettrons d’avoir plus d’information également.

En particulier, tu peux te rendre compte là-dedans que ce qui est compliqué, c’est quand tu écris.

Une autre source d’information serait la documentation de Ceph. C’est du stockage réparti, donc pas du tout ce que tu fais mais ils ont également des problèmes à résoudre qui peuvent t’intéresser de part la nature répartie.

Enfin, juste une question comme ça. Si ta base de donnée est répartie, où se situe le code et comment tu décides de si quelqu’un à le droit d’écrire ?

Chez les clients.

La base de données est embarqué dans le navigateur et est exploitée en javascript, donc c’est ce code qui manipule la BDD et c’est dans ce code que l’on écrira les contraintes d’accès et ainsi de suite.

Comment garantir que ce qui a été écris par un nœud pouvait être écris comme cela a été écris ? Grâce aux transactions.

Une transaction est une fonction qui elle seule à le droit d’écrire dans la BDD, une transaction devant être signée pour être valide, les autres nœud ayant également le même code pour la transaction pourront rejouer celle-ci afin de vérifier que le résultat obtenu est le même que celui finalement enregistrer dans la BDD ce qui garanti qu’il n’y a pas eu manipulation.

Merci pour le lien, je vais le lire avec grande attention.

Dans ce cas-là comment tu garantis tes contraintes d’accès ? Si le code qui manipule les données est disponible pour le client tu n’as à priori pas de raison de chiffrer  ? Ça a l’air de revenir un peu à fermer la porte à clé et mettre la clé sous le paillasson.

Est-ce que tu garanties la cohérence des lectures entre tes différents clients ? Est-ce que tu fais une synchronisation synchrone (hum) chaque fois que tu as une écriture entre tous tes clients ?

Ok, alors vu que tu comprends pas ma question prenons un exemple.

Ta base de donnée a plein de clients (clients/serveurs en fait, p2p quoi). Elle stocke les commentaires d’un article de blog. Deux de ces clients sont A et B. Il y a une partition réseau entre A et B. A poste un commentaire, B poste un commentaire. La partition réseau est résolue. Il en découle que la base de donnée de A et celle de B n’ont pas le même contenu.

Tu dis "toujours cohérent", comment est-ce possible vu que dans mon exemple c’est pas cohérent ?

Je rejoins unidan : si tous est chez le client, n’importe qui pourra a priori récupérer les infos privés. Au passage il faut aussi penser à la protection contre des clients "malveillant" : quid d’un client (modifié) qui cherche à pourrir les autres noeuds ou renvoyant de fausses informations ?

Sur le coup ça me fait penser à zeronet
L’idée est sympa, cependant, zeronet nécessite une signature et donc un seeder principal qui ensuite retransmet ça à tous
D’ailleurs, pourquoi faire une BDD client ? (je comprend pas)

Je me base sur le principe de fonctionnement de CouchDB, d’ailleurs j’intègre CouchDB, c’est justement lui qui gère mes index.

C’est CouchDB qui résous ce genre de problème, il a été conçu dans ce but.

Les documents ont une propriété révision basé sur le même principe que git; s’il n’y a pas de conflit dans l’évolution d’une MaJ (on passe de la version 2 à la version 3) alors pas de soucis. Si un conflit apparaît car par exemple deux utilisateurs auraient modifier dans le même temps une même informations (on reçois une version 3 différente de la nôtre alors que nous sommes également en version 3) alors CouchDB résous le problème de lui-même en faisant gagner une des deux version, il est évidemment possible de paramétrer cette gestion des conflit.

Il y a des données privée et publique; pour les données publique pas de soucis. Pour les données privée, par exemple un message privé alors celui-ci sera enregistré chiffré. Je pensais me baser sur PGP, pour l’exemple des messages privé.

Concernant les nœuds malveillant c’est justement tout le but des transactions, chaque nœud doit vérifier que l’informations qu’il récupère est correcte, tout d’abord on garanti l’intégrité de l’informations par les signature PGP (pour éviter qu’un nœud modifie le contenu publier par un autre nœud) ensuite on garanti la cohérence de l’informations (un nœud n’a pas écris n’importe quoi n’importe où) au travers du mécanisme de transaction. Chaque nœud rejoue la transaction de son coté (avec le code présent de son coté évidement pour être sur de pas exécuter n’importe quoi) et vérifie que le résultat obtenu est identique à ce que le nœud communiquant l’information à justement communiqué.

D’accord donc il n’y a pas de cohérence. Il y a une eventual consistency, donc c’est pas cohérent. Une même requête vers 2 noeuds peuvent me montrer que les 4 derniers commentaires de l’article X sont 10 12 13 15 et 10 12 13 16. Plus tard, un jour, ces données seront réconciliées et un des 2 commentaires (15 ou 16) sera supprimé.

Dans le cas des commentaires non, justement en ayant une fonction permettant de gérer les conflits rien n’empêche de définir que l’on souhaite finalement garder l’ensemble des commentaires.

Cela serai plus délicats dans le cas de l’édition d’un billet de blog à plusieurs auteurs par exemple; là fusionner les différences devient plus difficile.

C’est ce qu’on te montre du doigt. As-tu une solution pour régler ce conflit à part effacer une des modifications qui l’emporte ?

Ouais enfin, ce que je voulais montrer du doigt, ou plutôt vérifier, c’est si l’OP connait les notions de base ou pas. Je pense que c’est pas le cas.

La source, tu t’attaques à un truc très très compliqué. Il y a des décennies de recherche académique sur le sujet. Si sans connaitre la base, les théorèmes d’il y a 30 ans, tu penses pouvoir inventer un truc dans ce domaine, je pense qu’il faut revoir des attentes à la baisse et sérieusement étudier le sujet.