Analiza ObjectId z żądania nie byłaby trudna (więc nie jestem pewien, dlaczego to jest problem?). Jeśli celem jest tworzenie adresów URL dających się pisać, warto mieć krótszy i „bardziej przyjazny” adres URL.
Nie możesz wziąć 12-bajtowej liczby, która jest gwarantowana jako unikalna w konfiguracji sharded MongoDB i skondensować ją do mniej niż 12 bajtów, aby była gwarantowana jako unikalna (na przykład wspomniałeś poniżej siedmiu znaków).
Z dokumentacji , obiekt MongoDB ObjectId składa się z:
- czterobajtowy znacznik czasu
- 3-bajtowy identyfikator maszyny
- dwubajtowy identyfikator procesu
- i 3-bajtowy licznik.
Tak więc albo będziesz musiał poświęcić część identyfikatora ObjectId (a tym samym sharding), albo opracować alternatywny format tworzenia identyfikatora, który jest indeksowany.
Chociaż możesz potencjalnie zahaszować identyfikator, ponownie mogą pojawić się konflikty, dla których chciałbyś kodować (ponownie, nie możesz skrócić 12 bajtów do 4 bajtów i zagwarantować unikalności). A jeśli są możliwe konflikty (a wystąpią, jeśli zmniejszysz całkowitą liczbę dostępnych bitów), i tak będziesz potrzebować jakiejś tabeli pomocniczej (i musisz utworzyć indeks, aby przejść z wygenerowanego identyfikatora do ObjectId) .
Wynikowe opcje:
- Usuń zwykle znaczące bity — jeśli to zrobisz, nie podziel kolekcję
- Stwórz własne, unikalne rozwiązanie ID (a jeśli jest na farmie internetowej, może wyglądać bardzo podobnie do MongoDB, aby poradzić sobie z unikalnością)
- użyj ObjectId jako długiej liczby i uruchom na nim skrócony algorytm (będzie musiał zostać najpierw rozbity na mniejsze części, ponieważ przekracza precyzję numeryczną JavaScript wynoszącą 53 bity), wypróbuj ten algorytm na przykład =kodować to (będzie miał około 17 znaków)
- użyj czegoś krótszego, ale unikalnego jako identyfikator dla swoich dokumentów
- Najłatwiej:po prostu zaakceptuj, że identyfikatory są długie. :)
(Nie jest jasne, dlaczego przeglądarka musiałaby wykonać tę konwersję — dlaczego miałaby mieć identyfikator ObjectID dokumentu?)
