mysql - mediumblob - char vs varchar para el rendimiento en la base de datos

string varchar mysql (5)

Estoy usando mySQL para configurar una base de datos de opciones sobre acciones. Hay aproximadamente 330,000 filas (cada fila es 1 opción). Soy nuevo en SQL, así que estoy tratando de decidir sobre los tipos de campo para cosas como símbolo de opción (varía de 4 a 5 caracteres), símbolo de acciones (varía de 1 a 5 caracteres), nombre de la empresa (varía de 5 a 60 caracteres).

Quiero optimizar para la velocidad. Tanto la creación de la base de datos (que ocurre cada 5 minutos a medida que sale nueva información de precios) no tengo un feed de datos en tiempo real, pero es casi en tiempo real porque recibo un nuevo archivo de texto con 330,000 filas entregadas a mí cada 5 minutos, esta nueva información reemplaza completamente a los datos anteriores), y también para la velocidad de búsqueda (habrá una interfaz web donde muchos usuarios pueden ejecutar consultas ad hoc).

Si no estoy preocupado por el espacio (dado que la duración de la memoria base es de 5 minutos, y cada fila contiene quizás 300 bytes, tal vez 100 MB para todo) ¿cuál es la forma más rápida de estructurar los campos?

La misma pregunta para campos numéricos, en realidad: ¿Hay una diferencia de rendimiento entre int (11) e int (7)? ¿Una longitud funciona mejor que otra para consultas y clasificación?

¡Gracias!

Dadas las limitaciones del sistema, sugeriría un varchar ya que cualquier cosa que haga con los datos tendrá que acomodarse a cualquier relleno que coloque en su lugar para hacer uso de un carácter de ancho fijo. Esto significa más código en alguna parte que es más de depuración, y más posibilidades de errores. Habiendo dicho eso:

El mayor cuello de botella en su aplicación se debe a la caída y recreación de su base de datos cada cinco minutos. No obtendrás mucho beneficio de rendimiento de los microalimentos como elegir char sobre varchar. Creo que tiene algunos problemas arquitectónicos más serios para abordar en su lugar. - Princesa

Estoy de acuerdo con el comentario de arriba. Tienes peces más grandes para freír en tu arquitectura antes de poder preocuparte por la diferencia entre un char y varchar. Por un lado, si un usuario web intenta ejecutar una consulta ad hoc y la base de datos está en proceso de recreación, obtendrá errores (es decir, "la base de datos no existe" o simplemente problemas de tipo de "tiempo de espera agotado") )

Sugeriría que, en su lugar, cree (como mínimo) una tabla de cotización para los datos de cotizaciones más recientes (con una marca de tiempo), una tabla de símbolos de cotización y una tabla de historial. Sus usuarios de la web consultarían contra la tabla de cotización para obtener los datos más recientes. Si aparece un símbolo en su archivo de 5 minutos que no existe, es lo suficientemente simple como para que el script de importación lo cree antes de publicar la nueva información en la tabla de citas. Todos los demás se actualizan y las consultas predeterminadas a los datos del día actual.

En MyISAM, hay algunos beneficios al hacer registros de ancho fijo. VARCHAR es ancho variable. CHAR es de ancho fijo. Si sus filas solo tienen tipos de datos de ancho fijo, entonces toda la fila es de ancho fijo, y MySQL obtiene alguna ventaja al calcular los requisitos de espacio y el desplazamiento de las filas en esa tabla. Dicho esto, la ventaja puede ser pequeña y no merece la pena una pequeña ganancia posible que se ve superada por otros costos (como la eficiencia de caché) de tener columnas CHAR de ancho fijo y acolchado donde VARCHAR almacenaría de forma más compacta.

El punto de ruptura donde se vuelve más eficiente depende de su aplicación, y esto no es algo que se pueda responder, excepto al probar ambas soluciones y utilizar la que mejor se adapte a sus datos con el uso de la aplicación.

Con respecto a INT (7) frente a INT (11), esto es irrelevante para el almacenamiento o el rendimiento. Es un malentendido común que el argumento de MySQL para el tipo INT tenga algo que ver con el tamaño de los datos; no es así. El tipo de datos INT de MySQL siempre es de 32 bits. El argumento entre paréntesis se refiere a la cantidad de dígitos para agregar si muestra el valor con ZEROFILL. Por ejemplo, INT (7) mostrará 0001234, donde INT (11) mostrará 00000001234. Pero este relleno solo ocurre cuando se muestra el valor, no durante el cálculo de almacenamiento o matemática.

Si los datos reales en un campo pueden variar mucho en tamaño, varchar es mejor porque lleva a registros más pequeños, y registros más pequeños significan una base de datos más rápida (más registros pueden caber en la memoria caché, índices más pequeños, etc.). Por la misma razón, usar ints más pequeños es mejor si necesita velocidad máxima.

OTOH, si la varianza es pequeña, por ejemplo, un campo tiene un máximo de 20 caracteres, y la mayoría de los registros en realidad tienen casi 20 caracteres de largo, entonces el carácter "char" es mejor porque permite algunas optimizaciones adicionales por parte del DB. Sin embargo, esto realmente solo importa si es cierto para TODOS los campos en una tabla, porque entonces usted tiene registros de tamaño fijo. Si la velocidad es su principal preocupación, incluso podría valer la pena mover cualquier campo de tamaño no fijo a una tabla separada, si tiene consultas que usan solo los campos de tamaño fijo (o si solo tiene consultas de escopeta).

Al final, es difícil generalizar porque mucho depende de los patrones de acceso de su aplicación real.

Definitivamente no volvería a crear la base de datos cada vez. En cambio, haría lo siguiente:

leer en el archivo de actualización / instantánea y crear algún objeto basado en cada fila.
para cada fila, obtenga el nombre del símbolo / opción (único) y configúrelo en la base de datos

Si fuera yo, también tendría un caché en memoria de todos los símbolos y los datos de precios actuales.

Los datos de precios nunca son una int; puede usar caracteres.

El nombre de la compañía probablemente no sea único ya que hay muchas opciones para una compañía en particular. Eso debería ser un índice y puede ahorrar espacio simplemente usando la identificación de una empresa.

Como alguien más también señaló: sus clientes web no necesitan tener que acceder a la base de datos real y hacer una consulta, probablemente pueda simplemente presionar su caché. (aunque eso realmente depende de qué tablas y datos expone a sus clientes y qué datos desean)

Tener acceso de consulta para otros usuarios también es una razón para NO seguir eliminando y creando una base de datos.

Recuerde también que la creación de bases de datos está sujeta a la implementación real de la base de datos que utilice. Si alguna vez puertos desde MySQL a, por ejemplo, Postgresql, descubrirá un hecho muy desagradable que la creación de bases de datos en postgresql es una operación comparativamente muy lenta. Es órdenes de magnitud más lentas que leer y escribir filas de tablas, por ejemplo.

Parece que hay un problema de diseño de la aplicación que debe abordar primero, antes de optimizar el rendimiento para elegir los tipos de datos adecuados.