INFOSTART EVENT 2018 EDUCATION

Второй тур голосования за доклады.
Окончание 5 сентября.

Бобрышов Александр | Ведущий программист | ООО "Проф ИТ"

«Как организовать консолидацию данных из трёх десятков предприятий не привлекая программистов на местах?»

Давайте представим, что у нас есть "зоопарк" из разных конфигураций 1С, от разных организаций одного холдинга, занимающихся совершенно непохожей деятельностью (от промышленного производства до туристической деятельности). Бухгалтерские данные должны стекаться из этих предприятий в управляющую компанию, учет в которой ведется в системе, принципиально отличающейся от 1С. Некоторые дочерние организации работают на решениях без штатных программистов и находятся за 1000+ км. Я расскажу, какую архитектуру и технологии выбрать для такого обмена. Как наладить выгрузку данных по одной кнопке без изменения конфигурации предприятия. Как создавать и модифицировать правила обмена для разных предприятий из офиса управляющей компании. Как следить за состоянием обмена из единого центра управления.

0. Dem1urg 167 31.07.18 10:12 Сейчас в теме

Зачем запросу план и кто его выполняет?

Как определить, почему запрос выполняется слишком долго? Что происходит с запросом на стороне сервера баз данных? В статье приводится объяснение, что такое план запроса и для чего он нужен. А также говорится о том, в чем разница между потоком операторов и потоком данных, как работает оптимизатор и зачем нужна статистика.

Перейти к публикации

Комментарии
Сортировка: Древо
1. Крококот 09.08.18 10:38 Сейчас в теме
Пара дополнений/уточнений:
Для эффективности Nested Loops критически важен размер именно внешней таблицы; внутренняя таблица может быть и большой (в этом случае желательно соединение по ключу с хорошей селективностью, правда).
Table Scan (как и Clustered Index Scan) эффективны не только для малых таблиц, но и тогда, когда условия поиска в таблице имеют небольшую селективность, либо когда получается таблица полностью. Если необходимо получить, к примеру, 70% записей таблицы, то проще получить её полностью, чем заморачиваться работой с индексами.
Ну и последнее. Не замечал того, что Index Scan выполняется быстрее, чем Table Scan. Разве в том случае, когда отбор по индексируемым полям задействовать не получается как-то используется то, что индекс сортирован?
3. vitkhv 09.08.18 12:44 Сейчас в теме
(1)
Не замечал того, что Index Scan выполняется быстрее, чем Table Scan.

Если индекс кластерный, формально разницы быть не должно.
4. Dem1urg 167 09.08.18 12:52 Сейчас в теме
(3) Если нужно отобрать из таблицы данные по условию, и условие частично покрывается кластерным индексом, в некоторых случаях IndexScan будет быстрее. Зависит от селективности условия отбора.
6. vitkhv 09.08.18 13:21 Сейчас в теме
Хотелось бы на тестах это увидеть, а то сколько не тестировал разницы не увидел.
16. Dem1urg 167 09.08.18 15:44 Сейчас в теме
(6) In a table without a clustered index (a heap table), data pages are not linked together - so traversing pages requires a lookup into the Index Allocation Map.
A clustered table, however, has it's data pages linked in a doubly linked list - making sequential scans a bit faster

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

https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2008-r2/ms177443(v=sql.105)
26. vitkhv 09.08.18 17:31 Сейчас в теме
(16) Из этого - на HDD будет быстрее, на SSD пофиг. Давно я с HDD не работал, надо будет подключить и протестировать.
7. Крококот 09.08.18 13:25 Сейчас в теме
(4)
Если условие покрывается кластерным индексом хотя бы частично, то будет использован оператор Clustered Index Seek, с использованием в предикате конструкции WHERE. Нет?
2. Alex_CheST 1 09.08.18 12:38 Сейчас в теме
Огромное спасибо. Очень понятно и доступно написано. Я как раз хотел разобраться что это за зверь. А то поверхностно пока знаю
alex-l19041; +1 Ответить
5. vitkhv 09.08.18 13:02 Сейчас в теме
Вообще для MSSQL сервер раньше говорилось, что его соединение методом вложенных циклов самое эффективное, в отличии от соединения хэшированием, которое более эффективно у Oracle. Это даже в рассылке "SQL сервер дело тонкое" отражено.

Да и сортировка слиянием, если таблицы уже отсортированы, тоже проходит быстрее соединения хэшированием.
8. vitkhv 09.08.18 13:54 Сейчас в теме
(5) А адаптивные соединения которые появились в 2016 MSSQL во многом решают проблемы с устареванием статистики. Жаль только они не применимы для архитектуры таблиц 1С.
11. Dem1urg 167 09.08.18 14:35 Сейчас в теме
(8) В новых MS SQL вообще очень много интересных фишек, которые, к сожалению, неприменимы в контексте 1С.
9. boln 978 09.08.18 14:03 Сейчас в теме
Еще бы только поменьше картинок на архитектурную тематику и сами картинки поменьше размером. Множество картинок с домиками аналогию не усиливает, только текст загромождает.
10. Dem1urg 167 09.08.18 14:29 Сейчас в теме
(9) Статья написана на основе доклада. Все картинки - это слайды из презентации.
12. nicxxx 192 09.08.18 15:10 Сейчас в теме
"для подзапроса статистики нет" - вот тут автор неправ. Каждый подзапроса - это выборка откуда-то, другого подзапроса или таблицы. Оптимизатор, раскручивая вложенные подзапросы, добирается до исходной таблицы, а там уже статистика есть. Вот она и будет использоваться в дальнейшем.
15. Dem1urg 167 09.08.18 15:40 Сейчас в теме
(12) Согласитесь, что "качество" такой "раскрученной" статистики может быть сильно не очень. И чем глубже вложенность, тем выше вероятность, что толку от подобной статистики не будет.
17. vitkhv 09.08.18 15:49 Сейчас в теме
(15)ну да именно поэтому и тормозят запросы к ВТ РС. Потому как там жуткий подзапрос.
20. nicxxx 192 09.08.18 16:05 Сейчас в теме
(17) Не соглашусь. Подзапроса не жуткий. MSSQL довольно хорошо понимает его и строит план, который изначально предполагает применение даже внешних условий к самому первому оператору ( определение MAX(_period)). Ну а дальше уже проще, работает с ограниченной выборкой.
23. vitkhv 09.08.18 16:33 Сейчас в теме
(20) понимает и строит. Но при выносе max(_period) в #temp таблицу, понимает и строит гораздо лучше, особенно на версиях ниже 2012 сервера. 1С даже из за плохого понимания оптимизатором подзапроса ввела механизм представлений.
24. nicxxx 192 09.08.18 17:16 Сейчас в теме
(23) Мне пока не удалось ускорить получение среза таким образом. Наоборот, тратится время на создание временной таблицы и дальнейшее чтение из нее. Планы получаются одинаковые в части формирования временной таблицы с MAX(_period).
25. vitkhv 09.08.18 17:20 Сейчас в теме
(24) А мне удалось и не раз. Теперь после этого только так и пишу. Хотя таблица среза последних, путает карты иногда.

А вообще время на построение #temp таблицы не существенно.

Как то прочитал про эволюцию писателей запросов:
На первом шаге учишься писать простые запросы, на следующем шаге учишься писать сложные запросы и на последнем шаге учишься писать опять простые.

А простыми запросы на третьем шаге получаются только с использованием #temp таблиц, правда многоэтажными.
alex-l19041; +1 Ответить
13. nicxxx 192 09.08.18 15:19 Сейчас в теме
Здесь тоже неправда: "Крайне не рекомендую создание индекса через SQL, потому что как только вы сделаете «Обновить конфигурацию базы данных» из конфигуратора, все эти индексы “улетят”,". Никуда они не улетят, пока изменения не коснутся конкретной таблицы с таким индексом, причем нужна именно реструктуризация.
14. Dem1urg 167 09.08.18 15:39 Сейчас в теме
(13) Спасибо за уточнение. Речь шла о том, что созданные "вручную" индексы могут быть уничтожены платформой, т.к. она не знает об их существовании. И что не нужно удивляться, если в определенный момент времени "ручной" индекс внезапно исчезнет.
28. logarifm 1022 12.08.18 19:28 Сейчас в теме
(13) Тут вы частично правы, а частично нет. Это еще много зависит от версии платформы
18. ctpayc 09.08.18 15:51 Сейчас в теме
Вам пора писать книгу "SQL для чайника бухгалтера". А не кажется, что ваши читатели могут быть чуть умнее инфузории? Работа оптимизатора рассмотрена на непонятном уровне, где рассказ о том, как оптимизатор выбирает индексы, как считает время на исполнение каждой операции, как именно определяется оптимальный план.
А по фактическим утверждениям вообще огонь:
1. "Index Scan чуть хуже чем Index Seek, но тоже неплохо, и только Table Scan это плохо". Да, ладно, чем это Clustered Index Scan сильно лучше чем Table Scan? А почему оптимизатор выбирает Table Scan на таблице со 100 записями, хотя у него есть подходящий индекс?
2. "Для подзапросов никакой статистики нет, оптимизатор может только очень приблизительно оценить …". О_О Это сейчас серьезно? Совсем не может оптимизатор с ним справиться... какой глупенький... Вот так и рождаются мифы, что вложенный запрос это всегда плохо и надо всегда переписывать их на временные таблицы. Был у меня такой: "Ну я это где-то слышал...", потом сидел переделывал, все что поисправлял… Он не может определить сколько будет записей, только если во вложенном запросе была группировка! Не надо эту ахинею больше писать - люди в нее верят.
3. "В tempdb надо регулярно выполнять truncate"... Что сказать, без комментариев - позовите Лаврова, он точнее выразит мои мысли.
4. "Индекс, включающий все измерения в том порядке, в котором они указаны в дереве метаданных, создается по умолчанию. Наиболее часто используемые – лучше выносить вверх". А о каком регистре мы для начала говорим? А что если у нас по частоте использования на первом месте измерение Склад, потом Номенклатура, а еще есть Контрагент и Партия... Нам в каком порядке их выносить? И ведь люди последуют этой рекомендации вместо того чтобы подумать и построить порядок правильно...
...
21. nicxxx 192 09.08.18 16:10 Сейчас в теме
(18) Даже если была группировка, он может оценить кардинальность с определенной степенью точности. Довольно высокой степенью.
22. Dem1urg 167 09.08.18 16:17 Сейчас в теме
(18) О, эксперты подтянулись. И зачем было утруждать себя чтением настолько ненужной и глупой статьи?
mytg; vitkhv; sank84; HiGHT; +4 1 Ответить
29. ADirks 179 13.08.18 10:56 Сейчас в теме
(22) А затем, что 1Сники слепо верят в эту ахинею про "подзапросы - зло" и "tempdb - это благо". И все эту идиотию бездумно повторяют.
30. Dem1urg 167 13.08.18 15:06 Сейчас в теме
(29) Невозможно в рамках 30 минутного доклада рассказать обо всех особенностях формирования планов запросов. Да еще и людям, которые имеют весьма общие представления о реляционных базах данных. Да, в докладе есть неточности, есть упрощения, есть ошибки. И я буду благодарен за указание на них. Но не в формате
"Что сказать, без комментариев - позовите Лаврова, он точнее выразит мои мысли. "


Про "подапросы - зло, tempdb - добро". Нет универсальных рецептов. Все зависит от конкретной ситуации. Но чтобы принять правильное решение нужно понимать как оно там "внутри" работает. Хотя бы в общих чертах.

Напишите хорошую и правильную статью, про подзапросы, tempdb и "вот это вот всё". Все будут только благодарны.
31. ADirks 179 14.08.18 07:52 Сейчас в теме
(30) В том то и дело, что универсальных рецептов нет, и надо каждый раз думать. Но почему-то мало кто хочет этим заниматься. 1С-никам же методичка от 1С по видимому представляется наивысшим авторитетом, а там такое как раз и пишут.
Хороших же статей и книжек на эту тему чуть более чем дофига.
32. Dem1urg 167 14.08.18 09:44 Сейчас в теме
(31) Если можете что-то порекомендовать - киньте ссылки, прям сюда, в комментарий.
27. vitkhv 10.08.18 11:36 Сейчас в теме
(18)
Он не может определить сколько будет записей, только если во вложенном запросе была группировка!


Т.е. если во вложенном подзапросе будет SELECT DISTINCT FROM то уже сможет определить сколько будет записей?
33. ADirks 179 14.08.18 11:12 Сейчас в теме
Неплохая книжка: Дэн Тоу - Настройка SQL для профессионалов
Не тупо "делай раз, делай два", а хорошая методика. Соединения правда пишет в секции WHERE, немного неудобно.
введение: http://www.sql.ru/articles/mssql/2005/122801sql.shtml
скачать в djvu: https://proklondike.net/books/dbobshee/tou_sql_tuning.html
34. ADirks 179 14.08.18 13:54 Сейчас в теме
про tempdb есть хорошая публикация https://infostart.ru/public/850217/
где наглядно показано, что и как происходит, если её нагружать
35. Solikamsk 15.08.18 10:40 Сейчас в теме
Небольшая ошибка в "Соединение слиянием"

Пока .. Цикл
Строка1 = Таблица1[Сч1]
Строка2 = Таблица1[Сч2] //здесь должна быть Таблица2
36. Solikamsk 15.08.18 13:22 Сейчас в теме
И всё-таки мне, господа, совсем не понятен алгоритм "слияния". Допустим:

Таб1: Таб2:

2 ; 1
1 ;

т.е. простые две таблицы. В первой две строки (2;1), во второй одна (1).
По Вашему алгоритму она один раз зайдет в цикл, выйдет и не найдет совпадений...

Что не так?
37. Solikamsk 15.08.18 13:35 Сейчас в теме
Здесь не слова про сортировку :) Начал в других источниках смотреть.
Оставьте свое сообщение
Новые вопросы с вознаграждением
Автор темы объявил вознаграждение за найденный ответ, его получит тот, кто первый поможет автору.

Вакансии

Удаленный ИТ-журналист
Санкт-Петербург
По совместительству

Удаленный бизнес-аналитик 1С
Санкт-Петербург
Временный (на проект)

Программист 1С
Москва
Полный день

Консультант-аналитик 1С
Санкт-Петербург
зарплата от 80 000 руб.
Полный день

Аналитик 1С
Москва
зарплата от 80 000 руб. до 120 000 руб.
Полный день