Dos amigos lanzan Chirp, una pequeña red social. Unos cientos de curiosos el primer día; un solo servidor de aplicación y una sola base bastan. Tocas enviar y el mensaje sale; abres un perfil con un clic. Una tienda de barrio con una sola caja. Nadie habla de tamaño, todos buscan registros. Me gusta este cuadro porque muestra el mal del tamaño mostrando primero su ausencia.
Luego los registros suben, de cientos a miles. Separemos dos oficios: leer (abrir un perfil, listar mensajes) y escribir (publicar, seguir a alguien). Cuando ambos se aplastan sobre un solo equipo, la fila se alarga. Primer reflejo: comprar un equipo más grande, con procesador más fuerte y memoria más amplia. Ese camino choca con un muro. Un día no hay equipo mayor, o la factura duele. La partición nace justo contra ese muro.
Particionar es cortar las tablas y poner cada parte en su servidor. La tabla de usuarios se corta en cuatro; delante, una capa de encaminado sabe qué pregunta va dónde. Una tienda cambiada por cuatro sucursales más una recepción que manda a cada uno a la buena. Fácil de decir, fino de lograr.
Primer punto fino: la clave de partición, la columna que dispersa las filas. Chirp elige el identificador. Cambiarla luego, ¿qué trae? Imaginemos partir por país. Cada fila en cada parte se relee una por una, cada uno busca su país y se muda a la parte buena. Una mudanza gigante. De ahí una elección cuidada desde el inicio. La documentación de MongoDB da el mismo aviso: variedad de valores, frecuencia, crecimiento continuo.
Una buena clave tiene sus costumbres. Una: muchos valores distintos. Partir por país da unos doscientos valores para sesenta y cuatro partes; las partes de países poblados sudan mientras las calmas duermen. Los identificadores ofrecen millones de valores para cuantas partes se quiera. Dos: los nuevos llegan a todas. Partir por año de registro hincha la parte del año mientras las viejas se vacían. Identificadores en serie giran cero, uno, dos, tres y se equilibran solos.
Primer método: el hash. Se pasa el identificador por una función hash, se divide por el número de partes, se guarda el resto. Leo cae en la parte cero. Belleza: bastan identificador más número, cada servidor calcula solo sin charlar. Como un sorteo para cestos de ropa, donde todos saben la regla de memoria. Los equipos con pocas preguntas de rango adoran esta vía.
Segundo método: los rangos. Cada parte posee un tramo de valores. Una aplicación bancaria guarda marzo junto en una parte, abril en la siguiente. Las preguntas de rango vuelan con pocas partes visitadas. Precio: las filas frescas llevan todas la fecha de hoy, así cada escritura llueve sobre la parte más joven. La guía de MongoDB plantea el trato con simpleza: los rangos sirven a preguntas de rango, el hash dispersa escrituras.
Tercer método: el directorio. Una tabla de consulta anota qué cliente vive en qué parte. Una fila cambia y un gran cliente logra su parte privada; los pequeños comparten. Flexibilidad máxima. Precio: cada pedido consulta primero la tabla. Tabla lenta, todo lento; tabla muerta, todo perdido. Como la libreta del portero: útil hasta el día en que desaparece. Los equipos con clientes desiguales toman esta vía.
Cuarto método: la geografía. Las filas descansan cerca de sus dueños, los europeos en servidores de Europa. Dos motivos. Uno: la velocidad, pues la respuesta salta el océano. Dos: las normas, pues ciertos datos deben quedarse en casa. Como comprar cerca de casa en vez de cruzar la ciudad. Precio: una región animada puede asar su parte. Los equipos con preguntas regionales y prisa por la demora toman esta vía.
Luego el punto delicado: las claves calientes. El mensaje de Lena explota; millones de me gusta golpean una sola parte hasta ahogarla. Remedio: la sal. Números del uno al diez junto al identificador 500, los apoyos se dispersan sobre diez claves. Un solo carácter cambiado da un hash del todo distinto, así las diez claves caen en partes variadas. Perfiles y mensajes siguen en su sitio; solo la carga de apoyos se reparte. Precio: el total pide diez lecturas más una suma. Regla clara: el modesto Chris sigue sin sal, solo las claves que arden se salan. El texto de CosmicLearn cifra el dolor, una sola partición se atasca pasado el millar de escrituras por segundo, y la nota de Amazon muestra particiones calientes que se dividen solas.
¿Cómo decide la capa de encaminado? Cada lectura visita primero la caché; un acierto nunca toca las partes. Ante un fallo, o cuando el pedido escribe, la bola queda en la capa. La capa hace dos preguntas: clave con sal o no, qué parte sirve. ¿Apoyo con sal? Se elige una de diez claves al azar y allí se escribe. ¿Total pedido? Se leen diez partes y se suman. Recepción y central: la mesa responde lo que sabe, el resto sale hacia la sala buena.
Añadir partes duele con restos simples. Pasar de cuatro a cinco cambia casi todos los restos, casi todos se mudan. Chris y Leo parten a casas nuevas. El camino tomado para crecer se llena de camiones. Alivio: el orden en círculo del hash estable. Todos los valores hash forman un círculo, las partes se posan en él, y la regla camina en sentido horario desde cada identificador hasta la primera parte. Una nueva solo toma la carga del vecino; Chris y Leo se quedan en casa. El costo baja de todos a una sola parte. La idea sube a un escrito de Karger de 1997, de los días de Akamai.
Los círculos tiemblan también: puestos al azar dan arcos anchos a unas, estrechos a otras, y los fallos vuelcan arcos enteros sobre un vecino. Remedio: puestos virtuales, poner cada parte diez veces sobre el círculo. Cada una posee arcos pequeños regados cuyos totales se juntan, y los fallos se abren sobre todos los que siguen. Nota de campo: Cassandra vivió años con 256 puestos, luego bajó a 16 para aligerar el cuidado. Pocos puestos, equilibrio flaco; demasiados puestos, cuidado pesado; el punto dulce se busca. Los utensilios suavizan el resto: la documentación de Vitess describe una repartición en línea, partes nuevas alzadas, filas copiadas mientras las escrituras corren, lecturas movidas y luego escrituras, mientras la documentación de CitusData, venida del mundo Postgres, ofrece un reequilibrio vivo parecido. Lección guardada: partir es cuidado de casa, no cirugía. Cuando un equipo ya no abraza las filas, cuando el número de servidores se moverá, y cuando el costo de mudanzas se acepta, el círculo merece su sitio; si no, equipo grande, buenos índices y caché compran una paz más barata.
Momentos clave
Comentario de la IA
"Este tema toca un día la puerta de cada desarrollador. En su lugar, nunca dejaría la llamada de partir al último día, y tomaría la clave en serio desde el primero."
Evaluación de la IA
Lo fuerte de este curso está en una sola historia que carga ideas vastas. Con Chirp, la clave de partición, la sal y el círculo dejan de flotar y se vuelven las cuitas de una aplicación. Si entrara al equipo, mi pregunta del primer día sería: ¿por cuánto se multiplicarán nuestras filas en dos años, y qué columna cargará ese peso? Sin respuesta, el pánico acecha el día de partir.
El otro bando lleva razón: partir no cura nada solo. Más partes suben el costo total de lecturas, las claves con sal fuerzan sumas sobre diez partes, y un montaje con directorio deja una tabla única en punto flaco. En tamaños chicos y medios, equipo grande, buenos índices y caché suelen bastar. Mi regla: nunca cortar antes de que un equipo se llene de verdad, pero con la clave lista para ese día.
Fuentes
6 enlaces; ninguna otra noticia publicada los cita. Stories sharing a link do not confirm each other; a source's origin is not inferred from how often it is cited.
partición · bases de datos · escala