Comment concevez-vous un schéma pour interroger efficacement les éléments imbriqués dans une base de données clé-valeur?

Question

J'utilise Mnesia avec Erlang, mais cette question s'applique à toutes les bases de données de valeurs-clés telles que couchdb, etc.

J'essaie de me libérer du processus de pensée du SGBDR, mais je ne peux pas comprendre comment mettre en œuvre efficacement ce type de schéma.

Disons que j’ai un enregistrement d’utilisateur et qu’il possède de nombreux enregistrements SubItemA, qui ont de nombreux enregistrements du sous-élément B, donc:

User
-SubItem A
--SubItem B
...

Je dois exécuter des requêtes sur le sous-élément B. Est-il efficace de le faire lorsqu'il est ce niché? Devrais-je simplement normaliser pour que ce soit plus rapide?

J'ai entendu parler de personnes qui utilisaient la duplication de données pour que les données soient à la fois niché et séparé, est-ce ridicule ou est-ce vraiment utile dans certains cas?

Answer 1

La question sous-jacente est la suivante: quelle est la performance assez bonne ?

Le fait d’analyser le dictionnaire utilisateur sous forme de tableaux n’est pas une surcharge excessive si vous avez vraiment besoin d’examiner chaque sous-élément B de manière détaillée et que la taille des B domine celle du dictionnaire.

Si cela ne vous suffit pas, normalisez-le afin d'éviter de lire toutes les données utilisateur et sous-élément A lorsque vous interrogez le sous-élément B. Utilisez une clé composée telle que (UserId, SubItemAId, SubItemBId) dans le dictionnaire du sous-élément B si la table est ordonnée afin que vous puissiez effectuer des requêtes de plage.

Si cela tue totalement les performances de votre requête utilisateur / sous-élément A, considérez la duplication de données en dernier recours, car elle est plus sujette aux erreurs.

Answer 2

Dans CouchDb, il serait simple d’émettre des entrées de vue pour chacun des sous-éléments. Cela vous donnerait un accès très rapide à ces éléments. En fonction de ce que vous avez également mis dans les entrées de vue, vous pouvez probablement fournir les informations nécessaires pour relier des documents / sous-éléments parents.

Answer 3

Je ne suis pas sûr de Mnesia et je commence tout juste à utiliser CouchDB, mais si je comprends bien, dans CouchDB, comme vous générez vos propres index personnalisés ("vues"), vous pouvez facilement créer un index. sur ces sous-éléments.

Un exemple de fonction de carte:

function(doc) {
    for(var i in doc.subitems_a) {
        var subitem_a = doc.subitems_a[i];

        for(var j in doc.subitems_a[item_a].subitems_b) {
            var subitem_b = subitem_a.subitems_b[j];

            emit(subitem_b, doc)
        }
    }
}

Il s’agit en réalité d’une liste indexée de sous-éléments Bs. Vous pouvez ensuite couper et épisser cette liste à votre guise.

Answer 4

En fait, cela dépend de la base de données que vous utilisez, je pense. Dans CouchDB, une chose fonctionnera mieux tandis que dans Mnesia, quelque chose d’autres serait mieux. Devez-vous partitionner et partager les données? Sur quels critères devriez-vous le faire? Combien de duplication de données est suffisante?

Comme Jeffery Hantin l’a dit, il faudra quelques expériences et analyses pour trouver la bonne solution. Cela dit, la plupart des bases de données non relationnelles vous fournissent les outils nécessaires pour résoudre le problème. Votre partie détermine les compromis de chacun et le compromis que vous pouvez accepter par rapport aux autres.