|
|
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
Всем привет. Есть большая таблица (~ 2 млрд. записей) и к ней идёт порядка 80% всех запросов. В этой таблице нужно сделать ALTER (добавить 1 столбец). Тупо в лоб сделать alter понятное дело нельзя. Рассматривал вариант Код: sql 1. но тоже не подходит, так как после переименования таблиц сбросится кеш, а набор нового кеша сложит базу. Между этой базой и другой настроена репликация master - master. Версия mysql 5.6.25. Может кто-то знает какие-то другие варианты сделать alter? Заранее спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 09:12 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
Может, разумнее создать связанную 1:1 таблицу с нужным полем? skeletorнабор нового кеша сложит базу. Когда-нибудь всё равно это делать придётся. Почему не сейчас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 09:19 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
Не понял про связанную таблицу. Насчёт кеша: не согласен с "Когда-нибудь всё равно это делать придётся". Мы исходили из следующего: что проще реализовать: alter таблицы или переписать часть кода, что бы это поле выгребалось из другой таблицы. Так вот, после анализа пришли к выводу, что проще сделать alter, нежели переписывать огромные участки кода во многих местах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 09:37 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
skeletorпосле анализа пришли к выводу, что проще сделать alter, нежели переписывать огромные участки кода во многих местах. Фраза неясна. Как может потребоваться переписывание кода, если этого поля раньше не было, т.е. изменения не могут коснуться кода, который это поле не использует? Только новый код, знающий про это поле, будет его использовать... Ну и... у вас что, структуры и запросы хардкодятся, что ли? skeletorНасчёт кеша: не согласен с "Когда-нибудь всё равно это делать придётся". Когда-нибудь или сервис перестартовывается, или весь комп. После рестарта кэш чист как слеза младенца... skeletorНе понял про связанную таблицу. Что именно не понято? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:09 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
skeletorно тоже не подходит, так как после переименования таблиц сбросится кеш, а набор нового кеша сложит базу.о каком именно кэше идет речь? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:14 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
miksoftskeletorно тоже не подходит, так как после переименования таблиц сбросится кеш, а набор нового кеша сложит базу.о каком именно кэше идет речь? Кеш запросов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:20 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
Akinaskeletorпосле анализа пришли к выводу, что проще сделать alter, нежели переписывать огромные участки кода во многих местах. Фраза неясна. Как может потребоваться переписывание кода, если этого поля раньше не было, т.е. изменения не могут коснуться кода, который это поле не использует? Только новый код, знающий про это поле, будет его использовать... Ну и... у вас что, структуры и запросы хардкодятся, что ли? skeletorНасчёт кеша: не согласен с "Когда-нибудь всё равно это делать придётся". Когда-нибудь или сервис перестартовывается, или весь комп. После рестарта кэш чист как слеза младенца... skeletorНе понял про связанную таблицу. Что именно не понято? Не придирайтесь к словам. Я не программист, видимо так написан код (раз мне так объяснили). Насчёт рестарта базы, если какая-то из баз крешится, то переключаем всё на вторую базу и потом малыми порциями включаем нагрузку, что бы прокешировалась база. Пока писал вы меня натолкнули на одну мысль, попробую проверить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:22 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
skeletormiksoftпропущено... о каком именно кэше идет речь? Кеш запросовЭтот кэш и так сбрасывается при каждой модификации таблицы. Конечно, не весь, а результаты тех запросов, которые используют эту таблицу. Кроме того, кэш запросов обычно бывает довольно небольшой (ибо большой тянет много накладных расходов) и, если что, заполнится обратно довольно быстро. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:23 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
skeletor, тупо сделать alter. с default. пользователей остановить, ничего с ними не станет, переживут. Если что, начальству скажешь, что это - бесплатная говносубд, а не Oracle Enterprise Edition, так что за что заплатили, то и получили. на крайняк не добавляй колонку, а сделай новую таблицу, PK старой плюс новые поля. И join. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:28 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
skeletorAkinaпропущено... Фраза неясна. Как может потребоваться переписывание кода, если этого поля раньше не было, т.е. изменения не могут коснуться кода, который это поле не использует? Только новый код, знающий про это поле, будет его использовать... Ну и... у вас что, структуры и запросы хардкодятся, что ли? пропущено... Когда-нибудь или сервис перестартовывается, или весь комп. После рестарта кэш чист как слеза младенца... пропущено... Что именно не понято? Не придирайтесь к словам. Я не программист, видимо так написан код (раз мне так объяснили). Насчёт рестарта базы, если какая-то из баз крешится, то переключаем всё на вторую базу и потом малыми порциями включаем нагрузку, что бы прокешировалась база. Пока писал вы меня натолкнули на одну мысль, попробую проверить. а чего ты тогда этим вообще занимаешься? оставь это профессионалам, Или хотя-бы тем, кто себья так называет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:31 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
skeletorНе придирайтесь к словам. Я не программист, видимо так написан код (раз мне так объяснили).Я вижу невозможную информацию. И стараюсь прояснить ситуацию. И вместо ответов возмущаться - неконструктивно. А что программисты врут в надежде минимизировать свои трудозатраты - это понятно. ALTER TABLE на такой таблице в любом случае растянется как минимум на часы, а то и дни. И всё это время таблица будет недоступна. Так что только создание новой структуры и перекачка данных в неё - пусть и с повышенной нагрузкой, но это можно сделать без остановки основных процессов. Останов БД на время догрузки недостающего хвоста и подмены таблицы - минимальное зло, если выбрана именно модификация структуры. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:31 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
по отдельной таблице. вместо добавления поля в данную таблицу можно создать новую таблицу с новым полем и первичным ключом старой. это будет быстро и не будет блокировать никого. приложение при этом должно естественно вставлять запись и в новую таблицу, и брать данные откуда тоже. разумеется, это делать можно не всегда, а только если нужно эти данные сохранить или прочитать. это - дежурный прием проектирования бд на этапах эксплуатации, в тех условиях, когда невозможно делать alter table. (alter table иногда все же делать можно и нужно). если бы ты обратился к профессионалам, они наверняка бы тебе это подсказали. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:41 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
MasterZivесли бы ты обратился к профессионалам, они наверняка бы тебе это подсказали. ну собственно поэтому сюда и написал :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 10:54 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
авторALTER TABLE на такой таблице в любом случае растянется как минимум на часы, а то и дни. И всё это время таблица будет недоступна нечетатель раздела 15.11.1 Overview of Online DDL детектед. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 13:44 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
ScareCrowавторALTER TABLE на такой таблице в любом случае растянется как минимум на часы, а то и дни. И всё это время таблица будет недоступна нечетатель раздела 15.11.1 Overview of Online DDL детектед.Все равно радости мало. http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-overview.html Add a column Although ALGORITHM=INPLACE is allowed, the data is reorganized substantially, so it is still an expensive operation. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 13:55 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
ScareCrowнечетатель раздела 15.11.1 Overview of Online DDL детектед. Add a columnAlthough ALGORITHM=INPLACE is allowed, the data is reorganized substantially, so it is still an expensive operation . ALGORITHM=INPLACE is supported for adding a virtual generated column but not for adding a stored generated column . Так что как была операция дорогая, так и остаётся... Что же до доступа - вот у меня счас в одном окне консоли добавляется поле в 8-гиговую таблицу (с ALGORITHM=INPLACE есссно), а в другом простой SELECT сидит и ждёт, когда это безобразие закончится... 5.7.11, InnoDB, file_per_table... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 14:28 |
|
||
|
Альтернативы ALTER'y на большой таблице на нагруженной базе
|
|||
|---|---|---|---|
|
#18+
AkinaScareCrowнечетатель раздела 15.11.1 Overview of Online DDL детектед. Add a columnAlthough ALGORITHM=INPLACE is allowed, the data is reorganized substantially, so it is still an expensive operation . ALGORITHM=INPLACE is supported for adding a virtual generated column but not for adding a stored generated column . Так что как была операция дорогая, так и остаётся... Что же до доступа - вот у меня счас в одном окне консоли добавляется поле в 8-гиговую таблицу (с ALGORITHM=INPLACE есссно), а в другом простой SELECT сидит и ждёт, когда это безобразие закончится... 5.7.11, InnoDB, file_per_table... https://www.percona.com/doc/percona-toolkit/2.2/pt-online-schema-change.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2016, 17:09 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=104&tid=1831885]: |
0ms |
get settings: |
10ms |
get forum list: |
19ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
29ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
60ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 387ms |

| 0 / 0 |
