J'ai un projet avec 2 applications (livres et lecteurs).
L'application de livres a une table avec 4 millions de lignes avec ces champs: à éviter Pour interroger la base de données avec 4 millions de lignes, je pense à le diviser par sujet (20 modèles avec 20 tables avec 200.000 lignes (book_horror, book_dramme, ECC). dans "Reader", je suis Pensant à insérer ces champs: donc au lieu de fourrure, je pense utiliser un "book_subject" entier (qui permet d'accéder à la table appropriée) et "book_id" ( qui permet d'accéder au livre dans la table spécifiée dans "book_subjject"). est une bonne solution pour éviter d'interroger une table avec 4 millions de rangées? y a-t-il une alternative solution? merci ^ __ ^
6 Réponses :
ForeGeCey est implémenté comme integerfield dans la base de données, de sorte que vous économisez peu à rien au prix de votre modèle.
J'utilise l'index mais la table contient 4 millions de rangées et elle est souvent interrogée. Donc, je ne sais pas si l'index suffit: - \
Si ce n'est pas alors, la base de données a besoin de plus de mémoire.
4 millions de lignes ne sont rien à éternuer, mais des bases de données sont construites pour ce genre de chose, surtout si vous indexez. Je ne m'inquiéterais que si vous vous releviez d'au moins cent millions de rangées.
Je ne connais pas avec Django, mais j'ai une compréhension générale de la DB.
Lorsque vous avez de grandes bases de données, il est assez normal de Index Votre base de données . De cette façon, récupérer des données, devrait être assez rapide.
Quand il s'agit d'associer un livre avec un lecteur, vous devez créer une autre table, qui relie le lecteur aux livres.
Ce n'est pas une mauvaise idée de diviser les livres en sujets. Mais je ne suis pas sûr de ce que vous entendez en ayant 20 applications.
20 applications signifie 20 tables :) J'utilise déjà l'index, mais la table dispose de 4 millions de lignes et il est souvent interrogé. Donc, je ne sais pas si l'index suffit: - \
DIEU NON! Ne pas diviser en 20 tables! Faites un diagramme d'oreille de vos tables, et vous verrez quelle table supplémentaire vous devez gérer cela. Par exemple. Tables supplémentaires pour relier la personne aux livres, catégorie à livres, etc.
Avez-vous des problèmes de performance? Si tel est le cas, vous pourriez avoir besoin de Ajouter quelques index .
Un moyen d'avoir une idée où un index aiderait à regarder votre journal de requête de DB Server ( instructions ici si vous êtes sur MySQL).
Si vous n'avez pas de problèmes de performance, alors allez-y. Des bases de données sont faites pour gérer des millions d'enregistrements et Django est plutôt bon pour générer des requêtes raisonnables.
Oui, c'est un problème de performance. J'utilise l'index mais la table contient 4 millions de rangées et elle est souvent interrogée. Donc, je ne sais pas si l'index suffit: - \
Un index plus gros (plus de colonnes) est probablement la voie à suivre, peut-être en plus de memcached en tant que mention @JCM. Souvent, les index de colonne unique ne vous aident pas parce qu'ils ne sont pas utilisés par vos requêtes.
Une approche commune de ce type de problème est Sharding . Malheureusement, il est principalement à la hauteur de l'ORM de le mettre en œuvre (Hibernate le fait merveilleusement) et Django ne le supporte pas. Cependant, je ne suis pas sûr que 4 millions de lignes sont vraiment tout ce mal. Vos demandes devraient toujours être entièrement gérables.
Peut-être que vous devriez peut-être regarder à la mise en cache avec quelque chose comme Memcached . Django supporte ce très bien.
Comme beaucoup l'ont dit, il est un peu prématuré de diviser votre table dans des tables plus petites (partitionnement horizontal ou même au sifflement). Des bases de données sont faites pour gérer les tables de cette taille, de sorte que votre problème de performance est probablement ailleurs.
Les index sont la première étape, on dirait que vous l'avez fait cependant. 4 millions de lignes doivent être correctes pour que la DB soit manipulée avec un index.
Deuxièmement, vérifiez le nombre de requêtes que vous utilisez. Vous pouvez le faire avec quelque chose comme la barre d'outils Django Debug, et vous serez souvent surpris de voir combien de requêtes inutiles sont faites.
La mise en cache est la prochaine étape, utilisez Memcached pour pages ou parties de pages inchangées pour la plupart des utilisateurs. C'est là que vous verrez votre plus grand nombre de performances pour le petit effort requis.
Si vous avez vraiment besoin de scinder les tables, la dernière version de Django (1.2 Alpha) peut gérer le frisson (par exemple multi-db), et vous devriez pouvoir remédier à une solution de partitionnement horizontale (Postgres propose un façon in-db pour le faire). S'il vous plaît n'utilisez pas de genre pour diviser les tables! Choisissez quelque chose que vous ne changez jamais, jamais changer et que vous sachez toujours lorsque vous faites une requête. Comme auteur et diviser par la première lettre du nom de famille ou quelque chose. Il s'agit de nombreux efforts et comporte un certain nombre d'inconvénients pour une base de données qui n'est pas particulièrement grosse - c'est pourquoi la plupart des gens ici conseillent contre cela!
[modifier]
J'ai laissé la dénormalisation! Mettre des comptes communs, des sommes, etc. dans la table d'auteur, par exemple pour empêcher les joints sur des requêtes courantes. L'inconvénient est que vous devez le maintenir vous-même (jusqu'à ce que Django ajoute un carton dénormalized). Je regarderais cela pendant le développement pour des cas clairs, simples ou après que la mise en cache vous a échoué - mais bien avant ou partitionnement horizontal.
Ok si je vais diviser la table, je vais le scinder par la première lettre ... en effet est plus raisonnable :) La table est interrogée à partir d'Ajax à l'aide d'un champ autocomplete avec cette requête dans les vues.py: books.objects.filter (book_title__istartswith = demande.get ['Q']) [: 100] Alors recommandez-vous Me Index + Memcached? Merci
Faites un index sur le Fist Trois lettres de titre (ou tout ce qui est le premier numéro que vous commencez à interroger la base de données) et il sera assez rapide.
Vous n'avez pas mentionné la base de données que vous utilisez. Certaines bases de données - comme MySQL et PostgreSQL - ont des paramètres extrêmement conservateurs hors-box, qui sont essentiellement inutilisables pour tout, sauf de petites bases de données sur de minuscules serveurs.
Si vous nous dites quelle base de données que vous utilisez et quel matériel il s'exécutent et si ce matériel est partagé avec d'autres applications (servant-t-il également l'application Web, par exemple), nous pourrons peut-être vous donner Quelques conseils de syntonisation spécifiques.
Par exemple, avec MySQL, vous aurez probablement besoin d'accorder les paramètres InnoDB; Pour PostgreSQL, vous devrez modifier Shared_buffers et un certain nombre d'autres paramètres.
4 millions n'est pas beaucoup, vous avez un cas d'optimisation prématurée.
La table est interrogée à partir d'Ajax à l'aide d'un champ autocomplete avec cette requête dans les vues.py: books.objects.filter (book_title__istartswith = request.get ['Q']) [: 100])
Si vous interrogez une table sur un champ de texte et des performances, vous pouvez choisir de mettre en œuvre une recherche en texte intégral. Cependant, la taille de votre champ interrogé est de 40 caractères seulement, et je ne suis pas sûr que cela pose un gros problème pour la DB.
Ce n'est pas la question que vous avez posée, mais vous pouvez trouver cela utile: Stackoverflow.com/Questtions/1566717/...