REDBEAN ORM performance [fermé]

Je pense que la réponse de Tereško n'est pas tout à fait juste.

Premièrement, il ne répond pas à la question initiale. C'est en effet un cas contre ORM, et je suis d'accord avec les problèmes décrits dans sa réponse. C'est pourquoi J'ai écrit RedBeanPHP. Tout simplement parce que la plupart des ORM ne parviennent pas à rendre votre vie un peu plus facile ne signifie pas que le concept d'un système de cartographie relationnelle d'objet est défectueux. La plupart des ORM essaient de cacher SQL, c'est pourquoi les jointures sont si complexes; ils doivent réinventer quelque chose de similaire dans un objet orienté environnement. C'est là que RedBeanPHP diffère, car il ne cache pas SQL. Il crée des tables SQL lisibles et valides faciles à interroger. Au lieu d'un langage de requête fabriqué, RedBeanPHP utilise un ancien SQL simple pour l'enregistrement et la récupération des beans. En bref; RedBeanPHP fonctionne avec SQL plutôt que contre. Cela le rend beaucoup moins complexe.

Et oui, les performances de RedBeanPHP sont bonnes. Comment puis-je être sûr? Parce que contrairement aux autres ORM, RedBeanPHP distingue entre le mode de développement et le mode de production. Pendant le cycle de développement, la base de données est fluide; vous pouvez ajouter des entrées et elles seront ajoutées dynamiquement. RedBeanPHP crée les colonnes, les index,devine les types de données, etc. Il étire même des colonnes si vous avez besoin de plus d'octets (type de données plus élevé) après un certain temps. Cela rend RedBeanPHP extrêmement lent, mais seulement pendant le temps de développement lorsque la vitesse ne devrait pas être un problème. Une fois que vous avez terminé le développement, vous utilisez freeze la base de données avec un spécificateur de mode unique R:: freeze () et pas plus les vérifications sont faites. Ce qui vous reste est une couche de base de données assez simple sur votre serveur de production. Et parce que peu est fait, la performance est bonne.

Oui, je sais, je suis l'auteur de RedBeanPHP donc je suis biaisé. Cependant, j'avais l'impression que mon ORM était vu sous la même lumière que les autres ORM, ce qui m'a incité à écrire ceci. Si vous voulez en savoir plus, n'hésitez pas à consulter le site web RedBeanPHP, Et voici une discussion sur la performance.

À notre société Nous utilisons RedBeanPHP pour les systèmes embarqués ainsi que les systèmes d'affaires financières, il semble donc évoluer plutôt bien.

Ensemble, Moi et la communauté RedBeanPHP essayons sincèrement de faire du monde ORM un meilleur endroit; vous pouvez lire l'énoncé de missionici .

Bonne chance avec votre projet et j'espère que vous trouverez la solution technique que vous cherchez.

Je diffère de @tereško ici-ORMs peut rendre les requêtes de base de données plus faciles à écrire et plus faciles à maintenir. Il y a un excellent travail dans Propel et Doctrine, à mon avis-profitez-en! Il y a un certain nombre de comparaisons de performances sur le web, et consultez également NotORM (Je ne l'ai pas utilisé mais ils font des comparaisons avec Doctrine, si je me souviens bien).

Si vous arrivez à un point où votre débit vous oblige à faire du SQL brut, optimisez à de ce point. Mais en termes de réduction de votre nombre de bogues et d'augmentation de votre productivité, je pense que vos économies financeront un meilleur serveur de toute façon. Bien sûr, votre kilométrage peut varier.

Je ne connais pas RedBean, incidemment, mais je suis légèrement d'avis que Propel est plus rapide que Doctrine dans la plupart des cas, puisque les classes sont pré-générées. J'ai utilisé Propel quand c'était la seule option et je suis resté avec, bien que je ne serais certainement pas opposé à l'utilisation de la Doctrine.

2018 mise à jour

Propel 2 est toujours en alpha après un certain nombre d'années, et a besoin d'un certain nombre de grands projets de refactoring, qui malheureusement ne se faisaient pas. Bien que les mainteneurs disent que cet alpha est bon à utiliser en production, car il a une bonne couverture de test, ils ont maintenant commencé sur Propel 3. Malheureusement, cela n'a pas encore eu de Versions, au moment où j'ai écrit ceci, malgré le dépôt d'un an.

Bien que je pense que Propel était un grand projet, je je me demande s'il est préférable d'utiliser autre chose pour le moment. Il pourrait encore renaître de ses cendres!

J'irais avec la situation "chevaux pour les cours" qui utilise un mélange et un match des deux mondes. J'ai construit quelques applications à grande échelle en utilisant RedBean, donc mon commentaire se concentrera uniquement sur RedBean et non sur d'autres ORM.

REDBEAN ORM est-il lent?

Eh Bien, cela dépend de la façon dont vous l'utiliser. Dans certains scénarios, c'est plus rapide que la requête traditionnelle car RedBean met en cache le résultat pendant quelques secondes. La réutilisation de la requête produira des résultats plus rapidement. Regardez le journal en utilisant R::debug(true); Il montre toujours

"SELECT * FROM `table` -- keep-cache"

Scénario 1: Récupération De Tout (*)

Dans RedBean si vous interrogez

$result = R::findOne('table', ' id = ?', array($id));

Ceci est représenté par

$result= mysql_query("Select * from TABLE where id =".$id);

Vous pouvez faire valoir que si la table a plusieurs colonnes, pourquoi devriez-vous interroger (*).

Scénario 2: une Seule colonne

Extraction d'une seule colonne

R::getCol( 'SELECT first_name FROM accounts' );

Comme je l'ai mentionné "chevaux pour les cours", les développeurs ne devraient pas simplement compter sur FindOne, FindAll, FindFirst, FindLast mais rédigez également soigneusement ce dont ils ont vraiment besoin.

Scénario 3: La Mise En Cache

Lorsque vous n'avez pas besoin de mise en cache, vous pouvez désactiver au niveau de l'application, ce qui n'est pas une situation idéale

R::$writer->setUseCache(true);

RedBean suggère que si vous ne voulez pas désactiver la mise en cache au niveau de l'application, vous devez utiliser une requête traditionnelle avec le paramètre no-cache comme $result = R::exec("SELECT SQL_NO_CACHE * FROM TABLE");

Cela résout parfaitement le problème de l'extraction des données en temps réel de la table par complètement suppression du cache de requête.

Scénario 4: Le Développement Rapide De

L'utilisation D'ORM rend le développement de votre application très rapide, les développeurs peuvent coder en utilisant ORM 2-3x plus rapidement que L'écriture SQL.

Scénario 5: Requêtes Et Relations Complexes

RedBean présente une très bonne façon d'implémenter des requêtes complexes et des relations one-to-many ou many-to-many

SQL simple pour les requêtes complexes

$books = R::getAll( 'SELECT 
    book.title AS title, 
    author.name AS author, 
    GROUP_CONCAT(category.name) AS categories FROM book
    JOIN author ON author.id = book.author_id
    LEFT JOIN book_category ON book_category.book_id = book.id
    LEFT JOIN category ON book_category.category_id = category.id 
    GROUP BY book.id
    ' );
    foreach( $books as $book ) {
        echo $book['title'];
        echo $book['author'];
        echo $book['categories'];
    }

Ou Façon RedBean de gérer les relations plusieurs-t-à-plusieurs

list($vase, $lamp) = R::dispense('product', 2);

$tag = R::dispense( 'tag' );
$tag->name = 'Art Deco';

//creates product_tag table!
$vase->sharedTagList[] = $tag;
$lamp->sharedTagList[] = $tag;
R::storeAll( [$vase, $lamp] );

Les Problèmes De Performance

Les arguments tels que les ORM sont généralement lents, consomment plus de mémoire et ont tendance à ralentir une application. Je pense qu'ils ne parlent pas de RedBean.

Nous l'avons testé avec MySQL et Postgres à la fois, croyez-moi la performance n'a jamais été un goulot d'étranglement.

On ne peut nier que les ORM additionnent peu de frais généraux et ont tendance à rendre votre application plus lente ( juste un peu ). L'utilisation D'ORM est principalement un compromis entre le temps du développeur et les performances d'exécution légèrement plus lentes. Ma stratégie consiste d'abord à construire l'application de bout en bout avec L'ORM, puis en fonction des cas de test, à modifier les modules critiques de vitesse pour utiliser un accès direct aux données.