И цпу жрет на это. Не ?

жрёт

а это то, что тебя волнует? :)

Ну а как же полировка торпеды ?

нет.

Нет всетаки bytea годен. Можнохранить в качестве первичного ключа куски тру рандома по 16 байт. Это будет занимать по 17 байт на ячейку

А чо бы и нет

Надо забенчить

тру рандом не принимает мер к неповторению, в отличие от ууида

Ахахахаа. Ржал как конь

И как ууид устраняет нерандомность ?

https://en.wikipedia.org/wiki/Universally_unique_identifier#RFC_4122_variant

неповторение, а не нерандомность

UUID с точки зрения безопасности, если ид светится наружу

неповторение, а не нерандомность

Штэ. Назови этот способ

Штэ. Назови этот способ

я же ссылку скинул. там вполне себе 5 вариантов генерации ууидов под разные задачи

Ну а чем тебе /dev/urandom не устраивает ?

Нафиг его еще кодировать в чото

я же ссылку скинул. там вполне себе 5 вариантов генерации ууидов под разные задачи

Кароче каждый нод типэ использует свой фиксированный префикс к рандому.

Там они перемудрили с этим ууид. Реально. Меряются чей рандом рандомнее. Тогда как есть достаточно рандомный даже для криптографии рандом.

Хренью страдают. В любом случае как и просто рандом, ууид может случайно повториться. О чем педивикия и говорит

Марк, обрисую вариант. Есть у тебя таблица... Порциями данные из неё выгружаются на мобильные клиентам... Клиенты могут их менять, добавлять новые, удалять.... А потом через какое то время сливать все назад. Тогда ни префиксы, ни рандомы тебе не помогут. Только uuid.

Это не страдание хренью, а сложный академический вопрос. В системах с миллиардами объектов рандом очень даже может повторяться, т.к. из-за плохой реализации генераторов пространство рандома сильно сужается.

Это не страдание хренью, а сложный академический вопрос. В системах с миллиардами объектов рандом очень даже может повторяться, т.к. из-за плохой реализации генераторов пространство рандома сильно сужается.

Тогда тебе ничего непоможет. Ууид тоже на рандомах

тут_уже_ничего_не_исправить_господь_жги.jpg

Тогда тебе ничего непоможет. Ууид тоже на рандомах

нет. в нём есть мак и таймстемп, временами :)

с маками, правда, проблема с последних времён виртуализации

нет. в нём есть мак и таймстемп, временами :)

Маки повторяются. А время синхронизировано как правило

Витоге всеравно просто рандом.

повторением маков ты можешь управлять, в отличие от повторения рандома

Штэ

У нормальных рандомов есть куча способов пополнения энтропии. См линукс

Например гит кладет болт на коллизию хешей

Ну и если когото прет - ну юзай свой префикс на каждом клеенте и шмат рандома

Марк, пример из реальной жизни. Есть soap сервис. Клиенты шлют запросы. Запросы складываются в БД. Как уникально идентифицировать запрос? Когда генерация уникальных значений производится не на 1м сервере (и даже не на фиксированом их количестве)... никакое повышение энтропии рэндома не поможет. А в алгоритмы генерации uuid уже заложены в большей или меньшей степени способы повышения энтропии

Вот эта вот святая вера что в ууид есть какието магические средства просто смешит

в общем, есть industry standard путь решения всех этих проблем, возникающих от использования рандома в лоб. пользуйтесь им как black box, если не хотите разбираться. если будете переимплеменчивать его руками, то можете переизобрести его заново, решая те же самые проблемы, или просто ловя их в продакшене. если хотите разобраться, что за проблемы решаются - почитайте стандарт, там они вполне указаны.

Там нет магии - там есть конкретные алгоритмы

Uuid - это всего лишь представления рэндомов

нет. uuid - стандарт идентификаторов. задача идентификации не идентична задаче рандома.

Именно. И есть весьма годный рандом. /dev/urandom. Без энтропийных приколов никак его самому не сделать

Поэтому и в ууидной либе ничего сделать нельзя такого особого и надежного.

Сетевок может не быть. Они могут быть виртуальными и тд

Недоступными для чтения мака и пр.

uuid можно получить из данных

10 goto 10

и идентифицировать иммутабельную запись по ней самой

что очень хорошо, например, для распределённого поиска дубликатов

О чем я и говорю. Если есть рандом нормальный то его напрямую в постгресе и надо использовать. А если нет -- то никакой ууид не спасет.

О чем я и говорю. Если есть рандом нормальный то его напрямую в постгресе и надо использовать. А если нет -- то никакой ууид не спасет.

простите, вы не следите за моими доводами, я более не продолжаю диалог с вами.

Uuid - несколько рэндомов. Тут важен алгоритм их склейки

Uuid - несколько рэндомов. Тут важен алгоритм их склейки

не рандомов же. значений. среди которых может быть, а может не быть рандом, в зависимости от алгоритма генерации. и алгоритм генерации конкретного ууида указывается в нём самом, потому что в нём есть заголовки.

ознакомьтесь же с https://tools.ietf.org/html/rfc4122 в конце концов

не рандомов же. значений. среди которых может быть, а может не быть рандом, в зависимости от алгоритма генерации. и алгоритм генерации конкретного ууида указывается в нём самом, потому что в нём есть заголовки.

Тут формулировка не критична. Тот же mac - вообще говоря не рандомен, но их распределение по миру - делает вероятность попадания последовательных значений твоим клиентам (генераторам uuid) к очень маленьким величинам

про маки, как человек, ведущий базу маков wifi, могу отдельно рассказать, всё не так радужно :)

Ну в uuid не только ведь мак ).

пожалуйста, не называйте рандомом различающиеся значения

а то потом люди думают, что можно просто рандом в bytea положить и какая разница.

И немного о генерации идентификаторов по данным. В простейшем случае это хэш. Но опять же с моим примером soap - ты можешь генерировать хэш - и возвращать его клиенту в ответе на запрос. И он будет достаточно уникально идентифицировать запрос. Но проблема в том, что это ресурсоемко

Я проста у вас ваше мнения хотел спросить.. Что вы используете и почему

uuid (guid), можем прыгнуть на любое другое хранилище с сохранением воркфлоу

как ещё на распределённых системах айдишки выдавать, не счётчиком же? :)

++

ERROR: S client not available

Хренью страдают. В любом случае как и просто рандом, ууид может случайно повториться. О чем педивикия и говорит

замечательное формальное доказательство, что тут сказать

и идентифицировать иммутабельную запись по ней самой

А можно ссылку? Интересный кейс

А можно ссылку? Интересный кейс

ссылку не знаю, где взять у меня есть какое-то количество данных, которые проходят по пайплайну и являются по сути агрегацией других данных, не имеющей id агрегации чаще всего (в наиболее важных кейсах) получаются идентичными, так что id я им выставляю пост-фактум как id = hash(data) потом они миграцией уезжают в прод-базу, и им делается insert on conflict do nothing - записи только добавляются, не удаляясь; id не зависит от системы, на которой они были сгенерированы

кот, может вам будет интересно в жуно http://www.vldb.org/pvldb/vol9/p1365-fernandes.pdf

ссылку не знаю, где взять у меня есть какое-то количество данных, которые проходят по пайплайну и являются по сути агрегацией других данных, не имеющей id агрегации чаще всего (в наиболее важных кейсах) получаются идентичными, так что id я им выставляю пост-фактум как id = hash(data) потом они миграцией уезжают в прод-базу, и им делается insert on conflict do nothing - записи только добавляются, не удаляясь; id не зависит от системы, на которой они были сгенерированы

Понял, спасибо ?

кот, может вам будет интересно в жуно http://www.vldb.org/pvldb/vol9/p1365-fernandes.pdf

о! спасибо :)

Всем доброго времени суток. Я программист 1С. Хоу осуществить переход на c MS SQL на PostgreSQL. Подскажите, кто осуществлял такие переходы и насколько успешно. На сколько ощутима разница в работе. Спасибо

Всем доброго времени суток. Я программист 1С. Хоу осуществить переход на c MS SQL на PostgreSQL. Подскажите, кто осуществлял такие переходы и насколько успешно. На сколько ощутима разница в работе. Спасибо

ПостгресПро занимается этим постоянно

У них на сайте по этому поводу много информации

ок. спасибо большое

Всегда пжлста.

а как в psql можно дождаться старта postgres, если он не принимает коннекшены?

А есть способ посмотреть последний запрос, вызвавший ошибку?

А все, нашел.

а как в psql можно дождаться старта postgres, если он не принимает коннекшены?

Никак, думаю. Цикл на баше с проверкой exit code не вариант?

Никак, думаю. Цикл на баше с проверкой exit code не вариант?

вариант, спасибо, впилил

вариант, спасибо, впилил

Поищи баг редхата на этутему. Там сервак не успевал прогрузиться за три секунды. Фикс -- ждать пять секунд.

Это центос, детка

https://bugzilla.redhat.com/show_bug.cgi?id=800534

У меня вообще докер

опа, теперь это канал про аниме

Не про аниме а об аниме

Четай классеку

:(

Патчите? :)

постоянно :(

Всё. Теперь 600!

То есть все сообщения читают 600 человек? Так и до страха сцены недалеко

а коммитить в паблик гитхаба - не страшно?

То есть все сообщения читают 600 человек? Так и до страха сцены недалеко

Да, Дмитрий. 600 человек сейчас внимательно следят за каждым вашим сообщением.