Проверил mysqli::query() без MYSQLI_ASYNC на той же таблице, результаты как при использовании PDO: 1 966 866 432
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Полная Версия: Данные за каждый месяц
| Цитата (twin @ 26.12.2014 - 11:48) |
| Единственное, что могу показать, чтоб не быть голословным, это объемы, с которыми приходится работать. |
Ааа, понятно. Если RAM на сервере меньше 48Г, то проблема в диске.
Совет один - поможет или RAM до 64Г или SSD.
А 80М строк это немного для чтения - секунд в 30 можно уложится, если без индексов.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
| Цитата (Invis1ble @ 26.12.2014 - 12:13) |
| Проверил mysqli::query() без MYSQLI_ASYNC на той же таблице, результаты как при использовании PDO: 1 966 866 432 |
При чём тут это? Там (mysqli::query) даже есть пример "/* Если нужно извлечь большой объем данных, используем MYSQLI_USE_RESULT */"
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
| Цитата (S.Chushkin @ 26.12.2014 - 11:19) | ||
При чём тут это? Там (mysqli::query) даже есть пример "/* Если нужно извлечь большой объем данных, используем MYSQLI_USE_RESULT */" |
при том, что я проверяю различные способы и отписываюсь о результатах
сейчас и USE_RESULT проверю
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Итак, встречаем победителя - MYSQLI_USE_RESULT - с результатом 524 288 !
Какой-то подозрительный результат на фоне других
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Какой-то подозрительный результат на фоне других
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
Интересное наблюдение - в цикле на первой итерации ставлю var_dump($data); exit;
- результат появляется практически мгновенно и после этого несколько секунд идет работа с хардом.
При других вариантах сначала шуршал хард и только потом появлялся результат. Хотя тут еще буферы могут быть замешаны, перепроверять лень уже.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
- результат появляется практически мгновенно и после этого несколько секунд идет работа с хардом.
При других вариантах сначала шуршал хард и только потом появлялся результат. Хотя тут еще буферы могут быть замешаны, перепроверять лень уже.
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (Invis1ble @ 26.12.2014 - 12:26) |
| Какой-то подозрительный результат на фоне других |
Так и должно быть, просто данные хранит движок сервера.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
Короче я так понял, что с USE_RESULT выборка хранится на стороне сервера и по мере итерации вытягивается инфа оттуда.
PS. опоздал с объяснением
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
PS. опоздал с объяснением
_____________
Профессиональная разработка на заказ
Я на GitHub | второй профиль
| Цитата (S.Chushkin @ 26.12.2014 - 08:16) |
| Ааа, понятно. Если RAM на сервере меньше 48Г, то проблема в диске. Совет один - поможет или RAM до 64Г или SSD. А 80М строк это немного для чтения - секунд в 30 можно уложится, если без индексов. |
А смысл? Если отлично работает цикл.
Индексы есть конечно. Но 30 секунд это для меня уже самоубийство. Гораздо меньше хватает, чтобы все легло.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 26.12.2014 - 12:44) |
| А смысл? Если отлично работает цикл. |
Зависит от того, что нужно. :)
Если "для души", то можно и покопаться.
| Цитата |
| Индексы есть конечно. Но 30 секунд это для меня уже самоубийство. Гораздо меньше хватает, чтобы все легло. |
Да ничего там не ляжет. И не должно. 30 сек это на чтение и обработку, как бы.
Я тут для интереса попытал малость...
У меня на движок (буфер) отдано 2Г, таблица 27М записей, 4Г размером.
Запрос
select * from table
limit 10000000, 20
после запуска движка (т.е. идёт чтение данных с диска): 46 сек, процесс mysqld.exe "берёт" 1.7Г
второй раз (т.е. все данные в буфере): 7.8 сек, 1.7Г
Т.е. из буффера читается в 5+ раз быстрее. И, я так понимаю, ограничение идёт уже по нагрузке проца - хрень однопоточная и берёт 100% нагрузки одного ядра.
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
S.Chushkin
| Цитата |
| Зависит от того, что нужно. Если "для души", то можно и покопаться. |
Ну вот именно) Для души полно другой работы. А это называется работать, чтобы наработаться.
Если есть вариант сделать быстро и безболезненно, то плевать на предрассудки. Не всегда запрос в цикле, это плохо.| Цитата |
| после запуска движка (т.е. идёт чтение данных с диска): 46 сек, процесс mysqld.exe "берёт" 1.7Г второй раз (т.е. все данные в буфере): 7.8 сек, 1.7Г Т.е. из буффера читается в 5+ раз быстрее. |
Для меня это много. 
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 26.12.2014 - 14:02) |
| Для меня это много. |
Потому что данные в таблицах обновляются ежесекундно. Я не проверял, но думаю, что кэш тут не сработает. Если пересчитывать онлайн, 40 секунд на генерацию страницы - много.
Специфика работы такова, что статистика пересчитывается не вся сразу, а для каждого пользователя индивидуально. Всего их около 10 000.
Если так же по крону без цикла, то придется собирать все строки в один запрос. Апдейт вообще жутко долгий, база ложится. Не говоря уже про память.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Специфика работы такова, что статистика пересчитывается не вся сразу, а для каждого пользователя индивидуально. Всего их около 10 000.
Если так же по крону без цикла, то придется собирать все строки в один запрос. Апдейт вообще жутко долгий, база ложится. Не говоря уже про память.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
| Цитата (twin @ 26.12.2014 - 14:37) |
| Потому что данные в таблицах обновляются ежесекундно. Я не проверял, но думаю, что кэш тут не сработает. Если пересчитывать онлайн, 40 секунд на генерацию страницы - много. |
А тут я не понял - при чём тут обновления в исходных таблицах и расчёт агрегированных данных? Например, по норме расчёт агрегированных данных для почасовой статистики должен делаться раз в час, а исходные данные пусть меняются хоть 1000 раз в секунду.
И надеюсь, ты не путаешь кеш на результаты запросов и буфер в InnoDB (innodb_buffer_pool_size). Буфер используется для работы с БД в RAM, а не на диске. При этом, надеюсь, innodb_flush_log_at_trx_commit в 2 установлен, чтобы буфер не сбрасывался на диск при каждом запросе.
Если же ты подразумевал, чтобы рассчитывать статистику каждый раз (при просмотре), то тут уж ... только если "сам себе злобный буратино"
Хотя, кто его знает - бывает, что заказчики хотят и такое.| Цитата |
| Специфика работы такова, что статистика пересчитывается не вся сразу, а для каждого пользователя индивидуально. Всего их около 10 000. |
Этого я не понял.
Почему нельзя просчитать всех сразу? Что там такого специфичного, что нельзя в запросе посчитать. 10000 это всего юзеров или всего за один расчёт?У меня, например, агрегатная статистика вообще просчитывается в реальном времени, при каждой генерации страницы. Это 2 из ~20 запросов на каждую страницу при времени генерации страницы < 0.1 сек. Конечно, большая часть SELECT берётся из кеша. UPDATE кеш не пользует, естественно. Всего на запросы уходит < 0.02 сек (без кеша - ~0.05).
| Цитата |
| Если так же по крону без цикла, то придется собирать все строки в один запрос. Апдейт вообще жутко долгий, база ложится. Не говоря уже про память. |
Так всё-таки, сколько записей (реально) у тебя изменяются? (всего за расчёт, который у тебя, как я понял, раз в час делается) И сколько записей (реально!) обрабатывается? (т.е. считывается, по которым идёт расчёт, а не те, что всего в таблице)
_____________
Рекламка / ad.pesow.com Хрень / mr-1.ru
S.Chushkin
Долго объяснять. Вкратце. Основная таблица (самая большая) собирает основную статистику. Есть несколько других, где другие данные. Для каждого пользователя (а их 10000) на основе этих данных расчитывается индивидуальная статистика. Она складывается в сводную таблицу. Вот она и апдейтится. Если это делать онлайн (при посещении страницы), то скрипт работает очень долго на выборке и пересчете. Такое время генерации страницы недопустимо.
Если пересчитывать по очереди, как у меня, но апдейтить сразу скопом, то лочится сводная таблица и вообще никто никуда зайти не может. Вот и приходится апдейтить её партиями. Соответственно в цикле.
Там еще есть несколько нюансов, всего не могу рассказать. Вобщем забей. Цикл тут все равно самое оптимальное решение.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Долго объяснять. Вкратце. Основная таблица (самая большая) собирает основную статистику. Есть несколько других, где другие данные. Для каждого пользователя (а их 10000) на основе этих данных расчитывается индивидуальная статистика. Она складывается в сводную таблицу. Вот она и апдейтится. Если это делать онлайн (при посещении страницы), то скрипт работает очень долго на выборке и пересчете. Такое время генерации страницы недопустимо.
Если пересчитывать по очереди, как у меня, но апдейтить сразу скопом, то лочится сводная таблица и вообще никто никуда зайти не может. Вот и приходится апдейтить её партиями. Соответственно в цикле.
Там еще есть несколько нюансов, всего не могу рассказать. Вобщем забей. Цикл тут все равно самое оптимальное решение.
_____________
Если вам недостаточно собственных заблуждений, можно расширить их мнениями экспертов.
Нужно уважать мнение оппонета. Ведь заблуждаться - его святое право.
Настаивал, настаиваю и буду настаивать на своем. На кедровых орешках.
Здесь расположена полная версия этой страницы.