Pavel
64 это ведь считай потолок.
когда ты к такой разрядности подходишь - тебе начинает нехватать .
но надеяться на то что ты не подойдешь к 2^53 не будет достигнуто никогда - немного самонадеяно.
особенно когда нет полной уверенности - кто эти числа будет генерить.
особенно учитывая что могут быть просто адовейшие гапы в последовательности
Pavel
наверное можно написать тестик, и орать при подходе к этому числу....
Snusmumriken
Я прост в своё время прикручивал steamworks к love2d, а там местные айдишники 64-разрядные. Выгружал их в луа извращенскими способами то в виде строки, то в виде таблички с парой 32-битных чисел.
Serezha
Serezha
я думаю ни одна нормальная база не потянет твой кейс
Serezha
тупо на диске умрет
Serezha
одно дело фантазировать а другое попробовать сгенерить это все и записать
Serezha
там где дичайшие гапы и мега данные - там используют ну на худой конейц uuid
Serezha
опираться на 64 целое число это детский сад
Serezha
у нас в кибане генерится миллион событиый в минуту и вот так выглядит айди AWq7Ik2tUKiFnigYUD_X
Serezha
а вот так айди контейнеров в докерах 90ae5a3b62521c36f04e0dbf50a3110d75ac2e391cf3af226c4a43931de5ad45
Serezha
и такая хрень вехде где нужны уникальные распределенные идентификаторы
Pavel
не находишь?
Anonymous
Snusmumriken
Pavel
Serezha
Anonymous
Ребята, если вам не хватает диапазона инт64 то явно база у вас будет на ууидах
Snusmumriken
посмотри как в монге objectId генерится
Не в курсе как в монге, но лично у меня обычно или таймстамп приклеивается к guid'у, дабы по времени сортировать/фильтровать, или ещё как. Рандомности это не мешает, но можно сортировать.
А то и вовсе userid_timestamp_guid, шоб прям совсем круто.
Serezha
я как раз говорю что у тебя простой кейс и не надо сову на глобус тянуть
Anonymous
Ибо распределена
Serezha
не будет у тебя 2 64 айдишников
Anonymous
Индекс по уидам строится на отличненько
Anonymous
Послушайте сережу
Anonymous
Главное чтобы движок бд поддерживал тип хотя бы raw
Pavel
Saphire
Snusmumriken
А если у тебя в минуту сотни новых ид?
Ну и чего? Таймстамп тогда, содержащий секунды, в крайнем случае даже милисекунды. Всё подстраивается под нужды.
А потом такой: "Отобрать мне ляпкиных-тяпкиных с пятой наносекунды прошлого вторника по девятую".
Serezha
и чем created_at плох
Serezha
какие то надуманные кейсы
Serezha
uuid есть разные в том числе с опорой на счетчик времени как я помню
Pavel
ну же
Snusmumriken
Но в целом да, если в качестве айдишки использовать хотя бы условно 256-битное число (четыре 64-битных, условно), оно индексируется очень даже неплохо, и объём индексов мелкий. Строковые ключи круты, но слишком длинные слегка стрёмные и жручие. С третьей стороны, таймстамп с наносекундами сам по себе может быть гуидом.
Serezha
какие там айди я показал
Pavel
так в чем тогда кейс снуса надуман
Serezha
Snusmumriken
Ну у меня система логирования на работе, с милисекундами, которые шлются сотнями и тысячами в секунду в одну машину. И иногда надо вытащить все варнинги в определённом периоде, отсортированные точно по времени.
Serezha
а не вклеиваться в авйди
Serezha
и скейлится как видишь
Saphire
Serezha
Serezha
селект склный
Serezha
это не хайлоад
Snusmumriken
Ну тут не сиклюэль (и даже не nosql) и не совсем хайлоад, но это не важно : )
Serezha
ну по идее тарантул быстрее должен быть обычной базы
Serezha
иначе нах он ваще 🙂
Snusmumriken
Он быстрее уже потому что он in-memory. И основное направление у него в сторону сервера lua-приложений, оркестратора микросервисов со встроенной бд. Маленькие базы, работающие больше конфигом и кешем чем собсно "базой". Как редис но сложнее, в общем.
Anonymous
У него просто ключ типа как в берклидб - один на всю запись
Anonymous
Вот он все поля и складывет в первичный ключ
Serezha
Serezha
они должны быть разбиты на 1000 мелких баз
Serezha
и там 2 53 хватит
Snusmumriken
Ой всё. Ты вообще никогда не знаешь, когда тебе понадобятся 16384-битные числа.
Serezha
Serezha
бывает не усмотрел пока кофе варил и оппа на - айдишники в базе переполнились 64 битные и ты такой - ну вот никогда не было такого и вот опять
Serezha
новые записи пошли затирать старые
Snusmumriken
Кстати, ты знаешь почему guid называется guid'ом, и зачем тут "gu"?
Anonymous
Глобалли юник
Anonymous
Ууид юниверсалли юние
Anonymous
Я щас только догнал что этот ваш тарантул использует типы луа для ключей записей
Anonymous
Надо пробросить через луа тип гцц __инт128
Anonymous
И отложить спор на пару тысячелетий
Snusmumriken
Допустим у тебя миллиард мелких баз, кластер из тонны микросервисов, обслуживает толпу народа. Туда надо вносить уникальные фиговины, но не заставляя каждую машину в кластере голосить: "а сколько у вас уже записей? какой идентификатор ещё не занят? уже занят? простите? а вот этот ещё не занят? ну блин, я за сегодня получу хоть какой-нибудь айдишник?". Вот в таких случаях часто используются, как ни странно, гуиды.
Serezha
спасибо кэп
Snusmumriken
Всегда пожалуйста. Так вот, о чём это я.
Snusmumriken
2^52 это круто, но не совсем и не во всех случаях.
Serezha
ну пойнт был в том что ЕСЛИ ВАМ НЕ ХВАТАЕТ 2 52 - вам нужен юид
Serezha
2 в 64 никак не решает проблем
Anonymous
Можно деловским способом
Snusmumriken
Ааааа. Нормас, я как всегда влез и сел в лужу.
Но 64-разрядка тоже нужна время от времени, потому что потому. Я уже описал свои большие проблемы со стимом, где под юзеры и группы используются 64ULL.
Anonymous
Пришей сбоку рукав и сделай композитный ключ
Snusmumriken
Upper 32UL, lower 32UL. Сдвигать но не смешивать.
Anonymous
Так там же по итогу 64 битное чмсло
Anonymous
То есть 2 в 52
Anonymous
В стиме вашем
Snusmumriken
Так там же по итогу 64 битное чмсло
Не совсем, там оно таки unsigned long long, а у луёв мантисса. В результате примерно 1/8 айдишников (людей которые зарегистрировались условно до 2010 года) выгруженных как обычные lua_number — нормальные, а остальная часть представляется в виде лютого отрицательного, дробного или отрицательного дробного числа.
Anonymous
А, точно. Сорян