Проектирование одновременных запросов к базе данных

Question

После некоторых размышлений о том, как люди рассчитывают загрузку базы данных для целей планирования емкости. Я не указывал это на сбой сервера, потому что вопрос связан с измерением только приложения, а не с определением инфраструктуры. В этом случае беспокоиться об этом придется кому-то другому!

Я знаю, что здесь огромное количество переменных, но мне интересно, как другие воспринимают приблизительный порядок величин. Это просто упражнение с затратами на раннем этапе жизненного цикла проекта до создания какого-либо конкретного проекта, поэтому на этом этапе не нужно много информации.

Вопрос, который я поставил перед специалистами по инфраструктуре: "Сколько пользователей одновременно". Давайте не будем обсуждать обоснование поиска только этой фигуры; это именно то, о чем просили в этом случае!

Это веб-интерфейс SQL Server с достаточно фиксированной и легко поддающейся количественной оценке аудиторией. На мой взгляд, это очень грубо для реальных одновременных запросов, сводится к все более детальным единицам измерения:

1. Общая аудитория
2. Одновременные сессии
3. Одновременные запросы
4. Одновременные запросы к БД

Это не учитывает такие факторы, как кеширование веб-приложений, частичные запросы страниц, объем записей и т. Д., И существует некоторая творческая лицензия, необходимая для определения частоты запросов на пользователя и количества обращений к БД и времени выполнения, но это кажется разумной отправной точкой. Я также осознаю необходимость масштабирования для пиковой нагрузки, но это еще кое-что, что можно подключить к одновременным сеансам при необходимости.

Это, по общему признанию, очень простой, и я уверен, что есть более полное руководство. Если кто-то может поделиться своим подходом к этому упражнению или указать мне на другие ресурсы, которые могут сделать процесс немного менее специальным, это было бы здорово!

Answer 1

Я постараюсь, но, очевидно, не зная деталей, довольно сложно дать точный совет.

Прежде всего, ребята из инфраструктуры могли бы задать этот вопрос с точки зрения лицензирования (сервер SQL может быть лицензирован для каждого пользователя или для каждого процессора)

Теперь вернемся к вашему вопросу. "Общая аудитория" важна, если вы можете предсказать / определить это число. Это может дать вам наихудший сценарий, когда все пользователи одновременно обращаются к базе данных (например, 9:00, когда все входят в систему).

Если вы храните информацию о сеансе, вы, вероятно, будете иметь как минимум 2 соединения на пользователя (1 сеанс + 1 основная БД). Но это число может быть (иногда заметно) уменьшено путем объединения пулов (зависит от того, как вы подключаетесь к базе данных). Используйте наихудший сценарий - 50 системных подключений + 2 * количество пользователей.

Одновременные запросы / запросы зависят от характера приложения. Нужно больше деталей. Больше одновременных запросов (к вашему внешнему интерфейсу) не обязательно приведет к большему количеству запросов на внутреннем интерфейсе.

Сказав все это - для целей расчета стоимости вы должны сосредоточиться на более широкой картине.

1. Лицензия на сервер SQL (если мне не изменяет память) будет стоить ~128K AUD (двойной Xeon). Горячий / теплый режим ожидания? Удвойте стоимость.

2. Дисковое хранилище - сколько памяти вам понадобится? Диски относительно дешевые, но если вы собираетесь использовать SAN, стоимость может стать заметной. Кроме того, чем больше дисков, тем лучше с точки зрения производительности.