2009-07-05 26 views
7

Alguna vez desarrollé varios proyectos basados ​​en el framework python Django. Y mejoró mucho mi producción. Pero cuando se lanzó el proyecto y hay más y más visitantes, el DB se convierte en el cuello de botella del rendimiento.¿Cuál es el significado de ORM?

Intento solucionar el problema y me parece que es ORM (django) lo que hace que sea muy lento. ¿Por qué? Porque Django tiene que servir una interfaz uniforme para el programador, sin importar el back-end de db que esté utilizando. Por lo tanto, definitivamente sacrifica el rendimiento de algunos db (convierte un sql en bruto en varios sqls y nunca utiliza la operación específica de db).

Me pregunto el ORM es sin duda útil y que puede:

  1. ofrecen una interfaz OO uniforme para los progarammers
  2. Realiza la migración db backend mucho más fácil (de MySQL a SQL Server u otros)
  3. Mejorar la robusta del código (usando ORM significa menos código, y menos código significa menos errores)

Pero si no tengo el requisito de la migración, ¿Cuál es el significado de la ORM para mí?

ps. Recientemente, mi amigo me dijo que lo que ahora está haciendo es volver a escribir el código ORM en el sql en bruto para obtener un mejor rendimiento. ¡Qué pena!

Entonces, ¿cuál es el verdadero significado de ORM, excepto lo que mencioné anteriormente? (Corrígeme si cometí un error. Gracias.)

+5

¿En lugar de "querer decir" me refiero a "valor"? –

+0

Tienes razón. Gracias. –

Respuesta

7

En su mayoría, respondió su propia pregunta cuando enumeró los beneficios de un ORM. Definitivamente hay algunos problemas de optimización que encontrará, pero la abstracción de la interfaz de la base de datos probablemente anule estos inconvenientes.

Menciona que el ORM a veces usa muchas sentencias SQL donde podría usar solo una. Es posible que desee ver "carga ansiosa", si su ORM lo admite. Esto le dice al ORM que busque los datos de los modelos relacionados al mismo tiempo que obtiene los datos de otro modelo. Esto debería dar como resultado un sql más eficiente.

Le sugiero que se quede con su ORM y optimice las piezas que lo necesitan, pero explore cualquier método dentro del ORM que le permita aumentar el rendimiento antes de volver a escribir SQL para hacer el acceso.

+0

Estoy de acuerdo con usted. De hecho, puedo averiguar qué operaciones de ORM ralentizan la consulta de db y optimizarlas después de hackear el ORM interno. Significa que debería saber sql muy bien en un lado, y conocer el ORM interno muy bien en otro lado. Parece indigno comparar con centrarse en el sql en bruto. –

3

Un buen ORM le permite ajustar el acceso a los datos si descubre que ciertas consultas son un cuello de botella.

Pero el hecho de que pueda necesitar hacer esto no elimina de ninguna manera el valor del enfoque ORM, porque lo lleva rápidamente al punto donde puede descubrir dónde están los cuellos de botella. Rara vez sucede que cada línea de código necesite la misma cantidad de optimización manual cuidadosa. La mayor parte no lo hará. Solo unos pocos puntos de acceso requieren atención.

Si escribe todo el SQL a mano, está "micro optimizando" todo el producto, incluidas las piezas que no lo necesitan. Entonces estás perdiendo el esfuerzo principalmente.

+0

¿Qué sucede si tienes administradores de bases de datos que gestionan los datos con varios equipos de clientes diferentes que acceden a la base de datos? – gbn

+0

@gbn: no estoy seguro de a dónde va con esa pregunta, pero en ese caso extendería una sola capa de datos (desarrollada con un ORM) a todos los otros equipos para compartir, y luego la mejoraría en respuesta a su retroalimentación (ya sea sobre el rendimiento, facilidad de uso o cualquier otro criterio de calidad). –

+0

Mi dirección es: todos mis equipos de clientes codifican contra mis procedimientos almacenados. Esto me permite tratar con los clientes de Java, C#, vb.net y VBA. El DAL es procedimientos almacenados. El idioma del cliente y ORM es irrelevante. – gbn

1

aquí es la definición de Wikipedia

mapeo de objetos relacional es una técnica de programación para la conversión de datos entre sistemas de tipo incompatibles en bases de datos relacionales y lenguajes de programación orientados a objetos.Esto crea, en efecto, una "base de datos de objetos virtuales" que se puede usar desde el lenguaje de programación.

0

un buen ORM (como Django's) hace que desarrollar y evolucionar su aplicación sea mucho más rápido; le permite suponer que tiene disponible todos los datos relacionados sin tener que factorizar cada uso en sus consultas ajustadas a mano.

pero uno simple (como el de Django) no lo libera del buen diseño de DB anterior. si ve el cuello de botella de DB con menos de varios cientos usuarios simultáneos, tiene serios problemas. O bien su base de datos no está bien ajustada (normalmente le faltan algunos índices), o no representa adecuadamente el diseño de los datos (si necesita muchas consultas diferentes para cada página, este es su problema).

Así que no abandonaría el ORM a menos que sea twitter o flickr. Primero haga todo el análisis de base de datos habitual: ¿ve muchos escaneos de tabla completa? agregue los índices apropiados. Muchas consultas por página? reconsidera tus tablas Cada usuario necesita muchas estadísticas? precalcularlos en un trabajo por lotes y servir desde allí.

+0

Gracias. Pero después de sintonizar la base de datos, y puede enfrentar el mismo problema. Tal vez el DB no se puede sintonizar más, y hay que considerar reescribir las operaciones ORM en sql en bruto para obtener un mejor rendimiento. –

+0

por supuesto. Creo que el techo de rendimiento del ORM es realmente alto. la mayoría de los sitios no estarán cerca. Además, no se trata solo de "ajustar el DB"; también se trata de utilizar la estructura de datos y los algoritmos correctos. Si realiza 50 consultas por página, ninguna cantidad de sintonización de DB le ayudará, tiene que reducirla a menos de 10, menos de 5 idealmente. – Javier

0

ORM te separa de tener que escribir ese SQL molesto.

También es útil para cuando (nunca) transfiere su software a otro motor de base de datos.

Lo malo: se pierde el rendimiento, que se corrige al escribir un sabor personalizado de SQL, que trató de aislar de tener que escribir en primer lugar.

+0

Gracias. Pero supongo que no has leído mi publicación. –

+0

No, lo leí. Tienes las dos razones para ORM. –

0

ORM genera consultas sql para usted y luego regresa como objeto para usted. por eso es más lento que si accede directamente a la base de datos. Pero creo que se ralentiza un poco ... te recomiendo que sintonices tu base de datos. puede ser que necesite verificar el índice de la tabla, etc.

Oracle, por ejemplo, necesita ser sintonizado si necesita ser más rápido (no sé por qué, pero mi administrador de DNS lo hizo y funciona más rápido con consultas eso involucrado con muchos datos).

Tengo una recomendación, si necesita hacer una consulta compleja (por ej .: informes) que no sea (Crear actualización Eliminar/CRUD) y si su aplicación no usará otra base de datos, debería usar sql directo (creo que Django tiene característica)

+0

Gracias. Y tu conclusión es casi la misma que la mía. –

Cuestiones relacionadas