Konwencje nazewnictwa kluczy Redis?

226

Jaka jest normalna konwencja nazewnictwa dla kluczy w redis? Widziałem wartości oddzielone, :ale nie jestem pewien, jaka jest normalna konwencja i dlaczego.

Dla użytkownika zrobiłbyś coś takiego ...

user:00

jeśli identyfikator użytkownika to 00

Czy jesteś w stanie zapytać tylko o początek klucza, aby zwrócić wszystkich użytkowników?

Mam głównie nadzieję, że uniknę problemów w przyszłości, badając sposoby, które działają dla ludzi i dlaczego je wybrali.

redis naming-conventions

— fantazyjny
źródło

205

Jaka jest normalna konwencja nazewnictwa dla kluczy w redis? Widziałem wartości oddzielone przez: ale nie jestem pewien, jaka jest normalna konwencja i dlaczego.

Tak, znak dwukropka :jest konwencją przy nazywaniu kluczy. W tym samouczku na stronie redis podano: Spróbuj trzymać się schematu. Na przykład „object-type: id: field” może być dobrym pomysłem, jak w „user: 1000: password”. Lubię używać kropek w polach zawierających wiele słów, takich jak „komentarz: 1234: odpowiedź.to”.

Czy jesteś w stanie zapytać tylko o początek klucza, aby zwrócić wszystkich użytkowników?

Jeśli masz na myśli coś takiego, jak bezpośrednie zapytanie o wszystkie klucze, które zaczyna się od, user:istnieje do tego polecenie klucze . Polecenia tego należy jednak używać wyłącznie w celu debugowania, ponieważ jest ono O (N), ponieważ przeszukuje wszystkie klucze zapisane w bazie danych.

Bardziej odpowiednie rozwiązanie dla tego problemu jest stworzenie dedykowanego klucza, nazwijmy to users, w którym można przechowywać wszystkie klucze użytkowników, na przykład, w liście lub zadanej struktury danych.

— yojimbo87
źródło

1

scannie jest opcją @EranH., najlepszą praktyką jest iterowanie kluczy. scansłuży do stopniowego iterowania kolekcji elementów.

— Kishor Pawar

2

@ yojimbo87 Więc będą dwie komendy, powiedzmy najpierw, że kluczem jest - użytkownik: 808021: hasło = XYZ, a druga to wpisanie klucza do rejestru lub indeksu (zestawu), ale co się stanie, gdy jedno polecenie zostanie wykonane pomyślnie i inne ulegają awarii, oznacza to, że klucze zostały utworzone, ale nie uzyskano wpisu do rejestru.

— LoveToCode,

1

@LoveToCode Możesz użyć transakcji, która powinna zagwarantować, że wszystkie lub żadna z operacji nie zostanie wykonana.

— yojimbo87

2

Zauważyłem również, że Redis Desktop Manager (narzędzie klienta Redis) również traktuje dwukropek „:” jako separator i wyświetla zgrupowane klucze zgrupowane

— Adam Rotaru

1

Uważam, że ta wyjątkowa wartość będzie ostatnia. Ułatwia zrobienie czegoś takiego:$redis->delete($redis->keys('user:password:*'));

— Kredki

26

Używamy dwukropka (:) jako separatora przestrzeni nazw i skrótu (#) dla części identyfikacyjnych kluczy, np .:

logistics:building#23

— Paznokieć
źródło

Jaka jest najlepsza konwencja nazw, jeśli masz więcej kluczy, takich jak lokalizacja, kategoria itp.? {resource}: {key} # {value}, {key} # {value} => SMS-y: locale # en, kategoria # 15? Czy masz jakieś inne sugestie?

— fsasvari,

1

W moim przykładzie „budowanie” to tylko nazwa „kolekcji”, a 23 to niestandardowe „id”. Jeśli masz złożony identyfikator z ustawieniami narodowymi = en i kategoria = 15, wówczas rzeczywistym identyfikatorem może być {en, 15}, więc przestrzeń nazw: text # {en, 15} lub, mówiąc dokładniej: namespace: text # {locale = en, category = 15}. Ale to tylko pomysł, nigdy tak go nie użyłem. Uważaj, aby nie zmieniać kolejności elementów id, ponieważ klucz nie zostanie oczywiście znaleziony. W rzeczywistości zamiast kodowania takiej złożoności w nazwach kluczy, rozważ użycie zamiast tego struktur danych redis. Spójrz na redis.io/topics/indexes

— The Nail

16

Konwencja wydaje się być dwukropkiem (:), ale jestem programistą, więc osobiście wolę ukośnik (/) jako separator. Slash jest już tak ważnym separatorem w adresach URL, które mają być jednolitymi lokalizatorami zasobów, więc są kluczem do zasobów. Dlaczego warto stosować inne podejście do jelita grubego (:)? Czy to coś pomaga?

Rozważ ten przykład:

Mamy interfejs API RESTful dla obiektów zabawkowych. Jest jeden:

http://example.com/api/toy/234

Gdzie go przechowujemy? Używamy Redis i ukośników, więc klucz jest oczywisty:

toy/234

To unikalny klucz do zabawki. Klucza można teraz używać także po stronie klienta:

{
    key: "toy/234",
    color: "red",
    url: function () {
        return API_BASE_URL + this.key;
    }
}

Użytkownik żąda obiektu z kluczem toy/666. Jak zdobyć od Redis? Przykład związany z Node.js:

redis.get(key, function reply_callback(error, toystring) {
    var toy = JSON.parse(toystring);
    ...
}

Nie trzeba konwertować ukośników na dwukropki i odwrotnie. Wygodne, nie sądzisz?

Uwaga: zawsze upewnij się, że użytkownik może uzyskać dostęp tylko do tego, co zamierzyłeś. Podane powyżej surowe podejście URL-to-key jest również w stanie pobrać user/1/password, jak zauważyli komentatorzy. Nie powinno to stanowić problemu, jeśli używasz Redis jako publicznej pamięci podręcznej tylko do odczytu.

— Akseli Palén
źródło

24

… Wygodne i niemal obrzydliwie niepewne. Błagasz o zdobycie curl http://example.com/api/user/1/passwordlub podobne. (Tylko

— mówię

3

Dwukropki, skróty i ukośniki mogą być używane do oznaczania różnych poziomów zagnieżdżenia, np.User#23:uploads:my/path/to/file.ext

— wcielony

31

Proszę nigdy nie brać danych wejściowych użytkownika jako klucza do bazy danych.

— Lyle,

1

Podoba mi się to, jak myślałeś, że wolisz ukośniki, ponieważ jesteś programistą.

— Hector Ordonez

@ELLIOTTCABLE Dzięki, dodano notatkę o niepewności. Czy widzisz jakiś problem w tym podejściu, jeśli Redis jest używany jako publiczna pamięć podręczna tylko do odczytu?

— Akseli Palén

6

Nie wiem, czy naprawdę istnieją jeszcze szeroko rozpowszechnione „najlepsze praktyki” dotyczące nazewnictwa kluczy Redis.

Eksperymentowałem z użyciem znaków ASCII NUL jako moich separatorów (ponieważ Redis i Python są czyste 8-bitowo). Wygląda trochę brzydko, jeśli patrzysz na surowe klucze, ale pomysł polega na tym, aby ukryć je za warstwą abstrakcji. Symbole dwukropka i potoku są oczywistymi alternatywami, pod warunkiem, że elementy przestrzeni nazw albo nie będą z nich korzystać, albo będziesz chciał zakodować każdy element w razie potrzeby. Jednakże, jeśli chcesz je kodować, to chciałbyś rozwinąć warstwę abstrakcji i unikając przeglądania surowych kluczy ... co wróciło mnie do korzystania z \ 0 w moim rozumowaniu.

Będę ciekawy, czy zostaną wyrażone jakieś inne opinie na ten temat.

— Jim Dennis
źródło

0

Wydaje mi się, że dla twojego przypadku lepiej byłoby zastosować HSET / HGET . Istnieje również polecenie HKEYS .

Wszystkie te polecenia mają taką samą złożoność jak GET / SET / KEYS, więc dlaczego ich nie użyć?

Możesz mieć następującą strukturę:

użytkownicy> 00> wartość
użytkownicy> 01> wartość

lub:

users: nazwa użytkownika> 00> wartość
users: nazwa użytkownika> 01> wartość

Wystarczy wyodrębnić identyfikator użytkownika i użyć go jako klucza skrótu. Osobiście wolę to podejście, ponieważ jest przyjemniejsze, a także możesz łatwo wyszukiwać istniejące identyfikatory użytkowników.

— in vitro
źródło