ещё одна претензия к mysql

hwh2010

Был тут тред про LAMP и другие технологии, я там предъявил несколько претензий к mysql, но они все были в пределах разумного.
Однако, сегодня я столкнулся с особенностью mysql (а, точнее, InnoDB от которой просто выпал в осадок.
Оказывается, если создать базу, положить в неё 200G данных, а потом удалить, то файл на жёстком диске раздуется на 200G, а обратно не сдуется. И нет другого способа уменьшить его обратно, кроме как ВСЕ базы, вертящиеся в том же Tablespace, складировать в виде дампа, а потом заново залить.
вот и всё.
в рот мне ноги, фак мой мозг.

pitrik2

да не
ну должна же быть команда чтобы сдуть
в оракле тоже не сдуется, но есть команда чтобы сдуть

hoha32

ваще-то команда есть

hwh2010

ваще-то команда есть

Подскажешь?

hoha32

OPTIMIZE TABLE
я ламо в БД, но когда у меня порезанная БД на 600 мегов так и не стала ужиматься, я понял что надо ботать документацию по администрированию %)

hwh2010

OPTIMIZE TABLE

и какой TABLE прикажешь OPTIMIZE? Я удалил не только толстую таблицу, но и всю базу, её содержащую.

dgaf

>а обратно не сдуется
а почему должен? мне не очевидно
к сведению: innodb не принадлежит mysql(sun это собственность oracle.

hoha32

значит, у меня MySQL не по той системе работает

hwh2010

а почему должен? мне не очевидно

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

к сведению: innodb не принадлежит mysql(sun это собственность oracle.

мне это неинтересно. мне интересно, что у меня на машине 20 Г данных занимают 220 Г места, а из-за этого я не могу дамп в постгрес закачать. Который, кстати, общественный, а потому место освобождает без бубна.

hwh2010

значит, у меня MySQL не по той системе работает

по идее можно было изначально сказать: "ребята, каждая таблица в своём файле". У меня такого сделано не было (по независящим от меня причинам). Впрочем, я считаю, что и в режиме "всё в одном файле" такого безобразия происходить не должно.

dgaf

пиши фичереквест
кстати, быстрее было бы сделать alter в myisam, потом обратно, чем через дамп

hwh2010

пиши фичереквест

горбатого могила исправит.

кстати, быстрее было бы сделать alter в myisam, потом обратно, чем через дамп

не "бы" а может быть так и сделаю, спасибо
но вот не уверен: там таблиц до жопы может быть, да и нет ли свойств, которые могут потеряться при конвертировании?

katrin2201

да и нет ли свойств, которые могут потеряться при конвертировании

foreign key и прочее констрейновое добро должно проипаться

shlyumper

а из-за этого я не могу дамп в постгрес закачать. Который, кстати, общественный, а потому место освобождает без бубна.

Постгрес общественный, но местами - такое же говно. Например, почитай, что нужно делать, когда у них меняется формат метаданных на диске между версиями постгреса. Такое происходит не так уж и редко - раз в несколько лет. Чтобы чтение было более увлекательным, представь, что у тебя в этом постгресе данных, скажем, гигов 800.

sinet

Я наступил на эти же грабли.
innodb_file_per_table конечно спасет, но без экспорта/импорта не преобразовать. >_<

sinet

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

dgaf

так innodb не их разработка -)

NAIL

Ну будет урок что надо таблицы в разных файлах хранить.
А там уже разумно что после delete место не освобождается, ибо там же данные физически лежат аки праймари кей, что даёт бонусы при селектах. В общем претензия не к mysql а к своему неразумному прошлому

sinet

А там уже разумно что после delete место не освобождается, ибо там же данные физически лежат аки праймари кей, что даёт бонусы при селектах.

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

В общем претензия не к mysql а к своему неразумному прошлому

Претензия к отсутствию функионала. Индексы тоже можно перестраивать, если данные таблицы перемещаются.

hwh2010

Ну будет урок что надо таблицы в разных файлах хранить.

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

А там уже разумно что после delete место не освобождается, ибо там же данные физически лежат аки праймари кей, что даёт бонусы при селектах.

тем не менее после dump-restore они лежат по-другому. Значит mysql не за бонусами гонится, а просто ленится (и не даёт) что-то менять.

Dasar

А там уже разумно что после delete место не освобождается, ибо там же данные физически лежат аки праймари кей, что даёт бонусы при селектах. В общем претензия не к mysql а к своему неразумному прошлому

я правильно понял, что если мы используем таблицу с primary key по времени - каждый день в нее активно добавляем кучу записей с сегодняшней датой, а старые(например, старше месяца) удаляем, то это таблица будет бесконечно расти?
и ты считаешь, что это нормальное поведение базы?

sinet

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

Вообще-то от того что ты удалишь файл, размер раздела не изменится.
Пример с файловой системой совсем не в тему.

sinet

Нет. Пустое место повторно используется. Он про то, что оставшиеся данные при delete не передвигаются, ибо на них ссылаются индексы.

hwh2010

Вообще-то от того что ты удалишь файл, размер раздела не изменится. Пример с файловой системой совсем не в тему.

ну да, не удалась аналогия.
скорее в тему жалоба программы, которые не возвращают память ОС (и которую можно вернуть, только перегрузив комп а в ответ предложение запускать их на разных машинах.

Dasar

Нет. Пустое место повторно используется. Он про то, что оставшиеся данные при delete не передвигаются, ибо на них ссылаются индексы.

каким образом оно используется, если вставка идет в конец, а место в начале, и данные не передвигаются?

sinet

А кто сказал, что вставка идет в конец?

Dasar

А кто сказал, что вставка идет в конец?

потому что primary key по времени и кластерный.
а записи добавляются по увеличению времени.

sinet

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

Dasar

все, согласен
согласен, что
переиспользование места(на уровне кусков) делается легко,
освобождение места(на уровне кусков) - делается тоже легко, но разработчики обычно ленятся,
дефрагментация - делается сложно.

kruzer25

Представь себе, что ты хранишь файлы на жёстком диске, потом удаляешь, а место не освобождается.

Вообще-то, с использованинем этой аналогии - так и есть. Ты удалил файлы - а данные на винчестере остались. Записал новые файлы - данные на винчестере изменились.
Так и тут - если была таблица на 800М, потом её удалили, а файл по-прежнему весит 800М - наверняка можно создать новую таблицу и напихать в неё на 800М данных, и файл не распухнет.

kruzer25

дефрагментация - делается сложно.

Как на уровне разработчика, так и на уровне пользователя (по времени).

Marinavo_0507

проще всего наверное было бы написать прогу, которая в оффлайне найдёт в файле ненужные страницы, и сделает там дыры
только я не помню, есть уже в линуксе сисколл, делающий дыру
но если нет, тоже не очень страшно