{"id":1431,"date":"2014-02-23T20:00:30","date_gmt":"2014-02-23T19:00:30","guid":{"rendered":"http:\/\/www.unicoda.com\/?p=1431"},"modified":"2014-07-11T16:25:56","modified_gmt":"2014-07-11T14:25:56","slug":"mongo-dans-tous-ses-etats-sharding","status":"publish","type":"post","link":"https:\/\/www.unicoda.com\/?p=1431","title":{"rendered":"Mongo Dans Tous Ses Etats – Sharding"},"content":{"rendered":"

La suite de mon \u00e9tude concernait le processus de sharding. Comme pour la r\u00e9plication, les informations proviennent cette fois du guide sur le sharding<\/a>.<\/p>\n

Sharding<\/h1>\n

Le sharding divise la donn\u00e9e et la distribue sur plusieurs machines, aussi appel\u00e9 shard<\/em> et r\u00e9sout ainsi le probl\u00e8me de scaling horizontal. Un cluster est constitu\u00e9 de shard, serveur de configuration et mongos. Le sharding r\u00e9duit la quantit\u00e9 de donn\u00e9e que chaque serveur doit stocker, ainsi que le nombre d’op\u00e9rations \u00e0 effectuer.<\/p>\n

Sharded cluster = shards + query routers (mongos) + config servers<\/p>\n

Shard (mongod \/ Replica Set)<\/h2>\n

Stock la donn\u00e9e.
\nEn production, pour des questions de haute disponibilit\u00e9 et de consistence des donn\u00e9es, chaque shard est un replica set et le cluster est constitu\u00e9 de deux shards ou plus.<\/p>\n

Query Router (mongos)<\/h2>\n

Sert d’interface avec l’application cliente et dirige les op\u00e9rations vers le shard appropri\u00e9. Un cluster peut contenir plusieurs routeurs pour distribuer la charge.<\/p>\n

En production, un mongos ou plus.
\nLes curseurs et d’autres ressources \u00e9tant sp\u00e9cifique \u00e0 une instance de mongos, chaque client doit interagir avec seulement un mongos.<\/p>\n

Config Server<\/h2>\n

Stock les m\u00e9tadatas du cluster.
\nContient un mapping entre les donn\u00e9es du cluster et les shards (Quelle donn\u00e9e se trouve sur quel shard). En production, un cluster poss\u00e8de exactement<\/strong> 3 config servers.<\/p>\n

Si un ou deux serveurs de configuration deviennent indisponible, les m\u00e9tadatas du cluster passe en lecture seule jusqu’\u00e0 ce que les trois serveurs soient \u00e0 nouveau disponible. Il est toujours possible de lire et d’\u00e9crire sur les shards mais aucune migration et aucun d\u00e9coupage n’aura lieu sur les chunks.<\/p>\n

Les sauvegardes de ces serveurs sont critiques.
\nSi le nom ou l’adresse qu’un cluster utilise pour se connecter \u00e0 un serveur de configuration change, il est n\u00e9cessaire de red\u00e9marrer tous<\/strong> les mongod et les mongos! D’o\u00f9 l’utilit\u00e9 des CNAMEs pour identifier les serveurs de configuration.<\/p>\n

Chaque serveur doit \u00eatre sur une machine s\u00e9par\u00e9e.<\/p>\n

Partitionnement des donn\u00e9es<\/h2>\n

Le partitionnement s’effectue en utilisant une cl\u00e9 de sharding (sharding key).<\/p>\n

Shard Key<\/h3>\n

Soit un champ index\u00e9 ou champ index\u00e9 compos\u00e9 existant dans tous les documents de la collection. MongoDB divise la shard key en morceaux (chunks) et les distribue de mani\u00e8re \u00e9gale entre les shards. La division de la cl\u00e9 s’effectue soit avec un range based partitioning ou un hash based partitioning.<\/p>\n

Pour s\u00e9lectionner une shard key, d\u00e9terminer les champs commun\u00e9ment inclut dans les requ\u00eates pour une application pr\u00e9cise et d\u00e9terminer quelles op\u00e9rations demandent le plus de performance.<\/p>\n

L’index sur la shard key ne peut pas \u00eatre un multikey index.<\/p>\n

Range Based Sharding<\/h3>\n

S\u00e9paration des donn\u00e9es en plusieurs intervalles. Deux documents avec une cl\u00e9 de sharding proche ont de grandes chances d’\u00eatre dans le m\u00eame chunk. N\u00e9anmoins, il peut en r\u00e9sulter une distribution in\u00e9gale des donn\u00e9es sur les shards. Plus efficace en cas de requ\u00eates sur des intervalles. Le router peut d\u00e9termin\u00e9 plus facilement vers quels shards diriger la requ\u00eate.<\/p>\n

Hash Based Sharding<\/h3>\n

MongoDB calcule un hash de la valeur du champ et utilise ces hashs pour cr\u00e9er les chunks. Deux documents avec une cl\u00e9 de sharding proche ont tr\u00e8s peu de chance d’\u00eatre dans le m\u00eame chunk. Cela permet de s’assurer d’une distribution plus al\u00e9atoire des donn\u00e9es au sein du cluster et assure une distribution r\u00e9guli\u00e8re des donn\u00e9es sur les shards. Une requ\u00eate sur un intervalle \u00e0 de grande chance de s’adresser \u00e0 tous les shards.<\/p>\n

M\u00e9canismes<\/h2>\n

Mongo dispose de m\u00e9canismes pour \u00e9viter qu’un shard devienne trop grand: splitting et le balancer.<\/p>\n

Splitting<\/h3>\n

Lorsqu’un chunk devient trop grand, mongo le divise en deux.
\nCeci n’affecte pas les donn\u00e9es ou les shards.<\/p>\n

Balancing<\/h3>\n

Permet de migrer des chunks. Lorsque la distribution des donn\u00e9es devient irr\u00e9guli\u00e8re, le balancer va migrer des chunks du shard avec le plus grande nombre de chunks \u00e0 celui qui en poss\u00e8de le moins. Les donn\u00e9es sont retir\u00e9s du shard d’origine apr\u00e8s une migration totale et r\u00e9ussie des donn\u00e9es.<\/p>\n","protected":false},"excerpt":{"rendered":"

La suite de mon \u00e9tude concernait le processus de sharding. Comme pour la r\u00e9plication, les informations proviennent cette fois du guide sur le sharding. Sharding Le sharding divise la donn\u00e9e et la distribue sur plusieurs machines, aussi appel\u00e9 shard et r\u00e9sout ainsi le probl\u00e8me de scaling horizontal. Un cluster est constitu\u00e9 de shard, serveur de … Continuer la lecture de « Mongo Dans Tous Ses Etats – Sharding »<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[126],"tags":[156,157],"class_list":["post-1431","post","type-post","status-publish","format-standard","hentry","category-logiciellibre","tag-mongodb","tag-sharding"],"_links":{"self":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/1431","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=1431"}],"version-history":[{"count":8,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/1431\/revisions"}],"predecessor-version":[{"id":1654,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=\/wp\/v2\/posts\/1431\/revisions\/1654"}],"wp:attachment":[{"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=1431"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=1431"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.unicoda.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=1431"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}