Если бы вас спросили, может ли система поддерживать двойной рост, какие 3 вещи вы бы сделали, чтобы ответить?
Допустим, на работе ваш босс говорит:
That system over there, which has lost all institutional knowledge but seems to run pretty good right now, could we dump double the data in it and survive?
Вы совершенно не знакомы с системой.
Это в SQL Server 2000 (в основном приложение для базы данных).
Тестовой среды нет.
Вы могли бы захватить его на выходных, если вам нужно было запустить тест.
Какие 3 вещи вы бы сделали, чтобы убедить себя, а затем и своего менеджера, что вы можете взять на себя эту дополнительную нагрузку. И если вы не можете сделать это на том же оборудовании ... дополнительное оборудование (измеряемое в долларах), которое потребуется, чтобы удовлетворить этот запрос.
Что касается ответа от doofledorfer, ваши предположения почти все отклоняются на 180 градусов. Но это моя вина за неоднозначный вопрос.
Один из основных серверов работает 7x24 с базой 70% и оттуда резко увеличивается, и никто не знает, что он делает.
Это не вопрос поддержки или нытья ... У нашей компании может не быть особого выбора в этом вопросе.
Поскольку это делается извне, задержки в реализации могут привести к огромным штрафам. Столь большие собрания оценить риски практически невозможно. Есть один риск, что двойной сброс данных приведет к остановке системы для существующих клиентов.
Я надеялся, что кто-то скажет что-то вроде: «Выключите ли вы систему в воскресенье вечером в полночь и запустите тесты SQLIO, чтобы увидеть, насколько близка подсистема хранения к насыщению». Такие вещи.
Ответы 4
это в основном зависит от его текущего уровня. Если удвоение идет с 2 ГБ до 4 ГБ, просто сделайте это. Если он увеличивается с 1 ТБ до 2 ТБ, вам нужно что-то запланировать.
Я бы собрал некоторую информацию с помощью монитора производительности и предоставил ее, чтобы помочь принять обоснованное решение.
Настройте тестовую среду, даже если мне придется делать это на моем ноутбуке.
Включите какой-либо вид ведения журнала в производственной системе, чтобы получить представление об объеме транзакций в дополнение к объему данных.
Читайте исходный код, когда я запускаю стресс-тесты на своем ноутбуке с увеличивающимся объемом данных.
Сказав это, я сочувствую этому поручению, потому что это несправедливо. Это все равно, что спросить кого-то в лодке, может ли лодка плавать с вдвое большим грузом, но вы не можете выйти из лодки или вывести ее из эксплуатации.
К сожалению, я не сомневаюсь, что у вас будет много возможностей использовать эту аналогию. Подобные безнадежные задания очень распространены.
Вы только что описали типичный Agile-проект. Ваш ответ должен быть таким:
- Я не знаю и не смогу сказать без тестирования.
- Помимо объема данных, могут возникнуть проблемы с шаблонами использования, взаимодействием приложений, настройкой базы данных и сервера и т. д.
- Итак, давайте рассмотрим основной список факторов риска и способы их устранения.
- Как только мы это сделаем, давайте рассмотрим их в порядке, обратном риску; и принимаем решение о остановке / продолжении по мере развития результатов.
- и т.п.
Без поддержки руководства и участия хотя бы на этом уровне любой другой ответ, который вы могли бы дать, является желанием с высоким риском, а «3 самых важных» - не следствие.
Я был бы настроен оптимистично, если ваша текущая система уже существенно не загружена. Большинство серверов должны работать на всех ресурсах с загрузкой менее 50%, в противном случае они должны поддерживать жизнедеятельность. И я ожидаю, что у вас не было бы разговора, если бы существующий сервер уже имел дело с проблемами нагрузки; хотя фраза «кажется, сейчас работает неплохо» достаточно неточна, чтобы вызывать беспокойство.
Это зависит от того, что вы подразумеваете под «удвоением данных».
Если это повлияет только на одну таблицу (скажем, на таблицу продуктов), вы, вероятно, в безопасности, поскольку большинство запросов, которые относятся к этой одной таблице, скорее всего, удвоят время выполнения (это предполагает, что вы не ссылаетесь на одно и то же время дважды. в запросе).
Проблема возникнет, если вы удвоите объем данных во всех таблицах, так как время выполнения может расти экспоненциально, что может привести к некоторым серьезным проблемам.
Но в целом я бы поддержал ответ от doofledorfer
удвоение данных означает, что каждая исходная таблица в базе данных будет иметь в два раза больше строк (клиентов, учетных записей, местоположений), таких как это ... и таблицы, добавляемые каждый день с результатами, будут иметь в два раза больше строк, добавляемых каждый день ... не удвоится сразу, но ежедневное прибавление удвоится.
Очень хорошая аналогия. Я люблю это. Серьезно, я собираюсь использовать это примерно 50 раз к концу следующего года и никогда не буду отдавать вам должное. ;-) мод +2