was besser/schneller komplexe Couchbase-IDs oder Inline-Dokument type = "my_document_type"

Question

Meine aktuelle id Schlüssel von 3 oder 4 Segmenten enthält:

namespace::my_key::id 
namespace::my_key::my_second_key::id 

Lösung 1. Verwendung komplexer IDs und erstellen Ansichten von in-ID suchen für einen Schlüssel

function (doc, meta) { 

    if(meta.id.indexOf("::my_key::") !== -1){ 
    emit([doc.source_id], [doc.name,doc.title,doc.ui]); 
    } 


} 

Lösung 2. für jedes Dokument hinzufügen Felder wie „Art“, „Namensraum“ Und creat Ansichten sie

mit

function (doc, meta) { 

    if(doc.type=='my_key'){ 
    emit([doc.source_id], [doc.name,doc.title,doc.ui]); 
    } 


} 

Wenn i Lösung 2 wählen, Ich habe ids auf meiner Anwendung zu erhalten und wahrscheinlich werde ich wie in Lösung tun 1.

Hat jemand Erfahrung ids bei der Benennung und Erstellen von Ansichten von ihnen? welche Probleme hatten Sie mit jeder dieser Lösungen. Oder vielleicht indexOf() Funktion wird nicht empfohlen?

Answer 1

Couchbase erstellt den Anzeigeindex im Hintergrund. Wenn Sie also den Parameter stale=false nicht verwenden, erhalten Sie dieselbe Leistung beim Abrufen von Dokumenten aus der Ansicht in beiden Lösungen.

In der ersten Lösung können Sie wahrscheinlich Schlüssel mit mehr Länge als in der zweiten erhalten, denn in 2 Lösung können Sie schreiben, doc, nicht meta. Couchbase speichert alle Metadaten in Memeory, also längere Schlüssel, die Sie haben, mehr Speicher wird benötigt. Auch indexOf ist langsamer als == oder ===, so dass Bau Index mehr Zeit brauchen kann.

So wie für mich ist die zweite Lösung besser.

Sie können auch die Festplattennutzung Ihrer Ansichten verbessern, indem Sie nur emit(doc.source_id, null) emitieren und IncludeDocs in Ihrer Clientbibliothek verwenden. Es wird ihre Größe reduzieren und würde fast nicht die Leistung beeinträchtigen.

Hier ist auch eine link für "Best Practice". Vielleicht wird es auch helfen.

Answer 2

Ich verwende wie Ihre Lösung 1.

In meinem Fall (Social Game Backend-Server), Schlüsselnamen der gespeicherten Datentyp angibt, zB "Spieler: {zone_id}: {uid}", " playerchar: {zone_id}: {player_uid}: {char_id} "usw. Also habe ich kein Typfeld im Dokument hinzugefügt, weil die Anwendung weiß, was sie will, und für die Reflektion niemals Informationen aus dem Wertinhalt benötigen.

Über Leistung/Geschwindigkeit, sorry ich keinen Vorschlag geben könnte, ich habe keine Anforderung von Abfragedaten mit Aussicht, alle Ansichten habe ich funktioniert nur auf Entwicklung & Backup-Umgebung und Daten analysitic & Jobs Statistik läuft mit anderen System nicht auf Couchbase.