J'ai déjà développé plusieurs projets basés sur Python Framework Django. Et cela a grandement amélioré ma production. Mais lorsque le projet a été libéré et qu'il y a de plus en plus de visiteurs, le DB devient le goulot d'étranglement des performances.
J'essaie de répondre à la question et de constater que c'est ORM (Django) de le faire devenir si lent. Pourquoi? Parce que Django doit servir une interface uniforme pour le programmateur, quel que soit le backend dB que vous utilisez. Donc, il sacrifie définitivement les performances de la DB (faites une SQL brute à plusieurs SQLS et n'utilisez jamais l'opération spécifique à la DB).
Je me demande que l'ormes est définitivement utile et qu'il peut:
Mais si je n'ai pas l'exigence de migration, quelle est la signification de l'ormes pour moi?
ps. Récemment, mon ami m'a dit que ce qu'il fait maintenant est de réécrire le code ORM au SQL brut pour obtenir une meilleure performance. Quelle pitié!
Alors, quelle est la vraie sens de l'orme sauf ce que j'ai mentionné ci-dessus? (S'il vous plaît corrigez-moi si je faisais une erreur. Merci.)
6 Réponses :
Un bon orm vous permet d'accorder l'accès aux données si vous découvrez que certaines requêtes sont un goulot d'étranglement.
Mais le fait que vous ayez peut-être besoin de le faire ne supprime en aucune manière la valeur de l'approche ORM, car cela vous amène rapidement au point où vous pouvez découvrir où sont les goulots d'étranglement. Il est rarement le cas que chaque ligne de code a besoin de la même quantité d'optimisation de la main minutieuse. La plupart d'entre eux ne le fera pas. Seuls quelques points chauds nécessitent une attention particulière.
Si vous écrivez tout le SQL à la main, vous êtes "micro optimisant" dans l'ensemble du produit, y compris les pièces dont les pièces n'en ont pas besoin. Donc, vous gaspillez surtout des efforts.
Et si vous avez développeur DBAS Gestion des données avec plusieurs équipes clientes différentes accédant à la base de données?
@GBN - Je ne sais pas où vous allez avec cette question, mais dans ce cas, je ferais une seule couche de données (développée avec une orme) à toutes les autres équipes à partager, puis à l'améliorer en réponse à leurs commentaires. (que ce soit sur la performance, la convivialité ou tout autre critère de qualité).
Ma direction est la suivante: tout mon code d'équipe client contre mes procédures stockées. Cela me permet de gérer les clients Java, C #, VB.NET et VBA. Le DAL est stocké des procédures. Le client Langauge et Orm est hors de propos.
I.e. Code de la main L'équivalent de la sortie de l'ORM dans une langue spécifique aux SMDBM. Un autre groupe où je travaille a essayé cela. L'exigence initiale était une SGDB spécifique, mais cela a rapidement changé (victimes de leur propre succès). En outre, il a été supposé que SPS serait "plus rapide", mais il s'est avéré que certaines parties de l'application devaient générer de manière dynamique leur SQL car les utilisateurs ont besoin d'une interrogation très flexible. Devinez quoi, ces requêtes dynamiques se sont avérées les requêtes les plus utilisées du système. Tous ces efforts de maintien de plusieurs ensembles de SP pour des requêtes qui ne sont pratiquement jamais courues! En utilisant Orm pour la prochaine version.
Donc, si vous n'avez jamais besoin de la possibilité de changer de fournisseurs de RDBMS (vous ne savez pas pourquoi vous voudriez que vous voudriez aller), vous devriez être correct ... Mon attitude est résumée par ce blog Post: SmelleGantCode.WordPress.com/2009/05/11/...
Ha! Eh bien, c'est une situation légèrement différente. L'une de vos exigences de votre entreprise semble être «tout ce qui se passe, nous devons utiliser ce SGBD en particulier dans le cadre de la solution». Donc, naturellement, il n'y a pas d'argument rationnel contre votre décision.
Merci, écouteux. Votre réponse me fait sentir mieux à propos de l'ormes.
Vous avez surtout répondu à votre propre question lorsque vous avez répertorié les avantages d'une ormission. Il existe définitivement quelques problèmes d'optimisation que vous rencontrerez, mais l'abstraction de l'interface de base de données surcharge probablement ces effectifs.
Vous mentionnez que l'ORM utilise parfois de nombreuses déclarations SQL où il pourrait en utiliser un seul. Vous voudrez peut-être examiner le "chargement désireux", si cela est pris en charge par votre orj. Cela indique à l'orèse d'aller chercher les données à partir de modèles associés en même temps que celle-ci récupère des données d'un autre modèle. Cela devrait entraîner une SQL plus performante.
Je suggérerais de rester avec votre orj et d'optimiser les pièces dont besoin, mais d'explorer toutes les méthodes dans l'orèse qui vous permettent d'accroître les performances avant de revenir à la rédaction de SQL pour effectuer l'accès.
Je suis surtout d'accord avec toi. En fait, je peux comprendre quelles opérations orm ralentissent la requête DB et les optimiser après le piratage de l'orèse interne. Cela signifie que je devrais savoir très bien sql d'un côté et connaître très bien l'orèse interne très bien sur un autre côté. Il semble indigne de comparer avec la mise au point sur le SQL brut.
Voici la définition de Wikipedia
L'objet-cartographie relationnel est une technique de programmation permettant de convertir des données entre des systèmes de type incompatibles dans des bases de données relationnelles et des langages de programmation orientés objet. Cela crée, en effet, une "base de données d'objet virtuel" qui peut être utilisée à partir de la langue de programmation.
Un bon orje (comme Django's) rend beaucoup plus rapide de développer et d'évoluer votre application; Il vous permet de supposer que vous disposez de toutes les données associées sans avoir à prendre en compte toutes les utilisations de vos requêtes à la main.
Mais un simple (comme Django's) ne vous soulage pas de bon vieux design de DB. Si vous voyez un goulot d'étranglement DB avec moins de plusieurs centaines d'utilisateurs simultanés simultanés, vous avez de graves problèmes. Soit votre dB n'est pas bien réglé (vous manquez généralement des index), soit cela ne représente pas de manière appropriée la conception de données (si vous avez besoin de nombreuses requêtes différentes pour chaque page, c'est votre problème).
Donc, je n'entraînerais pas l'ormes à moins que vous soyez Twitter ou Flickr. D'abord toutes les analyses de la DB habituelles: vous voyez beaucoup de scans de table complète? Ajouter des index appropriés. Beaucoup de requêtes par page? repenser vos tables. Chaque utilisateur a besoin de beaucoup de statistiques? les précalculer dans un travail de lot et servir de là.
Merci. Mais après avoir tapé la dB et que vous pouvez faire face au même problème. Peut-être que la DB ne peut plus être réglée et vous devez envisager de réécrire les opérations ORM à RAW SQL pour obtenir une meilleure performance.
bien sûr. Je viens de croire que le plafond de performance de l'ORM est vraiment élevé. La plupart des sites ne seront nulle part près de. En outre, il ne s'agit pas que de "régler la db"; Il s'agit également d'utiliser la bonne structure de données et des algorithmes. Si vous faites 50 questions par page, aucune quantité de réglage de la DB ne vous aidera, vous devez le ramener à moins de 10, moins de 5 idéalement.
orm vous sépare de devoir écrire ce Pesky SQL.
Il est également utile pour le moment où vous (jamais) portez votre logiciel à un autre moteur de base de données.
À l'inconvénient: vous perdez des performances que vous réalisez en écrivant une saveur personnalisée de SQL - qu'elle a essayé d'isoler de devoir écrire en premier lieu.
orm génère des requêtes SQL pour vous, puis de vous retourner comme objet. C'est pourquoi il est plus lent que si vous accédez directement à la base de données. Mais je pense que cela ralentit un peu ... Je vous recommande d'accorder votre base de données. Peut-être que vous devez vérifier l'index de la table, etc.
Oracle par exemple, doit être à l'écoute si vous devez avoir plus vite (je ne sais pas pourquoi, mais mon administrateur DB a fait cela et cela fonctionne plus rapidement avec des requêtes impliquées dans de nombreuses données).
J'ai une recommandation, si vous devez faire une requête complexe (par exemple: des rapports) autres que (Créer la mise à jour Supprimer / CRUD) et si votre application n'utilisera pas une autre base de données, vous devez utiliser directement SQL (je pense que Django l'a fonctionnalité)
Merci. Et votre conclusion est presque la même avec la mienne.
Plutôt que de «signification», je pense que vous voulez dire «valeur»?