co lepsze/szybsze kompleks ID couchbase lub dokument, inline type = "my_document_type"

Question

Moje obecne klucze id zawiera od 3 lub 4 segmenty:

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

Rozwiązanie 1. wykorzystują złożone id i utworzyć widoki wyszukując w identyfikatorze za kluczowy

function (doc, meta) { 

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


} 

Rozwiązanie 2. dla każdego dokumentu dodać pola takie jak „rodzaj”, „nazw” I cREAT poglądów użyciu im

function (doc, meta) { 

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


} 

jeśli wybiorę Rozwiązanie 2, muszę utrzymać id jest na mojej aplikacji i prawdopodobnie zrobię jak w roztworze 1.

Czy ktoś ma doświadczenie w zakresie nazewnictwa identyfikatorów oraz tworzenia widoków z nich? jakie problemy masz z każdym z tych rozwiązań. A może funkcja indexOf() nie jest zalecana?

Answer 1

Couchbase tworzy indeks widoku w tle, więc jeśli nie użyjesz parametru stale=false, uzyskasz taką samą wydajność podczas pobierania dokumentów z widoku w obu rozwiązaniach.

W pierwszym rozwiązaniu prawdopodobnie można uzyskać klucze o większej długości niż w drugim, ponieważ w 2 rozwiązaniach można dodać polecenie doc, a nie meta. Couchbase przechowuje wszystkie metadane w pamięci, więc dłuższe klawisze, potrzeba więcej pamięci. Również indexOf jest wolniejsze niż == lub ===, więc tworzenie indeksu może zająć więcej czasu.

Tak jak dla mnie drugie rozwiązanie jest lepsze.

Możesz również poprawić wykorzystanie dysku w swoich widokach, wykorzystując tylko emit(doc.source_id, null) i użyć IncludeDocs w bibliotece klienta. Zmniejszy to ich rozmiar i prawie nie wpłynie na wydajność.

Tutaj jest również link dla "najlepszej praktyki". Może to również pomoże.

Answer 2

używam jak rozwiązania 1.

w moim przypadku (gra społecznościowa serwera backend), nazwa wskazuje klucz zapisany typ danych, na przykład, „zawodnik: {id_strefy} {UID}”, " playerchar: {zone_id}: {player_uid}: {char_id} "itd. Tak więc nie dodałem pola typu w dokumencie, ponieważ aplikacja wie, czego chce, nigdy nie potrzebuje informacji z wartościowej zawartości do refleksji.

o wydajność/szybkość, przepraszam, że nie może dać żadnych sugestii, nie mam obowiązku danych kwerendy z widzenia, wszystkie widoki I utworzone działa tylko na rozwój & zapasowej środowiska, a dane analysitic & wyprzedzeń pracy biegnie z drugiej system nie na Couchbase.