Пропускная способность программного обеспечения / формулы роста базы данных

Question

Существуют ли какие-либо стандартные отраслевые формулы или практические правила для определения:

1. Использование полосы пропускания приложения / требования
2. Требования к росту базы данных

Я недавно начал управлять новым проектом .NET 3.5 / SQL Server и хотел бы использовать более структурированный подход, чем ранее, когда точно определяю, что нужно моему приложению с точки зрения хранения и пропускной способности. Если у кого-то есть какие-либо указатели, я был бы очень признателен!

Answer 1

Я не эксперт по SQL Server, но в целом, для определения размера базы данных, лучший способ продвинуться вперед - это немного понять схему. Например, есть ли разделы в базе данных? Есть много индексов и т. Д. Теперь умножьте количество записей, поступающих в базу данных в каждой транзакции, с частотой транзакций в час. Это дает общее количество записей, поступающих в базу данных в час. Умножьте это на средний размер строки, это обеспечит размер базы данных без разделения на разделы и пространство индекса. Чтобы вычислить накладные расходы на разделы, необходимо понять тип раздела, такой как диапазонный диапазон или хеш-раздел и т. Д., Количество разделов, которые будут созданы в час или в день, и добавить накладные расходы пространства для разделов. Обычно это число нужно увеличить на 50%, чтобы оценить размер базы данных. В случае сети, есть много способов сделать это. Я запускаю etheral для захвата сетевого трафика. Если вы захватываете сетевой трафик, становится интересно - как сезонность данных - как, например, в часы пик, каково максимальное использование полосы пропускания в часы занятости и т. Д. Затем вам нужен хороший инструмент для прогнозирования, например который позаботится о сезонности в данных, поймет тенденцию данных и приблизительно спрогнозирует, что произойдет, если вы увеличите нагрузку. Простой график и линейная кривая с использованием y = mx + c также помогут вам в этом.

Answer 2

Раскрытие информации в первую очередь: я работаю в Quest Software , компании, которая занимается управлением производительностью и планированием емкости.

Существует множество продуктов для удовлетворения этих потребностей. Quest делает несколько таких, как Spotlight для SQL Server, Spotlight для IIS, Capacity Manager для SQL Server и так далее. Нет единой формулы или практического правила, потому что каждый компонент в системе по-разному реагирует на загрузку, а каждая вещь, которую вы храните, масштабируется по-разному.

Например, если вы храните данные о продажах в хранилище данных, ваши данные о продажах будут расти довольно линейно. Это простая формула:

(Открыто дней) * (Количество транзакций в день) * (Количество элементов в транзакции)

Когда вы впервые открываете свой магазин, количество транзакций в день довольно низкое, но по мере распространения слухов о вашем бизнесе количество транзакций в день растет. Если вы начнете нести больше предметов (например, Amazon перейдет от книг ко всему), то ваши Предметы за транзакцию также могут возрасти - но не обязательно. Со временем, по мере роста ваших потребностей в отчетности, вы будете внедрять сводные таблицы, включающие данные о ваших клиентах, демографии и т. Д., И это также изменит объем хранимых вами данных.

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

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

В результате каждый продукт планирования мощностей имеет свои собственные наборы формул. Например, Capacity Manager имеет примерно полдюжины различных формул просто для прогнозирования роста диска, и это даже не говорит о потребностях процессора или памяти. В большом магазине вы обнаружите, что разные формулы работают лучше для разных типов данных. Как правило, я обнаружил, что эффективнее покупать готовый продукт со всеми этими формулами, а не заново изобретать колесо, чтобы стать экспертом в прогнозных формулах. (Я знаю, я знаю, вы ожидаете, что я скажу это, потому что я работаю на поставщика, но я купил Capacity Manager в качестве администратора базы данных, прежде чем я пришел на работу в Quest, хех.)

Answer 3

Невольно я бы указал на Закон данных Паркинсона .

Однако для каждой таблицы в базе данных я пытаюсь получить представление о среднем размере записи (особенно при работе с полями переменной длины, например, varchars), а затем умножить ее на количество записей, которые вы ожидаете добавить за год , Затем я складываю их все вместе, округляя до наиболее значимой цифры и удваивая результат. Это оставляет много места для накладных расходов и роста.

 round_up_to_one_sig_digit(sum(average_table_row_size 
                             * num_rows_in_one_year)) * 2

Подобный подход работает с пропускной способностью сети, но вы столкнетесь с некоторыми особенностями людей и сетей. Все они не входят в систему с средними интервалами (поэтому вы получаете пики в течение дня / вечера и в долинах рано утром. Вы также не хотите превышать 80% пропускной способности вашей сети или производительности, просто простые резервуары с коллизиями и т. Д. .)