Traitement d'un grand ensemble d'objets ActiveRecord en tant que données binaires

Question

J'ai un problème avec la manipulation d'un grand nombre d'objets d'enregistrement de type type ActiveRecord (les enregistrements sont extraits d'une opération complexe mais de la même table) et je veux passer cet objet entre actions du contrôleur. J'ai donc quelques solutions, mais je ne sais pas trop comment choisir. Une solution plus simple mais plus laide est de l'enregistrer dans les sessions. Mais comme je sais que l'enregistrement d'un grand ensemble d'objets dans les sessions ralentit clairement les performances des applications en raison du processus de sérialisation et de sérialisation fréquent (la sérialisation prend du temps, je suppose des services Web - SOAP et formatage binaire). La deuxième option qui semble prometteuse est de sauvegarder tous ces objets de modèle ActiveRecord en tant que blog dans la base de données, et avec une requête, nous pouvons tout récupérer et faire les opérations nécessaires avec cet ensemble de données. Mais je ne sais pas comment parcourir tous les objets après l'avoir récupéré de la base de données car il est toujours au format objet binaire. La méthode d'inspection des appels affiche tous les attributs et les valeurs, mais je suis totalement perplexe. Quelqu'un peut-il me dire comment enregistrer les objets de type modèle ActiveRecord en tant qu'objet binaire d'enregistrement unique et le récupérer et passer par l'ensemble de données. Ai-je besoin d'encodage comme Base64? Enfin, memcached produirait le résultat souhaité? ou au moins les liens qui peuvent suivre pour résoudre cela?

Et désolé pour la longue question et merci d'avance.

Answer 1

La réponse, et je déteste dire ceci, est que probablement la méthode est défectueuse. Cela va-t-il prendre plus de temps pour interroger à nouveau ces données exactes ou pour charger une ligne BLOB et la désérialiser? Je suppose que cela prend à peu près le même temps sans index, mais avec des index, vous pouvez obtenir votre ensemble de résultats de la base de données plus rapidement que même chargé le BLOB sans même l'appel unserialize. Maintenant peut-être que je me trompe à ce sujet, mais certainement la quantité de données qui reviennent est à peu près la même, donc une grande partie du temps de la base de données est exactement la même chose.

Memcached certainement se révéler utile ici mais de la même manière que le cache de requêtes (vous utilisez MySQL en supposant) serait utile. Les requêtes répétées pour la même chose doivent être renvoyées au laser rapidement par l'une ou l'autre méthode en supposant que le cache dans l'un ou l'autre cas est assez grand pour s'adapter à l'objet.

Mais vous avez raison de dire que stocker dans la session est un mauvais moyen et BLOB est probablement aussi au mieux à peu près la même chose que de simplement refaire la requête et de laisser le cache de requête le renvoyer.

Mais juste pour couvrir toutes les bases, la taille est le jeu de données totale vs combien REVIENT et combien de temps vous voyez les requêtes prennent? Je suppose que ce post est vraiment sur la performance, mais il est assombri par les détails de mise en œuvre.