Necesito actualizar un db grande rápidamente. Puede ser más fácil codificar en un lenguaje de scripting, pero sospecho que un programa C haría la actualización más rápido. ¿Alguien sabe si ha habido pruebas comparativas de velocidad?¿La velocidad de acceso a la base de datos MySQL está limitada principalmente por la base de datos o por el idioma utilizado para acceder a ella?
He oído especulaciones de que la API C es más rápida, pero no he visto ninguna referencia. Para realizar grandes operaciones de base de datos rápidamente, independientemente del lenguaje de programación, utilice los procedimientos almacenados: http://dev.mysql.com/tech-resources/articles/mysql-storedprocedures.html.
La velocidad proviene del hecho de que hay una tensión reducida en la red.
A partir de este enlace:
Los procedimientos almacenados son rápidos! Bueno, nosotros no podemos probar que para MySQL aún, y la experiencia de todos variará. Lo que podemos decir es que el servidor MySQL tiene alguna ventaja del almacenamiento en caché, solo como lo hacen las declaraciones preparadas. No hay ninguna compilación, por lo que un procedimiento almacenado de SQL no funcionará tan rápidamente como un procedimiento escrita con un lenguaje externo tales como C. La principal ganancia de velocidad proviene de la reducción de la red de tráfico. Si tiene una tarea repetitiva que requiere comprobación, bucles, varias declaraciones y ninguna interacción de usuario , hágalo con una sola llamada a un procedimiento almacenado en el servidor . Entonces no habrá mensajes yendo y viniendo entre el servidor y el cliente, para cada paso de la tarea .
No lo haría. La velocidad de la velocidad de actualización depende de:
Sospecho que usted piensa que un lenguaje de scripting será un cerdo en esta última parte - cantidad de datos transferidos.
Cualquier lenguaje de scripting será lo suficientemente rápido como para entregar los datos. Si tiene una gran cantidad de datos que necesita analizar/transformar rápidamente, entonces sí, C definitivamente sería el lenguaje de elección. Sin embargo, si envía datos de cadenas simples a la base de datos, no tiene sentido hacerlo, aunque no es difícil crear un programa C simple para la operación UPDATE. No es tan complicado hacerlo en C, está casi a la par con el uso de las funciones mysql_ de PHP desde el punto de vista de la "complejidad".
no olvide que la forma en que * escribe * las consultas SQL puede tener un gran efecto en la velocidad. – dqhendricks
Por supuesto, pero asumí que eso es un hecho, gracias por señalarlo :) –
Como C es un idioma de nivel inferior, no tendrá la sobrecarga de parseing/type-conversion que tendrán los lenguajes de scripting. Un int de MySQL puede correlacionar directamente con un C int, mientras que un PHP int tiene varios metadatos adjuntos que deben completarse o actualizarse.Por otra parte, si necesita hacer alguna manipulación de texto como parte de esta actualización grande, cualquier ganancia de velocidad de C probablemente se perderá en depuración/depuración debido a su soporte de manipulación de cadenas pobres en comparación con lo que podría hacer con facilidad trivial en un lenguaje de scripting como Perl o PHP.
Un int ** de MySQL ** no puede mapear ** a un C int. Un int de MySQL puede tomar el valor NULL. No estoy familiarizado con la API C de MySQL, pero otras API de C de la base de datos con las que he trabajado llevan una compensación de tiempo o memoria para manejar valores NULOS, el manejo también es generalmente engorroso para el programador. Por otro lado, la mayoría de los lenguajes de scripting incluyen un valor no definido, indefinido o nulo de forma nativa, esto hace que sea más fácil manejar el concepto de valor NULL utilizado por las bases de datos. –
¿Le preocupa la velocidad porque ya está lidiando con una situación en la que la velocidad es un problema, o simplemente está planeando el futuro?
puedo decir cómodamente que las interacciones DB están generalmente limitados por IO, ancho de banda, la memoria, el tráfico de base de datos, la complejidad de SQL, la configuración de la base de datos, problemas de indexación, y la cantidad de datos que se selecciona mucho más que por la elección de un script lenguaje frente a C.
Cuando se encuentra con cuellos de botella, casi siempre se resolverán con un mejor algoritmo, uso más inteligente de índices, dispositivos de E/S más rápidos, más almacenamiento en caché ... ese tipo de cosas (comenzando con algoritmos).
El cuarto componente de LAMP es un lenguaje de scripting después de todo. Cuando se realiza un ajuste fino, Memcache se convierte en una opción, así como en intérpretes persistentes (como mod_perl en un entorno web, por ejemplo).
El costo mayoritario en las transacciones de la base de datos se encuentra en el lado de la base de datos. El costo de interpretar/compilar su declaración de SQL y evaluar la ejecución de la consulta es mucho más sustancial que cualquier diferencia que se encuentre en el idioma de lo que se envió.
En raras ocasiones, el uso de la CPU de la aplicación para el trabajo intensivo en bases de datos es un factor mayor que el uso de la CPU del servidor de base de datos o la velocidad del disco de ese servidor.
A menos que sus aplicaciones sean de larga ejecución y no esperen en la base de datos, no me preocuparía compararlas. Si necesitan benchmarking, debe hacerlo usted mismo. Los casos de uso de datos varían enormemente y necesita sus propios números.
La API de C será marginalmente más rápida, por la sencilla razón de que cualquier otro lenguaje (independientemente de si es un "lenguaje de scripting" o un lenguaje totalmente compilado) probablemente, en algún nivel, será la asignación de ese idioma a la API C Usar la API de C directamente será, obviamente, unas pocas docenas de ciclos de CPU más rápidos que realizar una operación de mapeo y luego usar la API de C.
Pero esto es solo escupir en el océano. Incluso el acceso a la memoria principal es un orden de magnitud o dos más lento que los ciclos de CPU en una máquina moderna y las operaciones de E/S (acceso a disco o red) son varios órdenes de magnitud más lentas. No tiene sentido optimizar para que sea un microsegundo más rápido enviar la consulta si aún tardará medio segundo (o incluso varios segundos, para consultas complejas o examinar/devolver grandes cantidades de datos) para ejecutar realmente la consulta.
Elija el idioma en el que sea más productivo y no se preocupe por la optimización de la elección del idioma. Incluso si el lenguaje en sí se convierte en un problema de rendimiento (que es extremadamente poco probable), su productividad adicional ahorrará más dinero que el costo de un servidor adicional.
He encontrado que para grandes lotes de datos (Gigabytes o más), generalmente es más rápido general volcar los datos de mysql en un archivo o varios archivos en una máquina de aplicaciones. Luego procese allí (con su herramienta favorita, aquí: Perl) y use LOAD DATA LOCAL INFILE para volver a sorberla en una tabla nueva mientras hace lo mínimo posible en SQL.Al hacer esto, usted debe
índices quitar de la mesa antes de CARGA (puede no ser necesario para MyISAM, pero MEH).
siempre, SIEMPRE cargue los datos en orden PK!
agregue índices después de haber terminado de cargar.
Otra ventaja es que puede ser mucho más fácil para paralelizar el procesamiento en una máquina de aplicación barato con un montón de discos rápidos, pero volátil en lugar de hacer la escritura simultánea a su caro y no escalable base de datos maestra.
De cualquier manera. Los grandes conjuntos de datos generalmente significan que el DB es el cuello de botella.
Me refiero al procesamiento por lotes, obviamente. Si está pensando en aplicaciones tipo OLTP ... no haga esto. – tsee
Por supuesto es más rápido, la pregunta es: ¿cuánto? 1%? 0.5%? Ver la ley de Amdahl – ninjalj
No, la pregunta se refería principalmente a cómo acceder a una gran base de datos lo más rápido posible. Los puntos de referencia fueron una ocurrencia tardía. –
No me refiero a la pregunta de OP sino a la pregunta principal que debe hacer antes de optimizar algo, es decir, cuál es la aceleración máxima que podemos esperar de la optimización de esa parte del programa, según la ley de Amdahl. – ninjalj