Проблема производительности при использовании виртуальных компаний.

[Recoilme]

Цитата:

Сообщение от 7Up

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

Попробуйте вынести во внешние программы особо жрущие recid алгоритмы. Мы например перенесли среднедневные остатки и ещё часть "прожорливых" алгоритмов из аксапты и оттянули время "Ч" на пару лет. Если припечет - Сводное планирование полностью из системы вынесем, ещё съэкономим годик ))

[7Up]

до 400 тыс строк заказов в день. Все остальное пропорциоанально.
ЛОги на все основные таблички.
У нас recId жрут не только свои таблички, а в основном стандартные аксаптовские.

2 mit. Сутки - имеется в виду время работы процедуры, а не периодичность.

2 recoilme. Можно все вынести. Зачем тогда аксапта.

[mit]

Цитата:

Сообщение от 7Up

до 400 тыс строк заказов в день. Все остальное пропорциоанально.

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

[7Up]

Цитата:

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

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

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

[mit]

Цитата:

Сообщение от 7Up

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

а какая история? сколько лет? какая версия?

[Recoilme]

Цитата:

Сообщение от 7Up

до 400 тыс строк заказов в день. Все остальное пропорциоанально.
ЛОги на все основные таблички.
У нас recId жрут не только свои таблички, а в основном стандартные аксаптовские.

2 mit. Сутки - имеется в виду время работы процедуры, а не периодичность.

2 recoilme. Можно все вынести. Зачем тогда аксапта.

Слишком много. Или что-то путаете. Или Вы провакатор-конкурент, зашли поиздеваться.

Расскажите в каой отрасли пол лимона в день строк продаж?? М.б. Вы ... строки чеков запихать в старушку хотите????? Нельзя впихать невпихуемое!

[7Up]

Порядка 1000 клиентво, ассортимент до нескольких тыс. единиц. Ежедневные отгрузки до 200 единиц товара в среднем. И не только отгрузки, а много еще чего.

[Recoilme]

Цитата:

Сообщение от 7Up

Порядка 1000 клиентво, ассортимент до нескольких тыс. единиц. Ежедневные отгрузки до 200 единиц товара в среднем. И не только отгрузки, а много еще чего.

Нельзя ли из обозревателя таблицы выполнить запрос и сообщить его результаты??

SELECT count(recid) FROM CustInvoiceTrans where CustInvoiceTrans.invoicedate==20\07\2006

[7Up]

Цитата:

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

Нельзя ли из обозревателя таблицы выполнить запрос и сообщить его результаты??

SELECT count(recid) FROM CustInvoiceTrans where CustInvoiceTrans.invoicedate==20\07\2006

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

[Recoilme]

Цитата:

Сообщение от 7Up

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

Честно говоря я в этом и не сомневался.
Конкретно по вопросу: использовать компании для увеличения времени жизни recid - крайне нерациональная трата ресурсов.

[Vadik]

Цитата:

Сообщение от 7Up

до 400 тыс строк заказов в день. Все остальное пропорциоанально.
ЛОги на все основные таблички

так у Вас счетчик RecId переполнится в любом случае очень скоро - они из общего пула берутся, никакая "проверка кодов записей" не поможет
- вариант с виртуальными компаниями конечно интересный, хотя и небезгеморройный с точки зрения настройки и переноса данных
- посмотрите на стр. 524 Databases Advanced - там описана возможность генерировать уникальные RecId в пределах таблицы и компании, а не компании. Вариант тоже не без проблем, первая же "проверка кодов записей" эту идиллию порушит, опять же надо что-то делать с существующими данными (ссылки по RecId)

P.S. как представил себе SysDatabaseLog по строкам заказов, которых до 400 тысяч в день - жуть
P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

[Recoilme]

Цитата:

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

P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

Если буквально и в двух словах : "Пипец производительности"

Конечно я говорю о разнице - в использовании поля DataAreaId (его нет, включен ключ nodataareaid) и когда оно есть и используется во всех индексах напропалую, а не о том случае - писать туда "DAT" или хрень какую ещё

[7Up]

Цитата:

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

Если буквально и в двух словах : "Пипец производительности"

Конечно я говорю о разнице - в использовании поля DataAreaId (его нет, включен ключ nodataareaid) и когда оно есть и используется во всех индексах напропалую, а не о том случае - писать туда "DAT" или хрень какую ещё

select * from table1 where table1.dataareaId == "dat"
join * from table2 where table2.dataareaId == "vir"

что помешает БД использовать правильные индексы?

[Recoilme]

Цитата:

Сообщение от 7Up

select * from table1 where table1.dataareaId == "dat"
join * from table2 where table2.dataareaId == "vir"

что помешает БД использовать правильные индексы?

Ещё раз: ОТКЛЮЧЕНИЕ DATAAREAID ДАСТ ОФИГЕННЫЙ ВЫИГРЫШ ПО ПРОИЗВОДИТЕЛЬНОСТИ
Ключевое слово: NODATAAREAID

Не будет этого поля там "dataareaId ". Совсем не будет.

[7Up]

Цитата:

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

Ещё раз: ОТКЛЮЧЕНИЕ DATAAREAID ДАСТ ОФИГЕННЫЙ ВЫИГРЫШ ПО ПРОИЗВОДИТЕЛЬНОСТИ
Ключевое слово: NODATAAREAID

Не будет этого поля там "dataareaId ". Совсем не будет.

NODATAAREAID - имеется в виду SaveDataPerCompany = No?

[Vadik]

Ничего не имею против NODATAAREAID, однако хотел бы предложить вернуться к обсуждению проблемы генерации RecId в системе с 400000 строками заказов в день. Правда, проблема оказалась виртуальной , но осталась интересной (по крайней мере, до выхода четверки), и NODATAAREAID ее вроде как не решает (насколько я понимаю). Бенчмаркинг с т.зр. влияния NODATAAREAID разумеется проведу - на каких документах, из скольких проводок и на каких объемах? Ну и Ваши результаты само собой интересно было бы увидеть, чтобы знать, к чему стремиться

P.S. И, раз уж пошла такая пьянка, предпочел бы вместо NODATAAREAID отключить SaveDataPerCompany на "больших" таблицах в AOT. Надежнее как-то

[mit]

Цитата:

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

P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

э неет! с этим оч. осторожно! с точки зрения производительности то конечно, с переносом там тоже все автоматом происходит, а вот нарушение целостности это получить оч. легко, так как в качестве ссылок нередки случаи использования recId как уникального идентификатора. думаю, что в этом случае легко просто "приплыть" к необъясниым сбоям

[7Up]

Цитата:

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

так у Вас счетчик RecId переполнится в любом случае очень скоро - они из общего пула берутся, никакая "проверка кодов записей" не поможет
- вариант с виртуальными компаниями конечно интересный, хотя и небезгеморройный с точки зрения настройки и переноса данных
- посмотрите на стр. 524 Databases Advanced - там описана возможность генерировать уникальные RecId в пределах таблицы и компании, а не компании. Вариант тоже не без проблем, первая же "проверка кодов записей" эту идиллию порушит, опять же надо что-то делать с существующими данными (ссылки по RecId)

P.S. как представил себе SysDatabaseLog по строкам заказов, которых до 400 тысяч в день - жуть
P.P.S. с т.зр. производительности - какая разница системе, что в поле DataAreaId пишется?

Не понял про стр. 524 Databases Advanced. Можно уточнить что за книжка имеется в виду. Если так можно - эффект будет тот же, только dataareaid меняться не будет.
Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам.

[Recoilme]

Цитата:

Сообщение от 7Up

Про dataareaid - оно первое во всех индексах. Специалистами высказывается опасение, что разные dataAreaId приведут к тормозам.

Вот и слушайте Ваших специалистов, а не по форумам шляйтесь))

[Михаил Андреев]

Цитата:

Сообщение от 7Up

до 400 тыс строк заказов в день. Все остальное пропорциоанально.
ЛОги на все основные таблички.

Любопытно, откуда возьмутся эти поллимона строк? Кто их набьёт? Если люди, то их не менее 1-2 тыс. должно быть. И зачем логи на все основные таблицы?
Напоминает анекдот про бензопилу и суровых сибирских мужиков.
Либо дерево не то, либо инструмент не тот.
При таком объёме дублирование RecId - мелочь по сравнению с кучей других проблем. Как вы склад закрывать собираетесь? А сводное планирование как будет работать? И как одновременно тысяча человек будут работать с одними и теми же таблицами, взаимными блокировками и т.п.?
Чисто гипотетически:
1. Создание виртуальных компаний проблему RecId вряд ли решит. Да и ни к чему её таким образом решать: реально важно отсутствие дублирования RecId в одной компании одной таблицы.
2. Убирание dataareaid тоже вряд ли даст эффект в проблеме RecId. Не думаю, что эффект по производительности будет очень существенен: в большинстве таблиц индексы строятся с его учётом, а базы данных очень хорошо умеют сами оптимизировать запросы. Поэтому, на мой взгляд, гораздо эффективнее построить администратора базы данных, чем убрать dataareaid.