Sharding por ObjectID, ¿es el camino correcto?

Question

Soy como muchos otros que están pensando acerca del enfoque correcto para fragmentar mis colecciones en Mongo. La pregunta principal es: ¿cómo funciona el auto sharding?

El documento oficial dice: "MongoDB escala horizontalmente a través de una arquitectura de auto-sharding (partición)" y "Para particionar una colección, especificamos un patrón de clave de fragmento". con la nota "Es importante elegir la clave de fragmento correcta para una colección" :).
http://www.mongodb.org/display/DOCS/Sharding+Introduction#ShardingIntroduction-ShardKeys
http://www.mongodb.org/display/DOCS/Choosing+a+Shard+Key

Ahora la pregunta es - "es esta tecla derecha" (por sharding de objeto)?

db.runCommand({ shardcollection : "test", key : { _id : 1 }}) 

¿Qué ocurre internamente en Mongo? ¿Cómo Mongo dividirá los datos en fragmentos en este caso? Asumiendo que inicialmente tengo 10 millones de registros con 2 servidores shard, ¿qué sucede en el lado de Mongo cuando me gustaría agregar 2 servidores shard más cuando la colección alcanza los 20 millones de registros? No pude encontrar ese nivel de detalles en ninguna parte de las fuentes relacionadas con Mongo.

Teniendo en cuenta la naturaleza aleatoria de _id autogenerado y su estructura,

... http://www.mongodb.org/display/DOCS/Object+IDs ...

me gustaría fragmentar por el byte menos significativo (orden de RTL) con trozos dividido por el valor de 2-3 bytes: esto proporcionaría una manera fácil de fragmentar por 2^N de servidores shard - 2, 4, 8, .., 256 servidores shard con una carga más o menos pareja en cada fragmento y con la configuración mínima requerida. Por lo que tengo entendido, Mongo solo admite sharding/chunking por rangos explícitamente definidos y mi idea no funcionará. Es verdad?

Answer 1

Una nueva característica interesante en la versión 2.4 es que el índice de Hashed es compatible, y se puede utilizar como Shard Keys. Así que la respuesta a su pregunta principal "Sharding por ObjectID, ¿es la manera correcta?" puede ser sí ahora!

Más referencias están en los documentos oficiales:

Hash Shard Claves

http://docs.mongodb.org/manual/core/sharded-cluster-internals/#hashed-shard-keys

Índice de hash

http://docs.mongodb.org/manual/core/indexes/#hashed-index

Answer 2

En general, no es una buena idea utilizar el identificador de objeto predeterminado como la clave de fragmento, ya que tiene una marca de tiempo incrustada y aumenta monótonamente en el tiempo. Esto puede funcionar bien si realiza muchas actualizaciones de manera que toque documentos viejos y nuevos de manera uniforme. Sin embargo, esta es realmente una mala noticia si su aplicación tiene inserciones pesadas ya que la mayoría de sus escrituras irán a un único fragmento. Esto se debe a que las escrituras irán al fragmento que posee el fragmento [nearCurrentTimestamp -> infinito].

Cada mongos monitorea el tráfico de escritura a fragmentos y usa una heurística muy simple para determinar si un trozo se ha vuelto demasiado grande y necesita dividirse (el tamaño del umbral se puede configurar a través de trozo).

Cuando agrega un nuevo fragmento al clúster, el equilibrador (http://www.mongodb.org/display/DOCS/Sharding+Administration#ShardingAdministration-Balancing) verá un desequilibrio en el fragmento y comenzará a migrar trozos a los nuevos fragmentos.

Mongo admite fragmentación basada en rango, sin embargo, eso no significa que los rangos sean fijos ya que los trozos se pueden dividir en rangos más pequeños y moverse alrededor del clúster a lo largo del tiempo.