Oracle NoSQL : architecture
- Détails
- Catégorie : News
- Publié le jeudi 2 mai 2013 21:45
- Écrit par Administrator
- Affichages : 41601
Chose promise chose due, je viens de faire un tutorial pour monter son propre banc Oracle NoSQL à la maison :
---->testbed : NoSQL 11.2.2.0 <----
Mais, avant d’installer votre Oracle NoSQL, il faut comprendre son architecture et en connaitre les termes.
Je vais donc essayer d’expliquer cela…
Un KVStore (base NoSQL) est un ensemble de nœuds de stokages (SN : Storage Node) qui hébergent des nœuds de réplication (RN : Replication Nodes). Les données sont réparties sur les Replication Nodes(RN). Les Storages Nodes (SN) sont des serveurs (physiques ou virtuels).
Un SN peut héberger un ou plusieurs RN. Chaque RN peut contenir une ou plusieurs partitions. Nous pourrions résumer cela en disant qu’un SN est un serveur physique (un linux) qui héberge un ou des serveurs logiques (RN) et que ces serveurs logiques hébergent la donnée (partition).
Un groupe de RN forme un Shard (tesson en français). Dans un Shard il y a donc n Replication Node dont un est le master et les autres des replicas. La donnée est répliquée sur l’ensemble du Shard.
Dans un Shard, le nœud master est celui qui écrit dans la base de données et est chargé de recopier la donnée sur les replicas. Les replicas sont utilisés pour les opérations de read-only.
Chaque Shard contient une ou plusieurs partitions. Un couple valeur/clé appartient à une partition (voir news précédente).
Le nombre de RN contenu dans un Shard s’appelle le Replication Factor (RF). Plus le RF est élevé plus le débit en lecture est meilleur mais moins bon en écriture, car le master doit répliquer la donnée sur l’ensemble des replicas du Shard. Plus il y aura de Shard, et plus les performances en lecture et en écriture seront meilleures, car les données seront éclatées sur davantage de partition.
Un peu de graphisme pour mieux visualiser et aider à la compréhension:
Ici le KVStore est réparti en n Shard. Chaque Shard est composé de 3 Storage Node (serveur physique), le Replication Factor est de 3. Les données sont donc répétées 3 fois: 1 fois sur le Master (en écriture-lecture) et 2 fois sur les Replicas (en lecture). Dans cette configuration, sur un Shard on peut perdre 2 serveurs (SN), l’application continuera de voir l’ensemble de la base NoSQL.
Chaque Shard peut être vu comme une base de données indépendante pour un couple clé/valeur. Et le Shard lui-même est composé de 3 bases indépendantes (bases identiques). Donc si on veut de la puissance il suffit de rajouter des Shards donc des serveurs. Il faut reconnaitre que cette architecture est plus scalable que le RAC. En RAC on peut rajouter des serveurs mais les contentions disques resteront voir augmenteront suivant le codage de l’application, mais on gagnera cependant en puissance de calcul.
On pourrait résumer par : en RAC ou Database classique on partitionne la donnée dans une même base de données lu par un serveur (database classique) ou plusieurs serveurs (RAC), alors qu’en NoSQL on partitionne la donnée sur des serveurs (et des stockages) différents et c’est l’ensemble des serveurs qui forment la base de données complète… 2 philosophies différentes.