Примерно, какую пользу вы могли бы ожидать, чтобы выжать из MySQL-сервера ~ 1000 долларов?

Как вы заметили, это очень широкая оценка.

Большой вопрос в том, что вы используете эти 1000 долларов, чтобы купить. При условии, что вы будете использовать немного больше памяти и меньше процессорной мощности со средним жестким диском, я бы сказал, что разумно закодированное приложение (где это целесообразно = в основном использует все библиотеки абстрагирования, которые предоставляет ваш язык) с этими параметрами должно обрабатывать около 500 одновременные пользователи. Я бы догадался о большем, за исключением размера набора строк (поскольку чем больше строк помещается непосредственно в ОЗУ, тем меньше нужно идти на диск даже для немедленной записи).

Тип данных в строках и объем оперативной памяти, который вы можете себе позволить, безусловно, будут самыми важными факторами в этом сценарии. Если бы вы могли обойтись меньшим количеством записей и уменьшить размер индексированной таблицы, я думаю, что вы могли бы обойтись с 1000 пользователей одновременно.

Вы увидите две проблемы:

1. Объем данных, которые вы можете кешировать в ОЗУ, и, следовательно, объем ОЗУ, который у вас превышает минимальный, необходимый для выполнения основных операций ОС и сервера базы данных, определит, что вы можете избежать. Больше оперативной памяти, меньше потребностей ОС и меньшее количество полезного объема данных, которые должны храниться в оперативной памяти для запросов и записей, будет означать разницу между приемлемой производительностью и партиями, а также большим количеством перебора.

2. Дизайн вашего приложения здесь очень важен. Одна запись, распространяемая на 500-1000 пользователей, имеет огромное, огромное влияние. Точно так же, если ваши звонки не просты и не эффективны, вы быстро вызовете крушение поезда. Я основал свою оценку на ряде приложений MySQL, которые я видел в игре, с небольшим знанием того, как они работают. Если у приложения есть фундаментальные проблемы, то вы можете даже не получить 40 пользователей. Если вы кодируете его эффективно и учитываете аппаратные ограничения, вы можете легко масштабировать более 2000.

Я могу ответить на это. Я только что сошел с той поездки, снова буду ездить.

650–800 долл. США купит четырехъядерный AMD AMD с 8 ГБ оперативной памяти и 1 ТБ диском SATA2. $170 купит второй относительно быстрый диск объемом 1 ТБ. Имейте в виду, что это стандартное оборудование от большинства магазинов электроники / офисных магазинов / самых популярных. Вы можете получить больше взрыва в другом месте, но не плохо за деньги. Вы можете получить более быстрый четырехъядерный процессор чуть больше.

Теперь, что касается приложения, я предполагаю, что вы используете Linux/BSD/ Unix для ОС и избегаете дебатов MS vs Unix. Вот что я нашел:

У нас нет проблем с указанием 200+ активных пользователей / сессий в любом из наших приложений без мигания, независимо от того, насколько оно слабое. На самом деле, нам не удавалось сбросить / завершить работу / сбить приложение на любом четырехъядерном сервере, который мы запускали в течение некоторого времени... но мы извлекли некоторые уроки еще за одноядерные 200 МГц дни.

Например, наша сестринская компания продает довольно много систем мониторинга связи на основе MySQL с числом пользователей более 1300 на машину и в среднем несколько сотен одновременных сеансов в час. Ведение журнала и составление отчетов осуществляется в режиме реального времени (ну, некоторая буферизация происходит), и они работали на двухъядерных машинах с частотой 3 ГГц на медленных PATA-дисках [вздох]... Действительно, 133 МГц P-ata накопители. Самая большая задержка пользовательского интерфейса составляла около 2 секунд. Они выбросили MSSQL для MySQL десять лет назад и сразу же получили результаты.

Имейте в виду, что эти машины работают с веб-приложениями + базами данных... так что вы делаете математику. Это просто работает. Кроме того, я заменил на них несколько приложений oracle/MS/xxxx и никогда не заканчивал работать. Кроме того, позвольте мне остановиться на том, что другой парень сказал с точки зрения DBA... Вот 6 советов из окопов.

1. Операции записи снижают производительность, особенно если штрафы за блокировку являются чужой концепцией для ваших кодеров.
2. Делая все за одним огромным столом, вы убьете.
3. Чрезмерная нормализация не твой друг. Если ваши кодеры заполняют 3-ю обычную форму, ваше приложение будет работать плохо. Денормализованные данные занимают больше места, но позволяют выполнять большие задачи с помощью простых запросов.
4. Одна большая таблица захлебывается частыми записями. Смотрите 1.
5. Если вы пишете свое приложение для использования одной (или нескольких) таблиц для отображения данных и другой таблицы для записей, которые можно синхронизировать с таблицами чтения, когда позволяет загрузка системы, вы можете избежать неприятностей. Мы используем небольшое количество таблиц для буферизации записей и можем справиться с огромным количеством транзакций, потому что никто не вмешивается.
6. Используйте индексы. Если вы знаете, какие части запросов используются в качестве ключей, в любом случае.
7. Настройте установку базы данных на основе памяти. Смотрите документы MySQL онлайн. По правде говоря, если у вас менее 1000 активных сессий, вы часто можете просто увеличить количество подключений и просто пойти на это. http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html

Вы можете увидеть глупый 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 Мб / с