Чего-то лень делать insert, delete. хочется делать простые update, и чтобы после этих update селекты работали нормально по скорости. В общем хочу минимум: Часть полей сделать фиксированного размера (чары), часть плавающего (тексты и блобы). Хочу максимум: Все поля сделать плавающего размера, с указанием минимального размера для каждого поля (чтобы при изменениях в пределах этого размера не происходило фрагментации, но была возможность пихать данных больше этого размера). MyISAM, но вообще мне наверное все равно что использовать.
Ну как это делается)). Простая вещь наверное).. Я просто мануалы по mysql смотрел прошлый раз лет 13 назад, в то время функионал минимум реализовывался через char (в альтернативу varchar), и text, blob. Сейчас как я поинмаю char и varchar обрабатывается одинаково, и обработка зависит от типа таблицы - dynamic, fixed. Но разумно предполагать что за 13 лет развития MySQL появились и более подходящие алгоритмы управления, аналогичные тому, что я бы хотел в сценарии максимум. Понятно, что я это могу реализовать через workaround, но хотелось бы без костылей. Грубо говоря.. у 95% строк некоторое поле занимает до 1кб. Но у оставшихся 5% может достигать 20-30кб. Нужно, чтобы база данных при создании строки сразу же резервировала 1кб под это поле (и тогда апдейты в пределах этого размера не приведут к фрагментации строки), но при этом позволяла впихнуть в поле до 30кб.
и т.д Код (Text): CREATE TABLE `table` ( `id` int(10) unsigned NOT NULL AUTO_INCREMENT, `title` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL, `body` text COLLATE utf8mb4_unicode_ci NOT NULL, `created_at` timestamp NULL DEFAULT NULL, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Сам додумался. Работает намного быстрее. Плюс нет фрагментации. В каком-то проекте лет 10 назад делал. На обычном HDD таблица MyISAM делает более тысячи Insert+Delete в секунду, тогда как Update около 50 в секунду. Если формат фиксированный, то выжрет место на диске. по 65кб с строки. Если динамический, то при апдейтах в сторону увеличения размера строки будет фрагментация строк.
@mirosas так а вопрос в чем? вот список типов выбирай по необходимости https://www.w3schools.com/sql/sql_datatypes.asp
Нужна информация, как использовать MySQL, чтобы он выделял под строку, либо поля в строке некоторое задаваемое программером место (в байтах), но при этом позволял занять большее место, чем определено (этакий гибрид fixed и dynamic полей). Если такого нет в MySQL, то другую БД, простую к освоению и коннекту с php где это есть. Если и такого нет, то просто информацию что такого нет, чтобы я просто сделал workaround. Но если ничего такого нет, то хотелось бы не делать воркэраунд, а зафиксировать размеры чаров, и сделать плавающим размер text. Ежели я не ошибаюсь, то в современном MySQL char(255), вовсе не означает, что под поле выделено нужное место, если только не задан тип таблицы - fixed. Но если задать тип таблицы fixed - то под text (50000) будет выделено по 50кб, что ни к чему. Что касаемо типов, то это 13 лет назад так было. Сейчас даже char и varchar работают по другому, в зависимости от типа таблицы. Я ожидаю, что за 13 лет появились какие-то особые режимы работы таблиц, которые позволяют более гибко подходить к вопросу фиксированных и динамических полей. Если за 13 лет у MySQL только размеры файлов выросли и занимаемое место в оперативке, ну значит так. Если же и функционал подрос в нужной мне составляющей, то интересно как его использовать. Может какие-то другие базы данных работающие с php делают то, что мне нужно, тогда интересно какие.
Ну я так понял: 1. хотелки максимум не реализованы ни в MySQL, ни в других б.д. подключаемых к пхп. 2. часть полей сделать фиксированного размера, часть плавающего не получится. грустно.. но на хостинге все равно ssd стоит, нагрузки в финальной версии большие не предвидятся (при ускоренной обработке на своем пк валилось все), так что пофиг.
там собирать нечего. select, update (то, что селектнуто, с целью пометить, что задача поступила в обработку и ее не нужно брать другим процессам), затем обработка (около секунды), затем снова update (того же, что селектнуто). Все это в 50 параллельных процессов. После optimize table - работало нормально, но недолго.
Мне интересней не саму проблему решить (да я найду несколько разных способов решения почти любой проблемы), а понять, как таких проблем избегать. Вот отсутствие фрагментации, в сочетании с малым перерасходом места и было бы тем, что нужно. --- Добавлено --- Расскажу историю, как я работал с одним чувачком над одним маленьким проектиком. Я запроектировал таблицу обмена данных с ним, таким образом, что поле цены было типа float.(специально, чтобы не было разногласий по формату). А потом у нас с ним появился спор о том, что он думает что должна быть то ли точка, то ли запятая, а я думаю иначе. Я ему ткнул, что по структуре базы данных тип float. А он спросил - а нахрена я сделал цену типом float, а не varchar. (ну я не стал ему объяснять что специально так сделал, чтобы проблем у меня с выяснением что правильно точка или запятая не было, а просто пожал плечами, и сказал, ну вот так сделал). Ну так вот, я хочу с фрагментацией сделать по нормальному, чтобы ее в 95% случаев просто не было несмотря на апдейты всех строк раза по три, но при этом чтобы не было большого перерасхода занимаемого места, а для этого нужна поддержка со стороны движка базы данных. Тоесть сделать сразу так, чтобы проблема не появилась, а не заниматься решением проблем через помещение таблицы на память 3DXpoint, через впихивания всего оптом в одну транзакцию и или других способов решения проблем, появление которых можно предотвратить. Я так понимаю, движок MySQL просто не предоставляет нужного мне функционала, иначе бы наверное кто-нибудь бы уже сказал с какими параметрами создавать таблицу. Ну если оно так, то на этом тему можно и свернуть.