1. laggerok - 28 Мая, 2012 - 16:34:34 - перейти к сообщению
К чему приводят запросы типа select * from <tablename>, если в таблице миллионы записей, кроме того, что выведет всю таблицу, это создаст нагрузку на сервер и он будет относительно догло дуплить?
2. Alho - 28 Мая, 2012 - 16:41:28 - перейти к сообщению
Долгому исполнению запроса, невозможностью в это время использовать бд другими юзерами, возможны падения.
Всегда нужно выбирать лишь нужные поля и и ограничивать их кол-во лимитом.
Эти неприятности начинаются уже на сотнях тысяч, про миллионы - молчу, в моей доверенности такого пока не было.
Всегда нужно выбирать лишь нужные поля и и ограничивать их кол-во лимитом.
Эти неприятности начинаются уже на сотнях тысяч, про миллионы - молчу, в моей доверенности такого пока не было.
3. tato - 28 Мая, 2012 - 16:46:12 - перейти к сообщению
Будет так называемый хайлоад - т.е. большая нагрузка, поведение базы зависит от возможностей сервера, но в суровых реалях при миллионах записей база отвалится с вероятностью 99.99%.
======
Наврал хайлода не будет, просто все отвалится...
======
Наврал хайлода не будет, просто все отвалится...
4. laggerok - 28 Мая, 2012 - 16:54:49 - перейти к сообщению
Цитата:
невозможностью в это время использовать бд другими юзерами
А откуда такая информация?
5. tato - 28 Мая, 2012 - 17:00:52 - перейти к сообщению
Это оффициальная инфа, в завизимости от типа mysql бд (myisam || innodb) блакируется или вся таблица или конкретные поля.
6. laggerok - 28 Мая, 2012 - 17:02:35 - перейти к сообщению
Цитата:
Это оффициальная инфа, в завизимости от типа mysql бд (myisam || innodb) блакируется или вся таблица или конкретные поля.
Можно ссылочку почитать?
7. tato - 28 Мая, 2012 - 17:04:31 - перейти к сообщению
8. IronHawk - 28 Мая, 2012 - 17:06:18 - перейти к сообщению
Есть такой опыт, так как в распоряжении есть парочка баз в которых есть баблицы с 1-2 млн. записей.
Риск отказа СУБД велик при:
- некорректной архитектуре БД
- отсутствии оптимальности запросов к таблицам БД
Риск отказа СУБД велик при:
- некорректной архитектуре БД
- отсутствии оптимальности запросов к таблицам БД
9. laggerok - 28 Мая, 2012 - 17:30:00 - перейти к сообщению
Я еще со своей стороны узнал и в итоге имеет такое:
- нагрузка на сервек (или вообще крах, если оч все плохо);
- возможно, блокировка некоторых рядков, если это InnoDB;
- обновление кешей путем втуливания туда новой инфы с селекта;
- создание очереди запросов к данной таблице;
- нагрузка на сервек (или вообще крах, если оч все плохо);
- возможно, блокировка некоторых рядков, если это InnoDB;
- обновление кешей путем втуливания туда новой инфы с селекта;
- создание очереди запросов к данной таблице;
10. Мелкий - 28 Мая, 2012 - 19:54:14 - перейти к сообщению
Ох. причёсываю толпу народа и неточностей.
Будет вычитывать всю таблицу. Является ли это проблемой - зависит от объёма данных. И необходимой скорости отклика.
Если памяти достаточно и есть в этом реальная необходимость (чего мне не придумать, работу с данными на базу вешать и надо) - можно читать. Запрос элементарен, данные вовсе линейным чтением поднимаются.
На моей убитой виртуалке 3 ляма записей (около 250мб) обходится в цикле за 15 секунд времени. Замедление других запросов незаметно.
На 4 лямах - кончилась клиентская память, запрос отвалился.
База отработает спокойно. А вот на клиенте память кончится.
Блокировки при изменении данных, для сохранения консистентности.
Параллельные 100% чтения - задача самая простая из работы планировщика СУБД.
Помним о том, что limit 100000, 200000 всё равно прочитает 200 тысяч записей?
Всего лишь?
Тестовое задание ко мне на работу требует нормальной работы на базе в 2 млн пользователей. Связанная тестовая таблица у меня вышла 50млн записей, суммарно 2гб объём. (кстати, Питер, открыта вакансия)
Очень сложно обрушить сервер таким запросом. Вот если попробовать переджойнить с чем-нибудь - то да, nested loop очень печален на таких объёмах.
Само собой. Если это постоянная нагрузка - повод подумать об отключении кэша запросов и увеличении памяти машине.
И ещё раз обращу внимание - сильно сомневаюсь, что вам нужен на клиенте (php то есть) весь этот массив данных. Наверняка же как-то группировать и агрегировать собрались.
laggerok пишет:
К чему приводят запросы типа select * from <tablename>
Будет вычитывать всю таблицу. Является ли это проблемой - зависит от объёма данных. И необходимой скорости отклика.
Если памяти достаточно и есть в этом реальная необходимость (чего мне не придумать, работу с данными на базу вешать и надо) - можно читать. Запрос элементарен, данные вовсе линейным чтением поднимаются.
На моей убитой виртуалке 3 ляма записей (около 250мб) обходится в цикле за 15 секунд времени. Замедление других запросов незаметно.
На 4 лямах - кончилась клиентская память, запрос отвалился.
tato пишет:
в суровых реалях при миллионах записей база отвалится с вероятностью 99.99%.
База отработает спокойно. А вот на клиенте память кончится.
tato пишет:
в завизимости от типа mysql бд (myisam || innodb) блакируется или вся таблица или конкретные поля.
Блокировки при изменении данных, для сохранения консистентности.
Параллельные 100% чтения - задача самая простая из работы планировщика СУБД.
Alho пишет:
и ограничивать их кол-во лимитом.
Помним о том, что limit 100000, 200000 всё равно прочитает 200 тысяч записей?
IronHawk пишет:
Есть такой опыт, так как в распоряжении есть парочка баз в которых есть баблицы с 1-2 млн. записей.
Всего лишь?
Тестовое задание ко мне на работу требует нормальной работы на базе в 2 млн пользователей. Связанная тестовая таблица у меня вышла 50млн записей, суммарно 2гб объём. (кстати, Питер, открыта вакансия)
laggerok пишет:
- нагрузка на сервек (или вообще крах, если оч все плохо);
Очень сложно обрушить сервер таким запросом. Вот если попробовать переджойнить с чем-нибудь - то да, nested loop очень печален на таких объёмах.
laggerok пишет:
- обновление кешей путем втуливания туда новой инфы с селекта;
Само собой. Если это постоянная нагрузка - повод подумать об отключении кэша запросов и увеличении памяти машине.
И ещё раз обращу внимание - сильно сомневаюсь, что вам нужен на клиенте (php то есть) весь этот массив данных. Наверняка же как-то группировать и агрегировать собрались.
11. laggerok - 31 Мая, 2012 - 11:06:56 - перейти к сообщению
Еще в добавок: есть такой "страшний" тип данных как BLOB. Извращенцы, например, могуг заливать в поля, добрые фотки или картинки в этом типе данных.
А вообще это была не задача. Тут ослу понятно, что такого делать нельзя, просто интересовали практические последствия таких запросов...ну кроме увольнения с работы...
А вообще это была не задача. Тут ослу понятно, что такого делать нельзя, просто интересовали практические последствия таких запросов...ну кроме увольнения с работы...