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

[radiante]

Переиндекция данных в mysql занимает время, особенно если база очень большая, а добавилась/изменилась всего одна запись. Как часто и в какой момент происходит переиндексация, т.к. понятно что нет смысла это делать после каждого изменения значения какого та поля. Можно ли и как это настроить прозрачно чтобы сам движок mysql переиндексировал какую то таблицу или конкретный столбец раз в какой та период или лучше беспрерывно (новая переиндексация сразу после окончания предыдущей) на низком приоритете процесса, чтобы сервер не тормозил. Другими словами чтобы движок как только закончит предыдущую переиндексацию, начинал новый цикл без блокировки таблиц, например создав копию данных в другом месте, и сделав все, заменил старые индекс данные, на новые. Или все таки нужно это делать самому, добавляя новые данные в другую таблицу, пока основная переиндексируется, а потом делать слияние? Если че та не так пишу, объясните как все это реально происходит и как лучше сделать. Спасибо!

Mysql 5.1.49
innoDB и MyISAM
Поля: int,timestamp,text,varchar
10 млн строк в таблице
Insert 1000 строк в час
Update 5000 строк в час
Select 100 тыс строк в час

 

[zerkms]

Индекс перестраивается автоматом при модификации данных.

 

[radiante]

Индекс перестраивается автоматом при модификации данных.

А есть конкретные данные по скорости? Индекс это упорядочивание элементов массива, это полюбому надо время. Если в базе миллионы записей, то изменение даже одной вызывает пересортировку индексов, кто то знает другой способ? Именно поэтому на крупных проектах после добавления записи ее сразу нельзя найти через поиск этого же проекта. Кто понимает о чем я опишите плиз реальные данные по времени таких операций.

 

[zerkms]

Если запись добавляется - тогда значение вставляется в необходимое место. Весь миллион строк при этом не трогается.

Судя по всему ты таки не очень понимаешь о чём говоришь (не об индексах mysql, а о внешнем ПО)

 

[radiante]

Если запись добавляется - тогда значение вставляется в необходимое место. Весь миллион строк при этом не трогается.

Судя по всему ты таки не очень понимаешь о чём говоришь (не об индексах mysql, а о внешнем ПО)

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

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

 

[zerkms]

radiante
При изменении одного значения не нужно перестраивать весь индекс, нужно лишь переместить изменившееся значение.

 

[флоппик]

видимо это ты не понимаешь как индекс устроен. их индексы надо полностью пересортировать

Бред. В мускуле индексы типа btree - ничего не «сдвигается», добавляется новое значение в дерево, и на него устанавливаются указатели от других записей в индексе.

 

[radiante]

radiante
При изменении одного значения не нужно перестраивать весь индекс, нужно лишь переместить изменившееся значение.

куда переместить?))) я же описал уже что нельзя просто взять и вставить значение в память между двумя другими не сдвинув область памяти до или после! если ты попробуешь описать технически алгоритм и механизм то поймешь что ты говоришь ересь просто)

 

[radiante]

Бред. В мускуле индексы типа btree - ничего не «сдвигается», добавляется новое значение в дерево, и на него устанавливаются указатели от других записей в индексе.

а ты знаешь что такое btree на низком уровне? это способ сдвигать не не всю область памяти, чтобы что то вставить, а только какую то небольшую часть, за счет разбиения всего на эти части и описания этих частей в древовидной структуре с помощью набора указателей в отдельной от базы области памяти. а вы знаете хоть последствия такой структуры? те же самые накладные расходы на операцию update/insert. только чем больше заранее резервируется памяти под новые добавления и чем "чаще" ветви у дерева, тем быстрее вставка будет, но больше фрагментация и объем требуемой памяти.

 

[флоппик]

«На низком уровне» никакая память не сдвигается, сдвигаются указатели на область памяти.

а ты знаешь что такое btree на низком уровне? это способ сдвигать не не всю область памяти, чтобы что то вставить, а только какой то небольшой кусок, за счет разбиения всего на части и описания этих частей в древовидной структуре с помощью набора указателей в отдельной от базы области памяти. а вы знаете хоть последствия такой структуры? те же самые накладные расходы на операцию update/insert. только чем больше заранее резервируется памяти под новые добавления и чем "чаще" ветви у дерева, тем быстрее вставка будет, но больше фрагментация и объем требуемой памяти.

a) время поиска внутри узла совершенно никого не интересует, потому что оно в миллион раз меньше времени считывания блока с диска
б) данные с классического HDD считываются поблочно
в) именно размером блока определяется то, сколько в нём будет ключей, а не тем, сколько у нас там оперативной памяти. Размер буфера RAM влияет конечно же на то, сколько узлов диска в него поместится, но не размер самого узла

 

[zerkms]

куда переместить?))) я же описал уже что нельзя просто взять и вставить значение в память между двумя другими не сдвинув область памяти до или после! если ты попробуешь описать технически алгоритм и механизм то поймешь что ты говоришь ересь просто)

Отлично просто - пойду таблицы по несколько сотен миллионов записей выкину, потому что, на самом деле, вставка значения и перестроение индекса там занимают не доли секунды, а часы. Отлично. Спасибо, чувак, ты мне открыл глаза!

 

[radiante]

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

 

[флоппик]

Не пиши здесь больше бред, пожалуйста.

 

[zerkms]

В mysql такого нет. В mysql индексы перестраиваются сразу.

 

[radiante]

Отлично просто - пойду таблицы по несколько сотен миллионов записей выкину, потому что, на самом деле, вставка значения и перестроение индекса там занимают не доли секунды, а часы. Отлично. Спасибо, чувак, ты мне открыл глаза!

ты что, я не говорил что в реальности это будет так долго, выбирают компромисс, поясню на очень простом примере: Отсортирован 1 GB , надо вставить число 4 байта, сразу находим между какими ячейками в памяти (посередине например) и сдвигаем 500 MB вперед) вместо же этого можно разбить этот гиг на 100 тыс частей по 10 KB. При вставке нужного значения, нужно будет переместить максимум половину такого участка, т.е. 5 KB. уже быстрее. Еще лучше это делают с помощью дерева как тут правильно сказали. И получается более менее нормально. Я же спрашивал о другом, о том что настройка любой сложной системы по умолчанию всегда хуже чем подстройка под конкретные нужны, особенно в БД ! handlersocket например, ну совершенно не гибок в использовании но для конкретных задач увеличивает скорость работы с mysql в десять раз, именно потому что он и есть подстройка под конкретные нужны.

 

[zerkms]

HS не подстройка, а просто урезанный интерфейс.

 

[radiante]

Не пиши здесь больше бред, пожалуйста.

вот не надо только этого. если ты хоть немного бы представлял алгоритм на низком уровне не писал бы так, представь у меня все в оперативке, 100 GB, все забито строками из примари ки и даты, запускаем цикл меняющий даты в строках, выбирая строки и даты рандомом и чтение ID по дате после каждого обновления даты (тоже рандомом). Раз так миллиард эту операцию сделать, а потом сравнить время потраченное на это с временем на миллиард раз чтения без индексации, т.е. с чтением даты по ID. эх вы опупеете тогда у меня на разницу))) если кто то думает что он очень умный пусть опишет алгоритм быстрого решения этой задачи, возьму на работу в сша)))

 

[radiante]

HS не подстройка, а просто урезанный интерфейс.

так это и есть подстройка))) что значит это слово по твоему в данном контексте ? удаление ненужных операций для ускорения более простых запросов, т.е. уменьшение накладных расходов. Если у сайта(системы) именно такие запросу в БД, то такой плагин ему как раз самое то, поэтому это и называют подстроили систему под определенные задачи, более узкого профиля, в результате стало быстрее, вот и мне надо тоже самое.

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

 

[zerkms]

radiante
Нет, это не удаление ненужных операций. Это просто другой интерфейс доступа к SE.

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

В чём тогда смысл твоего здесь нахождения? Идите и делайте эффективнее, ок.

 

[radiante]

radiante
Нет, это не удаление ненужных операций. Это просто другой интерфейс доступа к SE.

В чём тогда смысл твоего здесь нахождения? Идите и делайте эффективнее, ок.

как это не удаление, плагин как раз и дает прямой доступ к индексам, в обход гибкого но поэтому и тормозного интефейса mysql. например HS не делает парсинг SQL запроса, т.е. можно сказать что эта операция им была удалена из решения задачи. Это и есть подстройка (или другой вариант решения задачи). переиндексация раз в час в конкретной задаче, так же даст многократное увеличение производительности. поймите на низком уровне при N строках либо дерево надо сделать размером N в квадрате деленое на 2 для максимальной скорости переиндексации всех данных, либо выбирать компромисс, при котором update поля с индексом, будет во много раз медленнее чем update поля без индекса. главное выбрать наилучший компромисс, а его движок выбирает сам, но лучший результат будет если подстроить самому под свои конкретные нужды.

а смысл получить ответ от тех кто знает больше меня.