¿Usar una dirección IP como clave principal es una buena práctica en scylla db?

Estoy usando scylla db y tengo una tabla que usa la dirección IP como clave principal. El RF para el clúster es 3. Creo que algunos nodos tienen muchas más cargas (ocupan más espacio en disco) que otros, incluso si las ownsestadísticas están cercanas (31% ~ 35%)

Me pregunto ¿porque estoy usando la dirección IP como clave principal y algunas direcciones IP son más populares que otras (como más actualizaciones en esas IP)?

El hecho de que algunas direcciones IP sean más populares (obteniendo más lecturas o escrituras) que otras, generalmente no es un gran problema, y ​​es bastante habitual. Scylla los dividirá aleatoriamente entre los diferentes nodos (y núcleos en cada nodo), y siempre que tenga muchas más particiones activas que los núcleos en su clúster, la carga y el uso del disco deben estar bastante bien equilibrados.

Las cosas pueden volverse diferentes en casos extremos, como cuando cada actualización hace crecer una partición (es decir, agregarle una fila), y solo unas pocas particiones son extremadamente calientes. Por ejemplo, puede imaginar una base de datos utilizada para registrar solicitudes, y además de un millón de clientes normales con 10 solicitudes por día, también tiene 10 "atacantes" que hacen un millón de solicitudes por día. En estos casos extremos, puede encontrarse con algunos de los nodos que transportan significativamente más carga o espacio en disco que otros. Tales casos extremos también pueden causar otros problemas: si bien el soporte de Scylla para particiones enormes ha mejorado recientemente, todavía no es perfecto, y si puede evitar estos casos extremos, es mejor.

Finalmente, si vuelvo a su pregunta original, "¿Es una buena práctica usar la dirección IP como clave principal en scylla db?", La respuesta es "sí, pero":

Es "sí" porque Scylla no tiene ningún problema específico con las direcciones IP como clave: distribuye las diferentes direcciones IP a diferentes nodos al azar (utilizando la función hash "murmur3"), por lo que no hay ningún problema particular con el hecho de que las direcciones IP se agrupan juntos (por ejemplo, varios clientes de la misma subred no solo se envían a los mismos nodos del clúster).

Es "pero" porque el problema no son las direcciones IP como clave per se, sino más bien el contenido de la partición que tiene la intención de almacenar, y cuán sesgada es la frecuencia de actualización, y el tamaño, para las diferentes particiones.

Ah, y una última nota:

Si está utilizando la Estrategia de compactación por niveles (STCS), el uso máximo de espacio en disco en cualquier momento en particular puede ser bastante mayor que la cantidad real de datos que se almacenan. Si su carga de trabajo es alta en sobrescrituras (los datos no se agregan, sino que se reemplazan, eliminan, etc.), antes de que la compactación termine su trabajo, los datos en el disco pueden ser el doble de la cantidad real de datos. Si este es el caso, si se inspecciona el sistema en algún momento al azar, que seobserve que algunos nodos tienen más datos en el disco que otros, dependiendo de su posición aleatoria en el trabajo de compactación cuando realiza esta medición. Algo que puede hacer para verificar si esto es lo que está viendo es invocar una "compactación importante" en todos los nodos, y medir el uso del disco en ese momento, esperando ver un uso de espacio en disco mucho más uniforme en todos los nodos.

Probablemente tenga razón, mejor agregue otro campo para difundir mejor los datos

¿Usar una dirección IP como clave principal es una buena práctica en scylla db?

Respondiendo a su pregunta solo, suponiendo que las direcciones IP se distribuyan de manera uniforme y sus patrones de acceso distribuidos de manera uniforme, está totalmente bien para cualquier base de datos con fragmentación de datos. En muchos casos, cuando sus distribuciones no son muy uniformes, también estará bien. por ejemplo, su patrón de acceso toca algunas IP más que otras.

Dependiendo de la estrategia de fragmentación de la base de datos, hace una diferencia si ingiere valores monotónicamente crecientes (por ejemplo, IP secuenciales) (MongoDB, Spanner, DataStore, etc.). Pero en el caso de ScyllaDB, Scylla mezcla cada clave de Partición con MurMurHash3 de forma predeterminada, por lo que puede suponer que la ingestión de datos se distribuye uniformemente a través del token ring.

De todos modos, si necesita leer / escribir por Clave == IP, no tiene muchas opciones. Sin embargo, puede depender de los detalles de su tarea.

encuentra que algunos nodos tienen muchas más cargas (ocupan más espacio en el disco) que otros, incluso si las estadísticas propias son cercanas (31% ~ 35%)

La carga generalmente mide el rendimiento, que es IOPS de disco o Solicitudes / seg de aplicación, o la utilización en%. Si considera la utilización del espacio en disco, es una historia totalmente diferente.

Si se refería a la utilización de nodos de rendimiento relativo, puede ser, por ejemplo:

• distribución de sus datos
• distribución de su carga (accesos) en el espacio de claves, la relación de lecturas y escrituras propias
• distribución de los tokens de nodos, que pueden dar solo un% de varianza

Si se refería al espacio en disco, además de lo que mencioné, hay muchos otros factores:

• pistas
• instancias no reparadas, programa de reparación
• lápidas, gc, compactaciones

Me pregunto es porque estoy usando la dirección IP como clave principal

No.

y algunas direcciones IP son más populares que otras (como más actualizaciones en esas IP)?

Depende de los factores mencionados anteriormente y de lo que quiere decir con la carga. Si se refería a espacio en disco, sus accesos de lectura no lo afectan. Las escrituras pueden.

Tener una dirección IP como clave principal es una mala práctica por estos motivos.

1. Las direcciones IP pueden cambiar. Si eso sucede, no estoy seguro de cómo puede consultar utilizando la antigua dirección IP.
2. Si ha reservado una dirección IP (estática y no cambia), entonces, si recibe más solicitudes de pocas IP, entonces no está creando nodos distribuidos uniformemente.
3. Agregar otro campo podría mejorar las cosas, sin embargo, no puedo recomendarlo a menos que conozca el patrón de acceso.