Wie gestalten Sie ein Schema, um effizient verschachtelte Elemente in einer Schlüssel-Wert-Datenbank abfragen?

Question

Ich verwende Mnesia mit Erlang, aber diese Frage gilt für jeden Schlüsselwert db wie CouchDB, etc.

Ich versuche, frei von dem RDBMS Denkprozess zu brechen, aber ich kann nicht wickeln meinen Kopf herum, wie effizient diese Art von Schema zu implementieren.

Sagen, dass ich einen Benutzerdatensatz haben, und er viele SubItemA Aufzeichnungen hat, die hat viele SubItem B Aufzeichnungen, so:

User
-SubItem A
--SubItem B
...

Ich muss Abfragen auf SubItem B. laufen Ist es effizient, es zu tun, wenn es diese verschachtelt? Soll ich es nur normalisieren, so wird es schneller sein?

Ich habe von einigen Leuten gehört, Vervielfältigung unter Verwendung von Daten, so dass die Daten sowohl sind verschachtelte und getrennt, das ist lächerlich oder ist das tatsächlich nützlich in manche Fälle?

Answer 1

Die zugrunde liegende Frage ist, wann ist die Leistung gut genug

Table-Scannen des Wörterbuch Benutzer nicht übermäßig Overhead, wenn Sie wirklich jeder SubItem B im Detail und die Größe der B die Gesamtgröße des Wörterbuchs zu untersuchen, brauchen vorherrscht.

Wenn das nicht gut genug ist, normalisieren es so können Sie vermeiden, in all dem Nutzer und SubItem Datenlese- vorne, wenn Sie SubItem B. Verwendung einer Verbindung Schlüssel wie (UserId, SubItemAId, SubItemBId) sind Abfragen in die SubItem B Wörterbuch, wenn der Tisch bestellt ist, so dass Sie Bereichsabfragen tun können.

Wenn das völlig Ihren Benutzer tötet / SubItem Eine Abfrage-Leistung, dann Datenduplizierung als letztes Mittel betrachtet werden, da es mehr fehleranfällig.

Answer 2

In CouchDB wäre es trivial sein Blick Einträge für jeden der SubItems zu emittieren. Dies würde Sie sehr schnellen Zugriff auf diese Elemente geben. Je nachdem, was Sie auch in der Sicht Einträge setzen könnten Sie bieten wahrscheinlich alle Informationen, die Sie benötigen für die Verbindung zurück zur Stammdokumente / Unterpunkte.

Answer 3

Ich bin über Mnesia nicht sicher, und ich bin gerade erst mit CouchDB die ersten Schritte, aber mein Verständnis ist, dass in CouchDB, da Sie Ihre eigenen benutzerdefinierten Indizes ( „Views“) erzeugen, können Sie ohne weiteres einen Index aufbauen diese Unterpunkte.

Ein Beispiel Kartenfunktion:

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)
        }
    }
}

Das ist effektiv eine indizierte Auflistung der SubItem Bs und dann könnten Sie schneiden und aus dieser Auflistung splice wie Sie wählen.

Answer 4

Eigentlich hängt es von der Datenbank, die Sie verwenden, denke ich. In CouchDB wird eine Sache besser arbeiten, während in Mnesia etwas anderes wäre besser. Sollten Sie die Daten partitionieren und Scherbe? Nach welchen Kriterien sollten Sie das tun? Wie viel Datenduplizierung ist genug?

Als Jeffery Hantin sagte es einige Experimente und Analysen dauern wird, die richtige Lösung herauszufinden. Das sagte die meisten der nicht-relationalen Datenbanken da, um Sie bieten die Werkzeuge, müssen Sie das Problem lösen. Ihr Teil ist, herauszufinden, die Kompromisse von jedem und dem Abwägen Sie im Vergleich zu den anderen akzeptieren können.