Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with
or
.
Download ZIP
Browse files

Started translation. Last part remains, but backing it up.

  • Loading branch information...
commit 1ed872a0d11a96613f8d072cfe788c68cf41f429 1 parent c185f7b
@Jil Jil authored
Showing with 41 additions and 38 deletions.
  1. +41 −38 editions/1/fr/clustering.html
View
79 editions/1/fr/clustering.html
@@ -1,4 +1,4 @@
-<title>Clustering</title>
+<title>Groupement de serveurs</title>
<meta charset="utf-8">
@@ -10,27 +10,30 @@
<script src="../../../script.js"></script>
-<h2 id="clustering">Clustering</h2>
+<h2 id="clustering">Groupement de serveurs</h2>
-<p>OK, you’ve made it this far. I’m assuming you more or less understand what CouchDB is and how the application API works. Maybe you’ve deployed an application or two, and now you’re dealing with enough traffic that you need to think about scaling. “Scaling” is an imprecise word, but in this chapter we’ll be dealing with the aspect of putting together a partitioned or sharded cluster that will have to grow at an increasing rate over time from day one.
+<p>Bon ! vous êtes arrivé jusque là. J’estime donc que vous comprenez, dans les grandes lignes, ce qu’est CouchDB et comment l’API fonctionne. Peut-être avez-vous même déployé une ou deux applications et que vous rencontrez un certain succès, ce qui vous amène à envisager le passage à l’échelle. Dans ce chapitre, nous allons mettre en place une grappe de serveurs (<em>cluster</em> en anglais) partitionnée ou fragmentée (<em>sharded</em> en anglais), laquelle va croître à un taux croissant à compter de sa mise en service.
-<p>We’ll look at request and response dispatch in a CouchDB cluster with stable nodes. Then we’ll cover how to add redundant hot-failover twin nodes, so you don’t have to worry about losing machines. In a large cluster, you should plan for 5–10% of your machines to experience some sort of failure or reduced performance, so cluster design must prevent node failures from affecting reliability. Finally, we’ll look at adjusting cluster layout dynamically by splitting or merging nodes using replication.
+<p>Dans un premier temps, nous nous intéresserons à la distribution des requêtes et des réponses dans une grappe CouchDB stable. Ensuite, nous verrons comment y inclure de la rendondance pour rendre un nœud hautement disponible. Ainsi, vous n’aurez plus à vous soucier de la perte d’une machine. En effet, dans une large grappe, vous devriez prévoir que 5 à 10% de vos machines connaîtront des problèmes (défaillance, performances dégradées) ; cela doit être pris en compte lors de la conception de la grappe pour qu’une défaillance ne nuise pas à la stabilité de l’ensemble. Enfin, nous nous pencherons sur la modification dynamique de la répartition des données en subdivisant ou en fusionnant des nœuds à l’aide du mécanisme de réplication.
-<h3 id="lounge">Introducing CouchDB Lounge</h3>
+<h3 id="lounge">Présentation du <em>CouchDB Lounge</em></h3>
-<p><a href="http://tilgovi.github.com/couchdb-lounge/">CouchDB Lounge</a> is a proxy-based partitioning and clustering application, originally developed for <a href="http://www.meebo.com">Meebo</a>, a web-based instant messaging service. Lounge comes with two major components: one that handles simple GET and PUT requests for documents, and another that distributes view requests.
+<p><a href="http://tilgovi.github.com/couchdb-lounge/">CouchDB Lounge</a>
+est une application mandataire (<em>proxy</em>) — originellement développée pour <a href="http://www.meebo.com">Meebo</a>, service de messagerie instantannée par navigateur — qui permet de partitionner et de <a href="http://www.cnrtl.fr/lexicographie/Grappeler">grappeler</a> des instances CouchDB. Lounge se compose de deux modules : le premier, <em>dumbproxy</em> s’occupe des « simples » requêtes GET et PUT visant à obtenir un document ; le second, <em>smartproxy</em> répartit les requêtes nécessitant de recourir à des vues.
-<p>The <em>dumbproxy</em> handles simple requests for anything that isn’t a CouchDB view. This comes as a module for <a href="http://nginx.net/">nginx</a>, a high-performance reverse HTTP proxy. Because of the way reverse HTTP proxies work, this automatically allows configurable security, encryption, load distribution, compression, and, of course, aggressive caching of your database resources.
+<p><em>dumbproxy</em> traite toutes les requêtes qui n’utilisent pas le mécanisme de vues de CouchDB. C’est un module de <a href="http://nginx.net/">nginx</a>, serveur mandataire frontal (en anglais, <em>reverse proxy</em>) HTTP très performant. Puisque ce serveur est le point d’entrée de votre infrastructure, et parce qu’il intègre les mécanismes de mandataire, vous pouvez le configurer pour apporter la sécurité que vous désirez, le chiffrement, la répartition de charge, la compression des flux et, bien sûr, l’antémémoire (en anglais, <em>cache</em>) pour soulager vos bases de données.
-<p>The <em>smartproxy</em> handles only CouchDB view requests, and dispatches them to all the other nodes in the cluster so as to distribute the work, making view performance a function of the cluster’s cumulative processing power. This comes as a daemon for Twisted, a popular and high-performance event-driven network programming framework for Python.
+<p>Quant à <em>smartproxy</em>, il traite uniquement les requêtes sur les vues CouchDB qu’il distribue entre les nœud de la grappe afin que les performances soient fonction de la puissance de celle-ci. Cela prend la forme d’un démon qui hante Twisted, <em>framework</em> Python de développement réseau orienté évènements et à hautes performances en plus d’être populaire.
-<h3 id="hashing">Consistent Hashing</h3>
+<h3 id="hashing">Empreintes stabilisées</h3>
-<p>CouchDB’s storage model uses unique IDs to save and retrieve documents. Sitting at the core of Lounge is a simple method of hashing your document IDs. Lounge then uses the first few characters of this hash to determine which shard to dispatch the request to. You can configure this behavior by writing a <em>shard map</em> for Lounge, which is just a simple text configuration file.
+<p><em>NdT : le terme anglais <a href="http://en.wikipedia.org/wiki/Consistent_hashing"><em>consistent hashing</em></a> (empreintes stabilisées) ne semble pas avoir de traduction française courante. Il s’agit d’une technique de génération d’empreintes qui évite d’avoir à recalculer toutes les empreintes en cas d’ajout ou de suppression d’un espace (voir ci-après). Vous pourriez trouver l’explication anglaise de Wikipédia plus compréhensible que celle donnée ci-dessous.
-<p>Because Lounge allocates a portion of the hash (known as a keyspace) to each node, you can add as many nodes as you like. Because the hash function produces hexidecimal strings that bare no apparent relation to your DocIDs, and because we dispatch requests based on the first few characters, we ensure that all nodes see roughly equal load. And because the hash function is consistent, Lounge will take any arbitrary DocID from an HTTP request URI and point it to the same node each time.
+<p>Le modèle de persistence CouchDB recourre à des identifiants uniques (ID) pour sauvegarder et ouvrir des documents. Aussi, c’est avec logique qu’au cœur de Lounge se trouve un système d’empreinte (<em>hash</em> en anglais) qui transforme ces identifiants de manière cohérente. À l’aide des premières lettres de cette empreinte, il sait vers quel nœud envoyer la requête. Vous pouvez paramétrer ce comportement en écrivant une <em>shard map</em>, laquelle se trouve d’un fichier texte de configuration.
-<p>This idea of splitting a collection of shards based on a keyspace is commonly illustrated as a ring, with the hash wrapped around the outside. Each tic mark designates the boundaries in the keyspace between two partitions. The hash function maps from document IDs to positions on the ring. The ring is continuous so that you can always add more nodes by splitting a single partition into pieces. With four physical servers, you allocate the keyspace into 16 independent partitions by distributing them across the servers like so:
+<p>La clé d’espace (<em>keyspace</em> en anglais) compose la première partie de l’empreinte et identifie chaque nœud, ce qui vous permet de définir autant de nœuds que vous le désirez. La fonction d’empreinte produit une chaîne hexadécimale qui ne semble avoir aucune relation avec les identifiants de vos documents et, cela couplé à la clé d’espace, assure une répartition globalement équitable entre les nœuds. De plus, puisque la fonction d’empreinte est cohérente, plusieurs requêtes d’accès à un même document seront toujours dirigées vers le même nœud.
+
+<p>L’idée qui consiste à diviser un ensemble de fragments à l’aide d’une clé d’espace peut être illustrée par un anneau certi d’empreintes. Chaque dégré (NdT : imaginez les marques d’une horloge) délimite la frontière entre deux partitions. La fonction d’empreinte assure la correspondance entre un identifiant de document à l’intérieur de l’anneau et sa position à l’extérieur de celui-ci. En outre, l’anneau est continu, ce qui vous permet toujours d’y ajouter de nouveaux nœuds ; pour cela, vous subdivisez un espace en plusieurs espaces. Ainsi, avec quatre serveurs physiques, vous pouvez partager l’espace en seize partitions indépendantes que vous répartissez de la manière suivante :
<div>
@@ -52,57 +55,57 @@ <h3 id="hashing">Consistent Hashing</h3>
</div>
-<p>If the hash of your DocID starts with <code>0</code>, it would be dispatched to shard <code>A</code>. Similarly for <code>1</code>, <code>2</code>, or <code>3</code>. Whereas, if the hash started with <code>c</code>, <code>d</code>, <code>e</code>, or <code>f</code>, it would be dispatched to shard <code>D</code>. As a full example, the hash <code>71db329b58378c8fa8876f0ec04c72e5</code> is mapped to the node <code>B</code>, database <code>7</code> in the table just shown. This could map to <code>http://B.couches.local/db-7/</code> on your backend cluster. In this way, the hash table is just a mapping from hashes to backend database URIs. Don’t worry if this all sounds very complex; all you have to do is provide a mapping of shards to nodes and Lounge will build the hash ring appropriately—so no need to get your hands dirty if you don’t want to.
+<p>Si l’empreinte de votre document commence par <code>0</code>, la requête sera envoyée au fragment <code>A</code>. Il en va de même pour <code>1</code>, <code>2</code> et <code>3</code>. En revanche, si elle commence par <code>c</code>, <code>d</code>, <code>e</code> ou <code>f</code>, la requête est envoyée à <code>D</code>. Par exemple, l’empreinte <code>71db329b58378c8fa8876f0ec04c72e5</code> est dirigée vers le nœud <code>B</code>, dans la base de données <code>7</code>, ce qui pourrait correspondre à <code>http://B.couches.local/db-7/</code> dans votre environnement. De cette manière, la table de correspondance fait le lien entre une empreinte et une base de données. Ne vous inquiétez pas si cela vous semble très compliqué : vous n’avez qu’à fournir le lien entre les fragments et les bases, Lounge s’occupera de générer l’anneau sans que vous ayez à mettre les mains dans le cambouis si vous ne le désirez pas.
-<p>To frame the same concept with web architecture, because CouchDB uses HTTP, the proxy can partition documents according to the request URL, without inspecting the body. This is a core principle behind REST and is one of the many benefits using HTTP affords us. In practice, this is accomplished by running the hash function against the request URI and comparing the result to find the portion of the keyspace allocated. Lounge then looks up the associated shard for the hash in a configuration table, forwarding the HTTP request to the backend CouchDB server.
+<p>Nous pouvons faire le parallèle avec le web : puisque CouchDB utilise HTTP, le serveur mandataire peut répartir les documents en fonction de l’URL sans avoir à connaître le contenu accesible par l’URL. C’est un principe de l’approche REST et c’est un des avantages que nous procure HTTP. En pratique, cette correspondance est assurée par une empreinte de l’URL demandée, laquelle est comparée à la table de correspondance pour trouver la clé d’espace appropriée. Lougne n’a plus qu’à trouver le fragment correspondant dans sa configuration pour faire suivre la requête vers le bon serveur CouchDB.
-<p>Consistent hashing is a simple way to ensure that you can always find the documents you saved, while balancing storage load evenly across partitions. Because the hash function is simple (it is based on CRC32), you are free to implement your own HTTP intermediaries or clients that can similarly resolve requests to the correct physical location of your data.
+<p>Le mécanisme d’empreintes stabilisées vous garantit l’accès aux documents que vous sauvegardez ainsi que l’égale répartition du stockage sur vos nœuds. De plus, la simplicité de la fonction d’empreinte (basée sur CRC32) vous permet de concevoir vos propres mandataires HTTP ou vos propres clients capables de s’adresse au bon serveur.
-<h4 id="storage">Redundant Storage</h4>
+<h4 id="storage">Redondance du stockage</h4>
-<p>Consistent hashing solves the problem of how to break up a single logical database evenly across a set of partitions, which can then be distributed across multiple servers. It does not address the problem of how to ensure that data you’ve stored is safe from loss due to hardware or software failure. If you are serious about your data, you can’t consider it saved until you have at least two copies of it, preferably in different geographical locations.
+<p>Le recours aux empreintes stabilisées répond à la problématique de répartition d’une base de données en fragments égaux, lesquels peuvent être répartis à leur tour sur différents serveurs. En revanche, cela ne met en rien vos données à l’abri. En effet, les données demeurent stockées à un seul endroit, les mettant ainsi à la merci d’un incident matériel ou logiciel. Vous ne pouvez considérer vos données en sécurité qu’à la condition qu’elles soient présentent en deux lieux différents, si possible géographiquement éloignés l’un de l’autre.
-<p>CouchDB replication makes maintaining hot-failover redundant slaves or load-balanced multi-master databases relatively painless. The specifics of how to manage replication are covered in <a href="replication.html">Chapter 16, Replication</a>. What is important in this context is to understand that maintaining redundant copies is orthogonal to the harder task of ensuring that the cluster consistently chooses the same partition for a particular document ID.
+<p>Le mécanisme de réplication de CouchDB permet d’obtenir sans trop d’efforts les fonctionnalités de basculement immédiat vers des bases esclaves redondantes ou de répartition de charge en bases de données multi-maîtresses (c’est-à-dire en réplication bidirectionnelle). Le paramétrage de la réplication est expliqué au <a href="replication.html">chapitre 16, <em>Réplication</em></a>. Ce qui importe ici, c’est de comprendre que maintenir des copies redondantes doit être dissocié de la tâche, plus complexe, consistant à toujours faire correspondre à un identifiant de document donné, un fragment donné.
-<p>For data safety, you’ll want to have at least two or three copies of everything. However, if you encapsulate redundancy, the higher layers of the cluster can treat each partition as a single unit and let the logical partitions themselves manage redundancy and failover.
+<p>Considérons que vous avez deux ou trois copie de chaque donnée pour en assurer la sécurité. Vous avez alors deux ou trois copies d’un même fragment. Du point de vue de la grappe, il n’existe qu’un fragment ; la duplication des données, la bascule en cas de défaillance et la répartition de charge sont assurées par le fragment en question.
-<h4 id="proxies">Redundant Proxies</h4>
+<h4 id="proxies">Redondance des serveurs mandataires</h4>
-<p>Just as we can’t accept the possibility of hardware failure leading to data loss, we’ll need to run multiple instances of the proxy nodes to avoid the chance that a proxy node crash could leave portions of the cluster unavailable. By running redundant proxy instances, and load balancing across them, we can increase cluster throughput as well as reliability.
+<p>De la même manière que nous ne pouvons laisser une éventuelle défaillance matérielle provoquer une perte de données, nous aurons recours à plusieurs serveurs mandataires afin que la perte de l’un d’eux ne rendent pas nos bases inacessibles. Leur redondance ainsi que la répartition de charge entre eux augmentera la disponibilité et la capacité totale à absorber les requêtes.
-<h4 id="merging">View Merging</h4>
+<h4 id="merging">Fusion des vues</h4>
-<p>Consistent hashing leaves documents on the proper node, but documents can still <code>emit()</code> any key. The point of incremental MapReduce is to bring the function to the data, so we shoudn’t redistribute the emitted keys; instead, we send the queries to the CouchDB nodes via HTTP proxy, and merge the results using the Twisted Python Smartproxy.
+<p>Le mécanisme d’empreintes stabilisées dépose les documents sur les bons nœuds. Toutefois, il peuvent toujours émettre (<code>emit()</code>) n’importe quelle clé. L’intérêt de MapReduce incrémental est de déporter le traitement aux nœuds de sorte que nous n’avons pas à redistribuer les clés émises. Il s’agit de faire suivre la requête du client, via le mandataire HTTP, à tous les nœuds et de fusionner les résultats à l’aide du Twisted Python Smartproxy.
-<p>Smartproxy sends each view request to every node, so it needs to merge the responses before returning them to the client. Thankfully, this operation is not resource-intensive, as merging can be done in constant memory space no matter how many rows are returned. The Smartproxy receives the first row from each cluster node and compares them. We sort the nodes according to their row key using CouchDB’s collation rules. Smartproxy pops the top row from the first sorted node and returns it to the client.
+<p>Smartproxy envoie chaque requête de vue à tous les nœuds. Il doit donc fusionner les réponses avant de les envoyer au client. Heureusement, cette opération n’est pas consommatrice de ressources, car la fusion peut s’opérer à pérmiètre mémoire constant quel que soit la volumétrie. Smartproxy reçoit le premier enregistrement de chaque nœud de la grappe et les compare. Nous trions les nœuds selon leur clé d’enregistrement en appliquant les règles d’inteclassement de CouchDB. Ensuite, Smartproxy récupère le premier enregistrement du nœud qu’il vient de classer premier et l’envoie au client.
-<p>This process can be repeated as long as the clients continue to send rows, but if a limit is imposed by the client, Smartproxy must end the response early, discarding any extra rows sent by the nodes.
+<p>Ce processus peut se poursuivre tant que les clients envoient des enregistrements, mais si une limite est donnée par le client, Smartproxy doit achever le traitement aussitôt et dédaigner les autres enregistrement dont lui font part les nœuds.
-<p>This layout is simple and loosely coupled. It has the advantage that it’s simple, which helps in understanding topology and diagnosing failures. There is work underway to move the behavior to Erlang, which ought to make managing dynamic clusters possible as well as let us integrate cluster control into the CouchDB runtime.
+<p>Cette approche est simple et faiblement couplée. Elle présente l’avantage d’être simple, ce qui permet de plus facilement appréhender la topologie et d’analyser les erreurs. Il y a du travail pour réussir à transplanter ce comportement en Erlang, mais cela nous permettrait de gérer des grappes dynamiques et d’intégrer le contrôle des ces derniers dans le cœur de CouchDB.
-<h3 id="growing">Growing the Cluster</h3>
+<h3 id="growing">Étendre la grappe</h3>
-<p>Using CouchDB at web scale likely requires CouchDB clusters that can be scaled dynamically. Growing sites must continuously add more storage capacity, so we need a strategy to increase the size of our cluster without taking it down. Some workloads can result in temporary growth in data size, in which case we’ll also need a process for shrinking the cluster without an interruption in service.
+<p>L’utilisation de CouchDB à l’échelle du web nécessite vraisemblablement d’avoir des grappes qui peuvent s’étendre de manière dynamique. Les sites en forte croissance ajoutent sans cesse de nouveaux espaces de stockage ; nous avons par conséquent besoin de pouvoir augmenter la taille de notre grappe sans pour autant l’arrêter. En outre, certaines charges provoquent une augmentation épisodique de la taille de la base, ce qui induit la nécessité d’un processus de réduction de la grappe sans interrompre son fonctionnement.
-<p>In this section, we’ll see how we can use CouchDB’s replication filters to split one database into several partitions, and how to use that technique to grow the cluster without downtime. There are simple steps you can take to avoid partitioning databases while growing the cluster.
+<p>Dans cette section, nous verrons comment utiliser les filtres de réplication de CouchDB pour subdiviser une base de données en plusieurs fragments, et comment utiliser cette technique pour étendre notre grappe sans l’arrêter. Vous pouvez en quelques étapes éviter de partionner les bases de données en étendant la grappe.
-<p><em>Oversharding</em> is a technique where you partition the cluster so that there are multiple shards on each physical machine. Moving a partition from one machine to another is simpler than splitting it into smaller partitions, as the configuration map of the cluster used by the proxy only needs to change to point to shards at their new homes, rather than adding new logical shards. It’s also less resource-intensive to move a partition than to split it into many.
+<p>La technique de <em>fragmentation zélée</em> (<em>oversharding</em> en anglais) consiste à partitionner la grappe de manière à avoir plusieurs fragments sur un même hôte physique. En effet, déplacer un fragment d’une machine vers une autre est une tâche plus simple que de le subdiviser, car seule la configuration de la grappe telle que décrite dans le serveur mandataire doit être mise à jour pour pointer vers le nouveau serveur, plutôt que de devoir y inclure de nouveaux fragments. Cela nécessite moins de ressources de migrer un fragment que de le subdiviser.
-<p>One question we need to answer is, “How much should we overshard?” The answer depends on your application and deployment, but there are some forces that push us in one direction over another. If we get the number of shards right, we’ll end up with a cluster that can grow optimally.
+<p>La question que nous devons alors nous poser est de savoir quel zèle est nécessaire. La réponse est fonction de votre application et de votre déploiement, mais il est des éléments qui nous poussent davantage d’un côté que de l’autre. Si nous taillons correctement nos fragments, nous obtiendrons un serveur qui pourra s’étendre de manière optimale.
-<p>In <a href="#merging">the section called “View Merging”</a>, we discussed how merges can be accomplished in constant space, no matter the number of rows returned. The memory space and network resources required to merge views, as well as to map from document IDs to partitions, does, however, grow linearly with the number of partitions under a given proxy. For this reason, we’ll want to limit the number of partitions for each proxy. However, we can’t accept an upper limit on cluster size. The solution is to use a tree of proxies, where the root proxy partitions to some number of intermediate proxies, which then proxy to database nodes.
+<p>Dans <a href="#merging">la section <em>Fusion des vues</em></a>, nous avons vu que la fusion se fait à espace constant quel que soit le nombre d’enregistrements retournés. En revanche, l’espace mémoire et les ressources réseau nécessaires à la fusion des vues, tout comme la correspondance d’un identifiant de document à un fragment, croissent linéairement en fonction du nombre de fragments gérés par un mandataire. Cependant, nous ne pouvons souffrir une borne supérieure à la taille de notre grappe. En conséquence, la solution réside dans l’utilisation d’un arbe de serveurs mandataires dans lequel la racine fait suivre à des mandataires secondaires, lesquelles accèdent aux nœuds.
-<p>The factors that come into play when deciding how many partitions each proxy should manage are: the storage available to each individual server node, the projected growth rate of the data, the network and memory resources available to proxies, and the acceptable latency for requests against the cluster.
+<p>Les facteurs à prendre en compte lors de la détermination du nombre de fragments que chaque mandataire doit pouvoir gérer sont : l’espace disque disponible pour chaque nœud, l’estimation de croissance des données, le réseau et les ressources mémoires mises à la disposition des serveurs mandataires et la latence acceptable pour traverser la grappe.
-<p>Assuming a conservative 64 shards per proxy, and 1 TB of data storage per node (including room for compaction, these nodes will need roughly 2 TB of drive space), we can see that with a single proxy in front of CouchDB data nodes, we’ll be able to store at maximum 64 TB of data (on 128 or perhaps 192 server nodes, depending on the level of redundancy required by the system) before we have to increase the number of partitions.
+<p>Ainsi, avec un réglage conservateur de 64 fragments par mandataire et de 1 TB d’espace utile par nœud (avec la compression, ces nœuds auront besoin d’environ 2 TB d’espace disque), nous pouvons voir qu’avec un seul mandataire devant les bases CouchDB, nous pourrons stocker au maximum 64 TB de données (sur 128 ou peut-être 192 nœuds, selon le niveau de redondance nécessaire) avant d’avoir à augmenter le nombre de fragments.
-<p>By replacing database nodes with another proxy, and repartitioning each of the 64 partitions into another 64 partitions, we end up with 4,096 partitions and a tree depth of 2. Just as the initial system can hold 64 partitions on just a few nodes, we can transition to the 2-layer tree without needing thousands of machines. If we assume each proxy must be run on its own node, and that at first database nodes can hold 16 partitions, we’ll see that we need 65 proxies and 256 database machines (not including redundancy factors, which should typically multiply the cluster size by two or three times). To get started with a cluster that can grow smoothly from 64 TB to 4 PB, we can begin with roughly 600 to 1,000 server nodes, adding new ones as data size grows and we move partitions to other machines.
+<p>En substituant des nœuds par un nouveau mandataire, et en subdivisant chacun des 64 fragments en 64 nouveaux fragments, nous arrivons à 4 096 fragments et une profondeur d’arbre de 2. De la même manière que le système initial pouvait faire tenir 64 fragments sur seulement quelques nœuds, nous pouvons passer à un arbre à deux niveaux sans avoir besoin de milliers de machines. Si nous acceptons l’hypothèse que chaque mandataire doit avoir son propre serveur et qu’une base de donnée peut accueillir 16 fragments, nous arrivons à 65 serveurs mandataires et 256 serveurs de bases de données (sans prendre en compte ceux requis pour la redondance qui multiplient ce nombre par deux ou trois). Ainsi, pour commencer avec une grappe qui pourra croître tranquillement de 64 TB à 4 PB, nous pouvons commencer avec environ 600 à 1 000 nœuds, en ajoutant de nouveaux nœuds quand la taille des données augmente et en déplaçant les fragments vers de nouvelles machines.
-<p>We’ve seen that even a cluster with a depth of 2 can hold a vast amount of data. Basic arithmetic shows us that by applying the same process to create a cluster with three layers of proxies, we can manage 262 petabytes on thousands of machines. Conservative estimates for the latency introduced by each layer is about 100 ms, so even without performance tuning we should see overall response times of 300 ms even with a tree depth of 3, and we should be able to manage queries over exabyte datasets in less than a second.
+<p>Nous savons donc qu’une grappe avec une profondeur d’arbre de deux peut accueillir une grande quantité de données. Des opérations mathématiques simples nous montrent qu’en appliquant le même raisonnement à une grappe d’une profondeur de trois, nous pouvons héberger 262 PB sur des milliers de machines. Des estimations conservatrices estiment la latence introduite par chaque niveau à 100 ms, donc même sans ajustements, le temps de réponse serait de 300 ms pour une profondeur d’arbre de 3, et nous serions capables d’exécuter des requêtes sur plus d’un exaoctet de données en moins d’une seconde.
-<p>By using oversharding and iteratively replacing full shards (database nodes that host only one partition) with proxy nodes that point to another set of oversharded partitions, we can grow the cluster to very large sizes while incurring a minimum of latency.
+<p>En recourrant à la technique de fragmentation zélée et en replaçant les fragments pleins (<em>full shard</em> en anglais ; nœuds qui hébergent un unique fragment) par des serveurs mandataires, nous pouvons étendre la grappe jusqu’à une taille collossale tout en subissant une latence minimale.
-<p>Now we need to look at the mechanics of the two processes that allow the cluster to grow: moving a partition from an overcrowded node to an empty node, and splitting a large partition into many subpartitions. Moving partitions is simpler, which is why it makes sense to use it when possible, running the more resource-intensive repartition process only when partitions get large enough that only one or two can fit on each database server.
+<p>Maintenant, nous allons nous pencher sur les mécanismes de deux processus qui permettent à la grappe de croître : déplacer un fragment d’un serveur surchargé à un nœud vide et subdiviser un fragment. Déplacer des fragments est une opération simple, ce qui invite à l’utiliser tant que c’est possible. Ainsi, nous gardons l’opération plus gourmande de subdivision pour les cas où un fragment devient si gros qu’un seul, ou que deux fragments occuppent à eux seuls tout un serveur.
<h4 id="moving">Moving Partitions</h4>
Please sign in to comment.
Something went wrong with that request. Please try again.