MySQL медленная выборка по PRIMARY KEY, что делать?
Solmyr
1009
Таблица, MyISAM количество записей 1500000 — 2000000. Строки fixed size по 2800 байт. PRIMARY KEY типа char(32). Жесткие диски HDD. Версия 10.1.44-MariaDB
Выборки по PRIMARY KEY занимают в среднем 5000 μс (0.005) секунды. По-моему это абсолютно ненормально. Для сравнения на той же системе те же данные при выборке из Mongodb на wiredtiger занимают 200 μс.
Подскажите плиз что может быть не так?
Stek
1 секунда = 1000 милисекунд.
5000мс = 5 секунд.
drDaemon
Solmyr:
Подскажите плиз что может быть не так?
Explain запроса делали ?
На запрос и структуру таблицы взглянуть бы
Solmyr
drDaemon: Explain запроса делали ?
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE the_table const PRIMARY PRIMARY 96 const 1
drDaemon: На запрос и структуру таблицы взглянуть бы
Запрос:
SELECT id, value FROM the_table WHERE id=’dfghekagr’
Структура длинная, лень красиво постить. 22 поля в общей сложности, типов INT, FLOAT и CHAR(n). Подробности разве могут иметь значение если row type FIXED?
edogs software
Solmyr: Таблица, MyISAM количество записей 1500000 — 2000000. Строки fixed size по 2800 байт. PRIMARY KEY типа char(32). Жесткие диски HDD. Версия 10.1.44-MariaDB
Выборки по PRIMARY KEY занимают в среднем 5000 μс (0.005) секунды. По-моему это абсолютно ненормально. Для сравнения на той же системе те же данные при выборке из Mongodb на wiredtiger занимают 200 μс.
Подскажите плиз что может быть не так?
МонгоДБ к гадалке не ходи достает данные из кэша так или иначе.
А у Вас майисам база на 2млн записей по 2.5кб — это 5гб. В память так полагаем вся не влезает? Тогда идет считывание с хдд.
Время позиционирования у хдд на 7200 об/мин до 0.0083 секунды, а еще надо не забыть эти 2 килобайта считать + у хдд еще другие дела есть.
Пусть у Вас серверные диски с 15000об/мин, ну допустим это будет 0.0042 секунды время позиционирования, если диск ничем не занят.
Чем Вам 0.005 секунды в этом варианте не нравится? 🙂 Откуда там 0.0002 возьмуться, если чисто по физике диск спозиционироваться даже не успеет?
В иннодб проще засунуть всю базу в кэш, если скорость действительно критична и других минусов нет — переходите на иннодб и ставьте размер кэша что бы вся база влезала.
Dreammaker
Solmyr: Подскажите плиз что может быть не так?
сортировка есть по какому-то полю? Если есть, то есть ли по нему индекс?
timo-71
Solmyr: SELECT id, value FROM
Раньше помогало составной ключ на id, value. Ну и иннодб. Если оп есть, чтоб оно поместилось. Давно на монге, мускул стал забывать.
edogs: МонгоДБ к гадалке не ходи достает данные из кэша так или иначе.
Там тоже через гадалку, если запаса оп нет. На 1 млн по «_id» на хдд, после systemctl restart mongod в зависимости от (ну, начнем с load average) вполне может от 1 до 5сек. На прогретом и 200 микросек м/б. Все зависит от наличия оп, ну и
wiredTiger:
engineConfig:
cacheSizeGB:
, как вариант. Если оп не хватает для каких то других процессов и индексов монги одновременно, то вполне вероятно и рандом — от сек до микросек..
Anamnado
знама что:
делать базу распределенной. (реляционной)
сложностей то в принципе нет а вот рутина переноса данных да.. (но можно написать скрипт опять же — руками миллион записей править это крякнуть можно- а в коде движка там не очень большие правки.. — опять же конечно все легко когда знаешь что делать)
что в итоге? (10 или больше таблиц по 150 000 записей в каждой вместо одной на 1500000- как понимаете разница при выборке будет и существенная)
других действенных решений как таковое нет — всякие там опции настройки они если и выиграют вам 0,05 секунд вам оно погоду не сделает..
ну а в реале если записей больше миллиона это уже свой сервер а не хостинг и работают уже с Оракл — он для больших БД и разрабатывался….
———- Добавлено 28.03.2020 в 04:16 ———-
Solmyr: Подскажите плиз что может быть не так?
там оно не что то не не так
это результат разных технологий…
как всегда есть как свои плюсы так и минусы…. (дело в том что 200мс это тоже много, конечно смотря где и смотря для чего.. вот к примеру сайт — там нормальный отклик для первого контента от сервера = до 1 сек -и вот 0,2 сек тратится только на обращение к БД …..- да это непозволительно много — он должен быть 0,05сек максимум чтобы уложиться в рамки. ()почему — а обращений может быть еще и много параллельных, нагрузка возрастет скорость будет теряться….. (ну как то так — писать много ленно (там по правильному так — если запрос 0,2 то вероятность паралельных запросов сильно возрастает… И а если сайт на хостинге не один ,, в общем я кратко для чуть понимания ,,, ) )) но ..тем не менее.
как уже сказал с применением у MySQL реляционной структуры вот этот плюс у Mongodb будет полностью утерян..
SocFishing
Автор, это нормально.
Мы используем Mongodb во всех проектах уже 8 лет. Структура хранения Mongodb выносит индексы отдельно в wt файлы, сама структура данные сортирована и разбита по файлам — коллекции.
В новых версиях можно вовсе запустить демона Mongodb и базу развернуть в памяти без возможности писать. Чтение ввиду особенности скорости памяти повышается еще больше.
Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL. Если вам нужно читать ключ — значение, то в ту же Mongodb.
Solmyr
Dreammaker: сортировка есть по какому-то полю?
Сортировки нет
Anamnado: делать базу распределенной. (реляционной)
То что вы описываете ниже по тексту называется шардинг.
Anamnado: работают уже с Оракл
Оракл это куча бабла и достаточно специфические полезные функции.
Anamnado: он для больших БД и разрабатывался
2кк записей и таблица 3.5Гб это совсем не «большие БД».
SocFishing: Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL.
Вот честно не понимаю, почему хвалят Postgre? Во многих случаях, когда у меня были проблемы с быстродействием, я тестировал Maria, Postgre и Mongo, и всегда быстрее всего оказывались или Maria или Mongo но никогда Postgre.
SocFishing: Если вам нужно читать ключ — значение
Нужно ключ-значение, но я пока что сделаю отдельную таблицу id, value в MariaDB и буду держать ее в памяти. Не хочу разбираться как (и умеет ли) Mongo держать таблицы в памяти.
ivan-lev
Solmyr,
Solmyr: PRIMARY 96 const 1
Если char 32 почему 96? реально нужны ключи в mb-кодировке?..
Solmyr
Таблица, MyISAM количество записей 1500000 — 2000000. Строки fixed size по 2800 байт. PRIMARY KEY типа char(32). Жесткие диски HDD. Версия 10.1.44-MariaDB
Выборки по PRIMARY KEY занимают в среднем 5000 μс (0.005) секунды. По-моему это абсолютно ненормально. Для сравнения на той же системе те же данные при выборке из Mongodb на wiredtiger занимают 200 μс.
Подскажите плиз что может быть не так?
Stek
1 секунда = 1000 милисекунд.
5000мс = 5 секунд.
drDaemon
Подскажите плиз что может быть не так?
Explain запроса делали ?
На запрос и структуру таблицы взглянуть бы
Solmyr
Explain запроса делали ?
На запрос и структуру таблицы взглянуть бы
Запрос:
SELECT id, value FROM the_table WHERE id=’dfghekagr’
Структура длинная, лень красиво постить. 22 поля в общей сложности, типов INT, FLOAT и CHAR(n). Подробности разве могут иметь значение если row type FIXED?
edogs software
Таблица, MyISAM количество записей 1500000 — 2000000. Строки fixed size по 2800 байт. PRIMARY KEY типа char(32). Жесткие диски HDD. Версия 10.1.44-MariaDB
Выборки по PRIMARY KEY занимают в среднем 5000 μс (0.005) секунды. По-моему это абсолютно ненормально. Для сравнения на той же системе те же данные при выборке из Mongodb на wiredtiger занимают 200 μс.
Подскажите плиз что может быть не так?
МонгоДБ к гадалке не ходи достает данные из кэша так или иначе.
А у Вас майисам база на 2млн записей по 2.5кб — это 5гб. В память так полагаем вся не влезает? Тогда идет считывание с хдд.
Время позиционирования у хдд на 7200 об/мин до 0.0083 секунды, а еще надо не забыть эти 2 килобайта считать + у хдд еще другие дела есть.
Пусть у Вас серверные диски с 15000об/мин, ну допустим это будет 0.0042 секунды время позиционирования, если диск ничем не занят.
Чем Вам 0.005 секунды в этом варианте не нравится? 🙂 Откуда там 0.0002 возьмуться, если чисто по физике диск спозиционироваться даже не успеет?
В иннодб проще засунуть всю базу в кэш, если скорость действительно критична и других минусов нет — переходите на иннодб и ставьте размер кэша что бы вся база влезала.
Dreammaker
Подскажите плиз что может быть не так?
сортировка есть по какому-то полю? Если есть, то есть ли по нему индекс?
timo-71
SELECT id, value FROM
Раньше помогало составной ключ на id, value. Ну и иннодб. Если оп есть, чтоб оно поместилось. Давно на монге, мускул стал забывать.
МонгоДБ к гадалке не ходи достает данные из кэша так или иначе.
Там тоже через гадалку, если запаса оп нет. На 1 млн по «_id» на хдд, после systemctl restart mongod в зависимости от (ну, начнем с load average) вполне может от 1 до 5сек. На прогретом и 200 микросек м/б. Все зависит от наличия оп, ну и
, как вариант. Если оп не хватает для каких то других процессов и индексов монги одновременно, то вполне вероятно и рандом — от сек до микросек..
Anamnado
знама что:
делать базу распределенной. (реляционной)
сложностей то в принципе нет а вот рутина переноса данных да.. (но можно написать скрипт опять же — руками миллион записей править это крякнуть можно- а в коде движка там не очень большие правки.. — опять же конечно все легко когда знаешь что делать)
что в итоге? (10 или больше таблиц по 150 000 записей в каждой вместо одной на 1500000- как понимаете разница при выборке будет и существенная)
других действенных решений как таковое нет — всякие там опции настройки они если и выиграют вам 0,05 секунд вам оно погоду не сделает..
ну а в реале если записей больше миллиона это уже свой сервер а не хостинг и работают уже с Оракл — он для больших БД и разрабатывался….
———- Добавлено 28.03.2020 в 04:16 ———-
Подскажите плиз что может быть не так?
там оно не что то не не так
это результат разных технологий…
как всегда есть как свои плюсы так и минусы…. (дело в том что 200мс это тоже много, конечно смотря где и смотря для чего.. вот к примеру сайт — там нормальный отклик для первого контента от сервера = до 1 сек -и вот 0,2 сек тратится только на обращение к БД …..- да это непозволительно много — он должен быть 0,05сек максимум чтобы уложиться в рамки. ()почему — а обращений может быть еще и много параллельных, нагрузка возрастет скорость будет теряться….. (ну как то так — писать много ленно (там по правильному так — если запрос 0,2 то вероятность паралельных запросов сильно возрастает… И а если сайт на хостинге не один ,, в общем я кратко для чуть понимания ,,, ) )) но ..тем не менее.
как уже сказал с применением у MySQL реляционной структуры вот этот плюс у Mongodb будет полностью утерян..
SocFishing
Автор, это нормально.
Мы используем Mongodb во всех проектах уже 8 лет. Структура хранения Mongodb выносит индексы отдельно в wt файлы, сама структура данные сортирована и разбита по файлам — коллекции.
В новых версиях можно вовсе запустить демона Mongodb и базу развернуть в памяти без возможности писать. Чтение ввиду особенности скорости памяти повышается еще больше.
Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL. Если вам нужно читать ключ — значение, то в ту же Mongodb.
Solmyr
сортировка есть по какому-то полю?
Сортировки нет
делать базу распределенной. (реляционной)
То что вы описываете ниже по тексту называется шардинг.
работают уже с Оракл
Оракл это куча бабла и достаточно специфические полезные функции.
он для больших БД и разрабатывался
2кк записей и таблица 3.5Гб это совсем не «большие БД».
Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL.
Вот честно не понимаю, почему хвалят Postgre? Во многих случаях, когда у меня были проблемы с быстродействием, я тестировал Maria, Postgre и Mongo, и всегда быстрее всего оказывались или Maria или Mongo но никогда Postgre.
Если вам нужно читать ключ — значение
Нужно ключ-значение, но я пока что сделаю отдельную таблицу id, value в MariaDB и буду держать ее в памяти. Не хочу разбираться как (и умеет ли) Mongo держать таблицы в памяти.
ivan-lev
Solmyr,
PRIMARY 96 const 1
Если char 32 почему 96? реально нужны ключи в mb-кодировке?..
key_buffer_size что показывает?