J'utilise Ruby on Rails et je me demande s'il est approprié d'utiliser une sorte de magasin de valeurs clés au lieu de MySQL. J'ai des utilisateurs qui ont beaucoup de listes et chaque liste a beaucoup de mots. Certaines listes ont des centaines de mots et je veux que les utilisateurs puissent copier une liste. C'est une lourde tâche MySQL b/c il va falloir créer ces centaines d'objets à la fois. Comme alternative, je considère l'utilisation d'une sorte de magasin de valeur de clé où la clé serait juste le mot. Une liste de mots pourrait être stockée dans un champ de texte dans mysql. Chaque liste pourrait être une nouvelle valeur clé db? Il semble que ce serait plus rapide de copier une valeur de clé db de cette façon plutôt que d'avoir à passer par la base de données. Il semble également que cela pourrait être plus rapide en général. Pensées?Utilisation de plusieurs magasins de valeurs clés
Répondre
La manière générale de résoudre ceci en utilisant une base de données relationnelle serait d'avoir une table de liste, une table de mots, et une table de mots de table reliant les deux. Vous avez raison de dire qu'il y aurait des frais généraux, mais ne les surestimez pas; Étant donné que la structure de la table est définie, il y a très peu de temps de stockage réel pour chaque enregistrement et les enregistrements peuvent être insérés très rapidement.
Si vous voulez des copies très rapides, vous pouvez autoriser la copie des listes en écriture. Cela signifie qu'une seule liste peut être référencée par plusieurs utilisateurs, ou plusieurs fois par le même utilisateur. Vous ne dupliquez réellement la liste que lorsque l'utilisateur tente d'ajouter, de supprimer ou de modifier une entrée. Bien sûr, c'est une optimisation prématurée, commencez simplement et ajoutez seulement des complications comme celle-ci si vous trouvez qu'elles sont nécessaires.
Vous pouvez utiliser un magasin de valeurs-clés comme vous le suggérez. J'éviterais d'essayer d'en construire un au dessus d'un champ de texte MySQL en moins vous avez une très bonne raison, cela rendra toute recherche par clé très lente, car cela nécessiterait une recherche de chaîne. Un magasin de données à valeur-clé comme CouchDB ou Tokyo Cabinet pourrait le faire très bien, mais il prendrait probablement plus de place (chaque enregistrement devant avoir sa propre structure définie et chaque mot devant être enregistré séparément dans chaque liste). La seule dimension de performance que je pense serait mieux si vous avez besoin de lectures et d'écritures massivement extensibles, mais cela n'est pertinent que pour le plus grand des systèmes.
J'utiliserais MySQL avec naïveté, et je n'apporterais des changements comme celui-ci que si vous avez besoin des performances et que vous pouvez prouver que cette méthode sera réellement plus rapide.
Merci beaucoup Zach. C'est très instructif. Je me demande, pourquoi est-il préférable d'utiliser un tableau de listes de mots? Pourquoi ne pas simplement mettre un list_id dans chaque objet word, puis has_many: mots dans List? – TenJack
Une deuxième question: je supposais que l'utilisation de regex sur une chaîne serait plus rapide qu'une requête db. Par exemple, je pourrais utiliser gsub pour trouver et supprimer un mot en remplaçant le mot par une chaîne vide. Est-ce que ce n'est pas une hypothèse valide? – TenJack
@TenJack - À votre première question: Je supposais qu'il y a un nombre limité de mots, comme dans un système d'étiquette. Bien sûr, comme il n'y a que très peu de mots dans une langue, le nombre de mots est limité. S'il y a moins de mots que d'entrées de liste et/ou si vous souhaitez indexer ou interroger par mot, utilisez une table de mots-listes. S'il y a très peu de mots communs entre les listes, alors un nombre de un-à-un irait bien. –