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

[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 - крайне нерациональная трата ресурсов.

[7Up]

Цитата:

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

Честно говоря я в этом и не сомневался.
Конкретно по вопросу: использовать компании для увеличения времени жизни 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?

[db]

Цитата:

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

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

Эта картинка как отключить в конф утилите. Такой же параметр есть и в настройка аоса. Делать надо на базе, в которой только одна компания - DAT. Естественно надо отсинхронизировать базу после запуска с таким ключом. Поле DataAreaId испарится из всех таблиц и индексов

По поводу опасений использования данной возможности - по крайней мере три очень нехилые розничные сети работают несколько лет с таким ключиком. Версии 3.0 от без СП до KR1. Проблем никаких.

А насчет производительности - протестируйте сами и решите сами. Не хочется ввязываться в очредную войнушку

[Vadik]

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

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

[Recoilme]

Цитата:

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

Ничего не имею против NODATAAREAID, однако хотел бы предложить вернуться к обсуждению проблемы генерации RecId в системе с 400000 строками заказов в день.

Хорошо. Давйте вернемся ))
Допустим завтра к Вам приходят и говорят, через месяц у нас в аксапте будет до 400 000 строк заказов в день. Т.е. 2000 заказов по 200 строк.
Знаете что я посоветую? Подумать о количестве записей? 64 битный ключ на 4 аксапте? Нет! Я посоветую подумать о смене работы))

Резюме надо составлять при таких объемах, а не по форуму писать))

Засим теоретическую часть обсуждения аксапты на 400000 строк продаж предлагаю закрыть.
Желающие могут засечь время создания и разноски заказа на 200 строк, умножить на 2000 , мыслено представить блокировки,24 на 6 и прочие прелести. Людям с развитым воображением лучше поберечь здоровье и не представлять))

[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 приведут к тормозам.