C'est moi où tu reproche à une base de données NoSQL de ne pas être ACID ?
Non; je pense qu'il reproche à MongoDB d'avoir fait des choix de design et marketing très douteux ainsi que d'avoir réussi à violer presque systématiquement les maigres garanties annoncées dans leur doc pendant ses 5+ premières années d'existence. Ce qui est fondamentalement un problème différent que de trouver que les garanties offertes par un outil ne sont pas adaptés à son besoin.
Ça a commencé par publier des benchmarks montrant à quel point ils étaient "rapides" alors que la configuration par défaut de Mongo était de ne pas garantir la durabilité des écritures acceptés (ie. non persisté dans un WAL).
Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière.
Côté garanties documentées, garanties réellement implémentées et configuration par défaut, on est passé par toutes les étapes possibles de WTF.
Il me semble qu'un changement significatif a eu lieu vers la version 3 et au moment où Aphyr les a mis en pièce. Ils ont commencé à chercher à afficher des garanties raisonnables et à les implémenter correctement. Le surnom snapshat for database de mongo ne vient pas de nul part; et tu peux aisément comprendre que suite à cet historique des gens s'en tiennent le plus loin possible.
[^] # Re: Scylla/MongoDB
Posté par ckyl . En réponse au journal Cassandra 4 qui la testent, un qui l'Hécube. Évalué à 10. Dernière modification le 06 août 2021 à 13:43.
Non; je pense qu'il reproche à MongoDB d'avoir fait des choix de design et marketing très douteux ainsi que d'avoir réussi à violer presque systématiquement les maigres garanties annoncées dans leur doc pendant ses 5+ premières années d'existence. Ce qui est fondamentalement un problème différent que de trouver que les garanties offertes par un outil ne sont pas adaptés à son besoin.
Ça a commencé par publier des benchmarks montrant à quel point ils étaient "rapides" alors que la configuration par défaut de Mongo était de ne pas garantir la durabilité des écritures acceptés (ie. non persisté dans un WAL).
Ça a continué avec des tonnes de bugs tous plus hallucinants les un que les autres. Si tu as des soirées de libre, remonte le bug tracker jusqu'à la version 3 et tu y trouveras les trucs les plus hallucinants que j'ai pu voir dans ma carrière.
Côté garanties documentées, garanties réellement implémentées et configuration par défaut, on est passé par toutes les étapes possibles de WTF.
Il me semble qu'un changement significatif a eu lieu vers la version 3 et au moment où Aphyr les a mis en pièce. Ils ont commencé à chercher à afficher des garanties raisonnables et à les implémenter correctement. Le surnom snapshat for database de mongo ne vient pas de nul part; et tu peux aisément comprendre que suite à cet historique des gens s'en tiennent le plus loin possible.