Я знаю, что это ужасный, обобщенный вопрос, на который нет хорошего ответа, и я заранее извиняюсь, но мне интересно, может ли кто-нибудь попытаться дать очень общую оценку.
Предположим, у вас есть выделенный сервер MySQL, работающий на современном оборудовании стоимостью около 1000 долларов.
Предположим, среднестатистический пользователь делает 20 запросов на чтение и 5 запросов на запись в минуту — все это простые запросы, без объединений; в основном это запросы типа «выбрать эту строку по UUID» из индексированной таблицы, содержащей около 10 000 000 строк.
Очень, очень, очень, очень приблизительно, сколько одновременных пользователей, по вашему мнению, может обслуживать такой сервер, прежде чем вы его «загрузите»?
решение1
Как вы отметили, это очень широкая оценка.
Главный вопрос в том, на что вы потратите эти $1000. При условии, что вы раскошелитесь на немного больше памяти и меньшую мощность процессора со средним жестким диском, я бы сказал, что разумно закодированное приложение (где разумно = в основном с использованием любых абстрактных библиотек, которые предоставляет ваш язык) с этими параметрами должно быть способно обрабатывать около 500 одновременных пользователей. Я бы предположил больше, если бы не размер набора строк (поскольку чем больше строк помещается непосредственно в ОЗУ, тем меньше обращений к диску вам придется делать даже для немедленной записи).
Тип данных, которые находятся в строках, и объем оперативной памяти, который вы можете себе позволить, безусловно, будут самыми важными факторами в этом сценарии. Если бы вы могли обойтись меньшим количеством записей и уменьшить размер индексированной таблицы, я думаю, что вы могли бы обойтись 1000 пользователями одновременно.
Две проблемы, которые вы увидите:
Объем данных, которые вы можете кэшировать в ОЗУ, и, следовательно, объем ОЗУ, который у вас есть сверх минимума, необходимого для выполнения основных операций ОС и сервера базы данных, определит, что вы можете себе позволить. Больше ОЗУ, меньше потребностей ОС и меньший полезный объем данных, которые должны храниться в ОЗУ для запросов и записей, будут означать разницу между приемлемой производительностью и большим, большим количеством проседаний.
Дизайн вашего приложения здесь абсолютно критичен. Одна запись, распределенная на 500-1000 пользователей, имеет огромное, огромное влияние. Аналогично, если ваши вызовы не просты и неэффективны, то вы быстро вызовете крушение поезда. Я основывал свою оценку на ряде приложений MySQL, которые я видел в игре, имея небольшое представление о том, как они работают. Если у приложения есть фундаментальные проблемы, то вы можете даже не достичь 40 пользователей. Если вы эффективно кодируете его и учитываете ограничения оборудования, вы можете легко масштабироваться за пределы 2000.
решение2
Я могу ответить на этот вопрос. Я только что сошел с этого аттракциона, поеду еще.
За 650–800 долларов можно купить 8 ГБ оперативной памяти, четырехъядерный процессор AMD средней скорости, работающий с диском SATA2 на 1 ТБ. За 170 долларов можно купить второй относительно быстрый диск на 1 ТБ. Имейте в виду, что это готовое оборудование из большинства магазинов электроники/офисных магазинов/мест типа best buy. Вы можете получить больше в другом месте, но неплохо за эти деньги. Вы можете получить более быстрый четырехъядерный процессор за небольшую дополнительную плату.
Теперь, что касается приложения, я предположу, что вы используете linux/BSD/unix для ОС и избегаю споров ms против unix. Вот что я нашел:
У нас нет проблем с указанием 200+ активных пользователей/сессий в любом из наших приложений без морга, независимо от того, насколько слабое приложение. Фактически, мы не могли уронить/упасть/затормозить приложение ни на одном четырехъядерном сервере, который мы запускали в течение некоторого времени... но мы извлекли некоторые уроки еще во времена одноядерных 200 МГц.
Например, наша дочерняя компания продает довольно много систем мониторинга коммуникаций на основе MySQL с 1300+ пользователями на машину и в среднем несколькими сотнями одновременных сеансов в час. Регистрация и отчетность выполняются в режиме реального времени (ну, некоторая буферизация происходит), и они работают на двухъядерных машинах 3 ГГц на [вздох] медленных дисках PATA... Действительно, на дисках P-ATA 133 МГц. Самая длинная задержка пользовательского интерфейса когда-либо составляла около 2 секунд. Они отказались от MSSQL в пользу MySQL десять лет назад и немедленно получили результаты.
Имейте в виду, что эти машины запускают веб-приложения+базы данных... так что посчитайте сами. Это просто работает. Кроме того, я заменил несколько приложений Oracle/MS/xxxx на эти, и они никогда не были близки к исчерпанию энергии. Кроме того, позвольте мне расширить то, что сказал другой парень с точки зрения dba... Вот 6 советов с передовой.
- Записи снижают производительность, особенно если штрафы за блокировку незнакомы вашим программистам.
- Если делать все за одной огромной таблицей, это убьет вас.
- Излишняя нормализация вам не друг. Если ваши кодеры полностью переходят на третью нормальную форму, ваше приложение будет работать плохо. Денормализованные данные занимают больше места, но позволяют добиться больших результатов с помощью простых запросов.
- Одна большая таблица захлебнется от частых записей. См. 1.
- Если вы пишете свое приложение, чтобы использовать одну (или несколько) таблиц для отображения данных и другую таблицу для записи, которая может быть синхронизирована с таблицами чтения, когда это позволяет загрузка системы, вы можете обойтись без всего. Мы используем небольшое количество таблиц для буферизации записи и способны справиться с невероятным количеством транзакций, потому что никто не попадает под удар.
- Используйте индексы. Если вы знаете, какие части запросов используются в качестве ключей, в любом случае.
- Настройте установку базы данных на основе памяти. Посмотрите документацию MySQL в Интернете. По правде говоря, если у вас меньше 1000 активных сеансов, вы часто можете просто увеличить количество подключений и просто сделать это. http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html
Вы можете увидеть тупой SQL в действии, взглянув на большинство плагинов WordPress и т. д. Большинство из них написано людьми, которые не понимают SQL, и они поставят сервер на колени в мгновение ока с помощью всего лишь нескольких пользователей.
решение3
Сервер за 884 доллара, 8 ГБ ОЗУ, два четырехъядерных процессора xeon, диск SATA 300 ГБ 7200 об/мин, 40% простоя, 5% iowait
Uptime: 780727 Threads: 276 Questions: 1884267879 Slow queries: 3964303 Opens: 60474
Flush tables: 1 Open tables: 440 Queries per second avg: 2413.478
при обслуживании 220мб/сек