Спустя 6 часов, 20 минут, 54 секунды (25.03.2011 - 09:46) alex12060 написал(а):
~ 500K записей.
А если запрос сделан грамотно, и еще стоят разного рода мемкэшды, то можно не беспокоится...
А если запрос сделан грамотно, и еще стоят разного рода мемкэшды, то можно не беспокоится...
Спустя 1 минута, 42 секунды (25.03.2011 - 09:47) Snus написал(а):
| Цитата (alex12060 @ 25.03.2011 - 06:46) |
| ~ 500K записей. |
Откуда такая информация?
Спустя 7 минут, 24 секунды (25.03.2011 - 09:55) alex12060 написал(а):
Это просто известно. Сам тестил, на сильно загруженном серве.
Но при перезаписи на более совершенный запрос, тормоз сильный слетел, но тормоз остался.
Но при перезаписи на более совершенный запрос, тормоз сильный слетел, но тормоз остался.
Спустя 23 минуты, 16 секунд (25.03.2011 - 10:18) Snus написал(а):
alex12060
Magic Search тестировал?
Magic Search тестировал?
Спустя 1 час, 31 минута, 42 секунды (25.03.2011 - 11:50) Renden написал(а):
Snus
alex12060
Я бы не сказал что 500к сильные лаги, у меня в таблице 821883 записи, запрос типа:
Time: 1.651ms
А такой:
Time: 0.821ms
Время терпимое пока что)
Хотя я думаю его можно тоже оптимизировать, да и тип таблиц в базе у меня неверный, так что если все сделать как надо думаю время сократиться раза в 2-3.
alex12060
Я бы не сказал что 500к сильные лаги, у меня в таблице 821883 записи, запрос типа:
SELECT * FROM traffic
Time: 1.651ms
А такой:
SELECT IFNULL (CONCAT(lastname,' ',firstname,' ',middlename) ,t.trafd_to) AS
host,users.ip,users.id,t.sum_traf from (select sum(trafd_all/1024) as sum_traf, trafd_to, trafd_date
from traffic WHERE MONTH(trafd_date) ='03' and YEAR(trafd_date)='2011' group by trafd_to) t left
join users on users.ip=t.trafd_to WHERE t.trafd_to LIKE '%192.168.2%' and
t.trafd_to!='192.168.2.254' and t.trafd_to!='192.168.2.255' ORDER BY t.sum_traf DESC
Time: 0.821ms
Время терпимое пока что)
Хотя я думаю его можно тоже оптимизировать, да и тип таблиц в базе у меня неверный, так что если все сделать как надо думаю время сократиться раза в 2-3.
Спустя 5 минут, 48 секунд (25.03.2011 - 11:55) alex12060 написал(а):
Snus
Нет. Ладно, я просто ответил по факту. Наверне, там хорошая оптимизация запросов.
Все зависит от нагрузки и красоты)
Renden
Интранет?
Нет. Ладно, я просто ответил по факту. Наверне, там хорошая оптимизация запросов.
Все зависит от нагрузки и красоты)
Renden
Интранет?
Спустя 1 минута, 40 секунд (25.03.2011 - 11:57) Snus написал(а):
alex12060
Я не знаю, что такое Magic Search, конечно, но могу сказать, что 500к для БД - это очень-очень мало. И если лагает такая база, то нужно срочно перепрофилироваться в грузчики.
Я не знаю, что такое Magic Search, конечно, но могу сказать, что 500к для БД - это очень-очень мало. И если лагает такая база, то нужно срочно перепрофилироваться в грузчики.
Спустя 1 минута, 52 секунды (25.03.2011 - 11:59) alex12060 написал(а):
Snus
Учту)
Тогда ответь пожалуйста, при каких объемах начинается тормоз?
Учту)
Тогда ответь пожалуйста, при каких объемах начинается тормоз?
Спустя 14 минут, 42 секунды (25.03.2011 - 12:14) Snus написал(а):
alex12060
Нет определенного кол-ва записей в таблице, которое может вызвать лаги (вернее просто так не правильно рассуждать). Тут определяющими факторами являются правильное построение структуры и запросов.
Нет определенного кол-ва записей в таблице, которое может вызвать лаги (вернее просто так не правильно рассуждать). Тут определяющими факторами являются правильное построение структуры и запросов.
Спустя 38 минут, 13 секунд (25.03.2011 - 12:52) Renden написал(а):
alex12060
Ога интранет)
А поповоду тормозов я думаю что например facebook он же тоже на mysql и не лагет, ну думаю там какой-та кластер из БД разделение нагрузок и тп.
Ога интранет)
А поповоду тормозов я думаю что например facebook он же тоже на mysql и не лагет, ну думаю там какой-та кластер из БД разделение нагрузок и тп.
Спустя 35 минут, 7 секунд (25.03.2011 - 13:27) sergeiss написал(а):
| Цитата (Snus @ 25.03.2011 - 13:14) |
| Нет определенного кол-ва записей в таблице, которое может вызвать лаги (вернее просто так не правильно рассуждать). Тут определяющими факторами являются правильное построение структуры и запросов. |
К этому еще только добавлю, что и количество выбираемых записей тоже влияет. И насколько я понимаю, в "правильном построении структуры" подразумевается, в т.ч., и правильная индексация.
Спустя 2 часа, 11 минут, 32 секунды (25.03.2011 - 15:39) Эли4ка написал(а):
мальчишки,а вы не подскажете как сдлеать так,чтобы если в БД больше 10000к записен ,то запись шла в БД на другом сервере?
И вот вопросик по Magic Search как мне его подредактировать его так,чтобы он индексировал и видео,и картинки..
И вот вопросик по Magic Search как мне его подредактировать его так,чтобы он индексировал и видео,и картинки..
Спустя 1 час, 42 минуты, 7 секунд (25.03.2011 - 17:21) Snus написал(а):
sergeiss
Речь ведь шла о "лагах", а не о времени выборки. Если лагов нет, то время выборки = кол-во строк * на единицу времени.
Я не могу назвать это лагами. Лаги, по моему скромному мнению, - это большие задержки.
Речь ведь шла о "лагах", а не о времени выборки. Если лагов нет, то время выборки = кол-во строк * на единицу времени.
Я не могу назвать это лагами. Лаги, по моему скромному мнению, - это большие задержки. Спустя 2 часа, 6 минут, 2 секунды (25.03.2011 - 19:27) alex12060 написал(а):
Спустя 8 часов, 56 минут, 9 секунд (26.03.2011 - 04:23) Эли4ка написал(а):
alex12060,спасибо