Распределение вычислительной нагрузки при импорте объектов - NAV: Администрирование

Pete V · 25.10.2005, 10:43

Ситуация: есть выгрузки из 1С(текстовый формат), полученные от торговых точек - отчеты продаж с детализацией до чека, т.к. эти данные потом используются при построении OLAP кубов. Таких файлов выгрузок много - около 100. Их надо "всосать" в Нав за максимально короткий срок. Предполагается это делать через датапорты используя несколько клиентских сессий, выполняющих задания по шедулеру.
Вопрос: чьи вычислительные мощности и как будут использоваться в этом процессе (серверные или клиентских машин) поглощения данных и как этот процесс можно оптимизировать?
Никакой информации по этому вопросу найти не удалось... может кто поделится соображениями/опытом/данными?

Шрэк · 25.10.2005, 11:05

Цитата:

Сообщение от Pete V

Вопрос: чьи вычислительные мощности и как будут использоваться в этом процессе (серверные или клиентских машин) поглощения данных и как этот процесс можно оптимизировать?
Никакой информации по этому вопросу найти не удалось... может кто поделится соображениями/опытом/данными?

<{POST_SNAPBACK}>

Информация такая есть в книге по Девелопменту, главы:

8.1 LOW IMPACT ON THE APPLICATION
8.2 LOW IMPACT ON THE SERVER
8.3 LOW IMPACT ON NETWORK TRAFFIC
8.4 LOW IMPACT ON DATABASE SPACE

В главе 8.2 описано, что происходит на сервере, когда, как из-за чего и даются общие рекомендации, как снизить нагрузку на сервер. В частности, например, использовать временные таблицы.

Scorpie · 31.10.2005, 13:38

Цитата:

Сообщение от Pete V

Ситуация: есть выгрузки из 1С(текстовый формат), полученные от торговых точек - отчеты продаж с детализацией до чека, т.к. эти данные потом используются при построении OLAP кубов. Таких файлов выгрузок много - около 100. Их надо "всосать" в Нав за максимально короткий срок.

<{POST_SNAPBACK}>

По-моему очень плохая затея.
А зачем вам такие детальные данные в именно Навижне?

**Yoil** · 31.10.2005, 14:15

Присоединяюсь к Scorpie.
Нафига так базу загромождать?
В крайнем случае создайте для чеков отдельную базу и там их храните (и пусть маркетинг крутит в этой базе свои кубы хоть до посинения). Сделайте в основной базе вьюшку, которая будет показывать какие-то общие показатели по чекам (скажем, сгруппированные по времени, товарам, скидкам и т.п.) и в основной базе используйте уже эту, "сжатую" информацию.

**GalaM** · 31.10.2005, 16:55

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

**Dzemon** · 31.10.2005, 17:19

Это стандартная ситуация для розничной сети ;-)
Менеджеры ЦО хотят знать ВСЕ и управлять ВСЕМ, а для этого им нужна аналитика по чекам. Вместо того чтобы тянуть в ЦО готовую аналитику, они требуют полный набор информации.

Решить проблему можно так: импортировать данные не навижиновским интерфейсом, а другой программой, причем во временную таблицу на SQL, а затем хранимой процедурой доводить ее до "ума", ну или навижиновской процедурой (тогда не во временную таблицу, но с мин. количеством ключей).

Scorpie · 31.10.2005, 17:39

Цитата:

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

Это стандартная ситуация для розничной сети ;-)
Менеджеры ЦО хотят знать ВСЕ и управлять ВСЕМ, а для этого им нужна аналитика по чекам. Вместо того чтобы тянуть в ЦО готовую аналитику, они требуют полный набор информации.

Лучше убить неделю-две на то, чтобы объяснить им пагубность этой затеи чем потом неделями разгребать последствия таких шагов когда база с легкостью перешагнёт 100Гб...

Цитата:

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

Решить проблему можно так: импортировать данные не навижиновским интерфейсом, а другой программой, причем во временную таблицу на SQL, а затем хранимой процедурой доводить ее до "ума", ну или навижиновской процедурой (тогда не во временную таблицу, но с мин. количеством ключей).

<{POST_SNAPBACK}>

Позволю себе не согласится.
Во-первых такая детализация в Навижн попросту не нужна и для такой системы как Нав слишком затратна по вкачиванию в неё стандартными путями
Во-вторых т.к. средства отчётности в Навижне не гибкие - всё ведёт к тому что для анализа будут пользоваться данные только из кубов.
А в такой ситуации нет смысла вообще в каком либо хранении детализации в навижне, - только как того требует аналитика...
Остальное в отдельные базы со своими кубами. Что кстати будет значительно проще если используется тот же AS - никаких проблем с наименованием полей(не любит сервер например запятые в названии таблиц), никаких проблем с OptionFields - можно сразу хранить текстовое значение а не иметь в Shared Dimensions "0,1,2,3,4" ...
Вообщем сплошные плюсы

**Dzemon** · 31.10.2005, 18:39

Цитата:

Позволю себе не согласится.
Во-первых такая детализация в Навижн попросту не нужна и для такой системы как Нав слишком затратна по вкачиванию в неё стандартными путями
Во-вторых т.к. средства отчётности в Навижне не гибкие - всё ведёт к тому что для анализа будут пользоваться данные только из кубов.
А в такой ситуации нет смысла вообще в каком либо хранении детализации в навижне, - только как того требует аналитика...
Остальное в отдельные базы со своими кубами. Что кстати будет значительно проще если используется тот же AS - никаких проблем с наименованием полей(не любит сервер например запятые в названии таблиц), никаких проблем с OptionFields - можно сразу хранить текстовое значение а не иметь в Shared Dimensions "0,1,2,3,4" ...
Вообщем сплошные плюсы smile.gif

А чего тут не соглашаться? Все тоже самое, только это следующий шаг

Вопрос-то был как быстрей закачать.

И все возвращается к тому, что будут строиться аналитические срезы под конкретные отчеты, а количество отчетов конечно ;-)

Pete V · 01.11.2005, 15:57

Спасибо всем за проявленный к теме интерес. Вопрос является открытым и +/- различных вариантов решения будут обсуждаться и оцениваться. Буду рад, если дискуссия разовьется и позволит выявить сильные и слабые стороны обоих решений. Само собой, что при определенном уровне развития и достижении некоторого оборота, храниние информации с детализацией до чеков становится накладным, но тем не менее на том же уровне развития такая информация представляет очень высокую маркетинговую ценность (даже такой базовый показатель как средний чек говорит о многом). Таким образом отражение этой информации в учетной или управленческой системе стало отраслевым стандартом, а с такими вещами не спорят и тут руководству предъявить нечего - эта информация нужна.
Также не обсуждается необходимость построения кубов - это единственный способ обрабатывать такие объемы информации.
Соответственно, на мой взгляд, открытым для обсуждения остается вопрос: что эффективнее/разумнее/лучше/дешевле/проще в реализации - разработать механизм выгрузки в Нав такой информации и раз в год сжимать выросшую базу(вероятно ее размер будет расти на Х*10ГБ в год, где Х = 5-10), либо разработать специальную базу хранения информации о продажах и уже ее использовать для получения OLAP кубов.
Тех, у кого есть мнение по этому вопросу, я с удовольствием выслушаю и надеюсь данная тема позволит найти оптимальное решение проблемы.

**Yoil** · 01.11.2005, 15:59

Pete V, у Вас есть хоть аргумент для хранения чеков в боевой базе?
Зачем вообще рассматривать этот вариант?

Pete V · 01.11.2005, 16:12

Аргументами в пользу такого решения могут являться:
1) Наличие одной, а не нескольких информационных баз, что не требует дублирования работ по выгрузке и соответствует философии обобщения информации и ее интеграции в одном хранилище, которой и руководствуются организации, ориентирующиеся на использование ERP;
2) Возможность использования этой информации для генерации ежедневных отчетов, которые могут быть полезны менеджерам среднего звена.

**Yoil** · 01.11.2005, 16:21

Ну 2) тут не при чем, 2) возможно при любом раскладе - какая разница, откуда эти отчеты получать

Насчет 1) - Навыжн таких объемов не любит. Сильно не любит. А если Навыжн что-то не любит, то его начинают не любить пользователи. В итоге все не любят айтишников.

Pete V · 01.11.2005, 16:39

Дело в том, что проект лишь разрабатывается и судя по всему, реально его внедрение начнется в то время, когда будет доступен SQL 2005, что вселяет надежду по поводу максимального размера базы, кроме того, судя по просачивающейся информации, в ближайшем будущем в Нав будет переписан механизм работы с БД, поскольку не секрет, что изначально рассчитанный на NDS, он не очень удачно работает с SQL. Так что я не думаю, что размер базы даже в 150-200ГБ будет смертельным для Нав, учитывая относительно небольшое число работающих с ним пользователей, а вот разработка дополнительной базы для целей сбора информации о продажах, на мой взгляд, может содержать риски, которые на первый взгляд не видны, но впоследствии могут привести к различного рода проблемам.
К примеру, пункт 2) действительно может быть реализован и в рамках базы, созданной для OLAP, но тогда к ней придется приворачивать механизм генерации отчетности... а там возникнут новые хотелки и снова вопрос в какой базе это делать... и зачем Нав ставили? так что у этого пути есть свои ловушки.

Pete V · 01.11.2005, 16:40

А про нелюбовь к IT-шникам... ну это просто беда и видимо это тоже отраслевой стандарт

пора давать молоко за вредность...

**Yoil** · 01.11.2005, 17:08

Нелюбовь к айтишникам появляется обычно тогда, когда айтишники идут на поводу желаний Самых Главных Начальников даже в технических вопросах, а потом у них все медленно и/или плохо работает

Например - держат детальную информацию по чекам в рабочей базе