(помним же что там утф не утф)

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

срыв покровов

Хотя и Postgres не подарок, но всеже получше.

срыв покровов

Накипело просто. Попробуй хранить в mysql колонку с GUIDами, это просто феерический пиздец.

но это же прексраный греп

Накипело просто. Попробуй хранить в mysql колонку с GUIDами, это просто феерический пиздец.

а че там такого? я думал, он в некоем подобии varchar(16) бинарно хранится там

По бинарным полям не построишь индекс.

фига о_О

На первый взгляд приплыли...

т.е. или экономишь оперативку с местом на харде и хранишь бинарно, но без индекса, или хуячишь в varchar(36), но с текстовым индексом?

т.е. или экономишь оперативку с местом на харде и хранишь бинарно, но без индекса, или хуячишь в varchar(36), но с текстовым индексом?

Бинго... и когда пробуешь это сделать понимаешь что выбрал не ту базу.

а в постгре с этим хоть в порядке всё?

не очень

не очень

Лучше, там под это нативный тип.

там приходится ебаться с выбором

для старых пг один екстеншен, для более модных другой

т.е. или экономишь оперативку с местом на харде и хранишь бинарно, но без индекса, или хуячишь в varchar(36), но с текстовым индексом?

как воркэраунд кодировать питоном в base85 байты уида и хранить varchar. По скорости норм, я проверял.

как воркэраунд кодировать питоном в base85 байты уида и хранить varchar. По скорости норм, я проверял.

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

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

ну и latin1_bin поставить не забыть.

а банальное ... foo_pk uuid default newuuid(), сделать кроссбазово тот еще геморрой

In [7]: len(base64.b85encode(uuid.uuid4().bytes)) Out[7]: 20

это нахуя?

это нахуя?

алфавит больше поле меньше индекс меньше.

перестраивается быстрее

In [7]: len(base64.b85encode(uuid.uuid4().bytes)) Out[7]: 20

ну и заебись, и рыбку съел, и на люстре покачался :)))

пиздец, конечно :(

пиздец, конечно :(

Именно.

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

Вообще кому интересно на Highload 2016 Зайцев рассказывал про это http://bit.ly/2mHrZHj

мне больше интересно кому он это рассказывает

percona неплохо так спиздила логотип у beats

мне больше интересно кому он это рассказывает

Я пошел посмотреть в глаза человеку который хочет рассказать какой mysql-noSQL

<spoiler>не убедил</spoiler>

зато в sqlite всё хорошо :)=)

зато в sqlite всё хорошо :)=)

Ага, тормозит себе в файле и ладно :-D

зато где его только не используют :)

но мне как-то страшно на это смотреть, ибо он даже с джангой нормально не работает

"даже"?

ну, по факту, работает

но почему "даже", это хороший вопрос

работает, но иногда зависает, когда запросов больше одного

в девсервере?

правда я про джангу 1.8, может в новой поправили

Я пошел посмотреть в глаза человеку который хочет рассказать какой mysql-noSQL

ну там хендлерсокет раньше был.

ага

только в 5.7 он умер

а зачем вам гуиды в базе

шардировочка ?

работает, но иногда зависает, когда запросов больше одного

джангопроблемы - https://www.youtube.com/watch?v=SlS5MxuianA

а зачем вам гуиды в базе

чтобы были. например, чтобы скрыть последовательность создания пользователей.

или да, шардировочка

чтобы были. например, чтобы скрыть последовательность создания пользователей.

uuid4 очень скрывает последовательность, ага. учитывая что в нем таймстемп зашит в открытом виде...

чтобы были. например, чтобы скрыть последовательность создания пользователей.

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

uuid4 очень скрывает последовательность, ага. учитывая что в нем таймстемп зашит в открытом виде...

ну, вот юзер с гуидом. угадай гуид следующего юзера, например.

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

ииииии, это guid!

нет это не гуид

да неужели? ну вот когда ты в свою хранимку с рандомом добавишь кода для уменьшения вероятности коллизии, етс, етс, етс. будет сравнимо с guid.

мы юзали и рандомы тоже

неудобно

да неужели? ну вот когда ты в свою хранимку с рандомом добавишь кода для уменьшения вероятности коллизии, етс, етс, етс. будет сравнимо с guid.

юник и цикл. вероятность коллизии крайне мала

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

и размер получается небольшой. символов 6 вон как видосы в ютубе

и размер получается небольшой. символов 6 вон как видосы в ютубе

там уже 8+.

ну пусть будет 8

ERROR: S client not available

чтобы были. например, чтобы скрыть последовательность создания пользователей.

Если в качестве pk, то производительность у индексов с u(g)uid очень плохая.

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

это напоминает мне http://thedailywtf.com/articles/A-More-Unique-Identifier

lLid-FKeSM0 - на, сам посчитай.

Если в качестве pk, то производительность у индексов с u(g)uid очень плохая.

зависит от а) СУБД, б) алгоритма генерации.

это напоминает мне http://thedailywtf.com/articles/A-More-Unique-Identifier

ага.

но ты сам можешь рулить сколько символов а не юзать миллион как в гуидах

но ты сам можешь рулить сколько символов а не юзать миллион как в гуидах

в гуиде 128 бит. это не миллион, а ровно 16 байт.

по-моему кто-то или пиздит или выбрал не тот генератор

зависит от а) СУБД, б) алгоритма генерации.

я читал про mysql и postgres, везде одно и тоже. На больших данных - сильная просадка по производительности. Для монотонных uuid - лучше, но все-равно сильно хуже чем для автоинкреметной sequence.

в гуиде 128 бит. это не миллион, а ровно 16 байт.

которые вон хранятся в 36 символах угу

которые вон хранятся в 36 символах угу

нет, они хранятся в 16 байтах в нормальных СУБД.

либо в 32 символах. дефисы не нужны.

зависит от а) СУБД, б) алгоритма генерации.

LДа, если знаешь БД или алгоритм, которой бы помог решить проблемы с производительностью, я был бы счастлив про них узнать ;)

с производительностью чего?

LДа, если знаешь БД или алгоритм, которой бы помог решить проблемы с производительностью, я был бы счастлив про них узнать ;)

MS Sql Server + Sequential UUID.

о, мсье знает волшебные слова

https://msdn.microsoft.com/en-us/library/ms189786.aspx

мсье вообще неплохо разбирается в MS Sql Server 2008-2014/

эту функцию вводили в 2005 или 2008?

мсдн имеет обыкновение изображать вид что еол продуктов не существует

эт я не помню, я её не юзал, т.к. в SQL Server мы не использовали GUID для PK. по ссылке вроде про 2008 написано.

ну такую инфу они обрезают 8\

если читать современные вин32 апи доки то создаться впечатление что половина функций появилась в хп/2003/висте, хотя половина из них ведет жизнь чуть ли не с 1.0

это да, я такую херню не понимаю.

тут уже про легаси выступали

я читал про mysql и postgres, везде одно и тоже. На больших данных - сильная просадка по производительности. Для монотонных uuid - лучше, но все-равно сильно хуже чем для автоинкреметной sequence.

на больших данных обычно mysql с постгрей не юзают ;)

юзают

на больших данных обычно mysql с постгрей не юзают ;)

расскажи об этом фейсбуку.

если речь про специфические варианты

только монга только молодость

специфические варианты это типа greenplum'а? ))

только арбузы