Если бы вас спросили, может ли система поддерживать двойной рост, что бы вы ответили на три вопроса?

Question

Допустим, на вашей работе ваш начальник говорит:

Та система там, которая потеряла все институциональные знания, но, кажется, сейчас работает довольно хорошо, могли бы мы сбросить вдвое больше данных и выжить?

Вы совершенно не знакомы с системой.

Это в SQL Server 2000 (прежде всего, приложение базы данных).

Там нет тестовой среды.

Возможно, вы сможете угнать его по выходным, если вам понадобится выполнить тест.

Что бы вы сделали, чтобы убедить себя и своего менеджера, что вы могли бы взять на себя эту дополнительную нагрузку? И если вы не можете сделать это на том же оборудовании ... дополнительное оборудование (в долларах), которое потребуется для удовлетворения этого запроса.

Чтобы ответить на ответ от doofledorfer, ваши предположения почти на 180 градусов отклонены. Но это моя вина за неоднозначный вопрос.

1. Один из главных серверов работает 7x24 на 70% -ной базе и отскакивает оттуда, и никто не знает, что он делает.

2. Это не проблема скупки или нытья ... У нашей компании может не быть большого выбора в этом вопросе.

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

Я надеялся, что кто-то скажет что-то вроде: посмотрите, отключите ли вы систему в воскресенье ночью в полночь и запустите тесты SQLIO, чтобы увидеть, насколько близка подсистема хранения к насыщению. Такие вещи.

Answer 1

1. Настройте тестовую среду, даже если мне придется сделать это на моем ноутбуке.

2. Включите некоторую регистрацию в производственной системе, чтобы получить представление об объеме транзакций в дополнение к объему данных.

3. Прочитайте исходный код, когда я запускаю стресс-тесты на моем ноутбуке с увеличивающимися объемами данных.

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

Answer 2

Вы только что описали типичный Agile-проект. Ваш ответ должен быть:

1. Я не знаю, и я не смогу сказать без тестирования.
2. В дополнение к объему данных могут быть проблемы с моделями использования, взаимодействиями приложений, настройкой базы данных и сервера и т. Д.
3. Итак, давайте проработаем базовый список факторов риска и способы их устранения.
4. Как только мы это сделаем, давайте проработаем их в обратном порядке риска; и принять решение об остановке / продолжении по мере развития результатов.
5. и т.д.

Без участия руководства и участия, по крайней мере, на этом уровне, любой другой ответ, который вы можете дать, - это желание с высокой степенью риска, а «3 самых важных» - не секвитур.

Я был бы оптимистичен, если ваша текущая система уже не загружена. Большинство серверов должны работать с емкостью менее 50% на всех ресурсах, или же они должны быть в состоянии жизнеобеспечения. И я ожидаю, что вы не будете вести разговор, если существующий сервер уже будет иметь дело с проблемами загрузки; хотя "кажется, что сейчас он работает довольно хорошо", достаточно неточно, чтобы вызывать беспокойство.

Answer 3

Это зависит от того, что вы подразумеваете под «удвоением данных».

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

Проблема возникнет, если вы удвоите объем данных во всех таблицах, так как тогда время выполнения может возрасти экспоненциально и может привести к серьезным проблемам.

Но в целом я бы поддержал ответ от doofledorfer

Answer 4

в основном зависит от текущего уровня. Если удвоение идет от 2 ГБ до 4 ГБ, просто сделайте это. Если он идет от 1 ТБ до 2 ТБ, у вас есть кое-какие планы.

Я собираю некоторую информацию с помощью Performance Monitor и предоставляю ее, чтобы помочь принять обоснованное решение.