Al elegir la clave principal, generalmente también elige la clave agrupada. Los dos a menudo se confunden, pero hay que entender la diferencia.
Claves primarias son negocios lógicos elementos. Su aplicación utiliza la clave principal para identificar una entidad, y la discusión sobre las claves principales es en gran medida si se usan claves naturales o claves sustitutas. Los enlaces dan muchos más detalles, pero la idea básica es que las claves naturales se derivan de una propiedad de entidad existente como ssn o phone number , mientras que las claves sustitutas no tienen ningún significado con respecto a la entidad comercial, como id o rowid y suelen ser del tipo IDENTITY o algún tipo de uuid. Mi opinión personal es que las claves sustitutas son superiores a las claves naturales, y la elección debe ser siempre valores de identidad para aplicaciones solo locales, guías para cualquier tipo de datos distribuidos. Una clave principal nunca cambia durante la vida útil de la entidad.
Claves agrupadas son la clave que define el almacenamiento físico de filas en la tabla. La mayoría de las veces se superponen con la clave principal (el identificador de la entidad lógica), pero en realidad eso no se aplica ni se requiere. Cuando los dos son diferentes, significa que hay un índice único no agrupado en la tabla que implementa la clave principal. Los valores clave agrupados pueden cambiar durante la vida útil de la fila, lo que hace que la fila se mueva físicamente en la tabla a una nueva ubicación. Si tiene que separar la clave principal de la clave agrupada (y a veces lo hace), elegir una buena clave agrupada es significativamente más difícil que elegir una clave principal. Hay dos factores principales que impulsan el diseño de claves agrupadas:
- El patrón de acceso a datos predominante .
- Las consideraciones de almacenamiento .
Patrón de acceso a datos . Por esto entiendo la forma en que se consulta y actualiza la tabla. Recuerde que las claves agrupadas determinan el orden real de las filas en la tabla. Para ciertos patrones de acceso, algunos diseños marcan la diferencia en el mundo con respecto a la velocidad de consulta o para actualizar la concurrencia:
-
datos actuales frente a datos de archivo. En muchas aplicaciones se accede con frecuencia a los datos pertenecientes al mes en curso, mientras que rara vez se accede a los del pasado. En tales casos, el diseño de la tabla usa la partición de la tabla por fecha de transacción, muchas veces usando un algoritmo de ventana deslizante. La partición del mes actual se mantiene en un grupo de archivos ubicado en un disco rápido caliente, los datos antiguos archivados se mueven a grupos de archivos alojados en un almacenamiento más económico pero más lento. Obviamente, en este caso, la clave agrupada (fecha) no es la clave principal (id de transacción). La separación de los dos está impulsada por los requisitos de escala, ya que el optimizador de consultas podrá detectar que las consultas solo están interesadas en la partición actual y ni siquiera mirar las históricas.
-
Procesamiento de estilo de cola FIFO. En este caso, la tabla tiene dos puntos calientes:la cola donde se producen las inserciones (poner en cola) y la cabeza donde se producen las eliminaciones (eliminar la cola). La clave agrupada debe tener esto en cuenta y organizar la tabla para separar físicamente la ubicación de la cola y la cabeza en el disco, para permitir la concurrencia entre poner y quitar cola, por ejemplo. utilizando una clave de orden de puesta en cola. En puro pone en cola esta clave agrupada es la única clave, ya que no hay una clave principal en la tabla (contiene mensajes , no entidades ). Pero la mayoría de las veces la cola no es pura, también actúa como almacenamiento para las entidades y la línea entre la cola y la mesa está borroso. En este caso, también hay una clave principal, que no puede ser la clave agrupada:las entidades se pueden volver a poner en cola, cambiando así el valor de la clave agrupada del orden de puesta en cola, pero no pueden cambiar el valor de la clave principal. No ver la separación es la razón principal por la que las colas respaldadas por la tabla de usuario son tan difíciles de corregir y están plagadas de interbloqueos:porque el encolado y el desencolado ocurren intercalados a través de la tabla, en lugar de localizarse en la cola y la cabeza de la cola.
-
Procesamiento correlacionado. Cuando la aplicación está bien diseñada, dividirá el procesamiento de elementos correlacionados entre sus subprocesos de trabajo. Por ejemplo, un procesador está diseñado para tener 8 subprocesos de trabajo (por ejemplo, para que coincida con las 8 CPU en el servidor), por lo que los procesadores dividen los datos entre ellos, por ejemplo. el trabajador 1 recoge solo las cuentas denominadas A a E, el trabajador 2 F a J, etc. En tales casos, la tabla debe agruparse por el nombre de la cuenta (o por una clave compuesta que tenga la posición más a la izquierda, la primera letra del nombre de la cuenta), para que los trabajadores localicen sus consultas y actualizaciones en la tabla. Dicha mesa tendría 8 puntos calientes distintos, alrededor del área en la que cada trabajador se concentra en ese momento, pero lo importante es que no se superpongan (sin bloqueo). Este tipo de diseño prevalece en los diseños OLTP de alto rendimiento y en las cargas comparativas de TPCC, donde este tipo de partición también se refleja en la ubicación de la memoria de las páginas cargadas en el grupo de búfer (localidad NUMA), pero estoy divagando.
Consideraciones de almacenamiento . La clave agrupada width tiene enormes repercusiones en el almacenamiento de la mesa. Por un lado, la clave ocupa espacio en todas las páginas que no son hojas del árbol b, por lo que una clave grande ocupará más espacio. En segundo lugar, y a menudo más importante, es que la clave agrupada se usa como clave de búsqueda por cada clave no agrupada, por lo que cada la clave no agrupada tendrá que almacenar el ancho completo de la clave agrupada para cada fila. Esto es lo que hace que las claves agrupadas grandes como varchar(256) y guids sean malas opciones para las claves de índice agrupadas.
También la elección de la clave tiene un impacto en la fragmentación del índice agrupado, lo que a veces afecta drásticamente el rendimiento.
Estas dos fuerzas a veces pueden ser antagónicas, el patrón de acceso a los datos requiere una cierta clave agrupada grande que causará problemas de almacenamiento. En tales casos, por supuesto, se necesita un equilibrio, pero no existe una fórmula mágica. Mide y prueba para llegar al punto óptimo.
Entonces, ¿qué hacemos con todo esto? Siempre comience considerando la clave agrupada que también es la clave principal de la forma entity_id IDENTITY(1,1) NOT NULL . Separe los dos y organice la tabla en consecuencia (por ejemplo, partición por fecha) cuando corresponda.
