|
14.01.2021, 12:00 | #1 |
Участник
|
Прежде всего, согласен с Vadik, требование опрашивать 6M записей с частотой 1 раз в минуту - это какой-то перебор.
Но скорее всего, заказчик хотел иметь возможность опрашивать часто и опрашивать повторно некоторые разрезы (по группам, по условиям платежей, по наличию скидочной карточки и т.п.) поэтому простим такую формулировку. Критика предыдущих предложений 1. Change Tracking - хорош. Но слишком привязывает в MS SQL. В наше непростое время Great Again вендор-lock - это серьезный недостаток 2. ModifiedDateTime, RecID и прочие неубывающие последовательности - в топку, поскольку именно этот статус позволяет узнать что изменилось во всем справочнике, но не позволяет запросить измененные только в некоторых записях, и вынуждает делаеть полные запросы по всем 6M записей (а время еще и требует филигранной синхронизации времени на разных аосах/клиентах) 3. перехватывать событие/триггера изменений и записывать логи - чревато DDOS системы на расчетных полях типа себестоимости в складских проводках, алгоритм долбит обновлениями до посинения. (особенно категорически не надо использовать SysDatabaseLog) Что есть в стандартной Аксапте? 4. в аксапте уже есть поле recVersion. Ядро Аксапты использует это поле в рамках механизма оптимистической конкуренции в формах для того, чтобы узнать изменилась ли запись в других Аксаптах. Это то, что нам нужно! подход с recVersion придумал не майкрософт, но почитать об этом подходе можно здесь https://docs.microsoft.com/ru-ru/sql...n-transact-sql Кратко как поле RecVersion работает в аксапте: 1. RecVersion = 0 при создани записи 2. RecVersion = random(int) при любом обновлении записи (повторю: это делает ядро Аксапты, программировать это не надо) Инвариант: С огромной вероятностью recVersion после обновления будет отличаться от recVersion до обновления (ах это "почти"... длинные рассуждения о почти уникальных GUID и о инженерном подходе "на практике работоспособно") Что предлагается 5. 5.1. у вас есть справочник, состоящий из нескольких связанных таблиц (tab1, tab2 ... tabN) 5.2. у каждого справочника аксапта обслуживает служебное поле recVersion 5.3. Создайте shadow таблицу для вашего справочника tabShadow, в которой храните: 5.3.1. refRecVersion1, ... refRecVersionN - recVersion таблиц, которые вы выгрузили во внешнюю систему 5.3.2. [опционально] сериализованные значений полей, которые вы выгружаете. Важно, чтобы: 5.3.2.1. сериализованные значения можно было удобно сравнивать на равенство (изменились ли?) 5.3.2.2. сериализовать можно в аксаптовский container - тогда не надо будет программировать парсинг. Но конейнеры в MS SQL хранятся в (Memo)-полях. Со всеми вытекающими для производительности 5.3.3. FK к вашему справочнику, которые позволят однозначно связать shadow-запись и запись в справочнике (связь 0,1..0,1) 5.4. при каждой выгрузке обновляйте shadow-таблицу 5.5. shadow таблица позволит вам четко определить запросами 4 состояния: 5.5.1. есть запись в tab, нет записи в shadow - запись в справочнике создана, ни разу не выгружалась 5.5.2. есть запись в tab, есть запись в shadow, recVersion не совпадают - запись в справочнике изменилась, надо выгрузить 5.5.3. есть запись в tab, есть запись в shadow, recVersion совпадают - запись в справочнике не изменалась 5.5.4. ест записи в tab, есть запись в shadow - запись удалена, надо дать команду на удаление внешней системе 5.6. c shadow таблицей вы можете накладывать любые фильтры на справочник и получать измененные записи только среди отфильтрованных 5.7. shadow таблица не будет нагружать вашу систему паразитной нагрузкой в insert/update/delete и логах. будет работать только по запросу там еще куча соображений. но пока хватит. Последний раз редактировалось mazzy; 14.01.2021 в 12:07. |
|
|
За это сообщение автора поблагодарили: sukhanchik (10), vmoskalenko (4). |
14.01.2021, 13:00 | #2 |
Боец
|
Цитата:
Сообщение от mazzy
Прежде всего, согласен с Vadik, требование опрашивать 6M записей с частотой 1 раз в минуту - это какой-то перебор.
Но скорее всего, заказчик хотел иметь возможность опрашивать часто и опрашивать повторно некоторые разрезы (по группам, по условиям платежей, по наличию скидочной карточки и т.п.) поэтому простим такую формулировку. Критика предыдущих предложений 1. Change Tracking - хорош. Но слишком привязывает в MS SQL. В наше непростое время Great Again вендор-lock - это серьезный недостаток 2. ModifiedDateTime, RecID и прочие неубывающие последовательности - в топку, поскольку именно этот статус позволяет узнать что изменилось во всем справочнике, но не позволяет запросить измененные только в некоторых записях, и вынуждает делаеть полные запросы по всем 6M записей (а время еще и требует филигранной синхронизации времени на разных аосах/клиентах) 3. перехватывать событие/триггера изменений и записывать логи - чревато DDOS системы на расчетных полях типа себестоимости в складских проводках, алгоритм долбит обновлениями до посинения. (особенно категорически не надо использовать SysDatabaseLog) Что есть в стандартной Аксапте? 4. в аксапте уже есть поле recVersion. Ядро Аксапты использует это поле в рамках механизма оптимистической конкуренции в формах для того, чтобы узнать изменилась ли запись в других Аксаптах. Это то, что нам нужно! подход с recVersion придумал не майкрософт, но почитать об этом подходе можно здесь https://docs.microsoft.com/ru-ru/sql...n-transact-sql Кратко как поле RecVersion работает в аксапте: 1. RecVersion = 0 при создани записи 2. RecVersion = random(int) при любом обновлении записи (повторю: это делает ядро Аксапты, программировать это не надо) Инвариант: С огромной вероятностью recVersion после обновления будет отличаться от recVersion до обновления (ах это "почти"... длинные рассуждения о почти уникальных GUID и о инженерном подходе "на практике работоспособно") Что предлагается 5. 5.1. у вас есть справочник, состоящий из нескольких связанных таблиц (tab1, tab2 ... tabN) 5.2. у каждого справочника аксапта обслуживает служебное поле recVersion 5.3. Создайте shadow таблицу для вашего справочника tabShadow, в которой храните: 5.3.1. refRecVersion1, ... refRecVersionN - recVersion таблиц, которые вы выгрузили во внешнюю систему 5.3.2. [опционально] сериализованные значений полей, которые вы выгружаете. Важно, чтобы: 5.3.2.1. сериализованные значения можно было удобно сравнивать на равенство (изменились ли?) 5.3.2.2. сериализовать можно в аксаптовский container - тогда не надо будет программировать парсинг. Но конейнеры в MS SQL хранятся в (Memo)-полях. Со всеми вытекающими для производительности 5.3.3. FK к вашему справочнику, которые позволят однозначно связать shadow-запись и запись в справочнике (связь 0,1..0,1) 5.4. при каждой выгрузке обновляйте shadow-таблицу 5.5. shadow таблица позволит вам четко определить запросами 4 состояния: 5.5.1. есть запись в tab, нет записи в shadow - запись в справочнике создана, ни разу не выгружалась 5.5.2. есть запись в tab, есть запись в shadow, recVersion не совпадают - запись в справочнике изменилась, надо выгрузить 5.5.3. есть запись в tab, есть запись в shadow, recVersion совпадают - запись в справочнике не изменалась 5.5.4. ест записи в tab, есть запись в shadow - запись удалена, надо дать команду на удаление внешней системе 5.6. c shadow таблицей вы можете накладывать любые фильтры на справочник и получать измененные записи только среди отфильтрованных 5.7. shadow таблица не будет нагружать вашу систему паразитной нагрузкой в insert/update/delete и логах. будет работать только по запросу там еще куча соображений. но пока хватит. |
|
14.01.2021, 13:07 | #3 |
Участник
|
Цитата:
поэтому я уже написал: Цитата:
5.3.2. [опционально] сериализованные значений полей, которые вы выгружаете.
но тут снова возникает "выбор инженера": упростить хранилище за счет того, что будут передаваться некоторое количество избыточных команд, или не передавать ничего избыточного собственно эту часть я и вырезал из своих рассуждений: допустить повторную передачу данных или кодить точные алгоритмы... Цитата:
но это если кодить. Последний раз редактировалось mazzy; 14.01.2021 в 13:11. |
|
14.01.2021, 13:07 | #4 |
Участник
|
SysDatabaseLog - и есть тот самый shadow. И понятно, что нельзя логировать таблицы типа проводок. Речь же идет о справочнике. А тут сам бог велел логировать, чтобы потом разбираться: кто ввел неправильные данные.
И RecId имеется в виду для таблицы SysDatabaseLog. И никаких 6 миллионов записей не надо считывать каждый раз. В примере я показал, что 26 тысяч запросов к SysDatabaseLog очень быстро работают для выборки нужных данных из 74 миллионов записей в SysDatabaseLog. А у автора вообще достаточно написать 1 запрос к таблице к SysDatabaseLog Я специально показал такой неоптимизированный пример с 26 тысячами запросов, чтобы было видно, что таблица SysDatabaseLog быстрая.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
14.01.2021, 13:17 | #5 |
Участник
|
Но вообще-то я согласен, что именно для этих целей использовать SysDatabaseLog неудобно по той причине, что там неудобно ловить момент изменения именно нужного поля. Хотя вроде мой джоб работает, но как-то сравнивать между собой два контейнера некрасиво смотрится. Неклассически что-ли.
Но все-таки это работает, и довольно быстро.
__________________
Мои утилиты для Аксапты версий 3.0-2012: http://aceofdatabase.blogspot.com/ |
|
14.01.2021, 13:17 | #6 |
Участник
|
нет. в SysDatabaseLog добавляются записи при каждом чихе.
в shadow таблица добавляется максимум 1 запись для каждой записи справочника. Цитата:
но видели мы на практике эти справочники... и что туда пихают. особенно, если в справочнике появляется "выгрузка в другую систему" Цитата:
чтобы выгружать - нет. никто ж не запрещает и shadow сделать, и в SysDatabaseLog включить. речь идет о том, что не надо использовать SysDatabaseLog для задач где нужно только "последнее" состояние. Цитата:
Сообщение от Ace of Database
И RecId имеется в виду для таблицы SysDatabaseLog. И никаких 6 миллионов записей не надо считывать каждый раз. В примере я показал, что 26 тысяч запросов к SysDatabaseLog очень быстро работают для выборки нужных данных из 74 миллионов записей в SysDatabaseLog.
А у автора вообще достаточно написать 1 запрос к таблице к SysDatabaseLog Я специально показал такой неоптимизированный пример с 26 тысячами запросов, чтобы было видно, что таблица SysDatabaseLog быстрая. |
|
Теги |
aif, ax2012, change tracking, интеграция, как правильно |
|
|