Pas un seul ORM

Bonjour à tous! Je suis en charge du département Développement Partenaires du service de réservation d'hôtel Ostrovok.ru . Dans cet article, je voudrais parler de la façon dont nous avons utilisé Django ORM sur un projet.

En fait, je trompais, le nom aurait dû être " Pas ORM single ". Si vous vous demandez pourquoi j'ai écrit ceci, ainsi que si:

• Vous avez Django sur la pile, et vous voulez extraire le maximum d'ORM, pas seulement Model.objects.all() ,
• Vous souhaitez transférer une partie de la logique métier au niveau de la base de données,
• Ou voulez-vous savoir pourquoi l'excuse la plus fréquente pour les développeurs de B2B.Ostrovok.ru est "si historiquement" ,

... bienvenue au chat.

En 2014, nous avons lancé B2B.Ostrovok.ru - un service de réservation en ligne d'hôtels, de transferts, de voitures et d'autres services de voyage pour les professionnels du marché du tourisme (agents de voyages, opérateurs et entreprises).

En B2B, nous avons conçu et utilisé avec succès un modèle d'ordre abstrait basé sur GenericForeignKey - meta order - MetaOrder .

Une méta-commande est une entité abstraite qui peut être utilisée quel que soit le type de commande auquel elle appartient: un hôtel ( Hotel ), un service supplémentaire ( Upsell ) ou une voiture ( Car ). À l'avenir, d'autres types peuvent apparaître.

Cela n'a pas toujours été le cas. Lorsque le service B2B a été lancé, seuls les hôtels pouvaient être réservés via celui-ci et toute la logique commerciale était concentrée sur eux. De nombreux champs ont été créés, par exemple, pour afficher les taux de change du montant des ventes et du montant du remboursement de la réservation. Au fil du temps, nous avons réalisé la meilleure façon de stocker et de réutiliser ces données, compte tenu des méta-commandes. Mais le code entier n'a pas pu être réécrit, et une partie de cet héritage est entrée dans la nouvelle architecture. En fait, cela a conduit à des difficultés dans les calculs, qui utilisent plusieurs types de commandes. Que faire - donc historiquement ...

Mon objectif est de montrer la puissance de Django ORM dans notre exemple.

Contexte

Pour planifier leurs dépenses, nos clients B2B manquaient vraiment d'informations sur le montant qu'ils doivent payer maintenant / demain / plus tard, s'ils ont des dettes sur les commandes et quelle est sa taille, ainsi que combien ils peuvent dépenser davantage dans leurs limites. Nous avons décidé d'afficher ces informations sous la forme d'un tableau de bord - une telle prise simple avec un diagramme clair.

(toutes les valeurs sont testées et ne s'appliquent pas à un partenaire spécifique)

À première vue, tout est assez simple - nous filtrons toutes les commandes du partenaire, les résumons et les affichons.

Options de solution

Une petite explication sur la façon dont nous faisons les calculs. Nous sommes une entreprise internationale, nos partenaires de différents pays effectuent des opérations - achat et revente de réservations - dans différentes devises. De plus, ils doivent recevoir les états financiers dans la devise choisie (généralement locale). Il serait stupide et peu pratique de stocker toutes les données possibles sur les taux de toutes les devises, vous devez donc choisir une devise de référence, par exemple le rouble. Ainsi, vous pouvez enregistrer les taux de toutes les devises uniquement sur le rouble. Ainsi, lorsqu'un partenaire souhaite recevoir un récapitulatif, nous convertissons les montants au taux fixé au moment de la vente.

"Dans le front"

En fait, c'est Model.objects.all() et la boucle de conditions:

 def output(partner_id): today = dt.date.today() # query_get_one -    partner = query_get_one(Partner.objects.filter(id=partner_id)) #    -  query = MetaOrder.objects.filter(partner=partner) result = defaultdict(Decimal) for morder in query: #  ,     #     payment_pending = morder.get_payment_pending() payment_due = morder.get_payment_due() #        # (     ) payable = morder.get_payable_in_cur() #       if payment_pending > today: result['payment_pending'] += payable # ,     if payment_pending < today and payment_due > today: result['payment_due'] += payable return result 

Cette requête renvoie un générateur qui contient potentiellement plusieurs centaines de réservations. Une demande à la base de données sera faite pour chacune de ces réservations, et donc le cycle se déroulera très longtemps.

Vous pouvez accélérer un peu les choses en ajoutant la méthode prefetch_related :

 # object -      GenericForeignKey. query = query.prefetch_related('object') 

Ensuite, il y aura un peu moins de requêtes vers la base de données ( GenericForeignKey sur GenericForeignKey ), mais à la fin nous nous arrêterons à leur nombre, car la requête vers la base de données sera toujours effectuée à chaque itération de la boucle.

La méthode de output peut (et devrait) être mise en cache, mais le premier appel remplit toujours l'ordre d'une minute, ce qui est totalement inacceptable.

Voici les résultats de cette approche:

Le temps de réponse moyen est de 4 secondes et les pics atteignent 21 secondes. Assez longtemps.

Nous n'avons pas déployé le tableau de bord pour tous les partenaires, et donc nous n'avons pas eu beaucoup de demandes pour cela, mais il suffit quand même de comprendre que cette approche n'est pas efficace.

Les nombres en bas à droite sont le nombre de requêtes: minimum, maximum, moyenne, total.

Sagement

Le prototype du front était bon pour comprendre la complexité de la tâche, mais pas optimal pour une utilisation. Nous avons décidé qu'il serait beaucoup plus rapide et moins gourmand en ressources de faire plusieurs requêtes complexes dans la base de données que de nombreuses requêtes simples.

Plan de demande

Les traits larges du plan de requête peuvent être décrits comme suit:

• collecter les commandes selon les conditions initiales,
• préparer les champs pour le calcul par annotate ,
• calculer les valeurs des champs
• faire des aggregate par le montant et la quantité

Conditions initiales

Les partenaires qui visitent le site ne peuvent voir des informations que sur leur contrat.

 partner = query_get_one(Partner.objects.filter(id=partner_id)) 

Dans le cas où nous ne voulons pas afficher de nouveaux types de commandes / réservations, nous avons seulement besoin de filtrer celles prises en charge:

 query = MetaOrder.objects.filter( partner=partner, content_type__in=[ Hotel.get_content_type(), Car.get_content_type(), Upsell.get_content_type(), ] ) 

Le statut de la commande est important (en savoir plus sur Q ):

 query = query.filter( Q(hotel__status__in=['completed', 'cancelled']) #     ,    # | Q(car__status__in=[...]) ) 

Nous utilisons également souvent des demandes prédéfinies, par exemple, pour exclure toutes les commandes qui ne peuvent pas être payées. Il y a beaucoup de logique métier, ce qui n'est pas très intéressant pour nous dans le cadre de cet article, mais en substance ce ne sont que des filtres supplémentaires. Une méthode qui renvoie une requête préparée pourrait ressembler à ceci:

 query = MetaOrder.exclude_non_payable_metaorders(query) 

Comme vous pouvez le voir, il s'agit d'une méthode de classe qui retournera également un QuerySet .

Nous préparerons également quelques variables pour les constructions conditionnelles et pour stocker les résultats des calculs:

 import datetime as dt from typing.decimal import Decimal today = dt.date.today() result = defaultdict(Decimal) 

Préparation du terrain ( annotate )

Étant donné que nous devons nous référer aux champs en fonction du type de commande, nous utiliserons Coalesce . Ainsi, nous pouvons résumer n'importe quel nombre de nouveaux types de commandes dans un seul champ.

Voici la première partie du bloc d' annotate :

 #     , #      from app.helpers.numbers import ZERO, ONE query_annoted = query.annotate( _payment_pending=Coalesce( 'hotel__payment_pending', 'car__payment_pending', 'upsell__payment_pending', ), _payment_due=Coalesce( 'hotel__payment_due', 'car__payment_due', 'upsell__payment_due', ), _refund=Coalesce( 'hotel__refund', Value(ZERO) ), _refund_currency_rate=Coalesce( 'hotel__refund_currency_rate', Value(ONE) ), _sell=Coalesce( 'hotel__sell', Value(ZERO) ), _sell_currency_rate=Coalesce( 'hotel__sell_currency_rate', Value(ONE) ), ) 

Coalesce travaille ici avec fracas, car les commandes d'hôtel ont plusieurs propriétés spéciales, et dans tous les autres cas (services supplémentaires et voitures), ces propriétés ne sont pas importantes pour nous. C'est ainsi que la Value(ZERO) pour les montants et la Value(ONE) pour les taux de change apparaissent. ZERO et ONE sont Decimal('0') et Decimal(1) , uniquement sous forme de constantes. Une approche amateur, mais dans notre projet c'est accepté comme ça.

Vous pourriez avoir une question, pourquoi ne pas mettre certains champs d'un niveau dans une méta-commande? Par exemple, payment_pending , qui est partout. En effet, au fil du temps, nous transférons ces champs dans une méta-commande, mais maintenant le code fonctionne bien, de telles tâches ne sont pas notre priorité.

Une autre préparation et calculs

Maintenant, nous devons faire quelques calculs avec les montants que nous avons reçus dans le dernier bloc d' annotate . Notez qu'ici, vous n'avez plus besoin d'être lié au type de commande (sauf une exception).

 .annotate( #  _base     _sell_base=( F('_sell') * F('_sell_currency_rate') ), _refund_base=( F('_refund') * F('_refund_currency_rate') ), _payable_base=( F('_sell_base') - F('_refund_base') ), _reporting_currency_rate=Case( When( content_type=Hotel.get_content_type(), then=RawSQL( '(hotel.currency_data->>%s)::numeric', (partner.reporting_currency,), ), ), output_field=DecimalField(), default=Decimal('1'), ), ) 

La partie la plus intéressante de ce bloc est le champ _reporting_currency_rate , ou le taux de change vers la devise de référence au moment de la vente. Les données sur les taux de change de toutes les devises vers la devise de référence pour une commande d'hôtel sont stockées dans currency_data . C'est juste JSON. Pourquoi gardons-nous cela? C'est historiquement le cas .

Et ici, il semblerait, pourquoi ne pas utiliser F et remplacer la valeur de la devise du contrat? Autrement dit, ce serait cool si vous pouviez faire ceci:

 F(f'currency_data__{partner.reporting_currency}') 

Mais les f-strings ne f-strings pas prises en charge en F Bien que le fait que Django ORM ait déjà la capacité d'accéder aux champs json imbriqués est très agréable - F('currency_data__USD') .

Et le dernier bloc annotate est le calcul _payable_in_cur , qui sera résumé pour toutes les commandes. Cette valeur doit être dans la devise du contrat.

 .annotate( _payable_in_cur=( F('_payable_base') / F('_reporting_currency_rate') ) ) 

La particularité de la méthode annotate est qu'elle génère beaucoup de constructions SELECT something AS something_else qui ne sont pas directement impliquées dans la requête. Cela peut être vu en déchargeant la requête SQL - query.__str__() .

Voici à quoi ressemble le code SQL généré par Django ORM pour base_query_annotated . Vous devez le lire assez souvent pour comprendre où vous pouvez optimiser votre requête.

Calculs finaux

Il y aura un petit wrapper pour l' aggregate , de sorte qu'à l'avenir, si le partenaire a besoin d'une autre métrique, il puisse être facilement ajouté.

 def _get_data_from_query(query: QuerySet) -> Decimal: result = query.aggregate( _sum_payable=Sum(F('_payable_in_cur')), ) return result['_sum_payable'] or ZERO 

Et encore une chose - c'est le dernier filtrage par condition commerciale, par exemple, nous avons besoin de toutes les commandes qui devront être payées bientôt.

 before_payment_pending_query = _get_data_from_query( base_query_annotated.filter(_payment_pending__gt=today) ) 

Débogage et vérification

Un moyen très pratique de vérifier l'exactitude de la demande créée est de la comparer avec une version plus lisible des calculs.

 for morder in query: payable = morder.get_payable_in_cur() payment_pending = morder.get_payment_pending() if payment_pending > today: result['payment_pending'] += payable 

Connaissez-vous la méthode du "front"?

Code final

En conséquence, nous avons obtenu quelque chose comme ceci:

 def _get_data_from_query(query: QuerySet) -> tuple: result = query.aggregate( _sum_payable=Sum(F('_payable_in_cur')), ) return result['_sum_payable'] or ZERO def output(partner_id: int): today = dt.date.today() partner = query_get_one(Partner.objects.filter(id=partner_id)) query = MetaOrder.objects.filter(partner=partner, content_type__in=[ Hotel.get_content_type(), Car.get_content_type(), Upsell.get_content_type(), ]) result = defaultdict(Decimal) query_annoted = query.annotate( _payment_pending=Coalesce( 'hotel__payment_pending', 'car__payment_pending', 'upsell__payment_pending', ), _payment_due=Coalesce( 'hotel__payment_due', 'car__payment_due', 'upsell__payment_due', ), _refund=Coalesce( 'hotel__refund', Value(ZERO) ), _refund_currency_rate=Coalesce( 'hotel__refund_currency_rate', Value(Decimal('1')) ), _sell=Coalesce( 'hotel__sell', Value(ZERO) ), _sell_currency_rate=Coalesce( 'hotel__sell_currency_rate', Value(Decimal('1')) ), ).annotate( # Calculated fields _sell_base=( F('_sell') * F('_sell_currency_rate') ), _refund_base=( F('_refund') * F('_refund_currency_rate') ), _payable_base=( F('_sell_base') - F('_refund_base') ), _reporting_currency_rate=Case( # Only hotels have currency_data, therefore we need a # check and default value When( content_type=Hotel.get_content_type(), then=RawSQL( '(hotel.currency_data->>%s)::numeric', (partner.reporting_currency,), ), ), output_field=DecimalField(), default=Decimal('1'), ), ) .annotate( _payable_in_cur=( F('_payable_base') / F('_reporting_currency_rate') ) ) before_payment_pending_query = _get_data_from_query( base_query_annotated.filter(_payment_pending__gt=today) ) after_payment_pending_before_payment_due_query = _get_data_from_query( base_query_annotated.filter( Q(_payment_pending__lte=today) & Q(_payment_due__gt=today) ) ) 

Voici comment cela fonctionne maintenant:

Conclusions

Après avoir réécrit et optimisé la logique, nous avons réussi à gérer assez rapidement les mesures d'affiliation et à réduire considérablement le nombre de requêtes dans la base de données. La solution s'est avérée bonne et nous réutiliserons cette logique dans d'autres parties du projet. ORM est notre tout.

Écrivez des commentaires, posez des questions - nous essaierons de répondre! Je vous remercie!