Concernant le profiling, c'est un peu plus gris, en Java je vais préférer que tout soit dans une même JVM pour avoir une vision globale et juste (historique des threads et lock dans JProfiler par exemple).
He ben ce n'est pas l'avis de certains développeurs de base de données clef-valeur en mémoire pour java qui préconisent d'avoir plusieurs JVM de tailles réduites et expliquent qu'on a de meilleures performance en lui dédiant du matériel (page 28). À savoir qu'hazelcast possède les 2 modes il peut être utilisé comme bibliothèque et comme cluster à coté.
Pour les statistiques NoSQL que tu présentes, se pose en effet la question de savoir si le nombre de drivers est lié à la simplicité du protocole.
Autre réflexion :
plus une base de données est populaire,
plus le nombre d'utilisateurs est grand,
plus le nombre d'utilisateurs de langages peu utilisés est important,
plus la probabilité qu'un développeur/utilisateur se colle à la création du driver est importante.
Tu en raconte des trucs, mais en l'état tu remet en cause ce qu'avance les développeurs de redis avec uniquement des « bouts de réflexions ». Pour le reste du commentaire je ne vois qu'à moitié où tu veux en venir et tu t'es amha perdu dans la conversation.
Bref :
là où la question des drivers peut être critique pour une base de données qui se crée, ils sont parti avec cette idée et ça a semble-t'il marché. Ça ne veut pas dire que c'est l'unique solution, c'est celle qu'ils ont choisi et tu peu difficilement avancer qu'ils ne sont pas arrivé à leurs fins
pas mal de base de données utilisent ou proposent des protocoles textes sans que ça ne semble les rendre inutilisables (redis donc, mais aussi elasticsearch, couchdb, hazelcast a une API rest,...) comme quoi ça ne doit pas être aussi bloquant que cela
tu sors des arguments qui se mordent la queue, tu n'a pas a le faire car des gens l'ont fais, merci, mais si tu regarde de plus prêt des langages relativement récents tu va voir que, le choix de base de données va d'un coup se limiter, tu as le droit de dire que tu t'en fout, mais c'est pas la question
Bon du coup j'en était à ma seconde tentative. La discussion n'est pas plus intéressante qu'auparavant. Si tu n'a rien de plus concret que ça a avancé je vais t'abandonner ici. Le fait qu'il ai débat et que je puisse te pointer des développeurs de différents projets qui ont un avis différents du tiens pourraient te montrer que, les choses ne sont pas aussi simples que tu l’avançais au départ (les protocoles textes et l'utilisation d'un serveur unique de base de données clef-valeur sont mauvais, avancé avec une certaines véhémence et aplomb), si ça n'a pas suffit je ne serais pas en mesure de te convaincre. Bref restons-en là.
[^] # Re: Formatage automatique
Posté par barmic 🦦 . En réponse à la dépêche Robert, un logiciel de stockage en mémoire vive. Évalué à 2.
He ben ce n'est pas l'avis de certains développeurs de base de données clef-valeur en mémoire pour java qui préconisent d'avoir plusieurs JVM de tailles réduites et expliquent qu'on a de meilleures performance en lui dédiant du matériel (page 28). À savoir qu'hazelcast possède les 2 modes il peut être utilisé comme bibliothèque et comme cluster à coté.
Tu en raconte des trucs, mais en l'état tu remet en cause ce qu'avance les développeurs de redis avec uniquement des « bouts de réflexions ». Pour le reste du commentaire je ne vois qu'à moitié où tu veux en venir et tu t'es amha perdu dans la conversation.
Bref :
Bon du coup j'en était à ma seconde tentative. La discussion n'est pas plus intéressante qu'auparavant. Si tu n'a rien de plus concret que ça a avancé je vais t'abandonner ici. Le fait qu'il ai débat et que je puisse te pointer des développeurs de différents projets qui ont un avis différents du tiens pourraient te montrer que, les choses ne sont pas aussi simples que tu l’avançais au départ (les protocoles textes et l'utilisation d'un serveur unique de base de données clef-valeur sont mauvais, avancé avec une certaines véhémence et aplomb), si ça n'a pas suffit je ne serais pas en mesure de te convaincre. Bref restons-en là.
https://linuxfr.org/users/barmic/journaux/y-en-a-marre-de-ce-gros-troll