-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Переиндексация. Подскажите как лучше сделать?
- Автор темы radiante
- Дата начала
Если уж на то пошло - то клики можно вообще сразу не писать, а потом из логов неспеша выгрести
Вообще, хочу извинится за свое поведение, потому что независимо от всего, переводить все на личность Димы было глупо и мелко. Тем самым хочу вернуть дискуссию в цивилизованное русло, и все же услышать формулировку того специфического случая, когда переименования таблицы эффективны. Никто не может знать всего, и я с удовольствием получу новую полезную информацию. Но — конкретную, а не ситуации из разряда «неуловимых Джо» — которых никто не встречал, потому что они никому не нужны.
Отвечаю по пунктам, ты видимо сверху страницы не заметил ответов...
> Придумывать на ходу граничные условия это как-то...
Высоконагруженная поисковая табличка как правило состоит из кучи каких-то чисел с кучей индексов и неких сложных селектов. На практики ничего не меняется, но если она очень большая, то как минимум в озу будет целиком индекс и уже будет существовать большая нагрузка на диск (задача не добавить новых тормозов). Какие придумывания.. просто это жизненный вариант, что поисковая таблица целиком в озу влезает.
> лок на всю таблицу(x2) для ее переименования тебя не спасет
Ты просто не знаешь, что 3 таблички (текущая->temp, подготовленная->текущая) можно переименовать в одну команду, без локов, атомарно. Смотри доку.
> Повторюсь, чем не угодил классический слейв в таком случае? Или партиционирование по индексу?
Да, как правило следует воспользоваться слейвом, как наиболее быстрым и выгодным решением "добавили железа и все ок". Разбивать табличку на части тоже можно, по придется программировать, а время дорого, хотя именно этим путем мы идем чаще всего (потом к этому слейвы добавляются, при необходимости).
Разбивать таблицу на диапазоны индекса (по диапазону некого индексного поля, ты, наверно, это имел ввиду) - это чушь. Тогда придется еще запросы сразу в несколько таблиц давать, склеивать ответы, т.к. мы не знаем, где именно нужные нам строки хранятся (вот уж говнокодистое решение). Поисковая табличка разбивается на части по иным методам, чтобы не пришлось множить запросы и клеить ответы. Для каждой задачи такой метод свой, нужно придумывать. Общего решения не существует.
---
Ты просто споришь с элементарной логикой. Проблема - индексы тормозят. Почему? Потому, что жопа с диском на несколько секунд случается, все висит. Вывод? Избавится от источника тормозов. Я - избавился. Ты - обплевал все и ничего по делу не написал (кроме традиционных советов). Даже элементарный совет про накопительный инсерт проигнорировал.
Мы некоторое время на 15 млн записей применяли данный метод, разбивали таблицу на части, держали 3 слейва, писали данные отложенно, все максимум кешировали и т.д. В конечном задолбало, запросы стали почти некешируемые, и в итоге просто 4 мыскля на 1 постгрес заменили, на том же железе. Все работает без слейвов и моего изврата с переименованием.
> Придумывать на ходу граничные условия это как-то...
Высоконагруженная поисковая табличка как правило состоит из кучи каких-то чисел с кучей индексов и неких сложных селектов. На практики ничего не меняется, но если она очень большая, то как минимум в озу будет целиком индекс и уже будет существовать большая нагрузка на диск (задача не добавить новых тормозов). Какие придумывания.. просто это жизненный вариант, что поисковая таблица целиком в озу влезает.
> лок на всю таблицу(x2) для ее переименования тебя не спасет
Ты просто не знаешь, что 3 таблички (текущая->temp, подготовленная->текущая) можно переименовать в одну команду, без локов, атомарно. Смотри доку.
> Повторюсь, чем не угодил классический слейв в таком случае? Или партиционирование по индексу?
Да, как правило следует воспользоваться слейвом, как наиболее быстрым и выгодным решением "добавили железа и все ок". Разбивать табличку на части тоже можно, по придется программировать, а время дорого, хотя именно этим путем мы идем чаще всего (потом к этому слейвы добавляются, при необходимости).
Разбивать таблицу на диапазоны индекса (по диапазону некого индексного поля, ты, наверно, это имел ввиду) - это чушь. Тогда придется еще запросы сразу в несколько таблиц давать, склеивать ответы, т.к. мы не знаем, где именно нужные нам строки хранятся (вот уж говнокодистое решение). Поисковая табличка разбивается на части по иным методам, чтобы не пришлось множить запросы и клеить ответы. Для каждой задачи такой метод свой, нужно придумывать. Общего решения не существует.
---
Ты просто споришь с элементарной логикой. Проблема - индексы тормозят. Почему? Потому, что жопа с диском на несколько секунд случается, все висит. Вывод? Избавится от источника тормозов. Я - избавился. Ты - обплевал все и ничего по делу не написал (кроме традиционных советов). Даже элементарный совет про накопительный инсерт проигнорировал.
Мы некоторое время на 15 млн записей применяли данный метод, разбивали таблицу на части, держали 3 слейва, писали данные отложенно, все максимум кешировали и т.д. В конечном задолбало, запросы стали почти некешируемые, и в итоге просто 4 мыскля на 1 постгрес заменили, на том же железе. Все работает без слейвов и моего изврата с переименованием.
Ты умудряешься противоречить сам себе в одном сообщении. О чем тут говорить?
15 миллионов записей в отрыве от числа выборок/вставок не говорят не о чем.
Я попросил привести тебе реальную ситуацию, ты упорно с одной стороны пытаешься все обобщить — с другой рассказываешь про какие-то «граничные случаи». Я пытаюсь узнать, что это это за случаи — ты мне рассказываешь, как у вас все было плохо, но не говоришь почему. Если у тебя боттлнек в записи на диск — это проблема с данными, которые пишутся однозначно медленнее индексов. Если у тебя боттлнек в записи в озу индексов — извини, тут уже никакие переименования таблиц тебя не спасут по определению уже.
Я попросил привести тебе реальную ситуацию, ты упорно с одной стороны пытаешься все обобщить — с другой рассказываешь про какие-то «граничные случаи». Я пытаюсь узнать, что это это за случаи — ты мне рассказываешь, как у вас все было плохо, но не говоришь почему. Если у тебя боттлнек в записи на диск — это проблема с данными, которые пишутся однозначно медленнее индексов. Если у тебя боттлнек в записи в озу индексов — извини, тут уже никакие переименования таблиц тебя не спасут по определению уже.
The rename operation is done atomically, which means that no other session can access any of the tables while the rename is running.
Что бы меня не обвиняли в голословности в очередной раз:
Атомарность переименования достигается эксклюзивными локами, о чем я писал, да еще и чистит кэш запросов. Кроме того, атомарность != быстрая операция.
Кстати если есть внешние ключи — после второго такого атомарного ренейма все рассыпется.
Атомарность переименования достигается эксклюзивными локами, о чем я писал, да еще и чистит кэш запросов. Кроме того, атомарность != быстрая операция.
Кстати если есть внешние ключи — после второго такого атомарного ренейма все рассыпется.
> Ты умудряешься противоречить сам себе в одном сообщении. О чем тут говорить?
Чето не вижу, где я себе противоречу. Объясни, пожалуйста. Я неосторожно упомянул, что как бы обычно все таблички минимум меньше ОЗУ. Т.е. всегда целиком туда влезают. Ты за это зацепился, мол я по ходу что-то выдумал. Я говорю - окей, ничего не изменится, если не вся влезала. Проблема никуда не исчезает, просто повышается.
> Если у тебя боттлнек в записи на диск — это проблема с данными, которые пишутся однозначно медленнее индексов.
> Если у тебя боттлнек в записи в озу индексов — извини, тут уже никакие переименования таблиц тебя не спасут по определению уже.
Проблема в записи данных в таблицу. Что включает в себя неминуемую перестройку индекса.
> Атомарность переименования достигается эксклюзивными локами, о чем я писал
Опа, ты мне открыл глаза. А я то было думал, что при переименовании часть запросов остаются работать на старой таблице, часть на новой
> Кроме того, атомарность != быстрая операция
Не медленнее, чем просто селект. В один момент времени 99 обычных потоков дают селект. Один служебный дает переименование. Как только очередь дойдет до ренейма, текущий тред поставит лок (дождется окончания исполнения начатых селектов), выполнит переименования файлов на диске и снимет лок.
В твоей же версии переименовать файлы намного тяжелее, чем штатно в реалтайме гонять записи в табличку.
> чистит кэш запросов
Кеп, в хайлоде, как правило, не юзается Query cache (отключен изначально). А уж внешние ключи тем более.
Зачем тебе в поисковой таблице внешние ключи, ума не приложу? 1С пишешь? .-)
> Я попросил привести тебе реальную ситуацию, ты упорно с одной стороны пытаешься все обобщить — с другой рассказываешь про какие-то «граничные случаи».
1. Не пытайся приписать мне того, чего нет. Я начал с того, что не рекомендовал это применять. Поэтому что-либо приводить не должен. Более того, несколько раз написал, что суть метода - как одно из поисковых решений, на равне с традиционными решениями. Нужно думать над плюсами и минусами. По результатам нашего исследования (мы не х. в форумах пинали, а тесты делали и видели, что тормоза именно из-за вставки/удаления строк, а не апдейтов или селектов) был ликвидирован корень тормозов.
2. Но раз уж ты все обкакал, окей, я готов обосновать свой метод и троллить тут с тобой хоть до посинения
Это гон. Я все довольно конкретно описал. И пример из жизни уже привели - баннерная таблица. Есть таблица с 90% чтением и 10% записью, 10 млн строк, 500 запросов в секунду. Никак не отменяя другие варианты оптимизации, которые и так знают традиционные программисты, я говорю, что было бы не плохо сделать отложенную однопоточную запись. Ты уже которую страницу гонишь, не понятно с какой целью. Хочешь что-то доказать - ну, так сделай тест, докажи. Какую конкретику ты ждешь? Я не понимаю. Просто абстрактная поисковая таблица чего либо, состоящая из id объектов и числовых аргументов, а не основной массив данных. Представь баннерную вертушку. Ты не видишь разницы между информацией, которая реальна нужна для решения "какой баннер показать пользователю" и "куча других полей о каждом баннере"? Ну, че, я эту элементарщину обсасывал на мастер-классе. Все написанное касается именно поисковых случаев.
> ты мне рассказываешь, как у вас все было плохо
У нас было все хорошо, т.к. отложенная запись на корню отключала подвисания. Без нее - ВСЕ потоки внезапно могли подвиснуть на несколько секунд, когда нагрузка превышала физические возможности сервера. Почему все висело? Мыскыль с диском игрался, не позволяя ни одному селекту выполнится до завершения этой операции (от какой-то внезапного INSERT/DELETE). С отложенной записью не было общего зависания, просто все запросы в равной степени начинали работать медленнее. Т.е. селект выполнялись не за 0.001 сек, а за 0.1. И то обрати внимание, что тормоза начинаются, т.к. CPU физически не может все селекты исполнить. Запись и апдейты как бы почти отключаются, реже записываясь на диск, не мешая им (на этой основе главная идея Pinb'ы - если в локалсетке началась жопа, все UDP пакеты со статистикой автоматически херятся, что не просто допустимо, а автоматически отключает не самый нужный функционал). Юзер этого почти не замечал. И конечно не было общего зависания в моменты переключения таблиц. Кстати, раз ты так уперся рогом, не обязательно их переименовывать. Пхп код просто может с началом нового этапа в таблицу с новым именем идти (t_01, t_02 ...), которая к тому моменту заранее создана, проиндексирована и раскочегарена в памяти (с нее сразу сделана копия в будущую таблицу).
Плохо было только то, что это костыль, хоть и полезный. Избавится от него получилось за счет pg. Мля, сколько раз тебе еще пересказать это?
Чето не вижу, где я себе противоречу. Объясни, пожалуйста. Я неосторожно упомянул, что как бы обычно все таблички минимум меньше ОЗУ. Т.е. всегда целиком туда влезают. Ты за это зацепился, мол я по ходу что-то выдумал. Я говорю - окей, ничего не изменится, если не вся влезала. Проблема никуда не исчезает, просто повышается.
> Если у тебя боттлнек в записи на диск — это проблема с данными, которые пишутся однозначно медленнее индексов.
> Если у тебя боттлнек в записи в озу индексов — извини, тут уже никакие переименования таблиц тебя не спасут по определению уже.
Проблема в записи данных в таблицу. Что включает в себя неминуемую перестройку индекса.
> Атомарность переименования достигается эксклюзивными локами, о чем я писал
Опа, ты мне открыл глаза. А я то было думал, что при переименовании часть запросов остаются работать на старой таблице, часть на новой
> Кроме того, атомарность != быстрая операция
Не медленнее, чем просто селект. В один момент времени 99 обычных потоков дают селект. Один служебный дает переименование. Как только очередь дойдет до ренейма, текущий тред поставит лок (дождется окончания исполнения начатых селектов), выполнит переименования файлов на диске и снимет лок.
В твоей же версии переименовать файлы намного тяжелее, чем штатно в реалтайме гонять записи в табличку.
> чистит кэш запросов
Кеп, в хайлоде, как правило, не юзается Query cache (отключен изначально). А уж внешние ключи тем более.
Зачем тебе в поисковой таблице внешние ключи, ума не приложу? 1С пишешь? .-)
> Я попросил привести тебе реальную ситуацию, ты упорно с одной стороны пытаешься все обобщить — с другой рассказываешь про какие-то «граничные случаи».
1. Не пытайся приписать мне того, чего нет. Я начал с того, что не рекомендовал это применять. Поэтому что-либо приводить не должен. Более того, несколько раз написал, что суть метода - как одно из поисковых решений, на равне с традиционными решениями. Нужно думать над плюсами и минусами. По результатам нашего исследования (мы не х. в форумах пинали, а тесты делали и видели, что тормоза именно из-за вставки/удаления строк, а не апдейтов или селектов) был ликвидирован корень тормозов.
2. Но раз уж ты все обкакал, окей, я готов обосновать свой метод и троллить тут с тобой хоть до посинения
Это гон. Я все довольно конкретно описал. И пример из жизни уже привели - баннерная таблица. Есть таблица с 90% чтением и 10% записью, 10 млн строк, 500 запросов в секунду. Никак не отменяя другие варианты оптимизации, которые и так знают традиционные программисты, я говорю, что было бы не плохо сделать отложенную однопоточную запись. Ты уже которую страницу гонишь, не понятно с какой целью. Хочешь что-то доказать - ну, так сделай тест, докажи. Какую конкретику ты ждешь? Я не понимаю. Просто абстрактная поисковая таблица чего либо, состоящая из id объектов и числовых аргументов, а не основной массив данных. Представь баннерную вертушку. Ты не видишь разницы между информацией, которая реальна нужна для решения "какой баннер показать пользователю" и "куча других полей о каждом баннере"? Ну, че, я эту элементарщину обсасывал на мастер-классе. Все написанное касается именно поисковых случаев.
> ты мне рассказываешь, как у вас все было плохо
У нас было все хорошо, т.к. отложенная запись на корню отключала подвисания. Без нее - ВСЕ потоки внезапно могли подвиснуть на несколько секунд, когда нагрузка превышала физические возможности сервера. Почему все висело? Мыскыль с диском игрался, не позволяя ни одному селекту выполнится до завершения этой операции (от какой-то внезапного INSERT/DELETE). С отложенной записью не было общего зависания, просто все запросы в равной степени начинали работать медленнее. Т.е. селект выполнялись не за 0.001 сек, а за 0.1. И то обрати внимание, что тормоза начинаются, т.к. CPU физически не может все селекты исполнить. Запись и апдейты как бы почти отключаются, реже записываясь на диск, не мешая им (на этой основе главная идея Pinb'ы - если в локалсетке началась жопа, все UDP пакеты со статистикой автоматически херятся, что не просто допустимо, а автоматически отключает не самый нужный функционал). Юзер этого почти не замечал. И конечно не было общего зависания в моменты переключения таблиц. Кстати, раз ты так уперся рогом, не обязательно их переименовывать. Пхп код просто может с началом нового этапа в таблицу с новым именем идти (t_01, t_02 ...), которая к тому моменту заранее создана, проиндексирована и раскочегарена в памяти (с нее сразу сделана копия в будущую таблицу).
Плохо было только то, что это костыль, хоть и полезный. Избавится от него получилось за счет pg. Мля, сколько раз тебе еще пересказать это?
Ясно.
В том, что вставки новых строк и селекты не завешивают друг-друга.. характер данных и нагрузки никак не менялись, только плавно растут все время. Из этого вывод, что большие поисковые таблицы эффективнее разместить на постгресе и оно чудесным образом будет работать в 3-4 раза быстрее. Почему так? Да хз, не разбираюсь в таких тонкостях. Пусть специалисты выдвинут предположения.
И отдельно. Я бы не рекомендовал бросать все и переводить весь проект (остальные части), т.к. все же постгрес убогое говно с дикими проблемами:
- ALTER практически не работает, вставка только новых столбцов и только в конец, существующие столбцы не изменить
- ENUM - дикие проблемы с удобством, проще выкинуть нах это бред и юзать INT + константы в php
- фичи типа " IF NOT EXISTS/SHOW *** " при создании базы или таблицы либо отсутствуют как класс, либо только-только добавлены в последнюю бету
- INSERT IGNORE не существует, INSERT с повтором ключа вызовет срачь в логи, INSERT ... OR DUPLICATE KEY UPDATE не существует, REPLACE не существует... неописуемый пипец такого масштаба, что даже просто строку в таблицу не вставить, нужно хранимые процедуры лепить.
Нам просто очень важна автоматизированная правка структуры таблиц, коих много, отсутствие подобных команд было шоком (я этого не знал, недавно выяснилось). В плане богатства синтаксиса - это как MySQL версии 1.0 *-дцать лет назад. Ну, для поисковой задачи таблички не впадлу и руками создать, настроив индексы, раз он хорошо для нужной задачи работает. И для фанатов PG сразу говорю - пожалуйста, кидание в меня рвотными пакетиками на поднятую тему в этом абзаце начинайте в другом топике, кое где я могу ошибаться...
> флоппик
> Ясно.
Позволь еще 5 копеек вставить... Я не "НЕ РЕКОМЕНДОВАЛ"! Я написал, что не буду рекомендовать никому данный костыль, но костыль сам по себе дает профит. Не надо перевирать смысл, даже если я ошибся с формулировкой. Тонкий едва уловимый момент
И отдельно. Я бы не рекомендовал бросать все и переводить весь проект (остальные части), т.к. все же постгрес убогое говно с дикими проблемами:
- ALTER практически не работает, вставка только новых столбцов и только в конец, существующие столбцы не изменить
- ENUM - дикие проблемы с удобством, проще выкинуть нах это бред и юзать INT + константы в php
- фичи типа " IF NOT EXISTS/SHOW *** " при создании базы или таблицы либо отсутствуют как класс, либо только-только добавлены в последнюю бету
- INSERT IGNORE не существует, INSERT с повтором ключа вызовет срачь в логи, INSERT ... OR DUPLICATE KEY UPDATE не существует, REPLACE не существует... неописуемый пипец такого масштаба, что даже просто строку в таблицу не вставить, нужно хранимые процедуры лепить.
Нам просто очень важна автоматизированная правка структуры таблиц, коих много, отсутствие подобных команд было шоком (я этого не знал, недавно выяснилось). В плане богатства синтаксиса - это как MySQL версии 1.0 *-дцать лет назад. Ну, для поисковой задачи таблички не впадлу и руками создать, настроив индексы, раз он хорошо для нужной задачи работает. И для фанатов PG сразу говорю - пожалуйста, кидание в меня рвотными пакетиками на поднятую тему в этом абзаце начинайте в другом топике, кое где я могу ошибаться...
> флоппик
> Ясно.
Позволь еще 5 копеек вставить... Я не "НЕ РЕКОМЕНДОВАЛ"! Я написал, что не буду рекомендовать никому данный костыль, но костыль сам по себе дает профит. Не надо перевирать смысл, даже если я ошибся с формулировкой. Тонкий едва уловимый момент
Ну справедливости ради, хотя я далеко не фанат постгреса
1) ALTER работает в рамках ANSI SQL, изменить-то всё (кроме порядка полей, к сожалению) можно, но не так удобно, как в mysql, где синтаксис идентичен create table. Скажем, задача синхронизации структуры двух таблиц решается куда сложнее, на порядок. Но решаема таки, надо парсить information schema и генерить нужные alter-ы. Идея хранить структуру таблицы в виде простого create table SQL отпадает (ну то есть придется писать неоправданно сложный парсер), надо либо выдумывать более удобный для парсинга формат (xml какой-нить, например), либо держать эталонные таблицы в отдельной базе/схеме.
2) Enum в 9.1 таки починили: можно добавлять элементы
4) частично решаемо через create rule, частично через with; без хранимок обходился пока (хотя, конечно, insert, который неявно может сделать update - это то еще западло). В мыскле конечно удобнее.
1) ALTER работает в рамках ANSI SQL, изменить-то всё (кроме порядка полей, к сожалению) можно, но не так удобно, как в mysql, где синтаксис идентичен create table. Скажем, задача синхронизации структуры двух таблиц решается куда сложнее, на порядок. Но решаема таки, надо парсить information schema и генерить нужные alter-ы. Идея хранить структуру таблицы в виде простого create table SQL отпадает (ну то есть придется писать неоправданно сложный парсер), надо либо выдумывать более удобный для парсинга формат (xml какой-нить, например), либо держать эталонные таблицы в отдельной базе/схеме.
2) Enum в 9.1 таки починили: можно добавлять элементы
4) частично решаемо через create rule, частично через with; без хранимок обходился пока (хотя, конечно, insert, который неявно может сделать update - это то еще западло
). В мыскле конечно удобнее.В реальности претензия должна звучать как "ALTER не позволяет менять порядок столбцов".
Потому что в остальном возможности не беднее мыскля....или делать таблицы-справочники руками. В конечном счёте, ENUM так и работает.
Ну drop ... if exists добавлен уже несколько лет назад, про последнюю бету заливать не надо. show ... нет и не будет, пользуйте information_schema.
А вот это претензия вполне реальная, действительно нету "upsert"ов. Проблема ещё в том, что копировать мысклёвый синтаксис и поведение никто не планирует (особенно в плане insert ignore), а сделать стандартную команду MERGE достаточно сложно. Хотя насколько я понимаю, сейчас это будет чуть проще из-за изменений в 9.1 связанных с блокировками по предикатам.
Ну вот не надо про богатство синтаксиса.
В реальной работе 99.999...% --- запросы DML, и только 0.0...01% --- DDL. А в плане DML Постгрес существенно побогаче будет. Ну а вам может иметь смысл какой-нить промежуточный формат для определения структуры иметь, и через него уже автоматически делать скрипты изменения. Вот, например: http://pgxn.org/dist/pyrseas/Не очень честный подход, когда свою порцию рвотных пакетиков ты вываливаешь в одной теме, а ответную "просишь" в другую.
