Imaginons le cas suivant : nous avons une base MongoDB, alimentée exclusivement par des batchs ordonnancés et via un client back office. Les utilisateurs, très nombreux,  y accèdent via une application client-serveur. La consistance ne doit être qu’in fine (eventually consistent en anglais). Nous avons donc, en gros, 1 accès en écriture pour 10 accès en lecture. Quelle architecture pourrions-nous mettre en place pour assurer la haute disponibilité de notre base de données et  donc nous prévenir de risques comme la perte d’un disque dur ? Comment pourrions-nous nous prémunir facilement contre une corruption et donc adresser la problématique de back up ? Je vais essayer de vous proposer une réponse unique à ces deux questions, en utilisant les fonctionnalités natives de MongoDB alliées aux possibilités offerte par l’utilisation des services proposés par Amazon Web Services…

(Lire la suite…)

Vu les speakers annoncés, no:sql(eu) à Londres était très prometteur mais c’était sans compter sur mère nature et ce fameux volcan islandais qui allait bloquer l’espace aérien d’Europe du nord…Malgré tout, no:sql(eu) est resté disponible et a offert un mode de fonctionnement « graceful degradation ». Un mode finalement efficace puisque quelques speakers ont réalisé leur présentation via Skype, principalement depuis les USA (quelques fois très tôt à cause du décalage horaire). Cela a également été l’occasion de discuter avec le CTO d’Amazon : Werner Vogels.

Quoiqu’il en soit, voilà ce que j’ai envie de retenir.
(Lire la suite…)