Retourner au contenu associé (journal : FlowG - Une solution "Low Code" de traitement de journaux (systèmes))
Posté par David Delassus (site web personnel) le 23 août 2024 à 23:43. En réponse au journal FlowG - Une solution "Low Code" de traitement de journaux (systèmes). Évalué à 3.
Sisi, l'outil stocke bien les données.
Mon choix s'est porté sur BadgerDB car c'est une base de données clés/valeurs très solide et distribuée sous forme de librairie Go.
Une base de données SQL implique d'avoir un schéma, ou de s'en servir comme une base de donnée clé/valeur.
Pour ce qui est de la structure de données sous jacente, BadgerDB utilise un LSM Tree ( https://en.wikipedia.org/wiki/Log-structured_merge-tree ) ce qui se prête très bien aux données que je désire stocker.
De plus BadgerDB supporte les transactions ACID (la plupart des base de données SQL aussi cela dit), donc il n'y a aucun inconvénient à l'utiliser.
En utilisant une base de données clés/valeurs, j'ai aussi un meilleur contrôle sur la structure de données pour les indexes.
Je t'invite à lire ce document : https://github.com/link-society/flowg/blob/main/docs/design/storage.md Il est peut être incomplet, donc tout retours dessus est bienvenu :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg
AltStyle によって変換されたページ (->オリジナル) / アドレス: モード: デフォルト 音声ブラウザ ルビ付き 配色反転 文字拡大 モバイル
[^] # Re: nosql ?
Posté par David Delassus (site web personnel) . En réponse au journal FlowG - Une solution "Low Code" de traitement de journaux (systèmes). Évalué à 3.
Sisi, l'outil stocke bien les données.
Mon choix s'est porté sur BadgerDB car c'est une base de données clés/valeurs très solide et distribuée sous forme de librairie Go.
Une base de données SQL implique d'avoir un schéma, ou de s'en servir comme une base de donnée clé/valeur.
Pour ce qui est de la structure de données sous jacente, BadgerDB utilise un LSM Tree ( https://en.wikipedia.org/wiki/Log-structured_merge-tree ) ce qui se prête très bien aux données que je désire stocker.
De plus BadgerDB supporte les transactions ACID (la plupart des base de données SQL aussi cela dit), donc il n'y a aucun inconvénient à l'utiliser.
En utilisant une base de données clés/valeurs, j'ai aussi un meilleur contrôle sur la structure de données pour les indexes.
Je t'invite à lire ce document : https://github.com/link-society/flowg/blob/main/docs/design/storage.md
Il est peut être incomplet, donc tout retours dessus est bienvenu :)
https://link-society.com - https://kubirds.com - https://github.com/link-society/flowg