Прогноз роста базы данных и выбор топологии системы - DAX: Администрирование

**sergeypp** · 05.12.2006, 16:49

На текущий момент у нас 40 магазинов.. Размер базы 40 Гиг.. В базе данные за 2 года.
Неогбходимо примерно расчитать насколько увеличится размер базы данных при увеличении магазинов до 500 штук..
К одному магазину относятся
1 Склад
3 Ячейки
15 Сотрудников
1 ЦФО
1 Касса
Прирост базы будет за счет
Продаж
Уценки
Складских проводок
Перенос товара со склада на склад
Инвентаризация
Забраковка
Закрытие склада

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

И как это все просчитать.. прирост базы за 1 месяц при таком кол-ве магазинов..
Можно воспользоваться след методологией
Определить основные таблицы.. расчитать сколько записей в них относятся к отдельному магазину за период в 1 месяц.. исходя из этого расчитать прирост для 500 магазинов

Также есть вариант 2
Посмотреть на сколько увеличилась база за 1 месяц.. поделить на 40 (магазинов) и узнать прирост базы для одного магазина..

Так же поднимается вопрос об архитектуре...
Какая будет топология.. звезда или снежинка
При топологии звезда.. будет 1 база и все будут работать в ней (я уже слышу голоса раздраженных пользователей, жалующихся на скорость работы)
при топологии снежинка в кустах тоже будут базы, которые должны будут каким то образом консолидироваться в общей базе...

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

Короче .. все мутно и непонятно
У кого есть какие соображения поделитесь ...

**mazzy** · 06.12.2006, 02:09

Цитата:

Сообщение от spp16rus

На текущий момент у нас 40 магазинов.. Размер базы 40 Гиг.. В базе данные за 2 года.
Неогбходимо примерно расчитать насколько увеличится размер базы данных при увеличении магазинов до 500 штук..

...

И как это все просчитать.. прирост базы за 1 месяц при таком кол-ве магазинов..
Можно воспользоваться след методологией
Определить основные таблицы.. расчитать сколько записей в них относятся к отдельному магазину за период в 1 месяц.. исходя из этого расчитать прирост для 500 магазинов

Также есть вариант 2
Посмотреть на сколько увеличилась база за 1 месяц.. поделить на 40 (магазинов) и узнать прирост базы для одного магазина..

Для начала стоит посмотреть здесь http://axapta.mazzy.ru/lib/dbgrowthsolution/
Мы, вроде туда уже смотрели.

Думаю, что и первый и второй вариант примерно одинаковы по сути.
А второй выполнить быстрее и проще.

Только смотреть не на прирост базы, а на прирост таблиц.
Для начала посмотреть какие таблицы являются самыми прожорливыми
(в QA выполнить команду dbcc contig with tableresults)
Сравнить с бэкапом месячной давности.
Вычеркнуть таблицы-логи.

Поделить на 40 магазинов (получится усредненный результат).
Умножить на 500.

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

Вопрос, конечно не отпадет, но планируемая скорость подключения новых магазинов наверняка уменьшится. И вы успеете нормально запланировать апгрейд оборудования, без криков "это должно быть уже вчера".

gl00mie_imported · 07.12.2006, 11:30

Цитата:

Сообщение от mazzy

Думаю, что и первый и второй вариант примерно одинаковы по сути. А второй выполнить быстрее и проще. Только смотреть не на прирост базы, а на прирост таблиц.
Для начала посмотреть какие таблицы являются самыми прожорливыми
(в QA выполнить команду dbcc contig with tableresults) Сравнить с бэкапом месячной давности. Вычеркнуть таблицы-логи.

dbcc showcontig with tableresults.
На каком-то буржуйском сайте нашел в свое время скрипт для определения размеров таблиц. Вот его немного доработанная версия (размеры выводятся в kb, отсортированные по убыванию):

Код:

set nocount on
/*
DATABASE TABLE SPY SCRIPT
 Micheal Soelter
 1/24/03
DESCRIPTION
 returns table size information
SORTING USAGE
 @sort bit values
 0 = alphabetically by table name
 1 = sorted by total space used by table
*/
declare @cmdstr varchar(100)
declare @sort bit
select @sort = 1 /* edit this value for sorting options */
/* DO NOT EDIT ANY CODE BELOW THIS LINE */
--create temporary table
if object_id('tempdb..#temptable') is not null drop table #temptable
create table #temptable
 (  table_name varchar(100),
	row_count int,
	table_size_str char(15),
	data_space_used_str char(15),
	idx_space_used_str char(15),
	unused_space_str char(15),
	table_size int,
	data_space_used int,
	idx_space_used int,
	unused_space int
 )
--create stored procedure string
select @cmdstr = 'sp_msforeachtable ''sp_spaceused "?"'''
--populate tempoary table
insert into #temptable (table_name, row_count, table_size_str, data_space_used_str,
						idx_space_used_str, unused_space_str)
	exec(@cmdstr)
--determine sorting method
update #temptable
	set table_size	  = cast(replace(table_size_str,	  ' KB', '') as int),
		data_space_used = cast(replace(data_space_used_str, ' KB', '') as int),
		idx_space_used  = cast(replace(idx_space_used_str,  ' KB', '') as int),
		unused_space	= cast(replace(unused_space_str,	' KB', '') as int)
if @sort = 0
	begin
		--retrieve table data and sort alphabetically
		select table_name, row_count, table_size, data_space_used, idx_space_used, unused_space
		from #temptable order by table_name
	end
else
	begin
		--retrieve table data and sort by the size of the table
		select table_name, row_count, table_size, data_space_used, idx_space_used, unused_space
		from #temptable order by table_size desc
	end
--delete temporay table
drop table #temptable

**sergeypp** · 06.12.2006, 10:17

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

**sergeypp** · 06.12.2006, 15:13

И еще один вопрос.. Насколько я знаю существует возможность объединения мощностей нескольких серверов для выполнения одной задачи.. Где можно про это почитать?

**mazzy** · 06.12.2006, 15:24

Цитата:

Сообщение от spp16rus

И еще один вопрос.. Насколько я знаю существует возможность объединения мощностей нескольких серверов для выполнения одной задачи.. Где можно про это почитать?

Кластеризация.

Если относительно Аксапты, то в каталоге с документацией
AX-300-TIP-028-v01.00-ENUS.doc - Installing Axapta Object server on a cluster fail-safe server

А также:
Axapta_ AxaptaObjectServer_WhitePaper.doc
AX-300-TIP-058-v01.00-ENUS.doc

Можно поискать по форумам.
Но тут одно но - чтобы несколько серверов выполняло ОДНУ задачу, программное обеспечение должно быть написано специально с учетом такой возможности. Аксапта не позволяет распределить ОДНУ задачу.

Аксапта и SQL позволяют распределить НЕСКОЛЬКО однородных задач на кластер серверов таким образом, чтобы эти однородные задачи не стояли в очереди на одном сервере, а выполнялись на разных серверах. Но на каждая конкретная задача будет выполняться на одном сервере.

**sergeypp** · 11.12.2006, 17:26

Посчитал прирост для каждой таблицы отдельно.. Исключил те, которые уменьшились.. Исключил таблицы логи. Результат поделил на разницу дней между бакапами.. и на 40 (кол-во магазинов)
получилось 2.3 мега генерит условно 1 магазин за 1 день (сюда же входит объем работы распределительных центров).. получается, что 500 магазинов за 1 месяц увеличат базу примерно на 33.7 Гига.. КОШМАР!!!!!!!!!

А будут какие нить комментарии по поводу выбора топологии.. Ну чего все какие унылые? )

**Vadik** · 12.12.2006, 09:26

Цитата:

Сообщение от spp16rus

получилось 2.3 мега генерит условно 1 магазин за 1 день (сюда же входит объем работы распределительных центров)..

А что, не так много.. Из База данных Аксапты быстро растет. Что делать? уже все сделано?

Цитата:

получается, что 500 магазинов за 1 месяц увеличат базу примерно на 33.7 Гига.. КОШМАР!!!!!!!!!

Дык.. еще не VLDB, конечно, но 500 магазинов все же. Задача увеличивается по масштабам более чем в 10 раз, но решаться должна на том же оборудовании? Так не получится, и убедить в этом руководство в Ваших же интересах (чтобы не стать крайним)
Кстати, с версией СУБД без изменений - MSSQL 2000?

**sergeypp** · 12.12.2006, 11:26

Цитата:

Сообщение от Vadik

А что, не так много.. Из База данных Аксапты быстро растет. Что делать? уже все сделано?

Да конечно, не без помощи mazzy )

Цитата:

Сообщение от Vadik

Дык.. еще не VLDB, конечно, но 500 магазинов все же. Задача увеличивается по масштабам более чем в 10 раз, но решаться должна на том же оборудовании? Так не получится, и убедить в этом руководство в Ваших же интересах (чтобы не стать крайним)

Это понятно.. оборудование должно докупаться

Цитата:

Сообщение от Vadik

Кстати, с версией СУБД без изменений - MSSQL 2000?

Пока, да.. Тестируется переход на 2005..