Mysql

[_HEDELKA_]

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

Подумал что если создавать под каждого пользователя свою таблицу так как унас всегда есть ID user и мы всегда сможем обратится к таблице и прочитать всего лишь 1 строчку (смотрел в строну индекса но там тоже выполняется больше 10 а когда работают 10 шаблонов и все они обращаются за какими то данными проще обойти эту систему)
Просто как я вижу по памяти одно и тоже просто это не в одном месте а в разных таблицах, пишите свое мнение интересно почитать)

 

[backoff]

я вот если честно не понял ничего, что делается и что надо

ps \ глянь мою подпись )

 

[_HEDELKA_]

я вот если честно не понял ничего, что делается и что надо

ps \ глянь мою подпись )

Ну смотри обычно создается 1 таблица user где хранятся все пользователи, что если вместо user таблицы будет user_id=31231287938 (название таблицы) и в этой таблице в 1 строчке хранятся все данные пользователя

Соответственно с каждым новым пользователем будет своя таблица где 1 строчка данные пользователя (нам не нужно проходить всю таблицу когда есть user_id но в таблице даже равно не работает, поэтому можно создавать отдельные таблицы для каждого)

 

[backoff]

на мой взгляд проще сделать одну таблицу, пихать все туда, сделать индексирование таблицы и к каждому user_id приписать ID индекса таблицы, тогда никаких тормозов не будет. брать строку с user_id, брать ее индекс ID и обращаться по нему уже к БД.

у меня что-то подобное, БД на 35кк строк, и парсинг идет в 100 потоков, проц загружен на 11% , sql жрет 1%
UPD: только что посмотрел, SQL даже не 1%, а 0.1%

 

[lavachik]

Ну смотри обычно создается 1 таблица user где хранятся все пользователи, что если вместо user таблицы будет user_id=31231287938 (название таблицы) и в этой таблице в 1 строчке хранятся все данные пользователя

Соответственно с каждым новым пользователем будет своя таблица где 1 строчка данные пользователя (нам не нужно проходить всю таблицу когда есть user_id но в таблице даже равно не работает, поэтому можно создавать отдельные таблицы для каждого)

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

Например создай 1 таблицу Users тут будут хранится ID (автоинкеремент сделай с ключем) юзеров
А вторая таблица будет data_one
Третья data_two и определять по user_id чток ком относится



И вообще сколько параметров от юзера ?

И сколько строк в БД ?

у меня есть БД уже больше чем на 1млн строк и столбцов в таблице много и справляется запросто

 

[_HEDELKA_]

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

Например создай 1 таблицу Users тут будут хранится ID (автоинкеремент сделай с ключем) юзеров
А вторая таблица будет data_one
Третья data_two и определять по user_id чток ком относится



И вообще сколько параметров от юзера ?

И сколько строк в БД ?

у меня есть БД уже больше чем на 1млн строк и столбцов в таблице много и справляется запросто

не поверишь 40 пользователей в базе любой запрос обрабатывается 20-50 секунд (представляю базу на 1кк)

Например создай 1 таблицу Users тут будут хранится ID (автоинкеремент сделай с ключем) юзеров
А вторая таблица будет data_one
Третья data_two и определять по user_id чток ком относится

По этому поводу опять же 4 таблицы и память кушать будет - но не так сильно страшно.

Почему вы не смотрите в более мощное решение задачи?
Ведь имея таблицу под название id пользователя при базе хоть в 1000000000000000 пользователей мы всегда знаем где находится таблица и какие данные нам нужны, нежели делать лазейки.

Например создай 1 таблицу Users тут будут хранится ID (автоинкеремент сделай с ключем) юзеров
А вторая таблица будет data_one
Третья data_two и определять по user_id чток ком относится

Я попробую сначала свою тактику а потом если что-то пойдет не так вашу)

В данном запросе (темы форума) я спросил мнение о таком необычном решении задачи

 

[WebBot]

А чего бы тогда вообще не отказаться от БД и не хранить все в файлах ... на каждого юзера свой файл, удобно (по вашей логике)
Не изобретайте велосипед, он давно изобретен - называется правильная структура таблиц + выявление и оптимизация тяжелых запросов + правильные индексы (не просто добавить индексы чтобы были, а смотреть EXPLAIN конкретных запросов, как они работают с этими инжексами и работают ли вообще ... возможно где-то составные индексы нужны и тп)

 

[Moonwalker]

не поверишь 40 пользователей в базе любой запрос обрабатывается 20-50 секунд (представляю базу на 1кк)

Тебе еще в прошлый раз рекомендовали поискать курсы по мускулу, чтобы изучить матчасть. У тебя ЯВНО проблема в структуре базы данных. При таких объемах НЕ МОЖЕТ быть проблем. Более того, даже при значительно бОльших объемах проблем быть не может, в конце концов, не может же все человечество ошибаться и неправильно использовать бд ))) Не удивлюсь, если ты до сих пор все в одно поле TEXT суешь и по нему продолжаешь искать.

ps. Предложение про файлы, к слову, да, подходящее. Смысла БД вообще никакого нет тогда.

 

[_HEDELKA_]

А чего бы тогда вообще не отказаться от БД и не хранить все в файлах ... на каждого юзера свой файл, удобно (по вашей логике)
Не изобретайте велосипед, он давно изобретен - называется правильная структура таблиц + выявление и оптимизация тяжелых запросов + правильные индексы (не просто добавить индексы чтобы были, а смотреть EXPLAIN конкретных запросов, как они работают с этими инжексами и работают ли вообще ... возможно где-то составные индексы нужны и тп)

Индекс работает на цифры?


Вы в предыдущей теме подсказали решение с = в место like но база все равно тормозила, я смотрел видео по индексам и исходя из входных данных это упрощение поиск имен итак далее, про цифры инфы вообще нет, и опять же если мне нужно не найти пользователя а получить конкретного из 1000 строк есть только один пользователь с таким id.

И как я понял работы индекса он берет середину проверяет что больше и тд. муть какая то, user_id не по порядку все пользователи.

Как то так

 

[_HEDELKA_]

Тебе еще в прошлый раз рекомендовали поискать курсы по мускулу, чтобы изучить матчасть. У тебя ЯВНО проблема в структуре базы данных. При таких объемах НЕ МОЖЕТ быть проблем. Более того, даже при значительно бОльших объемах проблем быть не может, в конце концов, не может же все человечество ошибаться и неправильно использовать бд ))) Не удивлюсь, если ты до сих пор все в одно поле TEXT суешь и по нему продолжаешь искать.

ps. Предложение про файлы, к слову, да, подходящее. Смысла БД вообще никакого нет тогда.

Всю инфу да в text
user_id в виде числового значения от 900000000000 чето там (щяс нет возможности посмотреть)

Я на данный момент не совсем понимаю зачем хранить инфу в другом формате если это text, id пользователя да можно в цифрах, но это же не помогает

 

[_HEDELKA_]

А чего бы тогда вообще не отказаться от БД и не хранить все в файлах ... на каждого юзера свой файл, удобно (по вашей логике)

Вы хотите сказать что он ищет таблицы также как и строки? Есть же название таблице оно фиксированное, просто обратись по названию и получи 1 строчку

 

[Moonwalker]

Я на данный момент не совсем понимаю зачем

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

 

[backoff]

не поверишь 40 пользователей в базе

тогда проще, создать папку users и туда пихать файлы TXT в которых через ";" добавляй инфу и бери потом файлы как таблицу и все, никаких тормозов не будет
в название файла записывай user_id

 

[WebBot]

Вы в предыдущей теме подсказали решение с = в место like но база все равно тормозила

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

 

[_HEDELKA_]

Исходя из диалога выяснили другую информацию: