varchar приводит к хиту производительности из-за фрагментации данных?
Как varchar столбцы обрабатываются внутренне механизмом базы данных? Для столбца, определенного как символ (100), DBMS выделяет 100 непрерывных байтов на диске. Однако для столбца, определенного как varchar (100), который, по-видимому, не имеет место, так как, смысл varchar не должен больше выделять место, чем необходимый для хранения фактического значения данных, сохраненного в столбце. Так, когда пользователь обновляет строку базы данных, содержащую пустой varchar (100) столбец к значению, состоящему из 80 символов, например, где делает пространство для тех 80, символы выделяются от? Кажется, что varchar столбцы должны привести к изрядному количеству фрагментации фактических строк базы данных, по крайней мере, в сценариях, где значения столбцов первоначально вставляются как пробел или ПУСТОЙ УКАЗАТЕЛЬ, и затем обновляются позже с фактическими значениями. Эта фрагментация приводит к ухудшенной производительности на запросах базы данных, в противоположность использованию символьных значений типа, где место для столбцов, сохраненных в строках, выделено непрерывно? Очевидно, использование varchar приводит к меньшему дисковому пространству, чем использование символа, но является там хитом производительности при оптимизации для производительности запросов, специально для столбцов, значения которых часто обновляются после начальной вставки?
6 ответов
Структуры данных, используемые в ядре базы данных, намного сложнее, чем вы думаете! Да, есть проблемы фрагментации и проблемы, при которых обновление varchar с большим значением может привести к снижению производительности, однако трудно объяснить / понять, каковы последствия этих проблем, без более полного понимания задействованных структур данных.
Для Сервер MS Sql, возможно, вы захотите начать с понимания страниц - основной единицы хранения (см. http://msdn.microsoft.com/en-us/library/ms190969.aspx )
В терминах Из-за влияния исправлений на производительность и типов хранилища переменных на производительность необходимо учитывать ряд моментов:
- Использование столбцов переменной длины может повысить производительность, поскольку позволяет разместить большее количество строк на одной странице,
В своем вопросе вы делаете много предположений, которые не обязательно верны.
Тип столбца a в любой СУБД вообще ничего не говорит вам о характере хранения эти данные, если в документации четко не указано, как они хранятся. ЕСЛИ это не указано, вы не знаете, как он хранится, и СУБД может свободно изменять механизм хранения от выпуска к выпуску.
Фактически, некоторые базы данных хранят поля CHAR внутри как VARCHAR, в то время как другие принимают решение о том, как сохранить столбец на основе заявленного размера столбца. Некоторые базы данных хранят VARCHAR с другими столбцами, некоторые с данными BLOB, а некоторые реализуют другое хранилище. Некоторые базы данных всегда перезаписывают всю строку при обновлении столбца, другие - нет. Некоторые заполняют VARCHAR, чтобы обеспечить ограниченное обновление в будущем без перемещения хранилища.
СУБД отвечает за выяснение того, как хранить данные и возвращать их вам быстро и согласованно. Меня всегда удивляет, сколько людей пробуют использовать базу данных, как правило, до обнаружения каких-либо проблем с производительностью.
В SQL Server varchar (за исключением varchar (MAX)) обычно хранится вместе с остальными данными строки (на той же странице, если данные строки <8 КБ, и в том же экстенте, если это <64 КБ. Только большие типы данных, такие как TEXT, NTEXT, IMAGE, VARHCAR (MAX), NVARHCAR (MAX), XML и VARBINARY (MAX), хранятся отдельно.
Ответ будет зависеть от конкретной СУБД. Для Oracle, безусловно, можно получить фрагментацию в виде «связанных строк», что приведет к снижению производительности. Однако вы можете смягчить это, предварительно выделив некоторое пустое пространство в блоках таблицы, чтобы обеспечить некоторое расширение из-за обновлений. Однако столбцы CHAR обычно делают таблицу намного больше, что имеет собственное влияние на производительность.
Это будет полностью зависеть от базы данных.
Я знаю, что в Oracle база данных резервирует определенный процент каждого блока для будущих обновлений (параметр PCTFREE). Например, если для PCTFREE установлено значение 25%, то блок будет использоваться только для новых данных, пока он не будет заполнен на 75%. Таким образом, остается место для роста рядов. Если строка растет так, что 25% зарезервированного пространства полностью израсходованы, то в конечном итоге вы получаете цепочки строк и снижение производительности. Если вы обнаружите, что таблица имеет большое количество связанных строк, вы можете настроить PCTFREE для этой таблицы. Если у вас есть таблица, в которой вообще никогда не будет обновлений, значение PCTFREE, равное нулю, будет иметь смысл
Ваш вопрос слишком общий, потому что разные механизмы баз данных будут вести себя по-разному. Если вам действительно нужно это знать, я предлагаю вам настроить тест, чтобы записать большое количество записей и рассчитать время. Вам нужно, чтобы на запись у вас ушел не менее часа.
Как вы предложили, было бы интересно посмотреть, что произойдет, если вы напишете вставить все записи с пустой строкой (""), а затем обновите их, чтобы 100 символов, которые являются достаточно случайными, а не просто 100 X.
Если вы попробуете это с SQLITE и не увидите существенной разницы, то я думаю, маловероятно, что более крупные серверы баз данных со всем анализом и настройкой, которые проводятся, будут хуже, чем SQLITE.