[mrkobel]

Szukam generatora id w ptython, najlepiej int64. Nie chcę UUID4.

Poleci ktoś, coś?
#python #programista15k

[p.....k]

@mrkobel: czemu nie uuid, czemu nie zwykły autoincrement? Tyle pytań żadnych odpowiedzi ( ͡° ͜ʖ ͡°)

[L.....k]

@mrkobel: a wrzuć zapytanie to w google

[zarev]

@powaznyczlowiek: nie uuid bo chce miec ladne IDki w urlach ( ͡° ͜ʖ ͡°)

[p.....k]

@zarev: kiedy uuid jest piękny właśnie 乁(♥ ʖ̯♥)ㄏ

[mrkobel]

@powaznyczlowiek: masz autoicrement w Cosmodb?
Bo chce int64. Skalowalne apki. Jedynie ciekawy id to snowflake z Twittera, ale nie ma żadnej sensownej implementacji w pythonie bez błędów.
@Lunatik: Jak nie masz nic ciekawego do powiedzenia to nie wypowiadaj się.

[zarev]

@mrkobel:
1. Jaka skala?
2. Jaki rodzaj indeksu uzywasz?

[p.....k]

@mrkobel: no dobra, a jest jakiś powód dla którego nie możesz sam tego autoincrementa w pythonie napisać synchronicznego? Ew skorzystać z timestampa (ns) - mieści się w zakresie. Z tego co czytam jest w Cosmo unique więc powinieneś być w stanie zrobić retry jakby jakimś cudem się id powtórzyły

[zarev]

@powaznyczlowiek: synchroniczny autoincrement to fatalna praktyka, zarowno wielowatkowosc jak i skalowanie powyzej jedna instancje przyniesie mase problemow

[p.....k]

@zarev: jakich konkretnie? ( ͡º ͜ʖ͡º) normalnie robisz strzał do synchronicznego komponentu znajdującego się na tym samym klastrze i...?

[zarev]

@powaznyczlowiek: i walisz locka zeby upewnic sie ze zaden inny request nie swisnie Twojego ID sprzed nosa, a pozostale requesty grzecznie czekaja na swoja kolej (⌐ ͡■ ͜ʖ ͡■)

[zibizz1]

@zarev: Zależy, jeśli ustalimy limit na 10/s to możemy robić synchroniczne numeryczne ID. To jest naprawdę spora wartość dla użytkowników i warto im dać możliwość korzystać z tego jeśli to tylko możliwe

[p.....k]

@zarev: ile twoim zdaniem trwa operacja zwiększenia i zwrócenia liczby? ( ͡° ͜ʖ ͡°) co to znaczy "czekają"?

[zarev]

@powaznyczlowiek: Incrementacja musi byc thread-safe, wiec zeby kazdy watek musi zlockowac access do danego resource a wszystkie inne beda musialy czekac az lock zostanie zdjety. Swoja droga jezeli jego DB nie wspiera autoincrementa to jak i gdzie Twoj synchroniczny komponent bedzie przechowywal stan? W bazie danych? ( ͡° ͜ʖ ͡°)

@zibizz1: Pewnie, dla mniejszej ilosci requestow nie ma to znaczenia, tak samo jak nie musisz uzywac

[zibizz1]

@zarev: Ale można używać skalowalnego rozwiązania i mieć licznik numeryczny. Bazy NoSQL wspierają transakcje, każdy dokument ma jeden punkt zapisu. Wrzucamy licznik do jednego dokumentu, robimy transakcje na nim i z głowy Tak jak powiedziałem jedyny warunek który trzeba określić to 10/s.

@mrkobel: wrzuć licznik do jednego dokumentu i transakcyjnie go podbijaj. Jak już chcesz używać numerka to żeby skorzystać z wszystkich jego zalet powinien rosnąć a nie być losowy.

[p.....k]

@zarev: w pamięci i na starcie będzie pobierał najwyższe id z cosmosa ¯\_(ツ)_/¯ jeżeli operacji zapisu jest aż tak dużo, że to co opisujesz powoduje problem to można pobierać cały batch idkow i cacheowac je po stronie klienta (tak robi Hibernate np)

[mrkobel]

@zibizz1: @powaznyczlowiek: @zarev:
Odpisze globalnie, założenia. Apke piszę w tej chwili jako SAS z Cosmo, ale całkiem możliwe, ze będę wchodził on prem i będę dopisywał repozytorium na postgresa lub inna bazę.
Z założeń zależy mi na losowej wartości (zapisuje pliki pod tym id, ukryta liczba elementów) na int, ze względu ze niektóre bazy lepiej pracują z int jako indeks.

Skala? Na ten moment pewnie do 10 tys rekordów

[mrkobel]

Ale coś widzę, ze nic nie znajdę na int64. Zostaje chyba UUID, ale tam jest int128 (╯︵╰,)

[p.....k]

@mrkobel: przy 3RPS i zamiarach na przepisanie repozytorium to możesz nawet olać to skalowanie i zrobić zwykły licznik ¯\_(ツ)_/¯

[mrkobel]

@powaznyczlowiek: nie jest to takie proste ;) to jest tylko input reqestow z zadaniami. Dochodzi czas na wrzucenie plików, inne reqesty i mikroserwisy które przetwarzają pliki od kilku minut do kilku h.

[p.....k]

@mrkobel: w porządku, ale i tak próbuje powiedzieć że to co robisz to premature optimization - nie możesz przy takich założeniach jak masz teraz myśleć o przyszłych bazach danych, które lepiej pracują z intami, i na siłę wpychać to rozwiązanie w silnik, którego zamierzasz używać teraz

Użyj UUID a jak się będziesz migrował do innej bazy danych to sobie napiszesz skrypt migracyjny i przepiszesz te uuidy na inty