Здравствуйте, _d_m_, Вы писали:
AB>>З.Ы. Но если кому-то совсем-совсем невмоготу и хочется именно типа GUID, то исходники открыты
___>Да-да там типа юникс вэй и прочее. А новые версии и апдейты как накатывать?
Наверно подразумевается, что Вы отправите патч, он будет утвержден, и накатан на основную ветку...
Здравствуйте, _d_m_, Вы писали:
___>Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте. А вот проблема ключа длиной 36 vs 16 — это риал.
Ничего не мешает хранить 16 байт в бинари формате.
AB>Если говорить непосредственно о типе поля GUID в MSSQL, то да, аналога нет. Если говорить о наличии уникальной (глобально) возрастающей последовательности, то есть. Как ее применять и применять ли (поскольку "проблем" с репликацией у MySQL нет при любом типе PK) — вопрос уже другой.
Точно. Особенно заметно проблем нету, если надо слить базы с других серверов, а в качестве PK использованы автоинкременты.
Здравствуйте, mrTwister, Вы писали:
___>>Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте. А вот проблема ключа длиной 36 vs 16 — это риал.
T>Ничего не мешает хранить 16 байт в бинари формате.
Здравствуйте, criosray, Вы писали:
C>Здравствуйте, _d_m_, Вы писали:
___>>А проблема фрагментации индексов преувеличена, я бы даже не называл это проблемой. Во всяком случае в MS SQL.
C>Она не преувеличена. Из-за нее мы вынуждены перестраивать индексы частями через каждые двое суток. Всего 10-15 дней и фрагментация порядка 90%, что неприемлимо.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, _d_m_, Вы писали:
_>> Значит нет там поддержки GUID-ов. Обычное МыСклевкое решение — через задницу. Я в MS SQL, .Net CLR UDF-ами могу хоть звезду с неба достать.
AB>Если говорить непосредственно о типе поля GUID в MSSQL, то да, аналога нет. Если говорить о наличии уникальной (глобально) возрастающей последовательности, то есть. Как ее применять и применять ли (поскольку "проблем" с репликацией у MySQL нет при любом типе PK) — вопрос уже другой.
Это физически невозможно. И как же решили великие создатели MySQL эту проблему?
Здравствуйте, Mamut, Вы писали:
M> Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
EXPLAIN SELECT ...
SET profiling = 1;
SELECT ...;
SELECT ...;
SHOW PROFILES;
SHOW PROFILE CPU FOR QUERY 2;
Здравствуйте, _d_m_, Вы писали:
_> Даже если так — и что? GUID тем и удобен, что его можно генерировать на клиенте.
Так и здесь можно.
_> А вот проблема ключа длиной 36 vs 16 — это риал.
Как уже говорилось, если хочешь экономить место, никто не запрещает его конвертировать в бинарное представление и заносить в BINARY(16) поле, по которому построить такой же индекс.
Здравствуйте, _d_m_, Вы писали:
AB>>З.Ы. Но если кому-то совсем-совсем невмоготу и хочется именно типа GUID, то исходники открыты ___>Да-да там типа юникс вэй и прочее. А новые версии и апдейты как накатывать?
Как обычно — сливается тэг, накатывается патч, компилируется, при желании оборачивается в пакет и раскатывается по серверам. Для тех, кто возьмется лезть в исходники, думаю, все остальное проблем не составляет.
Здравствуйте, Mamut, Вы писали:
_>> Стоп-стоп. Какой ACID? Если для DDL его нет. Тут уже упоминали .frm файлы. M>Ну, он в теории есть. По идее frm ожно восстановить по transaction-логам. Но это — в теории
Не знаю, как щас, но год-полтора назад ситуация была следующая:
1) запускаем скрипт, в единой транзакции обновляющий структуру базы;
2) скрипт выбрасывает исключение;
3) транзакция откатывается, включая изменения метаданных, хранимых и используемых innodb, но НЕ включая изменения в frm-файлах, используемых ядром мускуля (в т.ч. планировщиком ЕМНИП);
4) все последующие запросы к таблицам, метаданные которых рассогласованы, падают с внутренней ошибкой;
5) делаем /etc/init.d/mysqld stop;
6) ручками или скриптиком восстанавливаем frm-файлы (в документации мускуля было howto);
7) делаем /etc/init.d/mysqld start;
8) не забываем повторять про себя "во б#$% п#$#$# е#$#$#$ е#@#@ их в с#$#%# что б вы м#$^@ п#$#$%#$# cо своим е#$&@# муcкулем!" в течение всего процесса, начиная с пункта 4 (можно раньше).
Здравствуйте, dimgel, Вы писали:
D>Не знаю, как щас, но год-полтора назад ситуация была следующая: D>1) запускаем скрипт, в единой транзакции обновляющий структуру базы; D>2) скрипт выбрасывает исключение; D>3) транзакция откатывается, включая изменения метаданных, хранимых и используемых innodb, но НЕ включая изменения в frm-файлах, используемых ядром мускуля (в т.ч. планировщиком ЕМНИП); D>4) все последующие запросы к таблицам, метаданные которых рассогласованы, падают с внутренней ошибкой; D>5) делаем /etc/init.d/mysqld stop; D>6) ручками или скриптиком восстанавливаем frm-файлы (в документации мускуля было howto); D>7) делаем /etc/init.d/mysqld start; D>8) не забываем повторять про себя "во б#$% п#$#$# е#$#$#$ е#@#@ их в с#$#%# что б вы м#$^@ п#$#$%#$# cо своим е#$&@# муcкулем!" в течение всего процесса, начиная с пункта 4 (можно раньше).
А всего то надо было сделать бекап перед деплойментом. Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа). Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
Здравствуйте, mrTwister, Вы писали:
T>А всего то надо было сделать бекап перед деплойментом.
Вот, ты сам и подтвердил, что ACID-ом тут и не пахнет, нужно вручную. Предлагаешь два раза двухгиговую базу лопатить — один раз бэкап, второй раз внутри транзакции. Гы, а третий раз — восстановление из бэкапа. Тот же PostgreSQL, кстати, прекрасненько откатывает транзакции с DDL. Наверное потому что в нём нет этого идиотского бардака со storage engines и задвоений метаданных.
T>Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа).
Из сказанного это никак не следует, т.к. приведённый мной сценарий рушил метаданные независимо от того, работал с базой кто-нибудь ещё или нет.
И если уж на то пошло, условие down-time выполнялось автоматически, т.к. обновлялка работала при инициализации servlet context.
T>Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
Здравствуйте, Sheridan, Вы писали:
>> ИМХО, просто предсмертная агония. Было уже такое, "догоним и перегоним" (по количеству, а качество по-барабану). S>Да скорей бы уже.
Эту реплику, Максимко, должен был произнести я. Тебя ж не заставляют под мускуль сайты писать? Так что тебе должно быть пофиг.
dimgel wrote:
> S>Да скорей бы уже. > Эту реплику, Максимко, должен был произнести я. Тебя ж не заставляют под мускуль сайты писать?
Но могут заставить
> Так что тебе должно быть пофиг.
Мне не пофиг
Мне же всех вас и тебя в частности жалко, ага
Здравствуйте, mrTwister, Вы писали:
T>А всего то надо было сделать бекап перед деплойментом.
На нормальных серверах с нормальными транзакциями — нет необходимости.
T>Из всего этого следует только то, что деплоймент, изменяющий структуру базы данных на MySQL требует обязательный down-time на время прогона скрипта (и/или создния и восстановления бекапа).
На нормальных серверах не нужен никакой даунтайм (за редким исключением), и (ты удивишься) даже бэкап там делается на горячую без остановки сервера и отключения клиентов.
T>Но даже на оракле и скл сервере, все деплойменты которые я проводил/имел отношение/наблюдал проходили с down-time'ом на время бекапа (когда было возможно), прогона скрипта (без транзакций) и первичного тестирования. Так что в данном случае не было бы никакой разницы.
Ерунда какая-то — не нужен никакой даунтайм для с-ку-эль сервера. Ты не умеешь его правильно готовить. За оракл — не скажу, с ним не работаю.
Здравствуйте, Anton Batenev, Вы писали:
AB>Здравствуйте, Mamut, Вы писали:
M>> Причем в Enterprise tudio есть гниальная фича «показать план запроса», оторый подскажет, на каких именно данных просаживается запрос. Обычно бывает достаточно прикрутить забытый индекс — и вуаля.Для MySQL'я таких тлзов просто не существует в природе, насколько я знаю
AB>
EXPLAIN SELECT ...
AB>
AB>SET profiling = 1;
AB>SELECT ...;
AB>SELECT ...;
AB>SHOW PROFILES;
AB>SHOW PROFILE CPU FOR QUERY 2;
AB>
Спасибо, посмеялся.
Во первых, речь шла про план запроса. Типа такого http://files.rsdn.ru/21534/PlanPutina2.GIF , там еще мышкой наводишь например на индекс скан и смотришь что, где и почему — число строк, размер строки, io cost и многое.
Во вторых, T-SQL-е есть и подобное: set statistics io, set statistics time, show plan text и прочее.
