|
|
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Хм... Понятно... Скажите, а на основе MQT(суммарных таблиц) Вы это не пытались организовать? Вот это было бы весьма интересно.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2007, 15:30 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey TORTВы тестировали данный подход? Если не серкНе только тестировал, но и промышленно эксплуатировал. :) Присоединяюсь. У меня это сделано на MS SQL на триггерах. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2007, 15:41 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
TORTСкажите, а на основе MQT(суммарных таблиц) Вы это не пытались организовать? Вот это было бы весьма интересно....Как я уже сказал - я не пытался проводить тесты и сравнивать различные варианты реализации. Ну а в первой половине девяностых материализованных представлений еще не было. Поэтому приходилось все делать руками. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.12.2007, 15:51 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey.....у нас один исключительный случай, когда учетных единиц было мало (порядка сотни), а конкурирующих транзакций - много (до полусотни процессов и десятки тысяч операций в час у каждого). Тут задержки на блокировках становятся посущественней. Для этого случая был другой вариант, когда заполнением этой таблицы занимался отдельный фоновый процесс. А нельзя ли поподробнее вот с этого места? Как избавились от блокировок? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2007, 15:29 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
2 DobPilot А как часто у вас движения происходят и сколько userAccount? А то, например, в BOL MS SQL2005 есть примечание для Indexed View: BOL Indexed views typically do not improve the performance of the following types of queries: -OLTP systems that have many writes. -Databases that have many updates. -Aggregations of data with a high degree of cardinality for the GROUP BY key. A high degree of cardinality means the key contains many different values. .... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.12.2007, 16:29 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
По мотивам: Bogdanov Andrey Имеем таблицу Код: plaintext 1. 2. 3. 4. Таким образом число записей не превышает количества движений, а остаток на любой день достается запросом без суммирования: Код: plaintext Я не говорю, что это единственное верное решение, но в некоторых случаях оно работает очень хорошо. На MSSQL есть решение быстрее: Имеем таблицу Код: plaintext 1. 2. 3. 4. Код: plaintext На Oracle нет top 1 (rownum применить не получится без подзапроса). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 10:28 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Alex S На MSSQL есть решение быстрее: ... Код: plaintext а если надо остатки по нескольким счетам? по одному счету то редко когда нужно ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 10:32 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
SergSuperа если надо остатки по нескольким счетам? по одному счету то редко когда нужно Код: plaintext 1. 2. Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 12:53 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
SergSuper Alex S На MSSQL есть решение быстрее: ... Код: plaintext а если надо остатки по нескольким счетам? по одному счету то редко когда нужно Универсальный вариант: Код: plaintext 1. 2. 3. 4. Чем больше счетов в списке тем дольше будет работать. Для каждого счета за одну дату должна быть одна запись об остатках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 13:11 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Alex S На MSSQL есть решение быстрее: ...Давайте не будем в эту тему тащить сравнение MSSQL и Oracle. Да к тому же с отсутствием конкретных цифр. Я не уверен, что приведенное вами решение будет быстрее, чем аналогичное Oracle'овое. dekanА нельзя ли поподробнее вот с этого места? Как избавились от блокировок? Ну так конфликт блокировок возникает только при попытке разными процессам модифицировать остаток по одной и той же учетной единице. Если модификацией остатков занимается выделенный процесс, то никакого конфликта у него с самим собой быть не может. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 14:07 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Alex S SergSuperа если надо остатки по нескольким счетам? по одному счету то редко когда нужно Код: plaintext 1. 2. Код: plaintext 1. 2. Это я всё знаю, спрашивал чтобы всем было понятно что с двумя датами проще :)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 15:17 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Bogdanov Andrey Alex S На MSSQL есть решение быстрее: ...Давайте не будем в эту тему тащить сравнение MSSQL и Oracle. Да к тому же с отсутствием конкретных цифр. Я не уверен, что приведенное вами решение будет быстрее, чем аналогичное Oracle'овое. Топикстартер как раз хотел решений для различных СУБД. Быстрее - я имел ввиду не "MSSQL быстрее Oracle", а "реализация с одной датой и top 1 на MSSQL быстрее реализации с двумя датами на MSSQL". Тесты когда-то давно проводил, в итоге остановился на озвученном решении для MSSQL. Кроме того, с одной датой операция записи проще. Если будет время - постараюсь повторить тесты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 15:19 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
SergSuper Это я всё знаю, спрашивал чтобы всем было понятно что с двумя датами проще :)) А как это проще выглядит? SergSuperпо одному счету то редко когда нужно Кстати, в OLTP не так уж и редко ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 15:25 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Alex Sа "реализация с одной датой и top 1 на MSSQL быстрее реализации с двумя датами на MSSQL". Тесты когда-то давно проводил, в итоге остановился на озвученном решении для MSSQL. Кроме того, с одной датой операция записи проще.Ну вторая дата - это избыточность данных и естественно, ее поддержка требует "накладных расходов". Но некоторые примущества две даты имеют. Например, просуммировать остатки по позициям на определенную дату (то есть любой аналитический запрос) будет попроще и, наверное, побыстрее даже в MS-SQL. Я MS-SQL-ким диалектом не владею. Как с помощью Top поизящней записать запрос нижеприведенному? Код: plaintext ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 16:10 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Alex S SergSuper Это я всё знаю, спрашивал чтобы всем было понятно что с двумя датами проще :)) А как это проще выглядит? одна дата: Код: plaintext 1. 2. Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.12.2007, 18:09 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
ИМХО, остатки нужно хранить не по временным интервалам, а по определённому количеству записей между остатками. Т.о. мы получим более предсказуемую ситуацию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2007, 13:30 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
drevИМХО, остатки нужно хранить не по временным интервалам, а по определённому количеству записей между остатками. Т.о. мы получим более предсказуемую ситуацию. продемонстрируйте, что ли... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2007, 22:38 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
SergSuper drevИМХО, остатки нужно хранить не по временным интервалам, а по определённому количеству записей между остатками. Т.о. мы получим более предсказуемую ситуацию. продемонстрируйте, что ли... Допустим, такая структура. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. Добавляем триггер на sales_details, который находит соответствующую запись в таблице summary, и либо инкрементирует counter, либо добавляет в таблицу summary новую запись (если значение поля counter достигло некоторого порога). Эта структура будет хорошо работать, если наиболее частыми являются запросы по многим товарам. Если чаще требуются остатки по конкретному товару, то вместо двух последних таблиц получаем одну: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2007, 08:44 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
SergSuper... Код: plaintext 1. Ну незнаю, в таблице остатков у меня только Id номенклатуры, плоскость остатка, дата , два оборота и остаток. Все остальное в таблице номенклатуры, и так исторически складывается, что основная выборка идет по ней. Ну там, например, не закрытые счета такой-то группы. И одна UDF-ка "остаток" в перечне полей в select. Bogdanov Andrey...Ну вторая дата - это избыточность данных и естественно, ее поддержка требует "накладных расходов". Но некоторые примущества две даты имеют. Например, просуммировать остатки по позициям на определенную дату (то есть любой аналитический запрос) будет попроще и, наверное, побыстрее даже в MS-SQL. Я MS-SQL-ким диалектом не владею. Как с помощью Top поизящней записать запрос нижеприведенному? Код: plaintext Код: plaintext При этом такой показатель как "операций в секунду" не страдает. Кстати, хотел спросить про "отложенный" расчет отдельным потоком. Я так понимаю, существует лаг между записью фактического движения и "наличием" фактического остатка по учетной единице. Каким способом обеспечивалась "непротиворечивость" данных?, к примеру если алгоритму требуется величина остатка после записи движения, для следующей операции? Или было управление из алгоритма "можно отложить"/"нельзя отложить" расчет? И еще, например, у меня в расчете есть различные проверки на выход за разные пределы остатка и т.п., в большинстве случаев они являются критерием возможности проведения операции и этим проверкам нужен остаток. Если существует пул необработанных движений, как работают такие механизмы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2007, 11:11 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Alex SКстати, хотел спросить про "отложенный" расчет отдельным потоком. Я так понимаю, существует лаг между записью фактического движения и "наличием" фактического остатка по учетной единице. Каким способом обеспечивалась "непротиворечивость" данных?, к примеру если алгоритму требуется величина остатка после записи движения, для следующей операции? Или было управление из алгоритма "можно отложить"/"нельзя отложить" расчет? И еще, например, у меня в расчете есть различные проверки на выход за разные пределы остатка и т.п., в большинстве случаев они являются критерием возможности проведения операции и этим проверкам нужен остаток. Если существует пул необработанных движений, как работают такие механизмы? Для всякой аналитики используются только "обработанные" движения - то есть работа идет с таблицей остатков. Ну а для проверок естественно надо учесть необработанные. Но тут хитрость в том, что необработанных движений крайне мало, поэтому дополнительный запрос считающий сумму необработанных движений работает быстро. То есть у нас есть два остатка - аналитический (время получения которого не зависит от количества движений) и оперативный (получение которого больше на время суммирования маленького списка неучтенных движений). Сам пул необработанных движений можно организовать по-разному. Первый способ - колонка в списке движений, принимающая значения 1 (необработано) и null (обработано) - индекс по такой колонке очень мал и поиск по нему осуществляется быстро. Второй - складывать необработанные движения в отдельную таблицу (а после обработке оттуда удалять). Мы исползовали именно этот способ - так как хотелось минимизировать воздействие "отложенного" расчета на код системы (чтобы это было этаким дополнительным функционалом, устанавливаемым/убираемым по желанию). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2007, 11:54 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Bogdanov AndreyДля всякой аналитики используются только "обработанные" движения - то есть работа идет с таблицей остатков. Ну а для проверок естественно надо учесть необработанные. Но тут хитрость в том, что необработанных движений крайне мало, поэтому дополнительный запрос считающий сумму необработанных движений работает быстро. То есть у нас есть два остатка - аналитический (время получения которого не зависит от количества движений) и оперативный (получение которого больше на время суммирования маленького списка неучтенных движений). Сам пул необработанных движений можно организовать по-разному. Первый способ - колонка в списке движений, принимающая значения 1 (необработано) и null (обработано) - индекс по такой колонке очень мал и поиск по нему осуществляется быстро. Второй - складывать необработанные движения в отдельную таблицу (а после обработке оттуда удалять). Мы исползовали именно этот способ - так как хотелось минимизировать воздействие "отложенного" расчета на код системы (чтобы это было этаким дополнительным функционалом, устанавливаемым/убираемым по желанию). Спасибо за ответы. А в целом - реальные тесты показывали значительный/заметный/(другое) прирост производительности с пулом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2007, 15:14 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
Alex S Спасибо за ответы. А в целом - реальные тесты показывали значительный/заметный/(другое) прирост производительности с пулом? Да, в описанной выше ситуации: Bogdanov Andreyучетных единиц было мало (порядка сотни), а конкурирующих транзакций - много (до полусотни процессов и десятки тысяч операций в час у каждого).количество обрабатываемых транзакций возросло в несколько раз (раза в три-семь, точнее не скажу - не помню). Вполне вероятно, что итоговая схема не была оптимальной именно для этого случая, но это было решение полученное путем минимальных модификаций уже работавшей системы. И обеспечило простую поддежрку версии совместно с остальными. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2007, 16:05 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
хочу рассказать о своем методе расчета остатков на любую дату, несмотря на то что метод очень прост никто его почемуто не предложил. сперва у нас использовалось тупое суммирование по указанную дату: Код: plaintext но когда реестр дорос до 3млн записей стало подтормаживать. способ ускорения исходит из того, что остатки чаще всего нужно достать либо на сейчас, либо на близкую к сейчас дату, тоесть случай когда будут считаться остатки на позапрошлый год довольно редкий. 1. если построен индекс по полю reestr.dat то любым способ добится того чтобы он НЕ ИСПОЛЬЗОВАЛСЯ в данном запросе, например так: Код: plaintext 2. если не хочется суммировать многие тысячи строк с начала времен то можно суммировать строки с конца! для этого в реестр для каждого склада и каждой номенклатуры добавляется одна запись, которая будет содержать остаток на сейчас со знаком минус и датой движения для которой (reestr.dat) будет к примеру 01.01.2100 года. тогда получать остатки можно запросом Код: plaintext оба метода успешной мной эксплуатируются :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2007, 16:51 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
У нас похожий метод расчета... Только хранятся две вещи... Итоговый остаток по товарам, то есть сумма по всему движению... Ну и обсчитывается все движение от нужной даты... Строк в БД примерно 150 млн... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2007, 17:44 |
|
||
|
быстрое получение остатков на дату
|
|||
|---|---|---|---|
|
#18+
a7exander 1. если построен индекс по полю reestr.dat то любым способ добится того чтобы он НЕ ИСПОЛЬЗОВАЛСЯ в данном запросе, например так: У Oracle оптимизатор, собака, умный, и индекс в таком случае и сам не всегда использует. a7exanderдля этого в реестр для каждого склада и каждой номенклатуры добавляется одна запись, которая будет содержать остаток на сейчас со знаком минус Ну если уж хранить остаток, то можно тогда не только на сейчас хранить, но и на промежуточные дату. Все равно на проблему с блокировками уже нарвались. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2007, 18:20 |
|
||
|
|

start [/forum/topic.php?fid=35&msg=35017982&tid=1553196]: |
0ms |
get settings: |
10ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
36ms |
get topic data: |
7ms |
get forum data: |
2ms |
get page messages: |
49ms |
get tp. blocked users: |
1ms |
| others: | 258ms |
| total: | 381ms |

| 0 / 0 |
