Cómo manejar clave externa, mientras que la partición

Question

Estoy trabajando en la gestión de flotas. Estoy teniendo gran cantidad de escrituras en una mesa con la ubicación siguientes columnas

1. fecha
2. Tiempo
3. vehículo no.
4. los
5. latitud
6. velocidad
7. ID de usuario (que es clave externa ...)

Aquí esta tabla va a tener operación de escritura cada 3 s. Por lo tanto habrá millones registrados en el mismo. Así que para recuperar los datos más rápido planeo Partición. Ahora mi pregunta: -

1. Cómo manejar clave externa? He oído que la partición no admite la clave externa
2. ¿Qué columna se debe utilizar para la partición.
3. ¿Es necesario contar con clave única como una columna de partición.

No habrá billones de registro

@ rc-Gracias man..what ABT el rendimiento ... ver Estoy insertando los datos después de cada 3 s así que tengo que ejecutar un procedimiento de verificación cada vez que insertar los datos ... ¿Qué pasa con el rendimiento ?? ?

2> Me gustaría ir columna de partición como ningún vehículo ..... ¿hay alguna manera alterna ...

Answer 1

Leer: MySQL particionamiento Limitaciones

1.) FKs no se admiten en tablas con particiones.

• Una opción es crear un procedimiento almacenado que inserta / actualiza el registro y verificar dentro del procedimiento que el identificador de usuario pasado está presente en su tabla de usuarios antes de la inserción se lleva a cabo. Es necesario configurar los permisos en la tabla de modo que sólo se permite el SP para actualizar e insertar a permitir que las aplicaciones y / o usuarios de backdooring el cheque. También tendrá que tomar precauciones al retirar a los usuarios de la tabla de usuarios.

2.) ¿Qué columna se utiliza para la partición dependerá de cómo el acceso a la tabla. Si sus consultas se basan siempre en vechicle no., Entonces probablemente tiene sentido hacer una partición de hash en esa columna. Si está consultando o informar más en algo así como "qué vehículos se han añadido este mes" o si desea particiones "rodar" hacia fuera a medida que estén a cierta edad, entonces la partición de la fecha puede ser el camino a seguir. Esto es algo que tendrá que decidir en función de su uso.

3.) Vea el enlace de arriba para obtener más información.

Editar basado en pregunta del usuario:

Inserción de un registro cada 3 segundos no es una gran cantidad de rendimiento. Asegúrese de que tiene una clave principal en la tabla de usuarios para que el cheque dentro del procedimiento que se ha hecho de manera eficiente. (Esto es cierto incluso si fueron apoyados FKs) El DB estaría haciendo esta comprobación para usted detrás de las escenas si tuviera el apoyo a FK de lo que en ese sentido, no hace daño a ti. Si la comprobación termina siendo un cuello de botella, se puede sentir la necesidad de dejarlo de lado y posiblemente reportar los identificadores de usuario errantes como un proceso por lotes todas las noches, pero si eres tabla de usuario es relativamente pequeño e indexado correctamente no veo siendo ésta una cuestión.

Otra opción sería la de hacer la partición manualmente (es decir sharding) con tablas con particiones o no particionados. Con las tablas no particionadas por supuesto, se puede usar las claves externas nativos. Por ejemplo, usted podría dividir su tabla de vehículos en varias tablas como: (suponiendo que desea utilizar el vehicleNo como la "llave")

VehiclesNosLessThan1000

VehiclesNosLessThan2000

VehiclesNosLessThan ...

VehiclesNosLessThanMAX

A continuación, es probable que desee tener un SP de nuevo para que la aplicación / usuario no tiene que saber sobre las tablas. El SP sería responsable de la inserción / actualización de la tabla correcta en función del vehicleNo pasado. También querría un SP para la selección de datos para que la aplicación / usuario no tiene que saber la tabla para seleccionar de cualquiera. Para facilitar el acceso a todos los datos, puede crear una vista que todos los sindicatos de las mesas.

Tenga en cuenta que uno de los beneficios de esto es que en la actualidad MyISAM bloquea una tabla con particiones todo durante las actualizaciones, no sólo la partición que se está actualizando. Sharding una mesa de esta manera alivia esa afirmación porque las mismas tablas son las "particiones".

En base a los datos limitados que tengo sobre lo que está haciendo, probablemente escribiría 2 procedimientos almacenados, 1 para seleccionar los datos para la actualización y 1 / inserción de los datos y que su aplicación utilice las de todos los accesos. A continuación, me gustaría probar la partición regular a través de hash en la primera vehicleNo al tiempo que aplica la clave user_id dentro del procedimiento. Si esto se convierte en un problema, puede migrar fácilmente a sharding los datos a través de múltiples tablas sin tener que cambiar la aplicación, ya que toda la lógica sobre cómo recuperar y actualizar los datos están contenidos dentro de los SP.