Переиндексация. Подскажите как лучше сделать?

zerkms

TDD infected
Команда форума
как это не удаление, плагин как раз и дает прямой доступ к индексам, в обход гибкого но поэтому и тормозного интефейса mysql. например HS не делает парсинг SQL запроса, т.е. можно сказать что эта операция им была удалена из решения задачи.
операция не была удалена, она просто не была добавлена. потому что это самостоятельный интерфейс.

вам нужно ручное управление частотой индексации - стройте индексы внешними инструментами, тем же сфинксом. раз в час или раз в сутки.

ну и на всякий случай повторю в третий раз (а то вдруг вы прошлые 2 раза прочитали, а понять не смогли): в mysql способом управления построения индексами нет, в нём индексы или битые, или соответствуют данным.
 

iceman

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

DiMA

php.spb.ru
Команда форума
Ну вы тролли...

Итак, объясняю на пальцах. В базе имеется 1М значений. Вставляем новое в середину. При этом с вероятностью 90% (точных чисел не знаю) не будет происходить больших изменений данных и операция выполнится мгновенно, т.к. в индексе заранее предусмотрена дырка для вставок. Если при вставке все такие предусмотренные дырки в btree заполнить, то пойдет большое обновление индекса с сохранением новых дырок на будущее.

Вставка новых строк в таблицы это дорогая операция, т.к. перестраиваются индексы. Поэтому вставки новых строк имеет смысл оптимизировать хотя бы простейшим образом - собирать в пачки и делать один большой инсерт.

Другой извращенный вариант такой: из одной таблицы только читаем, а изменения накатываем в другую, потом мгновенно переименовываем обе таблицы (раз в минуту такое делаем). Профит в том, что пока в течении минуты накатываем изменения в другую таблицу, она иногда подвисает из-за перестроения индексов, зато первая таблицы для чтения работает без тормозов. Как только прошла минута, тормозим внесения изменений и в нее (ждем чуток окончания апдейтов индексов и тормозов жесткого диска), атомарно переименовываем обе таблицы, с новой работающей таблицы делаем неспешно копию в во вторую таблицу и повторяем... Я совершенно не рекомендую так делать, подойдет под специфические задачи, где большая таблица с кучей чисел, индексов, от 1М записей, практически некешируемых select запросов. И, конечно, проще не извращаться, а поставить слейвы, либо обратиться к че... просто горизонтальному масштабированию и разбить таблицу на более мелкие .-)
 

флоппик

promotor fidei
Команда форума
Партнер клуба
подойдет под специфические задачи, где большая таблица с кучей чисел, индексов, от 1М записей, практически некешируемых select запросов.
Это что ли специфическая задача? И как таблица с кучей чисел и индексов может иметь некешируемые селекты? Бред какой-то. Я просто сколько вижу сообщения Димы, он всегда решает «специфические задачи, которых вам не понять» на пять листов кода, которые у всех всегда решались парой строчек.
 

DiMA

php.spb.ru
Команда форума
затем, что это работающий способ, экономит одни ресурсы за счет перерасхода других
 

zerkms

TDD infected
Команда форума
А мы вообще на оракле - там и индексы собираются когда нам нужно, и селекты не блокирующиеся )
 

флоппик

promotor fidei
Команда форума
Партнер клуба
То что способ работает, не говорит о том, что он нормальный. Если какой-то архитектурный элемент уперся в свой технический потолок, надо не мистические велосипеды городить, а менять архитектуру этого элемента.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
флоппик, тут я с тобой не согласен.
решения выбираются исходя из экономической целесообразности в текущий момент.
на переписывание подсистемы хранения может просто не быть времени - проект должен продолжать работать сегодня,

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

DiMA

php.spb.ru
Команда форума
> Я просто сколько вижу сообщения Димы, он всегда решает «специфические задачи, которых вам не понять» на пять листов кода, которые у всех всегда решались парой строчек.

Ты уже наверно пятый раз толкаешь свою профанскую мысль, смысл которой: "я до этого раньше не додумывался, нах оно надо". Я уже отвечал, с примерами, в соседнем топике. Сколько раз еще ты собираешься эту мысль толкнуть?

> Если какой-то архитектурный элемент уперся в свой технический потолок

Спасибо кеп. Мы такие дураки, не знали, что кроме велосипедов существуют и культурные (традиционные) методы решать задачи.

Смысл программиста на любую задачу придумать десяток решений. Далее проанализировать плюсы и минусы каждой. Описанный метод из разряда, как выцепить из железа больше нагрузки, чем можно. Я могу еще много чего понаписать на этой почве. То, что ты изойдешься на сарказм, сути не меняет. В некоторых задачах для некоторых таблиц эффективнее постгрес воткнуть, быстрее в 5 раз мыскля, причем даже без репликации справляется.

> То что способ работает, не говорит о том, что он нормальный.

Хайлод, деточка, сплошь из ненормальных способов состоит. Я это тактично называют нетрадиционным подходом, а программистов не в теме - традиционными программистами.

Пипец, короче... опять развели на 2 страницы срачь, троллинг и оффтоп. Вместо советов автору топика как победить тормоза индексов, мало того что по-человечески не объяснили структуру индекса, не предложили ни малейшего варианта, так еще и первый же совет по прямому решения проблему обкакали. Ну, видно же, не заинтересован ты в решении проблемы, зачем же в тему лесть, может эффективнее в тряпочку помолчать?
 

iceman

говнокодер
DiMA
видимо это ты не понимаешь как индекс устроен.
, единственный способ это сделать отсортировать все значения даты в памяти по порядку и рядом с каждым значением написать ID строки где указана эта дата (т.е. будут пары чисел по 4 байта каждое, всего 8 MB).
единственный! другое он (ТС) не хочет рассматривать.

ТС основываясь на своих доводах, которые начал втирать собеседникам.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
это один из нечастых, к сожалению, случаев, когда DiMA описал реальный интересный и необычный алгоритм, спасибо
Посчитай стоимость создания копии мега-таблицы с теми же индексами,и цену сведения записей — я готов спорить что затраченные ресурсы превысят затраты на обычный апдейт индексов при вставке. Опять таки, описанное Димой решение ничто иное как «делаем слейв вручную» — зачем делать руками то, что можно и так делать автоматически - непонятно. О том, что делать, если ресурсов для слейва нет, и почему никто не видел приближающуюся жопу заранее говорить не будем, согласен. Ситуации всякие бывают. Однако вот это выдача крайне кривых костылей «под очень специфичный случай», которого что важно нет, и он не обсуждается, за божественное решение — я категорически против.
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Кстати, гораздо проще сделать PARTITION BY HASH(col) ибо индексы будут писаться для каждой партиции отдельно, что даст тот же эффект, но без лишних танцев с костылями.
 

DiMA

php.spb.ru
Команда форума
> ТС основываясь на своих доводах, которые начал втирать собеседникам

Разумеется, бредни ТС никак я не защищаю. В чем проблема объяснить нормально? Фаната на вас не хватает.

> Посчитай стоимость создания копии мега-таблицы

Довольно низкая. Тем более она целиком в ОЗУ и чтение всей таблицы ничего от других селектов не отличается. Копию можно сделать с нерабочей таблицы перед атомарным переименованием. Ты бы пораскинул чуток мозгами, окей? Даю подсказку. Куча запросов ломится в одну таблицу на чтение. Когда нагрузка зашкаливает, это все начинает просто чуток подтормаживать, но не висеть. Мелкие тормоза некоторых потоков с полсекунды вполне допустимы (кому как, конечно). Но если в эту таблицу пойти писать (изменять число строк, т.е. заставлять индексы перестаиваться), то произойдет подвисание на значительное время - порядка 10 секунд для ВСЕХ потоков, всего проекта сразу. Основные тормоза в этом процессе связаны с жестким диском (да и почти всегда, тормоз только он). Так вот, мы просто все операции с диском переносим в фоновый режим. Отдельный тред мыскля исполняет неспешно вставки, удаление и копирование, не отнимая ресурса у читающих потоков. При пересчете индекса будет висеть только служебный тред, работающий с изолированной таблицей, никак не касающийся 99 других рабочих тредов с запросами (ну, конечно, будет отнимать 1 % нагрузки CPU у всех, наравне, и 100% HDD).
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Тем более она целиком в ОЗУ
Внезапно. Придумывать на ходу граничные условия это как-то...Если у тебя тормозят селекты на таблице, которая целиком в ОЗУ, лок на всю таблицу(x2) для ее переименования тебя не спасет, а только ухудшит ситуацию, либо набив очередь кучей селектов ожидающих таблицу, либо у тебя будут отказы. Повторюсь, чем не угодил классический слейв в таком случае? Или партиционирование по индексу?
 

флоппик

promotor fidei
Команда форума
Партнер клуба
Кроме того, если это вдруг внезапно(!) окажется ndbcluster - индексы в нем хранятся в t-tree, поэтому не канает.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
флоппик речь шла не о селектах, а об очень интенсивных инсертах
например, крутилка рекламы - большой поток записей обо всех показах, их надо тщательно обрабатывать, и задержка в пол-часа некритична, но поток данных большой
 

флоппик

promotor fidei
Команда форума
Партнер клуба

флоппик

promotor fidei
Команда форума
Партнер клуба
например, крутилка рекламы - большой поток записей обо всех показах, их надо тщательно обрабатывать, и задержка в пол-часа некритична, но поток данных большой
Такие вещи пишутся в таблицу вообще без индексов, и индексируются в другой, а часто и просто в уже аггрегированной таблице.
 
Сверху