MySQL медленная выборка по PRIMARY KEY, что делать?

12 3
Solmyr
На сайте с 10.09.2007
Offline
495
958

Таблица, MyISAM количество записей 1500000 - 2000000. Строки fixed size по 2800 байт. PRIMARY KEY типа char(32). Жесткие диски HDD. Версия 10.1.44-MariaDB

Выборки по PRIMARY KEY занимают в среднем 5000 μс (0.005) секунды. По-моему это абсолютно ненормально. Для сравнения на той же системе те же данные при выборке из Mongodb на wiredtiger занимают 200 μс.

Подскажите плиз что может быть не так?

S
На сайте с 23.05.2004
Offline
290
#1

1 секунда = 1000 милисекунд.

5000мс = 5 секунд.

Это просто мой личный сайт (https://phpdevs.com/) в моей подписи.
DD
На сайте с 16.05.2012
Offline
65
#2
Solmyr:

Подскажите плиз что может быть не так?

Explain запроса делали ?

На запрос и структуру таблицы взглянуть бы

Разработка систем сбора данных на Python/Golang/NodeJs
Solmyr
На сайте с 10.09.2007
Offline
495
#3
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
На сайте с 15.12.2005
Offline
714
#4
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
На сайте с 20.04.2006
Offline
553
#5
Solmyr:
Подскажите плиз что может быть не так?

сортировка есть по какому-то полю? Если есть, то есть ли по нему индекс?

T7
На сайте с 19.09.2018
Offline
35
#6
Solmyr:
SELECT id, value FROM

Раньше помогало составной ключ на id, value. Ну и иннодб. Если оп есть, чтоб оно поместилось. Давно на монге, мускул стал забывать.

edogs:
МонгоДБ к гадалке не ходи достает данные из кэша так или иначе.

Там тоже через гадалку, если запаса оп нет. На 1 млн по "_id" на хдд, после systemctl restart mongod в зависимости от (ну, начнем с load average) вполне может от 1 до 5сек. На прогретом и 200 микросек м/б. Все зависит от наличия оп, ну и

wiredTiger:

engineConfig:
cacheSizeGB:
, как вариант. Если оп не хватает для каких то других процессов и индексов монги одновременно, то вполне вероятно и рандом - от сек до микросек..
Anamnado
На сайте с 08.02.2010
Offline
241
#7

знама что:

делать базу распределенной. (реляционной)

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

что в итоге? (10 или больше таблиц по 150 000 записей в каждой вместо одной на 1500000- как понимаете разница при выборке будет и существенная)

других действенных решений как таковое нет - всякие там опции настройки они если и выиграют вам 0,05 секунд вам оно погоду не сделает..

ну а в реале если записей больше миллиона это уже свой сервер а не хостинг и работают уже с Оракл - он для больших БД и разрабатывался....

---------- Добавлено 28.03.2020 в 04:16 ----------

Solmyr:
Подскажите плиз что может быть не так?

там оно не что то не не так

это результат разных технологий...

как всегда есть как свои плюсы так и минусы.... (дело в том что 200мс это тоже много, конечно смотря где и смотря для чего.. вот к примеру сайт - там нормальный отклик для первого контента от сервера = до 1 сек -и вот 0,2 сек тратится только на обращение к БД .....- да это непозволительно много - он должен быть 0,05сек максимум чтобы уложиться в рамки. ()почему - а обращений может быть еще и много параллельных, нагрузка возрастет скорость будет теряться..... (ну как то так - писать много ленно (там по правильному так - если запрос 0,2 то вероятность паралельных запросов сильно возрастает... И а если сайт на хостинге не один ,, в общем я кратко для чуть понимания ,,, ) )) но ..тем не менее.

как уже сказал с применением у MySQL реляционной структуры вот этот плюс у Mongodb будет полностью утерян..

Подпись без рабочей ссылки все равно, что коитус без кульминации ((c) Anadonam)
SocFishing
На сайте с 26.09.2013
Offline
118
#8

Автор, это нормально.

Мы используем Mongodb во всех проектах уже 8 лет. Структура хранения Mongodb выносит индексы отдельно в wt файлы, сама структура данные сортирована и разбита по файлам - коллекции.

В новых версиях можно вовсе запустить демона Mongodb и базу развернуть в памяти без возможности писать. Чтение ввиду особенности скорости памяти повышается еще больше.

Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL. Если вам нужно читать ключ - значение, то в ту же Mongodb.

★Сервис идентифицирует (https://socfishing.com/?utm_source=searchengines) посетителей вашего сайта и предоставляет их профили ВКонтакте, Телефон, Почта! Цены копеечные, работаем 8 лет.
Solmyr
На сайте с 10.09.2007
Offline
495
#9
Dreammaker:
сортировка есть по какому-то полю?

Сортировки нет

Anamnado:
делать базу распределенной. (реляционной)

То что вы описываете ниже по тексту называется шардинг.

Anamnado:
работают уже с Оракл

Оракл это куча бабла и достаточно специфические полезные функции.

Anamnado:
он для больших БД и разрабатывался

2кк записей и таблица 3.5Гб это совсем не "большие БД".

SocFishing:
Если вам нужна какая-то связанная структура, то я бы рекомендовал перенести в PostgreSQL.

Вот честно не понимаю, почему хвалят Postgre? Во многих случаях, когда у меня были проблемы с быстродействием, я тестировал Maria, Postgre и Mongo, и всегда быстрее всего оказывались или Maria или Mongo но никогда Postgre.

SocFishing:
Если вам нужно читать ключ - значение

Нужно ключ-значение, но я пока что сделаю отдельную таблицу id, value в MariaDB и буду держать ее в памяти. Не хочу разбираться как (и умеет ли) Mongo держать таблицы в памяти.

IL
На сайте с 20.04.2007
Offline
412
#10

Solmyr,

Solmyr:
PRIMARY 96 const 1

Если char 32 почему 96? реально нужны ключи в mb-кодировке?..

key_buffer_size что показывает?

12 3

Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий