Discussion :

[el3ctr0n]

Bonjour,

Dans le cadre d'un projet, je souhaite réaliser un stockage des toute les actions de mes visiteurs identifiés.
Mon utilisation de la base se limitera à du select/insert sur l'index d'utilisateur de manière à pourvoir ressortir toute ses actions pour y définir (via algo) un comportement type, etc..
Chacune des ces données contient des variables communes (date,id_user,type_action) et des infos spécifique au type de donnée (geolocalisation, inscription, clic sur lien, affichage de crea, ..).
Le nombre de donnée pouvant vite devenir conséquent (100-200million de stats/jour), mon choix de base se tourne naturellement vers mongoDB pour son architecture souple et pour la mise en cluster.

J'ai lu différentes docs, et à première vu, il faudrait au minimum 1 serveur routeur, 3 serveurs de configs et au moins 2 serveurs pour mes premiers shards.
Étant novice sur ce type de base, je n'est actuellement aucun recul sur la typologie de serveurs à utiliser.
Je suis actuellement chez OVH, auriez vous des conseils sur la gamme de serveur actuel qu'ils propose ? vaut t'il mieux privilégier la RAM au CPU? SDD ou non ? utilisation de plus de petits serveurs ou moins mais plus gros ?

Autre question, l'utilisation d'une seul collection pour y stocker cette énorme volume de donnée, n'est t'il pas un problème ? Si vous avez des expérience sur ce type de base, votre aide est la bienvenue

Merci par avance.

[rouardg]

Bonjour,

Difficile de répondre à toutes tes questions, car cela concerne à la fois de la conception, du développement, de l'architecture et de la haute-disponibilité.

Si tu débutes dans MongoDB, ce qui est aussi mon cas, je t'invite à suivre leurs formations gratuites en ligne :
https://university.mongodb.com/


A mon avis, il faut scinder le problème en 2 : partie développement et partie production.

Partie développement :

Pour commencer, il te faut au moins :
- 1 config serveur
- 1 routeur
- 2 Shard serveurs, sans Replica Set

A la limite, si l'on débute et que l'on n'a que très peu de moyens matériels, on peut tout faire tourner sur une seule machine, en utilisant des ports différents.

Il ne faut pas oublier que le routeur, qui est en fait l'exécutable mongos ne stocke pas de données, ce qui n'est pas le cas du config serveur et des Shards serveurs. Tous les 2 utilisent l'exécutable mongod, le config serveur stockant des méta-données (sur la composition du cluster, les Shards, les chunks, les plages de clé...), tandis que les Shards serveurs stockent les collections des bases de données.

Voici pour moi quelques règles essentielles dans le cas du Sharding :

- pour utiliser le Sharding, il faut d'abord l'activer au niveau de la base de données. Dans le cas contraire, les données de la base seront stockées sur le premier et même Shard S0 du cluster, ce qui peut faire du volume,

- on créé une collection Shardée en donnant une clé de Sharding, laquelle repose sur une ou plusieurs clés du document JSON.

Par exemple, je veux stocker des document JSON comme {a:"valeurA", b:"valeurB", c:"valeurC", d:"valeurD").

Si je sais que mes documents vont être recherchés la plupart du temps sur les clés b et d, alors je vais utiliser b et d comme clé de Sharding.

Il faudra aussi indiquer si la clé de Sharding, ici (b, d) est unique ou pas.

- il est possible de sharder une collection existante

- par défaut, MongoDB gère les plages de valeurs affectées à la Shard Key. Par exemple, si l'on a choisi le champ Name comme clé de sharding, MongoDB peut décider par exemple de stocker :

- les noms de Jane à Joe sur le Shard S0
- les noms de Joe à Kyle sur le Shard S1
- les noms de Kyle à Matt sur le Shard S2

Les données qui font parties d'une plage (Valeur min, Valeur max) sont appelées Chunk, le but étant que les Chunk soient répartis de manière à peu près équitable sur les différents Shards.

- comme on vient de le voir, MongoDb s'occupe du split des données suivant différentes plages, mais si on le souhaite, on peut imposer ses propres plages

- pour pouvoir sharder une collection, il faut comme on l'a vu, indiquer une Shard Key. Mais il faut en prérequis que cette Shard Key soit indexée


Cela fait beaucoup de chose, aussi voici un exemple qui porte sur une collection example dans la base test, constituée de documents JSON ayant 6 champs (A à F).

En gros :
- on détruit la collection example, dans le cas où elle existerait
- on a décidé que la clé de Sharding portait sur le triplet (B,C,D). aussi en prérequis on crée un index sur ce triplet
- on n'oublie pas d'activer le Sharding sur la base test
- à l'aide de la commande sh.splitAt, on a décidé d'allouer nous même les plages de valeurs
- sh.status nous donne des informations sur le Sharding
- à l'aide de boucles imbriquées, on charge la collection

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
db.example.drop();
db.example.createIndex( { b : 1, c : 1, d : 1 } );
sh.enableSharding("test");
sh.shardCollection("test.example", { b : 1, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 2, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 3, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 4, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 5, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 6, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 7, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 8, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 9, c : 1, d : 1 } );
sh.splitAt("test.example", { b : 10, c : 1, d : 1 } );
sleep(30000);.
sh.status();
 
for (i=1; i<=10; i++) { 
    for (j=1; j<=10; j++) { 
        for (k=1; k<=10; k++) { 
            var x = [];
            for (l=1; l<=10; l++) { 
                for (m=1; m<=10; m++) { 
                    for (n=1; n<=10; n++) { 
                    x.push( { a : i, b : j, c : k, d : l, e: m, f: n } );
                    }
                }
            };
            db.example.insert(x);
        };
    };
};

Pour finir, 27017 est le port par défaut d'une base MongoDB. Dans le cas d'un cluster Shardé, étant donné que le client doit se connecter à un routeur (au process mongos donc) et pas à une base en directe, il faut attribuer ce port à un routeur mongos, e tutiliser d'autres ports pour mongod.



Partie production :

Là il te faut au moins 3 config serveurs.
Il te faut plusieurs routeurs (je ne sais pas te dire combien).
Le nombre de Shards dépend du nombre de collections à sharder, du nombre de plages souhaitées et du volume de données à répartir.

Ensuite il faut penser à la haute disponibilité, c'est-à-dire à l'utilisation de Replica Sets. En clair, un Shard ne va plus reposer sur un serveur, mais sur un Replica Set qui en temps normal est constitué de 3 serveurs.

Supposons que je veuille me monter le cluster Shardé suivant :
- 5 Shards, chaque Shard reposant sur un Replica Set de 3 serveurs => 15 serveurs au total
- 4 routeurs => 4 serveurs
- 3 config serveurs => 3 serveurs

J'en arrive à un total de 22 serveurs !

Il est possible de diminuer le nombre de serveurs. Pour cela, 2 astuces :
- le routeur est en fait le process mongos qui ne gère pas de bases de données (pas de fichiers physiques). On peut donc le mettre sur un serveur de données, un serveur autre, voir même sur un poste client.
- les 3 Config Serveurs peuvent être mis sur 3 des 5 Shards. Par contre, il faudra éviter le Shard primaire (le S0) car comme celui-ci accueille toutes les bases non shardées, il est plus chargé que les autres.

Pour le reste (RAM, CPU, disques...) je ne sais pas te répondre, car je n'ai pas encore étudié l'architecture de MongoDB, et je ne sais pas ce que cela consomme, notamment en RAM et CPU.

[rouardg]

Dernier point :

Chacune des ces données contient des variables communes (date,id_user,type_action) et des infos spécifique au type de donnée (geolocalisation, inscription, clic sur lien, affichage de crea, ..).

A noter que l'insertion d'un document JSON ne peut se faire que si ce document inclut les champs de la Shared Key.

Donc si tu crées une collection shardée sur tes variables communes, l'insertion va marcher quelque soit le type de données.

Dans le cas contraire, si tu souhaites utiliser les infos spécifiques dans la clé de Sharding, tu vas être amené à créer plusieurs collections.

Comme quoi, au final, il va falloir choisir avec grand soin ta ou tes clés de Sharding. Et donc passer du temps sur un environnement de développement comme celui que je t'ai décrit.

[el3ctr0n]

Hello, merci pour ta réponse.

J'ai lu de nombreuses docs sur l'architecture en sharding, sur la clé de shard et les chuncks, du côté de la configuration je pense m'en sortir.
Sur la clé de shard, je vais utiliser les deux premières lettre d'un md5 sur l'id utilisateur (256 possibilités) que je nome Lot.
Avec l'expérience ce type de découpage fonctionne plutôt bien, la répartition sera homogène entre les shards.
Mon besoin principal étant de récupérer toutes les stats d'un utilisateur, mes requêtes porterons principalement sur un utilisateur spécifique, ou éventuellement sur le type d'action limité à un lot.

Mon problème actuel étant de prévoir un coût technique à mon projet, mes questions portent surtout sur le choix de ces serveurs.
Pour ce qui est des serveurs routeurs, ils se situerons sur des serveurs que je dispose déjà.
Il me reste juste à définir mes 3serveurs de configs, et mes shards.

J'ai aussi approfondi mes recherches et j'ai trouvé ceci qui m'aide un peu : https://www.mongodb.com/blog/post/ca...db-ten-minutes
J'ai juste un peu de mal à comprendre ou va se situé mon working set, sur la RAM de chacun des shards ou sur la RAM des serveurs de configs ?
Faut'il que je mette mes shards en Raid si je fait du répliquat set ?
Je pense commencer sur deux shards en répliquât set soit 6serveurs + 3 de configs.
Quoi qu'il en soit je vais devoir faire des test pour déterminer la taille du working set, de mes stats et des indexs.