[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"article-deep-evm-26-sharding-vs-particionamiento-tablas-masivas":3},{"article":4,"author":42},{"id":5,"category_id":6,"title":7,"slug":8,"excerpt":9,"content_md":10,"content_html":11,"locale":12,"author_id":13,"published":14,"published_at":15,"meta_title":16,"meta_description":17,"focus_keyword":18,"og_image":19,"canonical_url":19,"robots_meta":20,"created_at":15,"updated_at":15,"tags":21,"category_name":22,"related_articles":23},"d8000000-0000-0000-0000-000000000126","a0000000-0000-0000-0000-000000000085","Deep EVM #26: Sharding vs Particionamiento — Arquitectura para Tablas Masivas","deep-evm-26-sharding-vs-particionamiento-tablas-masivas","Comprende las diferencias entre sharding y particionamiento: cuándo usar cada uno, estrategias de clave de distribución, consistencia entre shards, y patrones para escalar PostgreSQL horizontalmente.","## Particionamiento vs Sharding\n\nAunque a menudo se confunden, particionamiento y sharding son conceptos diferentes:\n\n- **Particionamiento**: dividir una tabla en múltiples tablas físicas dentro del mismo servidor de base de datos\n- **Sharding**: distribuir datos entre múltiples servidores de base de datos\n\nEl particionamiento es más simple pero tiene un techo: un solo servidor. El sharding escala horizontalmente pero introduce complejidad distribuida.\n\n## Cuándo escalar verticalmente vs horizontalmente\n\n| Escenario | Solución |\n|-----------|----------|\n| Tabla de 50M filas, lecturas lentas | Particionamiento |\n| 500M filas, un solo servidor al límite | Sharding |\n| Escrituras saturan I\u002FO del disco | Sharding |\n| Diferentes regiones necesitan baja latencia | Sharding geográfico |\n| Datos temporales con retención | Particionamiento por rango + DROP |\n\n## Estrategias de clave de sharding\n\nLa clave de sharding determina en qué servidor se almacena cada fila:\n\n### Hash-based sharding\n```\nshard = hash(key) % num_shards\n```\nDistribuye uniformemente pero dificulta range queries.\n\n### Range-based sharding\n```\nshard_0: block 0-999999\nshard_1: block 1000000-1999999\n```\nPerfecto para datos temporales, pero puede crear hotspots.\n\n### Directory-based sharding\nUn servicio centralizado mapea claves a shards. Flexible pero añade latencia.\n\n## Implementación con Citus\n\nCitus es la extensión de PostgreSQL más popular para sharding:\n\n```sql\n-- En el nodo coordinador\nSELECT create_distributed_table('transactions', 'address');\n\n-- Las queries se enrutan automáticamente\nSELECT * FROM transactions WHERE address = '0xABC...';\n-- Se ejecuta solo en el shard correcto\n```\n\n## Consistencia entre shards\n\nEl mayor desafío del sharding es mantener la consistencia:\n\n- **Transacciones cross-shard**: requieren two-phase commit (2PC)\n- **Joins entre shards**: se ejecutan en el coordinador, potencialmente lento\n- **Agregaciones globales**: requieren scatter-gather a todos los shards\n\n## Patrón de migración gradual\n\n1. Comenzar con particionamiento local\n2. Cuando un servidor no es suficiente, migrar a Citus\n3. Añadir nodos worker incrementalmente\n4. Re-balancear datos automáticamente\n\n## Conclusión\n\nParticionamiento y sharding son herramientas complementarias. Comienza con particionamiento local, que es simple y efectivo. Escala a sharding solo cuando los límites de un solo servidor se alcanzan. Citus facilita la transición manteniendo la compatibilidad con PostgreSQL estándar.","\u003Ch2 id=\"particionamiento-vs-sharding\">Particionamiento vs Sharding\u003C\u002Fh2>\n\u003Cp>Aunque a menudo se confunden, particionamiento y sharding son conceptos diferentes:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Particionamiento\u003C\u002Fstrong>: dividir una tabla en múltiples tablas físicas dentro del mismo servidor de base de datos\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Sharding\u003C\u002Fstrong>: distribuir datos entre múltiples servidores de base de datos\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Cp>El particionamiento es más simple pero tiene un techo: un solo servidor. El sharding escala horizontalmente pero introduce complejidad distribuida.\u003C\u002Fp>\n\u003Ch2 id=\"cu-ndo-escalar-verticalmente-vs-horizontalmente\">Cuándo escalar verticalmente vs horizontalmente\u003C\u002Fh2>\n\u003Ctable>\u003Cthead>\u003Ctr>\u003Cth>Escenario\u003C\u002Fth>\u003Cth>Solución\u003C\u002Fth>\u003C\u002Ftr>\u003C\u002Fthead>\u003Ctbody>\n\u003Ctr>\u003Ctd>Tabla de 50M filas, lecturas lentas\u003C\u002Ftd>\u003Ctd>Particionamiento\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>500M filas, un solo servidor al límite\u003C\u002Ftd>\u003Ctd>Sharding\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Escrituras saturan I\u002FO del disco\u003C\u002Ftd>\u003Ctd>Sharding\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Diferentes regiones necesitan baja latencia\u003C\u002Ftd>\u003Ctd>Sharding geográfico\u003C\u002Ftd>\u003C\u002Ftr>\n\u003Ctr>\u003Ctd>Datos temporales con retención\u003C\u002Ftd>\u003Ctd>Particionamiento por rango + DROP\u003C\u002Ftd>\u003C\u002Ftr>\n\u003C\u002Ftbody>\u003C\u002Ftable>\n\u003Ch2 id=\"estrategias-de-clave-de-sharding\">Estrategias de clave de sharding\u003C\u002Fh2>\n\u003Cp>La clave de sharding determina en qué servidor se almacena cada fila:\u003C\u002Fp>\n\u003Ch3>Hash-based sharding\u003C\u002Fh3>\n\u003Cpre>\u003Ccode>shard = hash(key) % num_shards\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Distribuye uniformemente pero dificulta range queries.\u003C\u002Fp>\n\u003Ch3>Range-based sharding\u003C\u002Fh3>\n\u003Cpre>\u003Ccode>shard_0: block 0-999999\nshard_1: block 1000000-1999999\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Cp>Perfecto para datos temporales, pero puede crear hotspots.\u003C\u002Fp>\n\u003Ch3>Directory-based sharding\u003C\u002Fh3>\n\u003Cp>Un servicio centralizado mapea claves a shards. Flexible pero añade latencia.\u003C\u002Fp>\n\u003Ch2 id=\"implementaci-n-con-citus\">Implementación con Citus\u003C\u002Fh2>\n\u003Cp>Citus es la extensión de PostgreSQL más popular para sharding:\u003C\u002Fp>\n\u003Cpre>\u003Ccode class=\"language-sql\">-- En el nodo coordinador\nSELECT create_distributed_table('transactions', 'address');\n\n-- Las queries se enrutan automáticamente\nSELECT * FROM transactions WHERE address = '0xABC...';\n-- Se ejecuta solo en el shard correcto\n\u003C\u002Fcode>\u003C\u002Fpre>\n\u003Ch2 id=\"consistencia-entre-shards\">Consistencia entre shards\u003C\u002Fh2>\n\u003Cp>El mayor desafío del sharding es mantener la consistencia:\u003C\u002Fp>\n\u003Cul>\n\u003Cli>\u003Cstrong>Transacciones cross-shard\u003C\u002Fstrong>: requieren two-phase commit (2PC)\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Joins entre shards\u003C\u002Fstrong>: se ejecutan en el coordinador, potencialmente lento\u003C\u002Fli>\n\u003Cli>\u003Cstrong>Agregaciones globales\u003C\u002Fstrong>: requieren scatter-gather a todos los shards\u003C\u002Fli>\n\u003C\u002Ful>\n\u003Ch2 id=\"patr-n-de-migraci-n-gradual\">Patrón de migración gradual\u003C\u002Fh2>\n\u003Col>\n\u003Cli>Comenzar con particionamiento local\u003C\u002Fli>\n\u003Cli>Cuando un servidor no es suficiente, migrar a Citus\u003C\u002Fli>\n\u003Cli>Añadir nodos worker incrementalmente\u003C\u002Fli>\n\u003Cli>Re-balancear datos automáticamente\u003C\u002Fli>\n\u003C\u002Fol>\n\u003Ch2 id=\"conclusi-n\">Conclusión\u003C\u002Fh2>\n\u003Cp>Particionamiento y sharding son herramientas complementarias. Comienza con particionamiento local, que es simple y efectivo. Escala a sharding solo cuando los límites de un solo servidor se alcanzan. Citus facilita la transición manteniendo la compatibilidad con PostgreSQL estándar.\u003C\u002Fp>\n","es","b0000000-0000-0000-0000-000000000001",true,"2026-03-28T10:44:31.653366Z","Sharding vs Particionamiento — Arquitectura para Tablas Masivas","Sharding vs particionamiento: cuándo usar cada uno, claves de distribución, consistencia entre shards y escalado horizontal con Citus.","sharding particionamiento PostgreSQL",null,"index, follow",[],"DevOps",[24,30,36],{"id":25,"title":26,"slug":27,"excerpt":28,"locale":12,"category_name":22,"published_at":29},"d8000000-0000-0000-0000-000000000128","Deep EVM #28: Pipeline de Datos de Alto Rendimiento — Inserciones Batch, COPY y Resolución de Conflictos","deep-evm-28-pipeline-datos-alto-rendimiento-batch","Construye pipelines de datos de alto rendimiento con PostgreSQL usando protocolo COPY, patrones de upsert masivo, ajuste de WAL, connection pooling con PgBouncer y monitoreo.","2026-03-28T10:44:31.664358Z",{"id":31,"title":32,"slug":33,"excerpt":34,"locale":12,"category_name":22,"published_at":35},"d8000000-0000-0000-0000-000000000127","Deep EVM #27: Rendimiento de PostgreSQL a Escala — Índices, VACUUM y Optimización de Consultas","deep-evm-27-rendimiento-postgresql-indices-vacuum","Optimiza PostgreSQL para alto rendimiento: tipos de índices y cuándo usarlos, VACUUM y autovacuum, EXPLAIN ANALYZE, y técnicas de optimización de consultas para tablas de millones de filas.","2026-03-28T10:44:31.659082Z",{"id":37,"title":38,"slug":39,"excerpt":40,"locale":12,"category_name":22,"published_at":41},"d8000000-0000-0000-0000-000000000125","Deep EVM #25: Particionamiento de Tablas en PostgreSQL — Cuando Tu Tabla Supera 10M+ Filas","deep-evm-25-particionamiento-tablas-postgresql","Guía práctica de particionamiento en PostgreSQL para tablas grandes. Cubre particionamiento por rango, lista y hash con ejemplos reales, estrategias de migración y planificación de consultas.","2026-03-28T10:44:31.648416Z",{"id":13,"name":43,"slug":44,"bio":45,"photo_url":19,"linkedin":19,"role":46,"created_at":47,"updated_at":47},"Open Soft Team","open-soft-team","The engineering team at Open Soft, building premium software solutions from Bali, Indonesia.","Engineering Team","2026-03-28T08:31:22.226811Z"]