Ярослав, Ваши придирки излишни.

Я Вас поддержал, вообще-то. ;)

)))

сериал и так бигинтом подперт изнутри)

все, всем хороших выходных)

Я Вас поддержал, вообще-то. ;)

top 10 anime betrayals

юзаю UUID-ы, когда нужно сгенерировать строку-ключ для уникального, неподбираемого диплинка

Тут есть нюанс — Вам никто не обещал что взятый наугад алгоритм генерации будет криптографически стойким. Т.е. против криптоаналитика с такими "картами" лучше играть не садиться. ;)

этот риск я принял, но сообщение было в контексте применения непоследовательных идентификаторов, когда вроде их использования никак не избежать

там нет алгоритмов наугад, там спека все довольно четко описывает

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

Это всё не так однозначно. Есть производительность генерации UUID и sequence. И они совсем не равны. Кроме того, важна общая производительность, а не в какой-то конкретной точке.

Это всё не так однозначно. Есть производительность генерации UUID и sequence. И они совсем не равны. Кроме того, важна общая производительность, а не в какой-то конкретной точке.

уид-то на клиенте генерируется

Не обязательно на клиенте

Ещё раз говорю

А зачем его генерировать в базе?

там нет алгоритмов наугад, там спека все довольно четко описывает

А я вот читал, не далее как позавчера, что это зависит от вида UUID-ов, и, если внимательно читать спецификацию, стойкости там не обещают. Впрочем, я не криптоаналитик.

Был опыт разрушившая запарка размером 2тб, построенного на uuid

Если хотите ходить по граблям - вперед

Все на первых этапах красиво

ой, ну давайте без аргументации "на моей машине" и "сами не понимаете, во что вступаете"

А я вот читал, не далее как позавчера, что это зависит от вида UUID-ов, и, если внимательно читать спецификацию, стойкости там не обещают. Впрочем, я не криптоаналитик.

Там предлагается рандом и псевдорандом на выбор. Но это не случайные алгоритмы.

Uuid - тупиковая идея построения реляционной нормализованной модели жанных

уид-то на клиенте генерируется

А в базу-то вставляется. А что при этом происходит, Andrei Shmigiro уже написал. И, кстати, это ещё не всё, кажется... перечитаю.

*данных

Uuid - тупиковая идея построения реляционной нормализованной модели жанных

сериал - тупиковая идея построения реляционной нормализованной модели данных

beat this ?

When you need to shard your table, the autoincrementing is is a bottleneck across all shards as you need to hold a lock on it when incrementing. In fact, that's exactly how it's implemented explicitly in POSTGRES.

мимо вычитал

When you need to shard your table, the autoincrementing is is a bottleneck across all shards as you need to hold a lock on it when incrementing. In fact, that's exactly how it's implemented explicitly in POSTGRES.

Я ещё раз повторю, что важна производительность процесса в целом, а не в конкретной точке.

так может мы выиграем за счет уидов ???

Uuid - тупиковая идея построения реляционной нормализованной модели жанных

Да как это к нормализации-то отностится?! Тут уж вы хватили через край, IMHO. ;)

ладно, давайте просто сойдемся на том, что это две модели с не очень коррелирующими бенефитами

Там предлагается рандом и псевдорандом на выбор. Но это не случайные алгоритмы.

Я имел в виду, что, для того, чтобы быть уверенным, надо выбирать (и проверять) алгоритм. Неальзя просто взять uuidv1 и надеяться, что это хорошо...

ладно, давайте просто сойдемся на том, что это две модели с не очень коррелирующими бенефитами

Только вот, что касается "полной" производительности, выиграть UUID-ам — конкретно, v4, и именно в PostgreSQL, на практике (почти наверняка) не удастся ни разу. ;) И, ещё раз, я так и не понял, зачем они нужны в "обычной" базе (не распределённой)?

потому что все очень легко параллелится

А в базу-то вставляется. А что при этом происходит, Andrei Shmigiro уже написал. И, кстати, это ещё не всё, кажется... перечитаю.

Ах да, WAL ampification забыли.

у вас данные-то в большинстве таблиц сильно больше будут весить, чем оверхед на 64 бита

потому что все очень легко параллелится

Преимущество-то в чём, конкретно?

кажется не сошлись все-таки

When you need to shard your table, the autoincrementing is is a bottleneck across all shards as you need to hold a lock on it when incrementing. In fact, that's exactly how it's implemented explicitly in POSTGRES.

локи всегда зло

а здесь они нинужны

локи всегда зло

Лозунги — вот это зло. ;)

вот же, положила > выиграть UUID-ам — конкретно, v4, и именно в PostgreSQL, на практике (почти наверняка) не удастся ни разу. ;)

ладно, я серьезно не вижу смысла дальше обсасывать

кажется не сошлись все-таки

Benchmarks есть? И вообще, производительность — это конечно, хорошо... но другие минусы всё ещё с нами. ;)

Benchmarks есть? И вообще, производительность — это конечно, хорошо... но другие минусы всё ещё с нами. ;)

ну это не я заявляю о бесспорном выигрыше одного варианта над другим по производительности

ну это не я заявляю о бесспорном выигрыше одного варианта над другим по производительности

Хмм... то есть, Вы не считате, что так будет почти во всех ситуациях, и ранее приведённые теоретические причины Вас не убеждают?

я не шарю, но вроде uuid при логической репликации решают много проблем

если мастер мастер?

или я не прав?

Хмм... то есть, Вы не считате, что так будет почти во всех ситуациях, и ранее приведённые теоретические причины Вас не убеждают?

То есть я считаю, что бремя доказательства лежит на утверждающем. И что все зависит от конкретного кейса, потому что боттлнек может быть в разном, в т.ч. в сиквенсе.

я не шарю, но вроде uuid при логической репликации решают много проблем

Эээ... смотря каких проблем, наверное. А мы всё ещё про PostgreSQL? У нас как бы нет полноценной master-master репликации, если я чего-то не пропустил. :)

То есть я считаю, что бремя доказательства лежит на утверждающем. И что все зависит от конкретного кейса, потому что боттлнек может быть в разном, в т.ч. в сиквенсе.

> То есть я считаю, что бремя доказательства лежит на утверждающем. Не, ну это тоже черечур... Есть общепризнанные факты, и доказывать, что Земля круглая, мне как-то не захочется. И, опять-таки, давайте опеределимся, Вы хотите доказательства несуществования таких случаев? Если да, я могу хоть тысячи обратных привести, и Вы будете с полным правом говорить, что я исчерпал не все. :( Я утверждаю только то, что общая производительность вставки (в которой какие-то lock-и на sequence-ах, по идее, просто ничто по сравнению с другими элементами), почти всегда будет ниже. Если Вам нужны доказательства/обоснования этого утверждения, можно поискать...

Да мне все равно на самом деле. Просто "ну вы же понимаете, что Х" это вообще не аргумент.

Да мне все равно на самом деле. Просто "ну вы же понимаете, что Х" это вообще не аргумент.

ORLY? Вы понимаете, что 2*2=4? ;) Так Вам нужны обоснования (про UUID-ы) или нет?

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

https://www.cybertec-postgresql.com/en/int4-vs-int8-vs-uuid-vs-numeric-performance-on-bigger-joins/

вот есть такой бенчмарк

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

Вот это видели? https://blog.2ndquadrant.com/on-the-impact-of-full-page-writes/

давайте опять же не будем сводить все к записям

тем более что Let’s assume we have a simple table with primary key, either a BIGSERIAL or UUID выглядит как "у нас в таблице нет данных, кроме айдишника"

тем более что Let’s assume we have a simple table with primary key, either a BIGSERIAL or UUID выглядит как "у нас в таблице нет данных, кроме айдишника"

Ну это тестирования "основ", так сказать. Т.е. тест с одним JOIN-ом показывает, что UUID-ы немного медленнее (но это в RAM!), и его можно повторить; Тест из WAL amplification показывает, что random UUID как-то совсем не хороши для WAL, и его можно повторить; Т.е. в этих местах наши теории подтверждаются практикой, пока что.

Извините, я не готов верить таким бенчмаркам. Должна быть гипотеза, должно быть обоснование, должна быть проверка на наличие признаков, опровергающих гипотезу, "мы оставили сервак погреться на час" где-то в интернетах тоже все-таки так себе

Извините, я не готов верить таким бенчмаркам. Должна быть гипотеза, должно быть обоснование, должна быть проверка на наличие признаков, опровергающих гипотезу, "мы оставили сервак погреться на час" где-то в интернетах тоже все-таки так себе

Не верите — повторите, и сами увидите. В этом-то и смысл reproducible benchmarks. А гипотеза и обоснование там есть, и какие опровергающие "признаки" Вам нужны? ;)

там нет гипотезы

ERROR: S client not available

гипотеза - это "если мы сделаем Х, то должны увидеть Y, потому что будет эффект Z"

И ссылки на то, как его зарепродюсить (я имею в виду исходники теста), тоже нет

Оно все может быть так. Уиды могут быть абсолютно бесполезны. Я сейчас просто говорю о том, что нельзя вытащить просто первое утверждение из интернета, которое совпадает с нужным мнением, и апеллировать им, как и "ну вы же сами понимаете" и подобными конструкциями.

За сим все-таки закончу.

И ссылки на то, как его зарепродюсить (я имею в виду исходники теста), тоже нет

Ха! А ведь и верно. :) Ну никому нельзя верить. ;)

Оно все может быть так. Уиды могут быть абсолютно бесполезны. Я сейчас просто говорю о том, что нельзя вытащить просто первое утверждение из интернета, которое совпадает с нужным мнением, и апеллировать им, как и "ну вы же сами понимаете" и подобными конструкциями.

Да, отчасти оно так... тут только на репутацию 2ndquadrant, и конкретно, Tomas Vondra можно ссылаться. А гипотеза такая: "если мы будем писать случайные ключи в b-tree, вставки будут попадать на случайные листы (и таки да), и, следовательно, те из них, которые не были записаны с последнего checkpoint-а, дадут FPW." И, с виду, похоже.

5 мс. на 500к артикулов, с лимит 30

это во время записи конкуррентной если что

5 мс. на 500к артикулов, с лимит 30

Так Вы сгенерировали уже? И сколько получилось?

500к артикулов сейчас

А я забыл, сколько должно было быть. ;) А размер базы какой на данный момент (просто любопытно)?

404 MB |

должно быть около 3к артикулов, это максимум

должно быть около 3к артикулов, это максимум

З миллиона, в смысле? Т.е. в шесть раз больше, чем сейчас?

да.

вот запрос с джойном: https://explain.depesz.com/s/uREW

SELECT sps.id FROM shop_product_sku AS sps INNER JOIN shop_product_sku_offer spsf ON spsf.sku_id = sps.id WHERE EXISTS (SELECT 1 FROM shop_feature_brand_sku AS sfb WHERE sfb.sku_id = sps.id AND sfb.feature_value_code = 'xiaomi') AND EXISTS (SELECT 1 FROM shop_feature_cores_sku sfcs WHERE sfcs.sku_id = sps.id AND sfcs.feature_value_code = 2) AND EXISTS (SELECT 1 FROM shop_feature_ram_sku sfrs WHERE sfrs.sku_id = sps.id AND sfrs.feature_value_code = 4096) ORDER BY spsf.price DESC LIMIT 30;

но сдается мне что с ним что-то не так

но сдается мне что с ним что-то не так

Недетерминированный он, это как минимум. Вы с PostgreSQL раньше много работали? ;)

4 дня работаю с postgres

4 дня работаю с postgres

А до этого с чем работали из СУБД (может, у нас опыт пересекается, было бы легче советовать...)?

работал с MySQL, но тоже не долго. я как разработчик больше, а не как DBA

Не пересекается, значит. ;) Тогда, очень грубо, можно запомнить такое правило: PostgreSQL не любит "идиотских" запросов. ;) При этом, идиотскими считаются: недетерминированные (как в Вашем случае, на одних и тех же данных результат может быть разный); те, в которых есть что-то лишнее (например, "WHERE a= b OR false" <- вот этого "OR false" быть не должно); И т.д. и т.п. К тому же, при наличии нескольких способов сделать что-то, лучше "ходить, как все ходят". (Всё это обусловлено не только отношением PostgreSQL hackers к пользователям, как Вы могли бы подумать, но и архитектурой планировщика.) :)

вот запрос с джойном: https://explain.depesz.com/s/uREW

Да, кстати, у Вас в prodution не будет никахих препятствующих параллелизму настроек/условий? А то можно "обломаться" потом. :(

нет, не должно

значит буду учиться писать не идиотские запросы

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

а ну да, кажется понял.

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

Представьте, что все цены одинаковые, да.

значит буду учиться писать не идиотские запросы

Ну да, звучит грубо... но помогает! :) Вы отпишитесь, когда догенерируется... во время интенсивной заливки данных база у Вас совсем не в том режиме, что будет в production, к тому же, лучше бы ещё попробовать добавить (изменить) индексы.

спасибо за дискуссию) я отпишу как будет примерный ожидаемый объем данных.