r043v (./26) :
les commandes en cours seront dedans bien sur :- )

Comment est gérée la consistance exactement ?

sur la question du support, la communauté est assez conséquente, et je peu facilement discuter avec le créateur de la base, et il écoute le retour des gens.

Une botîe se contrefout royalement de parler au mec dans son garage. Elle veut un support, des garanties, un temps de résolution en X heures, la possibilité d'ouvrir un incident, éventuellement en 24/7.

les admins connaissent pas, ben écoute c'est pas bien compliqué, et il n'y à pratiquement, sinon rien à faire niveau maintenance, et il n'y à qu'un seul fichier de config

La encore quand tu bidouilles un truc c'est nickel. Dans un usage professionnel il te faut des admins formés. Quand le téléphone sonne à 4h du matin parce que l'appli est en carafe, avoir un admin qui connait ça fait une putain de différence.
Comment ça se comporte quand une donnée est corrompue ? Quelles sont les opérations à faire pour remonter la base après une coupure de courant ? Comment ça se passe si le filesystem passe en read-only spontanément ?

niveau sauvegarde, c'est simple, un seul fichier à sauvegarder, j'ai fait un .sh qui me sauve le fichier sur ftp toute les nuit à 4h du mat, j'ai en permanence le backup des 30 derniers jours. de plus j'ai fait un utilitaire dédié au backup, rdd

Le bricolage maison en environnement professionnel c'est un truc que tu évites à tout prix. Comment tu intègres ta base dans une solution de sauvegarde du marché ? Comment elle interagit si tu fais de la sauvegarde en mode bloc ? Est-ce qu'on peut faire la sauvegarde sans arrêter la base (sous entendu avec garantie à 100% de ne rien perdre ni corrompre) ? Et avec une méthode de sauvegarde qui s'appuie sur les mécanismes baie ?

> les interfaces non plus d'ailleurs ce qui dans un environnement de production est rédhibitoire
tu parles de quoi ?
si tu parle des clients pour se connecter il en existe un paquet si tu parle d'un utilitaire complet en ligne de commande, il est embarqué avec la base et marche tres tres bien, redis-cli

Je parle des interfaces dans leur ensemble. Ca comprend les interfaces utilisateur comme tu as indiqué, mais également :
- les interfaces applicatives (protocole)
- les interfaces d'opération (alertes remontées, intégration à l'outillage d'administration d'entreprise, système de packaging)

> C'est supporté par un nombre de middlewares assez restreint... c'est bien pour ca que mon framework web tourne exclusivement avec, et que je développe pour et avec redis au quotidien

Eh oui, mais en environnement professionnel tu essaies de limiter le nombre de solutions que tu déploies car chacune doit être gérée (montées de versions, patching, packaging), les admins doivent être formés, les développeurs aussi. Et accessoirement vu que les applications ont tendance à causer entre elles, la complexité globale croît de manière exponentielle avec le nombre de briques utilisées.
Du coup, déployer un système qui n'est pas pris en charge par les middleware ou applications existantes ça a un impact significatif.


C'est là que sont les vrais enjeux du monde professionnel. L'industrialisation.
Les performances, à part quelques rares cas extrêmes (comme google justement), on s'en bat carrément les couilles. Payer deux machines ça sera toujours moins cher que payer 2 équipes d'admins.