Каковы некоторые приблизительные пределы производительности (чтение/с, запись/с) для одного сервера базы данных (без архитектуры master-slave), предполагая, что хранилище находится на диске? Сколько чтений/с, записей/с в зависимости от типа диска? (SSD или не-SSD), предполагая простые операции (выбор одной строки по первичному ключу, обновление одной строки, корректная индексация). Я предполагаю, что этот предел зависит от поиска/записи на диске.
EDIT: Мой вопрос больше касается получения приблизительных показателей количества операций, поддерживаемых базой данных: например, чтобы знать, может ли новая функция, запускающая 300 вставок в секунду, поддерживаться без масштабирования с помощью дополнительных серверов.
решение1
Вы можете прочитать множество результатов тестовздеськак будто сайт является надежным источником.
решение2
Могу ли я быть настолько смелым, чтобы предложить вам протестировать его, чтобы получить ответ на ваш собственный вопрос. Если у вас есть Windows, запуститеSSIO.exeна вашем компьютере для разработки, чтобы протестировать производительность диска и понять, как он работает, не выполняя никаких действий.
Затем запустите монитор производительности (предполагая, что вы используете MS-SQL TKProf, возможно, Oracle - не используйте mysql или другие, извините, будет похожий инструмент.) Запустите свой запрос и посмотрите, сколько чтений/записей и сколько процессорного времени потребовалось для его выполнения. Затем вы можете сравнить цифры SSIO и монитора производительности и масштабировать требования к оборудованию для обработки количества пользователей/частоты, которые потребуются этому обновлению на основе вашего текущего оборудования.
Сказав, что 300 строк — это очень малое количество строк для изменения для любого разумного SQL Server даже на довольно медленных дисках. Если только нет массивных составных индексов или BLOB-объектов и т. д. Я наблюдал за процессами в реальном времени, когда пользователь наблюдал за запросом, создающим 1,5 млн строк, которые выполняются за доли секунды на относительно скромном оборудовании.
решение3
Тыне мочьсудите без сравнительного анализа вашего приложения и нагрузки.
Все сводится к уровням RAID, скорости вращения шпинделя, размеру транзакций (не только «вставок»), триггерам, внешним ключам, гиперпоточности, другим приложениям на сервере, оперативной памяти на сервере, организации дисков (отдельные тома для tempdb, один том на t-log базы данных, MDF и т. д.), уровню пакета обновления, конфигурации кэша RAID-контроллера, кэшу L + L3 ЦП, количеству ядер, дизайну схемы, коду...
Масштабирование вверх проще, чем масштабирование вниз: вы добавляете накладные расходы, если объединяете серверы или таблицы разделов. Дешевле добавить ОЗУ и больше шпинделей.
Хорошая статья - это35 тыс. TPS Пола Нильсона. По крайней мере, в 100 раз больше нагрузки, чем ваши 300 или около того.