Я знаю, что это ужасный, обобщенный вопрос, на который нет хорошего ответа, и заранее прошу прощения, но мне интересно, может ли кто-нибудь сделать удар по очень широкой оценке.
Допустим, у вас есть выделенный сервер MySQL, работающий на современном оборудовании стоимостью около 1000 долларов.
Допустим, средний пользователь делает 20 запросов на чтение и 5 запросов на запись в минуту - все простые запросы, без присоединений; в основном по строкам «выбрать эту строку по UUID» из индексированной таблицы из ~ 10 000 000 строк.
Очень, очень, очень, очень приблизительно, сколько одновременных пользователей вы ожидаете от такого сервера, прежде чем вы его «протолкните».
Как вы отметили, это очень широкая оценка.
Большой вопрос в том, на что вы потратите эти 1000 долларов. При условии, что вы используете немного больше памяти и меньшую мощность процессора со средним жестким диском, я бы сказал, что разумно закодированное приложение (где разумно = в основном с использованием любых абстрактных библиотек, которые предоставляет ваш язык) с этими параметрами должно быть способно обрабатывать около 500 одновременные пользователи. Я бы предположил больше, за исключением размера набора строк (поскольку чем больше строк помещается непосредственно в ОЗУ, тем меньше приходится делать на диск даже для немедленной записи).
Тип данных, которые находятся в строках, и объем оперативной памяти, который вы можете себе позволить, безусловно, будут самыми важными факторами в этом сценарии. Если бы вы могли обойтись меньшим количеством операций записи и меньшим размером индексируемой таблицы, я бы подумал, что вы могли бы обойтись с 1000 пользователей одновременно.
Вы увидите две проблемы:
Объем данных, которые вы можете кэшировать в ОЗУ, и, следовательно, объем ОЗУ, который у вас превышает минимальный, необходимый для работы базовой ОС и операций сервера базы данных, будет определять, что вам может сойти с рук. Больше ОЗУ, меньше потребностей ОС и меньший полезный объем данных, который должен храниться в ОЗУ для запросов и записей, будут означать разницу между приемлемой производительностью и партиями, а также большим количеством перегрузок.
Здесь абсолютно важен дизайн вашего приложения. Одна запись, распределенная между 500-1000 пользователями, имеет огромное, огромное влияние. Точно так же, если ваши звонки не просты и неэффективны, вы быстро вызовете крушение поезда. Я основывал свою оценку на ряде приложений mySQL, которые я видел в игре, с небольшим знанием того, как они работают. Если в приложении есть фундаментальные проблемы, то вы можете не попасть даже на 40 пользователей. Если вы запрограммируете это эффективно и примете во внимание аппаратные ограничения, вы сможете легко масштабироваться за пределы 2000.
Я могу на это ответить. Я только что сошел с этой поездки, поеду снова.
За 650-800 долларов можно купить четырехъядерный процессор AMD с умеренной скоростью ОЗУ 8 ГБ и диск SATA2 емкостью 1 ТБ. За 170 долларов можно купить второй относительно быстрый диск емкостью 1 ТБ. Имейте в виду, что это готовое оборудование, которое можно купить в большинстве магазинов электроники / офисного магазина / магазинов по лучшей цене. Вы можете получить больше удовольствия в другом месте, но неплохо за эти деньги. Вы можете получить более быстрый четырехъядерный процессор за немного больше.
Теперь, что касается приложения, я предполагаю, что вы используете linux / BSD / unix для ОС и избегаете дебатов ms vs unix. Вот что я нашел:
У нас нет проблем с указанием 200+ активных пользователей / сеансов в любом из наших приложений без мигания, независимо от того, насколько слабым является приложение. Фактически, мы не могли сбросить / вывести из строя / остановить приложение на любом четырехъядерном сервере, который мы запускали в течение некоторого времени ... но мы извлекли некоторые уроки еще в дни одноядерных 200 МГц.
Например, наша дочерняя компания продает довольно много систем мониторинга связи на основе MySQL с более чем 1300 пользователями на машину и в среднем несколькими сотнями одновременных сеансов в час. Ведение журнала и отчеты ведутся в режиме реального времени (ну, происходит некоторая буферизация), и они работали на двухъядерных машинах с частотой 3 ГГц на медленных дисках PATA ... Действительно, на дисках P-ata с частотой 133 МГц. Самая длинная задержка пользовательского интерфейса составляла около 2 секунд. Они отказались от MSSQL для MySQL десять лет назад и сразу получили результаты.
Имейте в виду, что на этих машинах запущены веб-приложения + базы данных ... так что вы делаете математику. Просто работает. Кроме того, я заменил ими ряд приложений oracle / MS / xxxx и никогда не приближался к тому, чтобы выдать пар. Кроме того, позвольте мне расширить сказанное другим парнем с точки зрения dba ... Вот 6 советов из окопов.
Вы можете увидеть глупый SQL в действии, посмотрев на большинство файлов wordpress / etc. плагины. Большинство из них написано людьми, у которых нет sql, и они мгновенно поставят сервер на колени с помощью всего лишь нескольких пользователей.
Сервер за $ 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 мб / сек