Java Tech Tips & Tutorials

Increase HBase read performance checklist Accès en parallèle, client "multihtread" Dans HBase les données sont découpées en Régions et ces Régions peuvent être servies par des Region Servers différents. La charge de lecture doit donc être dans la mesure du possible distribuée sur l'ensemble des serveurs.  Privilégier les lectures en mode "batch" L'API HBase permet de lotir des appels à la base dans des "Batch Operations". L’intérêt est d'éviter de trop nombreux aller/retour sur le réseau. Ainsi les opérations PUT, GET, DELETE peuvent être regroupées dans un seul appel à la base de donnée. HTable hTable = new HTable("cachetestdb"); List listOfget = new ArrayList (); for ( int i = 0; i < 10; i++) { String keyAsString = "17#" + i; Get get = new Get(Bytes.toBytes(keyAsString)); listOfget.add(get); } Object[] batch = hTable.batch(listOfget); for (Object object : batch) { Re

HBase + Subversion + Eclipse + Windows (it should be easy to adapt for Linux) Update : please note that since HBase-4336 / HBase 0.96 the source tree is split in more than one Maven module this post is no more relevant, i have created a new post on this subject : http://michaelmorello.blogspot.fr/2012/06/hbase-096-eclipse-maven.html This is a simple setup in order to play with the source code of HBase under Microsoft Windows. Since HBase use some Unix specific commands like chmod the only requirements here are  Cygwin and a working Maven 3 environment. (It is obvious that you need Java and Eclipse , but you DON'T need anything else like the Eclipse Maven plugin or any SSH configuration) 1. Checkout the source code The first step is to check out the source code from the Subversion repository. I did it under my cygwin home repository. In this example i want to play with the 0.90 branch : svn co http://svn.apache.org/repos/asf/hbase/branches/0.90/ hbase-0.90

Lorsque l'on insère une donnée dans HBase, la précédente version, si elle existe, n'est pas écrasée. HBase comme son mentor BigTable peut gérer plusieurs versions du contenu d'une même cellule. Pour ceux qui se demandent comment exploiter au mieux cette capacité de HBase voici un conseil de Bill Graham sur la mailing list HBase : "[...] Once someone realizes that you can store multiple values for the same cell,  each with a timestamp there can be a natural tendency to think "hey, I can store  a one-to-many using multiple version of a cell".  That's not the intent of versioned cell values. Versioned cell values can be thought of as a way to keep a history of change  for a single entity that at any given time only has one value. Like keeping  track of a state change over time. For a one-to-many relationship (i.e., a  user with many events), favor either multiple rows or multiple columns  instead." Pour résumer les versions multiples d'une mê

Enfin un framework qui me réconcilie avec les tests unitaires, non pas que j'étais très fâché, les tests unitaires sont nécessaires mais je ne prenais pas un grand plaisir à les faire. Je travaille en ce moment sur un projet de client/serveur basé sur les excellents framework Netty et Protobuf  et écrire des test unitaires sur ce type de projet très technique peut se révéler être assez difficile. Pourtant depuis peu je dois confesser que je prend un certain plaisir à en écrire, ceci depuis que j'ai découvert Mockito. Mockito ça sert à quoi ? L'un des problèmes avec les tests unitaires ce sont les objets qui sont mis en jeu. Certains objets sont en effet très difficile à instancier, il peut être même impossible de le faire si on est en phase de spécification et que seule l'interface a été écrite. Il est encore plus difficile de contrôler leur comportement pour recréer des contextes particuliers d’exécution comme recréer un contexte d'erreur. C'est là qu&

Avant-propos : à l'origine ce glossaire était destiné à consigner pour mon propre usage les définitions et les fonctions des différents éléments qui constituent la base de donnée NoSQL HBase. Il peut s'agir aussi bien de simples clarifications sur la sémantique comme de précisions beaucoup plus techniques sur le rôle joué par certains éléments. Il n'est pas exhaustif et est amené à être mis à jour au fil des évolutions de HBase. BloomFilter Filtre permettant d'exclure d'une recherche les FileStore d'une Region . Utilisé par exemple lorsque que l'on cherche la valeur associée à une clé, et que les données de cette clé sont potentiellement éclatées sur le MemStore et/ou plusieurs FileStore . Un BloomFilter permet alors de ne pas avoir à parcourir tous les FileStore présents dans la Region . Column Dans HBase la notion de colonne n'a pas réellement de sens.  Le modèle de gestion des données de HBase repose sur une notion de couple {clé, valeur}.

Dans quels cas le thread dump est utile ? Le thread dump est un instantané de l'activité des threads de la JVM. Leur analyse est intéressante dans les cas où l'activité de la JVM ne semble pas normale : Activité suspendue (deadlock/ interblocage ) ou partiellement suspendue (starvation/ famine ) Activité existante mais le "débit" est en deçà de ce qui est attendu (Goulot d'étranglement / Bottleneck) Activité existante mais le "débit" reste nul (Boucle infinie / Infinite Loop) Comment avoir un thread dump ? Nous nous limitons ici à la machine virtuel IBM sous AIX. Dans ce cas là il est extrêmement simple de déclencher la création d'un thread dump : il suffit de faire un kill -3 sur le processus Java. Un fichier dont le nom est javacore. [date] . [numero_processus] . [compteur] .txt est produit. Sur la sortie standard du processus vous devriez voir la ligne suivante s'afficher : JVMDUMP010I Java Dump written to ..... En général le dump

Ou « Combien de messages JMS un serveur JMS peut-t-il emmagasiner ? » Sous Weblogic (je ne sais pas comment cela se passe avec les autres) tout message JMS est stocké au moins partiellement dans la mémoire de la JVM, et cette mémoire n'étant pas infinie l'arrivée d'un grand nombre de messages associée à une mauvaise configuration du sous système JMS se solde souvent par un OutOfMemory. Le schéma ci dessous montrent les différents mécanismes qui peuvent être mis œuvre par un serveur JMS afin de gérer l'accumulation des messages JMS et de réguler leur arrivée. 1. Définir un quota Un message JMS consomme toujours de la mémoire . Partant de ce postulat un quota devrait toujours être défini sur un serveur JMS. Il évitera une saturation mémoire en refusant aux producteurs de poster des nouveaux messages lorsque le quota est atteint. Les quotas peuvent être définis au niveau des modules JMS, cependant il peut être plus "sécurisant" de les placer directement au n