En entornos "Big Tech" (sabes, el tipo con toneladas de usuarios, conjuntos de datos masivos y requisitos que evolucionan rápidamente), dependiendo de bases de datos Las restricciones para evitar la duplicación de datos, a menos que sea para algo como la reconciliación financiera donde cada centavo debe ser exacto, honestamente, puede no ser tan eficaz como usted piensa. Además, el coste de mantenerlos puede ser sorprendentemente alto. Un mejor enfoque a menudo es manejar la mayor parte de la lógica de deduplicación en la capa de la aplicación. Si puede evitar el uso de un índice único de la base de datos, considere hacerlo, o al menos pensarlo muy cuidadosamente antes de implementar uno. UNIQUE INDEX ¿Por qué empecé a repensar los índices únicos? porque me quemaron. Los índices únicos de la base de datos suenan bastante confiables, ¿verdad? La última línea de defensa contra la duplicación de datos. Yo solía pensar eso también. Cuando un campo en una tabla necesitaba ser único, accidentalmente golpearía un índice único en él. Hasta que la realidad me dio una dura llamada de despertar. Hace mucho tiempo, cuando mi cabello era mucho más lleno, tuve que añadir un índice único compuesto a una tabla con decenas de millones de líneas (por ejemplo, para campos como y que necesitan ser únicos juntos).Suena sencillo, ¿no es así?Bueno, todo el proceso de cambio se Durante este tiempo, el retraso en la replicación de maestro-esclavo estaba en un rollercoaster, y estábamos constantemente preocupados por los posibles hiccups de servicio.Después de eso, no pude dejar de preguntarme: ¿esta "unicidad" a nivel de base de datos vale la pena todo ese esfuerzo y riesgo? tenant_id is_deleted Días Entonces hubo otra situación incómoda. de negocios sabios, todos sabemos y son efectivamente el mismo correo electrónico. Tu código de aplicación seguramente lo normalizaría (por ejemplo, a la baja) antes de comprobar duplicados durante el registro. Pero el índice único de la base de datos (que a menudo es sensible al caso por defecto) no lo ve de esa manera. A veces, debido a los datos históricos o a las sincronizaciones de datos de canales laterales que no se normalizaron adecuadamente, terminaría con ambas versiones de caso del correo electrónico "el mismo" en la base de datos. En tales casos, el índice único o "vuelve un ojo ciego" a esta duplicación a nivel empresarial o, cuando intenta corregir los datos, sus reglas rígidas realmente se encuentran en tu camino. user@example.com USER@EXAMPLE.COM Y ni siquiera me empiece a cambiar los requisitos de negocio. Por ejemplo, tal vez "unicidad de correo electrónico" fuera suficiente antes, pero ahora el requisito cambia a "identificador de inquilino + unicidad de correo electrónico". Pedro y una nueva d. ¿Cómo coordinas estos dos conjuntos de operaciones? ¿Cuál va primero? ¿Qué pasa si algo va mal entre sí? La realización de tales operaciones en grandes mesas se siente como deshacer una bomba cada vez —totalmente nervioso. DROP CREATE Estas experiencias me obligaron a pensar: en entornos con grandes volúmenes de datos, alta concurrencia y cambios rápidos de requisitos, ¿el enfoque tradicional de los índices únicos sigue siendo el correcto? Este artículo trata de compartir mis reflexiones al respecto. 2. ¿Por qué le confiamos tanto? Índice único Índice único Antes de sumergirme en las quejas, vamos a ser justos y reconocer por qué los índices únicos son tan populares. La garantía final para la integridad de los datos: La barrera final para evitar la duplicación de los datos. Fácil de implementar: Algunas líneas de SQL al crear una tabla o agregar un DDL más tarde, y está terminado. Esquema como documentación: Está marcado en el esquema; este campo no puede tener duplicados. Potencial aumento del rendimiento de la consulta: Dado que es un índice, las consultas sobre esta clave pueden ser más rápidas. Estos beneficios son realmente bastante atractivos para proyectos pequeños, o cuando los volúmenes de datos son gestionables y la lógica empresarial no es demasiado compleja. 3. Bajo la lente "Big Tech": ¿Todavía son válidos esos beneficios? Índice único Índice único Examinemos cada uno de los "beneficios" mencionados anteriormente y veremos si todavía se mantienen en un entorno tecnológico a gran escala y rápido. "The ultimate safeguard"? Is this safeguard reliable? What exactly is it safeguarding against? It doesn't fully recognize business-level "duplicates"! Except the email case sensitivity issue I mentioned earlier (which could be solved by using but introduce more complexity in the DB layer), or phone numbers with or without , or usernames with or without special characters stripped... these nuances, which business logic considers "the same," are beyond the grasp of a database's simplistic "byte-for-byte identical" unique index. It can't prevent "logical duplicates" at the business layer. collation +44 The application layer has to do the heavy lifting anyway. Since all these complex "sameness" checks must be handled in the application code (you can't just throw raw database errors at users, can you?), the application layer is the true workhorse ensuring "business data uniqueness." The database's unique index is, at best, an "auxiliary police officer" whose standards might not even align with the business rules. In distributed systems, it's merely a "local bodyguard." Once you shard your tables in a distributed scenario, an in-table unique index can't ensure global uniqueness. Global uniqueness then relies on ID generation services or application-level global validation. At this point, the "safeguard" provided by the local database index becomes even less significant. This "ultimate safeguard" might miss the mark, has limited coverage, and relying solely on it is a bit precarious. "Easy to implement"? One-time setup, week-long headache. Adding a unique index to a brand new table is indeed just one SQL statement. But more often, you're changing the rules for an old table that's been running for ages and has accumulated mountains of data. Trying to alter a unique index on a table with tens of millions of rows (e.g., changing from a single-field unique to a composite unique) could mean several minutes of table locking! Online DDL tools might save you from service downtime, but the entire process can still be lengthy, resource-intensive, and risky. Agile? Not so fast! In scenarios with rapid iteration, multi-region synchronization, and compliance requirements, a single unique index change at the database level can hold you up for days. So much for agility. So, that initial "simplicity" is like bait compared to the "hell" of modifying it later. "Schema as documentation"? The documentation might not match reality! Yes, a unique index in the table structure acts as a form of "technical documentation." But "documentation" can be misleading. If the "uniqueness" defined by this index doesn't align with the actual, more complex business rules (like the case-insensitivity example), then this "documentation" is not only useless but can also mislead future developers. If changing this "documentation" (i.e., modifying the unique index) involves an epic struggle, why not write down the business rules properly in actual design documents, wikis, or code comments? Those are far easier to update. "A potential query performance boost"? Is the tail wagging the dog? This is a common misconception, or rather, an overemphasized "added value." If you simply want to speed up queries on a specific field or set of fields, you can absolutely create a regular, non-unique index for them! A non-unique index will boost query speeds just fine, and it comes without the write overhead, DDL pains, and rigid business logic constraints of a unique index. Master-slave index inconsistency can instantly "paralyze" replication: I've seen it happen multiple times: the unique index configuration on the primary database is updated (e.g., a field is added, or a constraint is changed), but the index on the replica isn't modified in sync. Then, as soon as data changes on the primary (e.g., a row is inserted that would be considered a duplicate on the replica, or the primary can write it but the replica can't due to the incorrect/outdated index), the binlog is applied to the replica, and bam! . Replication just dies. When this happens, you get data lag, read-write splitting is affected, and it can even impact failover capabilities. What a nightmare, right? Slave_SQL_Running: No Deja que la capa de aplicación haga el trabajo - ¡es lo que es bueno en! Teniendo en cuenta todos estos problemas con los índices únicos de la base de datos, la responsabilidad de asegurar la unicidad de los datos debe caer principalmente en nuestra capa de aplicaciones. Los beneficios de manejar la unicidad en la capa de aplicación son numerosos: Flexible y preciso: Cualquier cosa que la empresa define como un duplicado, podemos codificar la lógica de acuerdo: la sensibilidad del caso, la formatación, las condiciones complejas, lo llaman. Mejor experiencia de usuario: Si un usuario comete un error, podemos proporcionar un feedback claro y útil, como "Este número de teléfono ya está registrado. Rejeción temprana eficiente: la intercepción se duplica en la capa de la interfaz del servicio o incluso en la capa de la puerta de entrada, antes de que los datos incluso lleguen a la base de datos, ahorrando una vuelta sin sentido. Interface Idempotency: Esta es una poderosa arma contra las operaciones duplicadas.Si un usuario hace doble clic en el botón de envío, o un problema de red causa un retry, la idempotencia adecuada en la capa de la aplicación asegura que los datos no se dupliquen. Conclusión Sólo considere el uso de un índice único cuando sus beneficios (normalmente como un backstop de datos absoluto de última generación en casos extremos) superan claramente y significativamente las miríadas dificultades que causa en entornos complejos con grandes volúmenes de datos y rápida iteración (obstracción de agilidad, dolor operativo). Priorice los mecanismos de unicidad de la capa de aplicación robusta (validación frontal, procesamiento asíncrono, idempotencia, generación de ID global, etc.).
