Давно хотел написать данный пост, но никак руки не доходили. Надеюсь, он будет интересен многим, так как не каждый может ощутить то же.
Начать, наверное, стоит с того, что речь в данном посте будет идти о том, какие ощущения можно получить от создания интернет ресурса, у которого очень быстрое развитие.
Скажу вам одно – развивать ресурс в социальной сети с пустого места очень сложно. Мне как раз удалось почувствовать это на своей шкуре, так как, имея в разы больший функционал, а так же качество и сервис, мое приложение отстало в скорости роста в 7 раз, по сравнению с приложением, на которое шел постоянный слив трафика. Причем я могу вам сказать с точностью 100% о том, что здесь неважно было какой трафик – боты или живые люди, заинтересованные или нет. Все измерялось в общем числе установок приложения. Я пробовал запустить рекламу, но она не дала ожидаемого эффекта, а вот если бы были уже раскрученные на тот момент приложения, с которых можно было бы получить приток пользователей, это было бы совершенно другое дело.
Что касается ощущений… Ох… их очень много и они очень разные. Начиная от радости и заканчивая, конечно же, горой нервов и постоянных переживаний, куда же без них. Хотя, можно обойтись и без лишних нервотрепок, если конечно есть опыт, но в первый раз от них точно не убежишь.
Самые первые запоминающиеся моменты
– 500, 1к, 2к, 3к, 5к, 10к, 20к, 25к, 50к установок приложения.
– 25к, 50к, 100к, 150к DAU
– первое место в категории «Отдых» в рейтинге Mail.ru
– первое место в категории «Интернет» в рейтинге Mail.ru
– топ 100 во всем рейтинге Mail.ru (за день, неделю, месяц)
– падение сервера (каждое, причем)
– 3к, 5к, 10к TCP коннектов к серверу
Если вы никогда не сталкивались с такими нагрузками – вам постоянно нужно будет следить за работоспособностью сервера в пиковые часы посещаемости, а это с 16:00 до 24:00 по МСК (GMT+3). В этот период у сервера просто дикое желание упасть
При таких нагрузка каждый запрос, каждая строка кода отыгрывает очень важную роль в стабильности работы. Если база данных имеет свойство очень быстро расти – нужно очень быстро анализировать все запросы, и правильно расставлять ключи на таблицах, а так же проверять разные вариации запросов и структур таблиц, пока не будет подобран самый оптимальный вариант. Так как, когда в таблице более 10кк записей, неправильно поставленные запросы могут обрабатываться до 10, а то и более секунд, что естественно непозволительно, так как это все время загрузки скрипта.
Кроме программной части необходимо еще и сервер настроить под такие нагрузки, а это без опыта сделать довольно сложно, собственно как и все остальное. Опыт – самое ценное, что можно получить от таких моментов.
Ну и в заключение несколько советов, на все случаи жизни, так сказать.
Проверено, что 1 таблица с 10кк записей лучше чем 1000 таблиц с 100к записей в каждой. Конечно, здесь есть свои факторы. Если базу данных распределять по серверам, то ситуация будет обратной. Но серверу mysql не нравиться, когда на нем открыто 4к таблиц. Поэтому если БД находиться на 1м сервере – то разбивку на таблицы лучше не делать.
У каждой таблицы должны быть ключи, и именно ключи, а не ключ. При этом ключи должны быть составлены по коду, либо же код должен быть написан с учетом ключей. Без правильных ключей будет фейл.
Запросы с GROUP BY к нескольким большим таблицам могут оказаться довольно тяжелыми.
SELEC MAX(val) не всегда лучше чем SELECT val ORDER BY id DESC LIMIT 1, но и не всегда хуже. Все зависит от структуры таблицы и данных, которые в ней находяться.
SELECT count(*) без ключей это гибель
Неправильно составленный запрос к БД это падение процесса mysql. Точнее процесс просто виснет.
Если данные не очень динамичны – их следует кешировать через мемкеш. Кешировать можно не только SQL запросы, а и готовые массивы, полученные от обработки PHP, например.
За два месяца мой проект вырвался в Топ 100 по рейтингу Mail.ru, в БД 32кк записей, которые занимают уже 1,6 ГБ. База растет довольно стремительными темпами, что в принципе радует.
http://w0a.ru/blog/21.html
Начать, наверное, стоит с того, что речь в данном посте будет идти о том, какие ощущения можно получить от создания интернет ресурса, у которого очень быстрое развитие.
Скажу вам одно – развивать ресурс в социальной сети с пустого места очень сложно. Мне как раз удалось почувствовать это на своей шкуре, так как, имея в разы больший функционал, а так же качество и сервис, мое приложение отстало в скорости роста в 7 раз, по сравнению с приложением, на которое шел постоянный слив трафика. Причем я могу вам сказать с точностью 100% о том, что здесь неважно было какой трафик – боты или живые люди, заинтересованные или нет. Все измерялось в общем числе установок приложения. Я пробовал запустить рекламу, но она не дала ожидаемого эффекта, а вот если бы были уже раскрученные на тот момент приложения, с которых можно было бы получить приток пользователей, это было бы совершенно другое дело.
Что касается ощущений… Ох… их очень много и они очень разные. Начиная от радости и заканчивая, конечно же, горой нервов и постоянных переживаний, куда же без них. Хотя, можно обойтись и без лишних нервотрепок, если конечно есть опыт, но в первый раз от них точно не убежишь.
Самые первые запоминающиеся моменты
– 500, 1к, 2к, 3к, 5к, 10к, 20к, 25к, 50к установок приложения.
– 25к, 50к, 100к, 150к DAU
– первое место в категории «Отдых» в рейтинге Mail.ru
– первое место в категории «Интернет» в рейтинге Mail.ru
– топ 100 во всем рейтинге Mail.ru (за день, неделю, месяц)
– падение сервера (каждое, причем)
– 3к, 5к, 10к TCP коннектов к серверу
Если вы никогда не сталкивались с такими нагрузками – вам постоянно нужно будет следить за работоспособностью сервера в пиковые часы посещаемости, а это с 16:00 до 24:00 по МСК (GMT+3). В этот период у сервера просто дикое желание упасть
При таких нагрузка каждый запрос, каждая строка кода отыгрывает очень важную роль в стабильности работы. Если база данных имеет свойство очень быстро расти – нужно очень быстро анализировать все запросы, и правильно расставлять ключи на таблицах, а так же проверять разные вариации запросов и структур таблиц, пока не будет подобран самый оптимальный вариант. Так как, когда в таблице более 10кк записей, неправильно поставленные запросы могут обрабатываться до 10, а то и более секунд, что естественно непозволительно, так как это все время загрузки скрипта. Кроме программной части необходимо еще и сервер настроить под такие нагрузки, а это без опыта сделать довольно сложно, собственно как и все остальное. Опыт – самое ценное, что можно получить от таких моментов.
Ну и в заключение несколько советов, на все случаи жизни, так сказать.
Проверено, что 1 таблица с 10кк записей лучше чем 1000 таблиц с 100к записей в каждой. Конечно, здесь есть свои факторы. Если базу данных распределять по серверам, то ситуация будет обратной. Но серверу mysql не нравиться, когда на нем открыто 4к таблиц. Поэтому если БД находиться на 1м сервере – то разбивку на таблицы лучше не делать.
У каждой таблицы должны быть ключи, и именно ключи, а не ключ. При этом ключи должны быть составлены по коду, либо же код должен быть написан с учетом ключей. Без правильных ключей будет фейл.
Запросы с GROUP BY к нескольким большим таблицам могут оказаться довольно тяжелыми.
SELEC MAX(val) не всегда лучше чем SELECT val ORDER BY id DESC LIMIT 1, но и не всегда хуже. Все зависит от структуры таблицы и данных, которые в ней находяться.
SELECT count(*) без ключей это гибель
Неправильно составленный запрос к БД это падение процесса mysql. Точнее процесс просто виснет.
Если данные не очень динамичны – их следует кешировать через мемкеш. Кешировать можно не только SQL запросы, а и готовые массивы, полученные от обработки PHP, например.
За два месяца мой проект вырвался в Топ 100 по рейтингу Mail.ru, в БД 32кк записей, которые занимают уже 1,6 ГБ. База растет довольно стремительными темпами, что в принципе радует.
http://w0a.ru/blog/21.html
