Pavel
64 это ведь считай потолок. когда ты к такой разрядности подходишь - тебе начинает нехватать . но надеяться на то что ты не подойдешь к 2^53 не будет достигнуто никогда - немного самонадеяно. особенно когда нет полной уверенности - кто эти числа будет генерить. особенно учитывая что могут быть просто адовейшие гапы в последовательности
Pavel
наверное можно написать тестик, и орать при подходе к этому числу....
Snusmumriken
Я прост в своё время прикручивал steamworks к love2d, а там местные айдишники 64-разрядные. Выгружал их в луа извращенскими способами то в виде строки, то в виде таблички с парой 32-битных чисел.
Serezha
я думаю ни одна нормальная база не потянет твой кейс
Serezha
тупо на диске умрет
Serezha
одно дело фантазировать а другое попробовать сгенерить это все и записать
Serezha
там где дичайшие гапы и мега данные - там используют ну на худой конейц uuid
Serezha
опираться на 64 целое число это детский сад
Serezha
у нас в кибане генерится миллион событиый в минуту и вот так выглядит айди AWq7Ik2tUKiFnigYUD_X
Serezha
а вот так айди контейнеров в докерах 90ae5a3b62521c36f04e0dbf50a3110d75ac2e391cf3af226c4a43931de5ad45
Serezha
и такая хрень вехде где нужны уникальные распределенные идентификаторы
Pavel
а вот так айди контейнеров в докерах 90ae5a3b62521c36f04e0dbf50a3110d75ac2e391cf3af226c4a43931de5ad45
хранить такие строки, и строить по ним инжекс, кажется таки менее эффективно, чем int64 использовать
Pavel
не находишь?
Snusmumriken
и такая хрень вехде где нужны уникальные распределенные идентификаторы
Подклеивать первыми восемью символами дату создания.
Pavel
Serezha
хранить такие строки, и строить по ним инжекс, кажется таки менее эффективно, чем int64 использовать
ну придумайте что то новое мировая теория распределенных массивных систем скажет вам спасибо
Anonymous
Ребята, если вам не хватает диапазона инт64 то явно база у вас будет на ууидах
Snusmumriken
посмотри как в монге objectId генерится
Не в курсе как в монге, но лично у меня обычно или таймстамп приклеивается к guid'у, дабы по времени сортировать/фильтровать, или ещё как. Рандомности это не мешает, но можно сортировать. А то и вовсе userid_timestamp_guid, шоб прям совсем круто.
Serezha
я как раз говорю что у тебя простой кейс и не надо сову на глобус тянуть
Anonymous
Ибо распределена
Serezha
не будет у тебя 2 64 айдишников
Anonymous
Индекс по уидам строится на отличненько
Anonymous
Послушайте сережу
Anonymous
Главное чтобы движок бд поддерживал тип хотя бы raw
Saphire
Подклеивать первыми восемью символами дату создания.
А если у тебя в минуту сотни новых ид?
Snusmumriken
А если у тебя в минуту сотни новых ид?
Ну и чего? Таймстамп тогда, содержащий секунды, в крайнем случае даже милисекунды. Всё подстраивается под нужды. А потом такой: "Отобрать мне ляпкиных-тяпкиных с пятой наносекунды прошлого вторника по девятую".
Serezha
и чем created_at плох
Serezha
какие то надуманные кейсы
Serezha
uuid есть разные в том числе с опорой на счетчик времени как я помню
Pavel
какие то надуманные кейсы
посмотри rtb биржи. они по микросекундам ищат
Pavel
ну же
Snusmumriken
Но в целом да, если в качестве айдишки использовать хотя бы условно 256-битное число (четыре 64-битных, условно), оно индексируется очень даже неплохо, и объём индексов мелкий. Строковые ключи круты, но слишком длинные слегка стрёмные и жручие. С третьей стороны, таймстамп с наносекундами сам по себе может быть гуидом.
Serezha
посмотри rtb биржи. они по микросекундам ищат
яж тебе говорю у еня перед глазами система 1М событий в минуту с риал тайм поиском по ней
Serezha
какие там айди я показал
Pavel
так в чем тогда кейс снуса надуман
Serezha
так в чем тогда кейс снуса надуман
тем что время лежит в @timestamp
Snusmumriken
Ну у меня система логирования на работе, с милисекундами, которые шлются сотнями и тысячами в секунду в одну машину. И иногда надо вытащить все варнинги в определённом периоде, отсортированные точно по времени.
Serezha
а не вклеиваться в авйди
Serezha
и скейлится как видишь
Serezha
селект склный
Serezha
это не хайлоад
Snusmumriken
Ну тут не сиклюэль (и даже не nosql) и не совсем хайлоад, но это не важно : )
Serezha
ну по идее тарантул быстрее должен быть обычной базы
Serezha
иначе нах он ваще 🙂
Snusmumriken
Он быстрее уже потому что он in-memory. И основное направление у него в сторону сервера lua-приложений, оркестратора микросервисов со встроенной бд. Маленькие базы, работающие больше конфигом и кешем чем собсно "базой". Как редис но сложнее, в общем.
Anonymous
У него просто ключ типа как в берклидб - один на всю запись
Anonymous
Вот он все поля и складывет в первичный ключ
Serezha
они должны быть разбиты на 1000 мелких баз
Serezha
и там 2 53 хватит
Snusmumriken
Ой всё. Ты вообще никогда не знаешь, когда тебе понадобятся 16384-битные числа.
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
А, точно. Сорян