За последние 24 часа нас посетили 6596 программистов и 529 роботов. Сейчас ищут 202 программиста ...

фиксированные и динамические поля

Тема в разделе "MySQL", создана пользователем mirosas, 25 сен 2018.

  1. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    Чего-то лень делать insert, delete. хочется делать простые update, и чтобы после этих update селекты работали нормально по скорости.

    В общем хочу минимум:
    Часть полей сделать фиксированного размера (чары), часть плавающего (тексты и блобы).

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

    MyISAM, но вообще мне наверное все равно что использовать.
     
    #1 mirosas, 25 сен 2018
    Последнее редактирование: 25 сен 2018
  2. nospiou

    nospiou Активный пользователь

    С нами с:
    4 фев 2018
    Сообщения:
    2.905
    Симпатии:
    403
    @mirosas Умничка. Держи нас в курсе:)
     
  3. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    ???
     
  4. Valick

    Valick Новичок

    С нами с:
    12 авг 2018
    Сообщения:
    398
    Симпатии:
    81
    @mirosas, а что ты хотел услышать?
     
  5. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    Ну как это делается)). Простая вещь наверное).. Я просто мануалы по mysql смотрел прошлый раз лет 13 назад, в то время функионал минимум реализовывался через char (в альтернативу varchar), и text, blob. Сейчас как я поинмаю char и varchar обрабатывается одинаково, и обработка зависит от типа таблицы - dynamic, fixed. Но разумно предполагать что за 13 лет развития MySQL появились и более подходящие алгоритмы управления, аналогичные тому, что я бы хотел в сценарии максимум. Понятно, что я это могу реализовать через workaround, но хотелось бы без костылей.

    Грубо говоря.. у 95% строк некоторое поле занимает до 1кб. Но у оставшихся 5% может достигать 20-30кб. Нужно, чтобы база данных при создании строки сразу же резервировала 1кб под это поле (и тогда апдейты в пределах этого размера не приведут к фрагментации строки), но при этом позволяла впихнуть в поле до 30кб.
     
    #5 mirosas, 25 сен 2018
    Последнее редактирование: 25 сен 2018
  6. miketomlin

    miketomlin Активный пользователь

    С нами с:
    9 авг 2016
    Сообщения:
    936
    Симпатии:
    132
    @mirosas, используемые типы полей зависят не от «экстремумов» ваших хотелок.
     
  7. nospiou

    nospiou Активный пользователь

    С нами с:
    4 фев 2018
    Сообщения:
    2.905
    Симпатии:
    403
    и т.д
    Код (Text):
    1. CREATE TABLE `table` (
    2.   `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
    3.   `title` varchar(255) COLLATE utf8mb4_unicode_ci NOT NULL,
    4.   `body` text COLLATE utf8mb4_unicode_ci NOT NULL,
    5.   `created_at` timestamp NULL DEFAULT NULL,
    6.   PRIMARY KEY (`id`)
    7. ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
     
  8. miketomlin

    miketomlin Активный пользователь

    С нами с:
    9 авг 2016
    Сообщения:
    936
    Симпатии:
    132
    P.S. И кто вас надоумил использовать insert/delete вместо update?
     
  9. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    Сам додумался. Работает намного быстрее. Плюс нет фрагментации. В каком-то проекте лет 10 назад делал. На обычном HDD таблица MyISAM делает более тысячи Insert+Delete в секунду, тогда как Update около 50 в секунду.

    Если формат фиксированный, то выжрет место на диске. по 65кб с строки.
    Если динамический, то при апдейтах в сторону увеличения размера строки будет фрагментация строк.
     
  10. nospiou

    nospiou Активный пользователь

    С нами с:
    4 фев 2018
    Сообщения:
    2.905
    Симпатии:
    403
  11. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    Нужна информация, как использовать MySQL, чтобы он выделял под строку, либо поля в строке некоторое задаваемое программером место (в байтах), но при этом позволял занять большее место, чем определено (этакий гибрид fixed и dynamic полей). Если такого нет в MySQL, то другую БД, простую к освоению и коннекту с php где это есть. Если и такого нет, то просто информацию что такого нет, чтобы я просто сделал workaround.

    Но если ничего такого нет, то хотелось бы не делать воркэраунд, а зафиксировать размеры чаров, и сделать плавающим размер text. Ежели я не ошибаюсь, то в современном MySQL char(255), вовсе не означает, что под поле выделено нужное место, если только не задан тип таблицы - fixed. Но если задать тип таблицы fixed - то под text (50000) будет выделено по 50кб, что ни к чему.

    Что касаемо типов, то это 13 лет назад так было. Сейчас даже char и varchar работают по другому, в зависимости от типа таблицы. Я ожидаю, что за 13 лет появились какие-то особые режимы работы таблиц, которые позволяют более гибко подходить к вопросу фиксированных и динамических полей. Если за 13 лет у MySQL только размеры файлов выросли и занимаемое место в оперативке, ну значит так. Если же и функционал подрос в нужной мне составляющей, то интересно как его использовать. Может какие-то другие базы данных работающие с php делают то, что мне нужно, тогда интересно какие.
     
    #11 mirosas, 25 сен 2018
    Последнее редактирование: 25 сен 2018
  12. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    Ну я так понял:

    1. хотелки максимум не реализованы ни в MySQL, ни в других б.д. подключаемых к пхп.

    2. часть полей сделать фиксированного размера, часть плавающего не получится.

    грустно.. но на хостинге все равно ssd стоит, нагрузки в финальной версии большие не предвидятся (при ускоренной обработке на своем пк валилось все), так что пофиг.
     
  13. MouseZver

    MouseZver Старожил

    С нами с:
    1 апр 2013
    Сообщения:
    4.866
    Симпатии:
    784
    Адрес:
    Лень
    транзакцией пробывали собрать все и отправить в пулл ?
     
  14. Sail

    Sail Активный пользователь

    С нами с:
    1 ноя 2016
    Сообщения:
    819
    Симпатии:
    173
    "Слона", наверное, не заметил: MyISAM
     
  15. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    там собирать нечего. select, update (то, что селектнуто, с целью пометить, что задача поступила в обработку и ее не нужно брать другим процессам), затем обработка (около секунды), затем снова update (того же, что селектнуто). Все это в 50 параллельных процессов. После optimize table - работало нормально, но недолго.
     
    #15 mirosas, 25 сен 2018
    Последнее редактирование: 25 сен 2018
  16. mirosas

    mirosas Активный пользователь

    С нами с:
    17 июл 2015
    Сообщения:
    214
    Симпатии:
    5
    Мне интересней не саму проблему решить (да я найду несколько разных способов решения почти любой проблемы), а понять, как таких проблем избегать. Вот отсутствие фрагментации, в сочетании с малым перерасходом места и было бы тем, что нужно.
    --- Добавлено ---
    Расскажу историю, как я работал с одним чувачком над одним маленьким проектиком.

    Я запроектировал таблицу обмена данных с ним, таким образом, что поле цены было типа float.(специально, чтобы не было разногласий по формату). А потом у нас с ним появился спор о том, что он думает что должна быть то ли точка, то ли запятая, а я думаю иначе. Я ему ткнул, что по структуре базы данных тип float. А он спросил - а нахрена я сделал цену типом float, а не varchar. (ну я не стал ему объяснять что специально так сделал, чтобы проблем у меня с выяснением что правильно точка или запятая не было, а просто пожал плечами, и сказал, ну вот так сделал).

    Ну так вот, я хочу с фрагментацией сделать по нормальному, чтобы ее в 95% случаев просто не было несмотря на апдейты всех строк раза по три, но при этом чтобы не было большого перерасхода занимаемого места, а для этого нужна поддержка со стороны движка базы данных. Тоесть сделать сразу так, чтобы проблема не появилась, а не заниматься решением проблем через помещение таблицы на память 3DXpoint, через впихивания всего оптом в одну транзакцию и или других способов решения проблем, появление которых можно предотвратить.

    Я так понимаю, движок MySQL просто не предоставляет нужного мне функционала, иначе бы наверное кто-нибудь бы уже сказал с какими параметрами создавать таблицу. Ну если оно так, то на этом тему можно и свернуть.
     
    #16 mirosas, 25 сен 2018
    Последнее редактирование: 25 сен 2018
  17. Valick

    Valick Новичок

    С нами с:
    12 авг 2018
    Сообщения:
    398
    Симпатии:
    81