Agenda :
Depuis trois ans maintenant, NoSQL remet en question le monde centralisé des RDBMS. Les espaces de stockage distribués ne sont pour autant pas nouveaux et les banques, les plateformes de jeux utilisent des « grilles de données » pour adresser leurs enjeux de débit et de latence.
Quels sont les points communs? les principales différences entre les univers NoSQL et « data grids »?
Tous les navigateurs acceptent HTML5 et CSS3 mais tous ne comprennent pas leurs nouvelles fonctionnalités. L’usage de nouveaux attributs HTML5 ou de nouvelles propriétés CSS3 ne bloquera pas votre navigateur, ce dernier les ignora tout simplement. Un avantage indéniable qui nous permet d’utiliser dès aujourd’hui HTML5 et CSS3 même si certains de nos utilisateurs ne disposent pas encore de navigateurs les supportant. Comme je le précisais dans l’article Osez renoncer aux vieux navigateurs, il ne faut pas avoir peur d’utiliser des fonctionnalités HTML5 et CSS3 car des comportements dégradés natifs existent. Quels sont les comportements dégradés natifs acceptables ? Comment profiter d’une fonctionnalité HTML5 ou CSS3 si son comportement dégradé n’est pas acceptable ? Comment pallier l’absence de support des nouvelles API JavaScript si le navigateur ne les possède pas ?
Le modèle relationnel est né à une époque où l’espace était rare, et fut donc conçu pour minimiser le niveau de redondance des données: il était plus économique de stocker une indirection vers une chaine de caractères que de stocker cette chaine deux fois.
Aujourd’hui, cette contrainte d’espace ne tient plus. On achète un Teraoctet pour 100 dollars, la RAM est abondante, et les disques flash aux performances élevées vont bientôt rejoindre le prix des disques durs rotatifs.
Deux limitations fondamentales du stockage ont donc disparu: le coût de la redondance et le coût de la non-localité pour le traitement de structures de données complexes. Il est maintenant possible de concevoir de nouvelles bases de données plus riches et plus sûres.
La délégation de tâches en asynchrone est un moyen efficace d’alléger la charge que subissent nos systèmes. En effet, de nombreux cas d’utilisation ne nécessitent pas d’être exécutés de façon synchrone lorsqu’un utilisateur effectue une action ou qu’un événement extérieur intervient.
Par exemple, lorsqu’il n’est pas nécessaire de restituer la dernière version des données et que le traitement avant restitution est coûteux en ressources, il est possible de renvoyer des données préalablement mises en cache et de déporter en asynchrone une tâche de rafraîchissement de ce cache.
Un autre exemple concerne les systèmes qui mêlent des requêtes fortement consommatrices en ressources (CPU, mémoire, …) et des requêtes peu consommatrices pour lesquelles on va vouloir garantir une latence faible même lorsque des requêtes consommatrices sont en cours de traitement. Pour cela, déléguer les traitements coûteux à des workers via une file de messages peut aider à garantir des temps de réponse faibles pour les autres requêtes. Cette séparation est d’autant plus importante sur des systèmes qui s’appuient sur des technologies monothreadées telles que Ruby ou NodeJS (ce dernier a néanmoins l’avantage de ne pas consommer de ressources/process lorsqu’il effectue des I/O).
Pour résoudre cette problématique de délégation de tâches, on utilise habituellement une solution comme ActiveMQ ou RabbitMQ. Seulement, lorsqu’il est nécessaire :
aucune de ces deux solutions ne permet de satisfaire l’ensemble de ces critères. Cet article présente une solution possible à base de ZeroMQ, écrite en NodeJS et utilisée pour traiter les deux exemples précédents.
(Lire la suite…)
Un précédent article a exposé les grands principes de la sérialisation avec Thrift et Procotol Buffers. Ces deux frameworks promettent notamment une représentation des messages optimisée en termes de taille, ce qui est avéré dans le benchmark JVM Serializers : Thrift et Protocol Buffers y obtiennent une réduction de taille du message de 73% par rapport à la sérialisation native Java. Ce benchmark regroupe par ailleurs de nombreux autres frameworks de sérialisation du monde Java, mais se limite toutefois à l’utilisation d’un unique message de test.
Le présent article analyse l’influence de la structure (nombre et taille des objets, complexité de la grappe) sur la compacité du message sérialisé pour Thrift et Protocol Buffers. La comparaison est réalisée en Java, son protocole de sérialisation standard servant de référence.
(Lire la suite…)
Agenda :
Derrière cette formulation humoristique se cache un des fondements de l’industrialisation des développements : le fait de pouvoir tester de manière automatisée tout ou partie d’un système informatique.
Aussi bien dans les architectures complexes que dans les applications les plus simples, il est pertinent de pouvoir tester un composant logiciel unitairement (indépendamment des autres composants duquel il dépend) : les dépendances sont donc « mockées » ou simulées en français.
Il est aussi nécessaire de pouvoir créer un contexte favorable au scénario de test en injectant un jeu de données particulier via un automate de tests ou un injecteur.
Le développement d’applications Kinect n’échappe pas à cette nécessité. Voici comment simuler une Kinect avec la librairie MocKinect.
(Lire la suite…)
Depuis que les sites web sont devenus des applications riches, le besoin de push s’est largement manifesté. Il est présent sur des sites de mails, de feeds d’information, de partage de documents, de réservation de billets avec choix des places… Le push web permet de notifier le client d’une certaine information directement depuis le serveur, sans nécessiter de recharger la page du client. C’est typiquement un paradigme qu’on peut utiliser sur un site de messagerie instantanée.
Plusieurs technologies permettent d’implémenter ce genre de comportement, les plus connues étant probablement les WebSockets, les server-sent events (tous deux inclus dans les spécifications HTML5), ou encore le long polling, du web pull simulant du web push, utile sur certains navigateurs des moins récents.
(Lire la suite…)
La sérialisation est une des bases de la transmission de données entre systèmes. Certains langages proposent d’ailleurs une méthode de sérialisation en standard, qui leur est souvent propre.
L’interopérabilité entre systèmes hétérogènes nécessite que le format de sérialisation soit compréhensible par différents langages et plates-formes. De nombreux standards utilisent le mécanisme d’IDL (Interface Description Language) pour répondre à ce besoin : ASN.1, CORBA ou encore SOAP.
Depuis quelques années, de nouveaux frameworks basés sur un IDL ont vu le jour pour l’interopérabilité de technologies hétérogènes dans une optique d’économie de bande passante. Parmi eux, on trouve Thrift et Protocol Buffers. Ce premier article présente les deux frameworks sous l’angle de la sérialisation des messages et détaille leur utilisation en Java.
(Lire la suite…)
