Составные типы — бесплатный сыр мышеловки производительности

96 Comments

1. ildarovich 11.05.2013 at 12:24

   Очень интересно. Некоторые вещи хочется перепроверить или уточнить. Например, почему

   индексы по такому составному полю не могут использоваться и в более простом запросе:
   
   ВЫБРАТЬ РАЗЛИЧНЫЕ
   
   Справочник1.СоставноеПоле КАК СоставноеПоле
   
   ИЗ
   
   Справочник.Справочник1 КАК Справочник1

   Хочется подробностей про

   В принципе в современных СУБД давно есть средства, которы бы позволили работать с такими типами эффективно

   Как в принципе может использоваться индекс в

   Агрегатные функции — МИНИМУМ(…) и МАКСИМУМ(…)

   Пока прочитал по диагонали. Возможно, будут еще вопросы.

   Reply ↓
2. speshuric 11.05.2013 at 14:42

   (1)
   
   1. Индекс не будет использоваться потому что нет нужного индекса:
   
   ВЫБРАТЬ РАЗЛИЧНЫЕ
   
   Справочник1.СоставноеПоле КАК СоставноеПоле
   
   ИЗ
   
   Справочник.Справочник1 КАК Справочник1
   
   
   
   будет выполняться как
   
   ВЫБРАТЬ РАЗЛИЧНЫЕ
   
   Справочник1.СоставноеПоле.Тип КАК СоставноеПолеТип,
   
   Справочник1.СоставноеПоле.Число КАК СоставноеПолеЧисло,
   
   Справочник1.СоставноеПоле.Ссылка КАК СоставноеПолеСсылка
   
   ИЗ
   
   Справочник.Справочник1 КАК Справочник1
   
   
   
   Отдельно есть индексы (Справочник1.СоставноеПоле.Тип, Справочник1.СоставноеПоле.Число) и (Справочник1.СоставноеПоле.Тип, Справочник1.СоставноеПоле.Ссылка). И, если бы это было поле простого типа, а не сотавного, то можно было бы расчитывать, что движок БД его подхватит, а для составного — не получается использовать.

   Reply ↓
3. speshuric 11.05.2013 at 14:53

   (1)
   
   2. Про «средства, которы бы позволили работать» — там рядом ссылки есть.
   
   3. Мне если честно, казалось это очевидным. Попробую чуть подробнее. Самая простая аналогия для индекса — упорядоченный список статей с оглавлением. В такой структуре легко найти все значения, входящие в диапазон, а если этих значений очень много, то легко как минимум входящие в диапазон.
   
   Поэтому запрос
   
   ВЫБРАТЬ МИНИМУМ(ОстаткиНоменклатуры.Период)
   
   ИЗ РегистрНакопления.ОстаткиНоменклатуры КАК ОстаткиНоменклатуры
   
   ГДЕ ОстаткиНоменклатуры.Период>&Дата
   
   
   
   просто выберет первую запись из тех, которые «>&Дата».

   Reply ↓
4. ildarovich 11.05.2013 at 15:52

   (2) А это практически проверялось? — То есть Вы смотрели план соответствующего запроса? Проводили замеры?
   
   (3) 2. Ссылки я посмотрел, однако не совсем ясно как это практически использовать. Вычисляемые поля — что за функция? — Что-то вроде хеш-функции? — А коллизии? Фильтрованные индексы. В качестве фильтра — тип поля? Но там разве есть возможность в одном индексе задать несколько фильтров (по числу базовых типов + ссылка)? Разреженные столбцы — тут понятно. Индексы с включенными полями — опять непонятно использование по отношению к данной проблеме.
   
   3. Одно время мне это тоже казалось очевидным. Но я не нашел конкретного практического подтверждения тому, что это действительно делается. Может быть, плохо смотрел.

   Reply ↓
5. speshuric 11.05.2013 at 16:08

   (4)
   
   1. Да, конечно, план смотрел, хотя тут и план не нужно смотреть: нет покрывающего индекса. Но для статьи каждый пример проверялся.
   
   2.1. Вычисляемые поля не как хэш-функции, а как простое выделение из составного поля простого. Вычисляемые поля (которые можно было бы вычислять из одного varbinary) и их фильтрованное индексирование было бы хорошим решением. Чисто механически уменьшился бы объём индексом и увеличилось количество случаев их использования. Вечерком накидаю в SQL что я имею ввиду и приложу скрипт, чтобы было понятно. Но в любом случае это к 1С отношения не имеет. Серым шрифтом я пометил свое ворчание 🙂
   
   2.2. Индексы с включенными полями — именно они могли бы ускорить запросы типа того «ВЫБРАТЬ РАЗЛИЧНЫЕ» по которым сейчас индексы не используются.
   
   3. Сейчас приведу пример с планом.

   Reply ↓
6. speshuric 11.05.2013 at 17:20

   (4) скрипт
   

   set nocount on;
   declare @start bigint, @len bigint, @seed bigint;
   set @start = 0;
   set @len = 1000000;
   set @seed = 2;
   create table #tmp
   (
   id bigint not null primary key,
   somedata nvarchar(100) not null
   );
   with recursive_builder(id) as
   (select 1 id — это просто генерация списка интов
   union all select 2*r.id + 1 from recursive_builder r where 2*r.id + 1 <= @len
   union all select 2*r.id from recursive_builder r where 2*r.id <= @len)
   insert #tmp (id, somedata) select @start + (id-1)*@seed, NEWID() from recursive_builder r;
   declare @search_from bigint;
   set @search_from = 1000000;
   set statistics profile on;
   select min(id) from #tmp where id>@search_from;
   set statistics profile off;
   drop table #tmp;
   set nocount off;

   Показать

   результат (правая часть обрезана, чтобы поместилось нормально в форум):
   

   ———————
   1000002
   
   Rows                 Executes             StmtText                                                                                                                                 ……
   ——————— ——————— —————————————————————————————————————————————- ……
   1                    1                    select min(id) from #tmp where id>@search_from;                                                                                          ……
   1                    1                      |—Stream Aggregate(DEFINE:([Expr1003]=MIN([tempdb].[dbo].[#tmp].[id])))                                                               ……
   1                    1                           |—Top(TOP EXPRESSION:((1)))                                                                                                      ……
   1                    1                                |—Clustered Index Seek(OBJECT:([tempdb].[dbo].[#tmp]), SEEK:([tempdb].[dbo].[#tmp].[id] > [@search_from]) ORDERED FORWARD)  ……
   
   

   Показать

   Собственно, как и ожидалось.

   Reply ↓
7. Jogeedae 11.05.2013 at 19:53

   Спасибо за труд!
   
   1С действительно жертвует производительностью ради удобства разработки.
   
   Рекомендация делать запросы маленькими и простыми, заиграла новыми красками.
   
   Из статьи почерпнул для себя некоторые принципы, попробую практиковать.
   
   Неоптимальные запросы иногда пугают, особенно когда видишь 100% загрузки каждого из ЦП на сервере СУБД.(часто такое вижу у коллег) Поседеть можно :).

   Но всё же есть 2 момента:
   
   1. Оптимизация должна делаться там, где она необходима; Считаю, что не стоит утруждать себя ковыряниями над профайлером, ради 90% ускорения запроса выполняемого раз в неделю в течении 30 секунд.
   
   2. Встречался с проблемой составных типов только 1 раз в виде:
   

   Ошибка выполнения запроса: Построенный запрос к СУБД использует слишком много таблиц. Допустимо не более 256.
   
   Microsoft OLE DB Provider for SQL Server: Too many table names in the query. The maximum allowable is 256.

   (Это ограничение действовало на ms-sql 2000, по-моему)
   
   Удалось обойти с помощью проверки типа ссылки в запросе и разбиением его на составляющие + временные.

   Reply ↓
8. ILM 11.05.2013 at 20:05

   Спасибо за статью.
   
   «Многие знания, многие печали» — написано в книге Экклезиаста.
   
   Все дело в объеме данных, если количество записей в таблице не велико и скорость выполнения запросов приемлема для пользователей, то можно и не обращать внимание на составные поля. И наоборот 🙂
   
   В целом статья будет полезна как новичкам, так и разработчикам с опытом.

   Reply ↓
9. speshuric 11.05.2013 at 20:06

   (7)
   
   (Это ограничение действовало на ms-sql 2000, по-моему)
   
   Почти верно. До 2005 включительно.

   Reply ↓
10. speshuric 11.05.2013 at 20:09

    (8) Спасибо за отзыв. Не считаю небольшой объём и количество записей поводом писать кривой код. Ведь трудозатраты зачастую одинаковы.

    Reply ↓
11. ILM 11.05.2013 at 20:35

    (10) Главным ограничением всех процессов — является время. Можно написать супер код и опоздать.

    Reply ↓
12. ildarovich 11.05.2013 at 21:15

    (6) Спасибо, убедили… Видимо, запомнившаяся мне рекомендация использовать SELECT ТОР 1 … ORDER BY … вместо MIN в таких случаях относилась не к MS SQL или к другим типам индексов.

    Reply ↓
13. Bukaska 11.05.2013 at 22:45

    ТОже спасибо, поставила +
    
    Я ещё только учусь и всегда интересно знать, что если запрос надо строить именно так, то почему))))

    Reply ↓
14. Ish_2 12.05.2013 at 08:14

    (0) Прочитал мельком. Нужны ли такие изыскания ?
    
    Черт его знает, любая тема когда -нибудь становится актуальной.
    
    Написано вроде бы «по-врослому». Вызывает уважение. +

    Reply ↓
15. speshuric 12.05.2013 at 10:36

    Reply ↓
16. tormozit 12.05.2013 at 11:00

    Спасибо за полезное исследование с качественной подачей материала.

    Reply ↓
17. ildarovich 12.05.2013 at 12:10

    (6) Увидел в скрипте интересную рекурсивную CTE. Не могли бы ее прокомментировать: откуда-то взяли или сами придумали, почему считаете ее лучше чем простая CTE c 0 через id + 1 (на строчку короче и единицу не нужно будет отнимать). Сам использую подобные приемы, но в данном случае сомневаюсь в том, что будет быстрее. Замеры делали? За счет чего может быть выигрыш?

    Reply ↓
18. speshuric 12.05.2013 at 12:34

    (17)По порядку
    

    • Эту, cte кажется сам придумал, но не со своей идеей.
      
    • В этой cte мне нравится, что она «медленно» уходит в рекурсию. Обычно ставят OPTION (MAXRECURSION 0) (как здесь). В моём случае глубина рекурсии растет как логарифм, а соответственно значения по умолчанию (100 вложений) хватит и на bigint.
      
    • Производительность сравнивал, но не помню точно. Кажется мой вариант шустрый, но если я правильно помню, всё равно декартово произведение таблиц с «заготовкой» от 0 до «много» и с кластеризованным индексом рвёт остальные варианты, особенно если правильно прописать условия для использования индексов (оно получается громоздким).
      

    UPD: померял производительность с «одиночной» рекурсией — она примерно одинаковая.

    Reply ↓
19. AlX0id 12.05.2013 at 12:48

    Поставил бы пять плюсов и более, была бы возможность )
    
    Отличное и доступное изложение, интересный и глубокий материал — спасибо )

    Reply ↓
20. vet7777 12.05.2013 at 14:15

    Шурик, ты проделал огромную, а главное полезную работу. Причем ты все показал с профессиональной точки зрения, все грамотно разложил по полочкам. И кое-кого можно ткнуть носом теперь сюда ). Многие ситуации интуитивно и теоретически понимались, но ты провел отличное практическое исследование и описал проблему в целом. Причем не только показал минусы, но и указал как можно было бы исправить, как разработчикам, но и даже фирме 1С. Вообщем то, на infostart event можно было даже выступить с такой темой.
    
    PS: пиши еще )))

    Reply ↓
21. tormozit 12.05.2013 at 14:37

    (20) Да, я тоже считаю что такой материал был бы очень полезен на конференции.

    Reply ↓
22. speshuric 12.05.2013 at 15:09

    (20) Я же и есть главный бенефициар статьи. 😉
    
    (21) Мелковата тема для доклада. Если изложить в слайдах и рассказывать голосом, то это 5-10 минут от силы. При этом вся практическая ценность в разделе «Как следует работать…».

    Reply ↓
23. vet7777 12.05.2013 at 15:13

    Ну на конференцию едут ведь не только прорекламировать свои продукты, но и обменяться опытом. неужели на конференции нет блока 10-15 минутных докладов для обмена опытом?

    Reply ↓
24. apatyukov 12.05.2013 at 16:07

    (23) Александр как всегда скромничает о своем опыте, методичности, глубине знаний и уровне проектов которые ведет 🙂

    Reply ↓
25. speshuric 12.05.2013 at 16:49

    (24) Ну что ты тут наговариваешь? Опыт у меня маленький — на 3 года примерно меньше чем у тебя, по методичности и знаниям — vet7777 которому ты отвечаешь за мной вчера шлакокод переписывал, проектов я вообще не веду. Врёшь ты всё! 🙂

    Reply ↓
26. TrinitronOTV 13.05.2013 at 06:46

    спасибо автору за предоставленную статью…., очень для меня познавательно

    Reply ↓
27. DoctorRoza 13.05.2013 at 09:12

    Классно! 🙂 Однозначно + ! Чувствуется уровень 1С:Эксперта! Но! Хотелось бы больше примеров по оптимизации кода. Уверен, такая информация пойдет в раздел «КАК ИЗНАЧАЛЬНО ПРОГРАММИРОВАТЬ ПРАВИЛЬНО». Дополнительно, напишите статью как получить псевдокод из кода запроса 1С. Конечно, тут потребуется раскрыть и понятия SQL, пусть хоть на начальном уровне. Думаю, получится отличный цикл статей про связку СУБД + 1C. 🙂

    Reply ↓
28. sitec-it 13.05.2013 at 10:08

    Спасибо за статью. Сил прочитать все не хватило, но возьму на заметку приемы в запросах, хотя я и так знал, что поля составного типа — проблемные в плане производительности.

    Reply ↓
29. Evil Beaver 13.05.2013 at 11:20

    Статья объемная, работа проделана большая, спасибо. Однако, все это уже есть на ИТС и давно разжевано-пережевано. Составные типы — удобная фича, но использоваться должна с умом.

    Reply ↓
30. headMade 13.05.2013 at 15:03

    (29) Evil Beaver,
    
    а в каком разделе можно найти на ИТС, или может дадите ссылку на its.1c.ru ?

    Спасибо.

    Reply ↓
31. Evil Beaver 13.05.2013 at 15:21

    (30) headMade, честно говоря, нет времени искать. Поищите по словам «составной тип». Там где-то точно было черным-по-белому, как составной тип отображается в структуру таблиц СУБД и как нельзя делать с точки зрения производительности. В любом случае, текущая статья более чем исчерпывающая.

    Reply ↓
32. speshuric 13.05.2013 at 16:25

    (29) Не соглашусь. На ИТС относительно небольшой объём информации. Структура хранения на ИТС есть. Индексы, которые строятся — есть. Общая рекомендация «получение данных через точку от полей составного типа» и то, как разыменуются поля значений составных типов — есть. Рекомендация не делать нессылочные субконто — где-то тоже кажется была. Есть еще замечание про ограничения индексов на составные типы (тоже в контексте субконто) и замечание про разницу NULL/Неопределено в контексте запросов и составных типов.
    
    Зато нет:
    

    • Дополнительная существенноа деградация, если «получение данных через точку от полей составного типа» используется в ГДЕ или ПО. Сколько раз я переубеждал программистов, которые утверждали что «Регистр.Регистратор.Дата>&Дата» должен использовать индексы.
      
    • Почти полная бесполезность индексирования составных типов, содержащих несколько базовых (фактически индекс работает только для «ГДЕ СоставноеПоле = &Параметр»)
      
    • Неочевидная потеря производительности на «В (&Список)»
      
    • Тема того, как используется «ВЫБОР КОГДА ТОГДА» и МИНИМУМ/МАКСИМУМ
      
    • Почти нет приемов, как обходить проблемы производительности (за исключением ВЫРАЗИТЬ, которое, кстати, не всегда работает)
      

    Но в целом — да, если хоть иногда приходится смотреть ТЖ, трассу и планы запросов, то мегаоткровений тут нет. И подходы 1С к тому, как преобразовать язык запросов в SQL тоже предсказуемы, понятны и объяснимы. Собственно причины написания статьи изложены в (15) — мне просто нужно было консолидировать информацию по этой проблематике.

    Reply ↓
33. Evil Beaver 13.05.2013 at 16:48

    (32) да слов нет, Ваша статья — просто отличная. Имхо, ее можно было бы подсократить, т.к. несмотря на фундаментальность она сводится к известным тезисам:

    1. Составной тип — часто источник проблем
    
    2. Ссылочные типы вперемешку с примитивными — зло
    
    3. Получение полей от ссылочного типа через точку — зло
    
    4. Пункты 2+3 одновременно — аццкий сотона зохавал всех
    
    5. Если в запросе присутствует составное поле — нужно смотреть, как оно отобразится на реальный запрос.

    Итого, мне немного не хватило best practices в статье — как можно делать. Как нельзя, в-общем, и так было понятно. Тем не менее, прошу не воспринимать, как критику. Ни в коем случае. Это просто размышление вслух. Статья отличная, спасибо еще раз. Про потерю производительности по «СоставныеСсылки В (&СписокСсылок)» не знал, был уверен, что индекс гарантированно используется.

    Reply ↓
34. speshuric 13.05.2013 at 17:06

    (33) в этих формулировках согласен на 146%

    Reply ↓
35. tango 13.05.2013 at 17:14

    за ссылку отдельный +
    
    «1с как продукт мысли» — звучит
    

    В этой статье мы решили сконцентрироваться не на описании возможностей продукта «1С:Предприятия», а именно на технологических инновациях, которые в совокупности определили ряд совершенно новых технологий разработки бизнес-приложений и новых качеств самих этих приложений.

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

    Reply ↓
36. speshuric 14.05.2013 at 07:47

    (35) tango, я думаю, что не стоит придираться к хорошей маркетингово-популяризационной статье 2004 года. Тем более, что автор фактически не словом, но делом доказал, что они способны успешно развивать и улучшать продукт. Отдельное им спасибо за эволюционное, а не революционное развитие.

    Reply ↓
37. vlad.frost 14.05.2013 at 12:17

    Отличная статья в тему про дырявые абстракции http://russian.joelonsoftware.com/Articles/LeakyAbstractions.html (если вдруг кто ещё не читал)

    Reply ↓
38. Yashazz 14.05.2013 at 13:08

    Да, спасибо. Тоже далеко не всё знал насчёт использования (а точнее, неиспользования) индексов. Надеялся, что оно есть, а взаправду вот как. Отличная статья!

    Reply ↓
39. speshuric 14.05.2013 at 13:20

    (37) У Спольского вообще много хороших статей. Но вот дырявые абстракции — они на самом деле лежат очень многослойно вокруг нас.

    Reply ↓
40. Evil Beaver 14.05.2013 at 16:07

    (39) ну Спольски вообще любит покрасоваться, мол, во какую я штуку всем открыл, абстракции, оказывается, построены друг на друге 😉 Одна мысль там в этой статье мне нравится, дословно не помню, смысл такой, что несмотря на все современные инструменты и абстракции я все равно обязан знать то, что написано у Кернигана&Ричи, иначе мне, как спецу, каюк. Это прям эпиграф к Вашей статье. Составной тип клево — но нужно знать, что он есть на самом деле

    Reply ↓
41. vlad.frost 14.05.2013 at 17:24

    (40) Позволю себе ещё одну цитату: «Вычислительная техника — это дисциплина, в которой считается, что все проблемы можно решить благодаря введению одного или нескольких уровней косвенности.» © Деннис Де Брюле

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

    Reply ↓
42. speshuric 14.05.2013 at 18:05

    (40) Ну Спольскому с его особенностями простительна «любовь покрасоваться». А в 1С до фига и других дуршлагов-абстракций. Начиная со строк и арифметики:
    

    • Арифметика пытается усидеть на 2 стульях (точные значения и плавающая точка). В результате производительность нигде, артефакты на интеграции так и прут, и СУБД про такую арифметику ваще не в курсе. Когда я вижу что браузерs в JavaScript фигачат до 500 млн операций с числами в секунду, то вспоминая 1С прям аж… Прям аж…
      
    • Строки. Я не буду вспоминать эпопею с преобразованиями crlf. Я промолчу про то, что интерпретатор 1С считает буквами, а что нет (вопрос, кстати, не так тривиален 🙂 ). Давайте лучше про конкатенацию. А = А + «Ы» — что может быть проще. Пока этих выражений не 100500. Возникает глупая ситуация, когда для большого запроса к внешней системе основное время уходит на создание запроса, а не на выполнение или разбор. StringBuilder отсутствует. ТекстовыйДокумент не спасает. Зато спасает (кто бы мог подумать) ЗаписьXML:
      

      ТекстПостроитель = Новый ЗаписьXML;
      ТекстПостроитель.УстановитьСтроку();
      ТекстПостроитель.ЗаписатьБезОбработки(«Кусочек строки»);
      ТекстПостроитель.ЗаписатьБезОбработки(«, и еще один»);
      СтрокаРезультат = ТекстПостроитель.Закрыть();

      Я об этом писал у себя в бложике
      

    Реально, куда ни копни — герметичности этих абстракций нет. Ну да и ладно. Зато вентиляция 🙂

    Reply ↓
43. scape 15.05.2013 at 07:21

    Полезная информация. Благодарю. Но зачем страх нагонять, используя обороты «ужас», «кошмар», «зло» в технической статье? Пойду застрелюсь…

    Reply ↓
44. higs 15.05.2013 at 07:49

    А мне понравилось. Достаточно глубокая проработка и исследование, далеко не всегда доходят руки так глубоко лезть в скуль. Конечно, пока будешь приучать себя так писать запросы, производителность собственная упадет.
    
    Есть только некие неточно сформулированные в голове противоречия для использования рекомендованных правил из статьи и рекомендаций по работе в СКД. Например, в СКД рекомендовано отборы оставлять для выбора пользователя. Очень часто, это как раз составной тип или будет при соединении. Ну и еще там есть.
    
    Как я понимаю, для СКД все еще страшнее и ужаснее.

    За статью просто твердущий плюс!

    Reply ↓
45. zqzq 15.05.2013 at 08:44

    Статья во многом пересекается с приложением книги «Проф. разработка — реализация прикладных задач в системе 8.2», там с табличками и примерами расписаны особенности и неприятности составных типов (а также вообще хранение данных). Тут в статье более сумбурно и подробно мне показалось, в книге более структурировано и кратко.

    Reply ↓
46. Evil Beaver 15.05.2013 at 09:54

    (42) ЗаписьXML — это стрингбилдер? Аааааа ну точно же! Чорт, как все просто иногда оказывается! Мегареспект!!!!

    Про числа не понял… меня особо не докучала никогда производительность численных операций. А что за задачи?

    Reply ↓
47. ildarovich 15.05.2013 at 11:20

    (42) Насчет

    А = А + «Ы»

    написано в статье Опять двойка Там предлагается для решения проблемы

    первоначально работать с такими длинными строками как с массивом символов (строк), а затем преобразовывать массив символов(строк) в результирующую строку с помощью простейшей рекурсивной функции

    . Интересно теперь будет сравнить по быстродействию с решением через ЗаписьXML. Кстати, проблема А = А + «Ё» существует в большинстве языков. Смотрите, например, Строки в C# и .NET / Хабрахабр.

    Reply ↓
48. bulpi 15.05.2013 at 14:58

    Все хорошо. Единственное замечание. Когда мне ради оптимизации предлагают заменить запрос в 3 строки на запрос в 30 строк, я останавливаюсь и начинаю думать 🙂 Когда через полгода я (или не дай Бог не я!) снова полезет в этот модуль, то количество МОЕГО драгоценного времени ( а не железного компьютерного), потраченного на понимание , чего тут творится, вырастет в N раз и резко сократит общий выигрыш от оптимизации (аж до минуса). Так что я буду продолжать использовать вариант Регистратор.Основание.Контрагент=&Контрагент.

    Reply ↓
49. speshuric 15.05.2013 at 16:36

    (45) Да, 2-й том, страница 670 🙂 Но там не разобраны моменты с ВЫБОР и МАКСИМУМ, на грабли которых мы наступили. Если честно, то я пока долистываю первый том: на работе как-то не до чтения, домой купил недавно и дома больше 50-70 страниц в день не успеваю проработать.
    
    (48) Пожалуйста-пожалуйста. Лишь бы это было осознанным выбором, и вы умели видеть и лечить свои же грабельки. У меня вот, например, стоимость месяца работы меньше стоимости пятиминутного простоя некоторых ИБ предприятия.

    Reply ↓
50. speshuric 15.05.2013 at 22:33

    (47) Проверил. ЗаписьXML быстрее (для большого количества конкатенаций, конечно).

    Reply ↓
51. ildarovich 15.05.2013 at 22:59

    (50) Спасибо! — Буду иметь ввиду. Еще перепроверил, действительно, формирование строки из миллиона «Ы» занимает при помощи функции

    Функция ДлиннаяСтрокаЧерезЗаписьXML(Длина, Чего = «») Экспорт
    Запись = Новый ЗаписьXML;
    Запись.УстановитьСтроку();
    Чего = Лев(Чего + » «, 1);
    Для ё = 0 По Длина — 1 Цикл Запись.ЗаписатьБезОбработки(Чего) КонецЦикла;
    Возврат Запись.Закрыть()
    КонецФункции

    примерно 2 секунды. Ближайший конкурент через представление массива при помощи функции

    Функция ДлиннаяСтрокаЧерезПредставлениеМассива(Длина, Чего = «») Экспорт
    Массив = Новый Массив(Длина);
    Чего = Лев(Чего + » «, 1);
    Для ё = 0 По Длина — 1 Цикл Массив[ё] = Чего КонецЦикла; //на это уходит больше половины времени, а половина от этого просто на цикл!!!
    сё = Сред(СтрЗаменить(ЗначениеВСтрокуВнутр(Массив), «»»},» + Символы.ПС + «{«»S»»,»»», «»), 53 + СтрДлина(Формат(Массив.Количество(), «ЧГ=»)));
    Возврат Лев(сё, СтрДлина(сё) — 6)
    КонецФункции

    отстает на 12 процентов с результатом 2,5 секунды.

    Reply ↓
52. tormozit 15.05.2013 at 23:53

    (42) Про ЗаписьXML я сам не догадался. Теперь буду применять. Спасибо!

    Reply ↓
53. LexSeIch 16.05.2013 at 11:18

    Мир этому дому! Большое спасибо за серьезную статью. Информации много и она интересная, а тем более это не компиляция доков, а практически проверенно. Большой плюс.

    Reply ↓
54. kiros 16.05.2013 at 12:01

    Александр, огромное спасибо за статью! Теперь в голове расставилось все по полочкам. А применение на практике дало просто колоссальный результат (а кто бы мог подумать, где собака порылась). Как то раньше сильно надеялся на платформу, а оказывается… буду сильнее изучать эту тему. ОГРОМНОЕ СПАСИБО.

    Reply ↓
55. S2Sps 16.05.2013 at 18:08

    Спасибо огромное за статью. Прочитал как на духу. Написано очень подробно и особенно радуют примеры. Всегда радовался составным типам. А теперь вернулся на землю ) и уж точно буду использовать их впредь аккуратно.

    Reply ↓
56. uinx 17.05.2013 at 09:12

    Reply ↓
57. burlakov 17.05.2013 at 10:46

    Статья просто шикарная. На часть вещей просто глаза открылись. Даже не думал, что от составных типов может быть так плохо, хотя и зная о проблемах с производительностью составные типы практически не использую в своих разработках.

    Reply ↓
58. markgenuine 17.05.2013 at 15:50

    Автор молодец, узнал много интересного, написано очень грамотно, подробно и понятно даже любому пользователю.
    
    Спасибо.

    Reply ↓
59. speshuric 17.05.2013 at 16:48

    (56) uinx, а какая структура регистров? И как организовано «Номенклатура.Реквизиты.Сезонность»?

    Reply ↓
60. speshuric 17.05.2013 at 19:43

    Reply ↓
61. Sorm 19.05.2013 at 10:08

    Хорошая грамотная статья, да только кто сначала будет разбираться в причинах резкого замедления исполнения запроса, когда «одно поле поменяли»? Скажут — «оборудование не тянет, давайте новое купим», ну или на крайний случай — 120 тыс рублей. Что интересно — когда на новом оборудовании запрос будет работать также(ну или чуть быстрее) вот тогда уже начинается «1С — г… » или там три конверта:), но чтобы профайлер открыть — «а что это»? Пример — недавно на мисте обсуждали какой-то запрос, что-то там запрос к виртуальным регистрам, с невъ… количеством джоинов по регистратору(здравствуйте, вычисляемые поля), так в профайлер в теме влезло два человека:).

    Reply ↓
62. mikhailovaew 20.05.2013 at 17:33

    Статья феноменальная. Огромное спасибо автору за труд, систематизацию и оформление. За отстутствие снобизма, за готовность отвечать на комментарии.
    
    Завидую вашим коллегам, как прекрасно, когда есть у кого перенять опыт! А то сидишь единственным программистом на фикси, и в свой же говнокод и ткнуть некому…
    
    А теперь вопрос нуба: как неправильный пример приводится запрос «Регистр.Регистратор.Дата>&Дата». Имеется в виду, что отбор по дате должен идти через Период соответствующего регистра? А если нужно именно сделать отбор по каким-то свойствам регистратора, то как это правильно оформить в запросе? Возможно, потребность такого отбора сигнализирует о неправильной архитектуре регистра, но допустим, что регистр менять мы не будем, а отбор в запросе реализовать надо.

    Reply ↓
63. speshuric 20.05.2013 at 19:32

    (62) mikhailovaew:
    
    1. Отбор замедлится по любым реквизитам поля составного типа. Дата или не дата — тут не важно
    
    2. Архитектура, она обычно не в каменных скрижалях высечена и кривую архитектуру нужно менять. Пусть не за один день и не останавливая другие задачи, но менять придётся. Кроме изменения регистра есть еще как минимум прием — создание нового регистра.
    
    3. Как костыльный вариант (один из многих):
    

    ВЫБРАТЬ что-то
    ИЗ РегистрНакопления.МойРегистр КАК МойРегистр
    ГДЕ 1 В
    (ВЫБРАТЬ 1 ИЗ Документ.ДокументРегистратор1 КАК Док ГДЕ Док.Ссылка = МойРегистр.Регистратор И Док.Дата>&Дата
    ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1 ИЗ Документ.ДокументРегистратор2 КАК Док ГДЕ Док.Ссылка = МойРегистр.Регистратор И Док.Дата>&Дата
    ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1 ИЗ Документ.ДокументРегистратор3 КАК Док ГДЕ Док.Ссылка = МойРегистр.Регистратор И Док.Дата>&Дата
    ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1 ИЗ Документ.ДокументРегистратор4 КАК Док ГДЕ Док.Ссылка = МойРегистр.Регистратор И Док.Дата>&Дата
    ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1 ИЗ Документ.ДокументРегистратор5 КАК Док ГДЕ Док.Ссылка = МойРегистр.Регистратор И Док.Дата>&Дата
    ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1 ИЗ Документ.ДокументРегистратор6 КАК Док ГДЕ Док.Ссылка = МойРегистр.Регистратор И Док.Дата>&Дата
    ОБЪЕДИНИТЬ ВСЕ …….
    ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1 ИЗ Документ.ДокументРегистраторN КАК Док ГДЕ Док.Ссылка = МойРегистр.Регистратор И Док.Дата>&Дата)
    

    Показать

    Но потом править эту «прелесть» — проще застрелиться сразу. А когда таких запросов 500 в конфигурации?

    Reply ↓
64. mikhailovaew 20.05.2013 at 20:24

    (64) согласна, запрос душераздирающий.
    
    спасибо за ответ )

    Reply ↓
65. slazzy 23.05.2013 at 15:13

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

    Подскажите, где и вообще что можно читать в подобной тематике для начинающего программиста, который таки хочет стать хорошим программистом? ) есть ли вообще подобная литература/статьи, или единственный выход это исследовать самому?(ну помимо статей, которые есть на инфостарте)

    Reply ↓
66. speshuric 23.05.2013 at 16:32

    (65) Вон, выше «проф. разработку» советуют — в ней вагон информации. Ну и в принципе — ИТС и книги 1С. Остальное — как-то так, самостоятельно.

    Reply ↓
67. Ish_2 18.06.2013 at 09:02

    (60) Ты написал :
    
    «3.2. во временной таблице ПрайсЛист — нужен индекс по Номенклатура»
    
    В запросе также используется индексирование временной таблицы «ФильтрПодразделения»
    
    Вопрос : Зачем ?
    
    Оптимизатор запроса сам создаст индекс.
    
    Причем в моих опытах на временных таблицах значительного размера явное индексирование приводило
    
    к некоторому замедлению выполнения запроса как в файловом варианте так и в клиент-серверном.

    Reply ↓
68. speshuric 18.06.2013 at 14:39

    (67) Ish_2,
    
    1. Оптимизатор индекс не строит. Никогда. В лучшем случае добавит операцию «Sort».
    
    2. Но и операция Sort это ни разу не индекс на самом деле. Где-то сортированная выборка лучше обхода индексов (особенно для небольших таблиц), где-то хуже. Важно, что для каждого соединения таблиц скорее всего придётся серверу сортировать отдельной операцией с отдельными затратами.
    
    3. Сервер совсем не всегда правильно догадывается о том, нужно сортировать или не нужно. Индекс на ВТ — «прозрачный намёк» (я намёки жены примерно также понимаю: когда мусорный пакет она мне даёт в руки, тогда я его и выношу).
    
    4. И, да, индексирование не бесплатное. Но если утверждается, что у запроса план кривой и запрос долго выполняется, то для относительно мелкой ВТ можно и проиндексировать исходя из последующих сортировок/отборов/соединений — хуже скорее всего не станет.
    
    5. За файловый ничего говорить не буду. Я в нём никто, и не представляю как там ВТ сделаны.

    Reply ↓
69. Ish_2 18.06.2013 at 15:46

    (68) «Оптимизатор индекс не строит. Никогда. В лучшем случае добавит операцию «Sort». »
    
    
    
    Отлично. Рассматриваем клиент-сервер.
    
    1. Я сделал запросом временную таблицу ВРЕМ1 из двух-трех полей с уникальным полем «Ключ» ( скажем, 1 000 000 записей ). Индекс не строю.
    
    Аналогичным запросом получаю таблицу ВРЕМ2. Индекс для ВРЕМ2 также не строю.
    
    Затем делаю соединение двух таблиц по полю «КЛЮЧ» и вывожу результат. Засекаю время TIME1.

    2. Повторяю п1. Но для каждой из временных таблиц ВРЕМ1 и ВРЕМ2 указываю «ИНДЕКСИРОВАТЬ по КЛЮЧ».
    
    Засекаю время TIME2.

    Повторить эксперимент легко. Поэтому я утверждаю TIME1< TIME2 как минимум в два раза.
    
    Если ты подтвердишь этот факт , то тогда вопросы :

    1. почему явное индексирование временных таблиц приводит к резкому замедлению ?
    
    2. кто же индексирует ВРЕМ1 и ВРЕМ2 перед соединением ?

    Reply ↓
70. Ish_2 18.06.2013 at 16:20

    На всякий случай реальный текст запроса для п.1.
    
    В нем закомментирована опция «Индексировать по » .
    
    ВРЕМ1 и ВРЕМ2 отсортированы по разным полям.
    

    ВЫБРАТЬ ПЕРВЫЕ 500000
    ОП_ФинансовыеТранзакцииОпера.Ссылка,
    ОП_ФинансовыеТранзакцииОпера.НомерБрони,
    ОП_ФинансовыеТранзакцииОпера.КодУслуги
    ПОМЕСТИТЬ Врем1
    ИЗ
    Документ.ОП_ФинансовыеТранзакцииОпера КАК ОП_ФинансовыеТранзакцииОпера
    
    УПОРЯДОЧИТЬ ПО
    ОП_ФинансовыеТранзакцииОпера.НомерБрони
    // Индексировать по ОП_ФинансовыеТранзакцииОпера.Ссылка
    ;
    
    ////////////////////////////////////////////////////////////­////////////////////
    ВЫБРАТЬ ПЕРВЫЕ 500000
    ОП_ФинансовыеТранзакцииОпера.Ссылка,
    ОП_ФинансовыеТранзакцииОпера.НомерБрони,
    ОП_ФинансовыеТранзакцииОпера.КодУслуги
    ПОМЕСТИТЬ Врем2
    ИЗ
    Документ.ОП_ФинансовыеТранзакцииОпера КАК ОП_ФинансовыеТранзакцииОпера
    
    УПОРЯДОЧИТЬ ПО
    ОП_ФинансовыеТранзакцииОпера.КодУслуги
    //Индексировать по ОП_ФинансовыеТранзакцииОпера.Ссылка
    ;
    
    ////////////////////////////////////////////////////////////­////////////////////
    ВЫБРАТЬ
    Врем1.Ссылка,
    Врем1.НомерБрони,
    Врем1.КодУслуги,
    Врем2.Ссылка КАК Ссылка1,
    Врем1.НомерБрони как НомерБрони1,
    Врем1.КодУслуги  как КодУслуги1
    ИЗ
    Врем1 КАК Врем1
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ Врем2 КАК Врем2
    ПО Врем1.Ссылка = Врем2.Ссылка

    Показать

    Reply ↓
71. speshuric 19.06.2013 at 00:27

    Reply ↓
72. Ish_2 19.06.2013 at 11:16

    (71) По порядку. Рассматриваем запрос из (70).
    
    В твоем эксперименте с 8.3. при отсутствии индексации ВТ ты получил выигрыш во времени очень
    
    небольшой 15-20%. У меня же выигрыш по времени 100% ( т.е в 2 раза).
    
    Причем , разумеется , у меня запуск для (70) проводился многократно , эксперимент проводился в разных организациях в разные годы на 8.2. Тут нужен кто-то третий кто бы нас рассудил.
    
    Но мы сейчас оттолкнемся от результатов твоего эксперимента.
    
    1. Согласен ли ты с тем , что для конкретных примеров (60) индексировать таблицы «ФильтрНоменклатура»
    
    и «ФильтрПодразделения» и в (70) таблицы ВРЕМ1 и ВРЕМ2 НЕ нужно (причем без всяких оговорок) ?
    
    2. К сожалению ( а может быть и к счастью), никогда не открывал профалер.
    
    Тем не менее : кто же индексирует ВРЕМ1 и ВРЕМ2 в (70) перед соединением , если они не проиндексированы ?
    
    Ты пишешь , что НИКТО.
    
    Тогда совершенно непонятен механизм соединения двух таблиц в MSSQL без использования
    
    индексов. Это как ?
    
    Скажем, получение первой записи результирующей таблицы соединения происходит таким образом :
    
    Берем первую запись ВРЕМ1 , тупо сканируем таблицу ВРЕМ2 по значению ВРЕМ1.Ссылка, находим , выводим.
    
    И так далее для второй , третьей записи .. из ВРЕМ1.
    
    Так ?

    Reply ↓
73. speshuric 19.06.2013 at 18:31

    (72) Ish_2,
    
    1. Согласен ли ты с тем , что для конкретных примеров (60) индексировать таблицы «ФильтрНоменклатура»
    
    и «ФильтрПодразделения» и в (70) таблицы ВРЕМ1 и ВРЕМ2 НЕ нужно (причем без всяких оговорок) ?
    
    Нет. Могу показать, но на выходных. Если «запрос тормозит» из-за некорректного плана, то индексирование ВТ вряд ли ухудшит его. В данном случае по (60) я вообще сразу написал, что без доп. данных всё это будет гаданием на кофейной гуще.
    
    И еще раз обращу внимание. Сравнивать просто время — не вполне корректно.
    
    2. К сожалению ( а может быть и к счастью), никогда не открывал профалер.
    
    Ну профайлер я использовал только потому что терять время на запуск ТЖ (минута же!) было лень и показывает профайлер в целом больше, поэтому я его чаще использую. Время, запросы, планы можно было и из ТЖ взять. Профайлером, кстати, пользоваться очень просто. Могу научить 🙂
    
    Тогда совершенно непонятен механизм соединения двух таблиц в MSSQL без использования индексов.
    
    Настройка запроса — отличное место для начала. На русском. Про джойны, например, раздел «Дополнительные понятия настройки запросов». Если кратко: есть 3 вида джойнов (hash, merge, nested loops), в зависимости от ситуации оптимизатор использует каждый из них.
    
    Если надо в большом индексированном (упорядоченном) списке найти мало записей, то nested loops («вложенные циклы»).
    
    Если надо соединить 2 одинаково упорядоченных набора, то merge.
    
    В большинстве других случаев это будет hash join, которых тоже есть несколько видов. Hash join целиком или частями, в памяти или не совсем в памяти строит хэш-таблицу одного из наборов, а вторым набором идёт по хешам.
    
    Вариант Берем первую запись ВРЕМ1 , тупо сканируем таблицу ВРЕМ2 по значению ВРЕМ1.Ссылка, находим , выводим.
    
    И так далее для второй , третьей записи .. из ВРЕМ1. будет использоваться для очень маленьких временных таблиц или если оптимизатор профакапится и примет решение использовать nested loops там, где нужен был hash join.

    Reply ↓
74. Ish_2 20.06.2013 at 08:53

    (73) Почему на выходных ? Не пойму .
    
    Ты работаешь что ли ?

    Оттолкнемся от факта. Ты и я убедились в том , что для конкретного примера (70) индексация ВТ не нужна.
    
    Отсюда я делаю вывод , что индексация ВТ по ключевому полю НЕ нужна при условии, что в дальнейшем ВТ используется однократно ( фильтр или соединение).
    
    Если ты с этим не согласен, то приведи контрпример (текст запроса) , чтобы я проверил и убедился
    
    в обоснованности твоего несогласия.

    За «Настройку запроса» спасибо. Как далеко ушла техника .. пока я не открывал профайлер.

    Добавлено :
    
    Текст в (70) исправил «по-твоему» : последний запрос поместил в таблицу ВРЕМ3.
    
    И тогда TIME1 ( время без индексации) меньше TIME2 ( время с индексацией) в ~ 3 раза.

    Reply ↓
75. Al-X 20.06.2013 at 10:39

    Спасибо автору, статья СУПЕР !!! Эт скока же запросов мне надо просмотреть ?!!! Самое обидное, буквально вчера я в отчете использовал составные типы через точку в условии 🙁 .
    
    Мда… думаю я еще долго буду перечитывать статью и оптимизировать свои запросы.
    
    Еще раз спасибо за статью !!!

    Reply ↓
76. speshuric 20.06.2013 at 14:34

    (74) Ish_2, Посмотрел. В 8.1.15 и 8.2.16 индексы создаются отдельной командой CREATE INDEX, примерно так
    

    SELECT TOP 0 CAST(0 AS NUMERIC(38,8)) _Q_001_F_000,
    CAST(0 AS NUMERIC(38,8)) _Q_001_F_001
    INTO #tt1
    
    INSERT INTO #tt1
    (_Q_001_F_000, _Q_001_F_001)
    SELECT
    ….
    
    CREATE INDEX TmpInd1 ON #tt1 (
    _Q_001_F_000)

    Показать

    Отсюда и 2 раза. В 8.3.3 и вроде в последних 8.2 — заранее создаётся индекс (и вставка тупит лишь минимально).

    Reply ↓
77. Ish_2 20.06.2013 at 15:38

    (76) Вот и выяснили расхождения в результатах.
    
    Тем не менее , если представишь контрпример (74) будет совсем всё ясно.

    P.S. Ну , на выходных , конечно.

    Reply ↓
78. speshuric 20.06.2013 at 16:10

    (74) Да уж, посмотрел, как ВТ работают в 8.1.15 и 8.2.16, там действительно надо постараться для того, чтобы индексы заработали.
    
    Итого:
    
    1. Индексы создаются отдельной командой. После вставки. Это достаточно существенные затраты (для таблицы в 16 млн записей — создание индексов в 4-6 раз дороже самой вставки)
    
    2. В 8.2.16 создаются некластеризованные индексы. С одной стороны это хорошо, создание индексов не требует перелопачивания страниц данных, с другой — если индекс содержит не все строки таблицы, то почти гарантированно будет достаточно дорогой RID Lookup. То есть в индекс ВТ нужно запихивать ВСЕ колонки, которые потом могут быть использованы в запросах.

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

    Запрос, который у меня и для однократного использования индекса показывает нужность индекса:
    

    ВЫБРАТЬ 0 КАК Знч, 2 КАК База ПОМЕСТИТЬ Уровень0
    ОБЪЕДИНИТЬ ВСЕ ВЫБРАТЬ 1, 2;
    ВЫБРАТЬ
    Таб1.Знч + Таб1.База * Таб2.Знч КАК Знч,
    Таб1.База * Таб1.База КАК База
    ПОМЕСТИТЬ Уровень1
    ИЗ Уровень0 КАК Таб1, Уровень0 КАК Таб2;
    ВЫБРАТЬ
    Таб1.Знч + Таб1.База * Таб2.Знч КАК Знч,
    Таб1.База * Таб1.База КАК База
    ПОМЕСТИТЬ Уровень2
    ИЗ Уровень1 КАК Таб1, Уровень1 КАК Таб2;
    ВЫБРАТЬ
    Таб1.Знч + Таб1.База * Таб2.Знч КАК Знч,
    Таб1.База * Таб1.База КАК База
    ПОМЕСТИТЬ Уровень3
    ИЗ Уровень2 КАК Таб1, Уровень2 КАК Таб2;
    ВЫБРАТЬ
    Таб1.Знч + Таб1.База * Таб2.Знч КАК Знч,
    Таб1.База * Таб1.База КАК База
    ПОМЕСТИТЬ Уровень4
    ИЗ Уровень3 КАК Таб1, Уровень3 КАК Таб2;
    ВЫБРАТЬ
    Таб1.Знч + Таб1.База * Таб2.Знч КАК Знч,
    Таб1.База * Таб1.База КАК База
    ПОМЕСТИТЬ Уровень5
    ИЗ Уровень4 КАК Таб1, Уровень3 КАК Таб2
    ИНДЕКСИРОВАТЬ ПО Знч, База //вот этот индекс
    ;
    ВЫБРАТЬ Таб1.Знч КАК Знч, Таб1.Знч * 2 КАК Знч2
    ПОМЕСТИТЬ Уровень31
    ИЗ Уровень3 КАК Таб1;
    ВЫБРАТЬ
    Таб1.Знч,
    Таб1.База,
    Таб2.Знч КАК Знч1,
    Таб2.Знч2 КАК Знч2
    ИЗ
    Уровень5 КАК Таб1
    ВНУТРЕННЕЕ СОЕДИНЕНИЕ Уровень31 КАК Таб2
    ПО (Таб1.Знч МЕЖДУ Таб2.Знч И Таб2.Знч2)

    Показать

    Суммарно с индексом у меня делалось около 65 сек, а без индексов — 88

    Reply ↓
79. Ish_2 20.06.2013 at 18:54

    (78) Релиз 8.2.18.61. Твой запрос (78) скопирован в КонсольЗапросов.
    
    Время без индексирования 75 сек. ( сред.время 2 и 3 запуска)
    
    Время с индексированием 170 сек ( сред.время 2 и 3 запуска).

    Здесь всё понятно .
    
    И мы понимаем , что время без индексирования меньше всего лишь из-за кривости релиза 8.2.
    
    Но нас-то интересовал принцип ,
    
    т.е. нужно было в принципе добиться чтобы время с индексированием было меньше.
    
    И ты этого добился при использовании «некривого» 8.3.

    Дело тут , надо думать, в сложности выражения соединения ( у тебя «Таб1.Знч МЕЖДУ Таб2.Знч И Таб2.Знч2»)
    
    Здесь получаем , что преимущества индексированной таблицы становятся очевидными.
    
    В (70) же использовалось «слишком» простое условие «Врем1.Ссылка = Врем2.Ссылка».
    
    Ок. Спасибо !

    Reply ↓
80. speshuric 20.06.2013 at 19:16

    (79) тест запускал на чем? В смысле: какая версия скуля и что там с памятью и дисками? Типа могу подогнать, теперь уже понятно как. Там вопрос не в сложности выражения, а в том, что без индексов «МЕЖДУ Таб2.Знч И Таб2.Знч2» приводит к жестокому соединению с обходом по декартову произведению, а с индексами лишь выгребания небольших диапазонов. Остаётся лишь подобрать размеры таблиц. Как несложно заметить, тут индексированная таблица достаточно жирная.

    Reply ↓
81. Ish_2 20.06.2013 at 23:58

    (80)
    
    1. Сам я не очень-то .. Завтра спрошу у наших сисадминов.
    
    2. «Там вопрос не в сложности выражения, а в том, что без индексов «МЕЖДУ Таб2.Знч И Таб2.Знч2″ приводит к жестокому соединению с обходом по декартову произведению, а с индексами лишь выгребания небольших диапазонов.»
    
    Ну, да. Это и имелось ввиду.
    
    В случае усложнения ( добавления новых условий) резко увеличивается объем пробега для этой самой «hash join».

    Reply ↓
82. Ish_2 21.06.2013 at 00:48

    «А осадочек остался…».

    Дело в том , что я ни секунды не сомневался оптимизатор запроса сам строит необходимые индексы ( пусть даже некие «временные» , «виртуальные»)- если нужно ,после анализа условий соединения или фильтраций.
    
    Фразу «не индексируйте временные таблицы при однократном последующем использовании» я помню «со школы».
    
    Ведь еще при царе Горохе старые СУБД именно так создавали недостающие индексы — насколько помню.
    
    В последнем твоем примере необходимость создания недостающего индекса также очевидна.

    И тут на тебе : MSSQL этого не делает.
    
    Неужто трудно проанализировать выражение соединения и создать индекс ?
    
    А ORacle и прочие ?

    Reply ↓
83. Ish_2 21.06.2013 at 10:54

    (80)»тест запускал на чем? В смысле: какая версия скуля и что там с памятью и дисками? »
    
    Кластер серверов MSSQL
    
    ОС Windows Server 2008 R2 Enterprise
    
    Процессор X5675 3.07 GHz (2 шт)
    
    ОЗУ 32 Гб
    
    СХД EMC ( я спросил про диски , а мне сказали , что СХД — это система хранения данных)
    
    Microsoft SQL Server Standard Edition (64-bit) 10.50.1617.0

    Reply ↓
84. hogik 22.06.2013 at 01:11

    (82)
    
    «»не индексируйте временные таблицы при однократном последующем использовании» я помню «со школы».»(с)
    
    Игорь (Ish_2).
    
    Помнить мало, надо еще понимать. 😉
    
    Эта фраза относится к другому случаю — если «однократно» применяется запрос выборки записей из таблицы. Т.к. при индексировании выполняется полный просмотр всех записей таблицы. Плюс, затраты на построение самого индекса. А потом еще запрос будет просматривать N-ое количество записей. Т.е. быстрее будет работать сразу запрос без (вместо) предварительного индексирования.
    
    Вроде, это так очевидно? Даже, я это смог понять… 😉

    Reply ↓
85. Ish_2 22.06.2013 at 12:18

    (84) Дело прошлое , догадки — дело скользкое. Кто там что понял ,а что — нет..
    
    Пока ясно одно , MSSQL сам не создает недостающие индексы.
    
    Вчера возмущенный этим фактом я написал в MS. Жду вот.
    
    Думаю , к осени поправят.
    
    Как считаете ?

    Reply ↓
86. hogik 22.06.2013 at 16:08

    (85)
    
    «… к осени поправят … ?»(с)
    
    Игорь (Ish_2).
    
    Нет. Но, включат в планы для «MS SQL 2021».

    Reply ↓
87. MrFlanker 25.12.2013 at 18:56

    Отличная статья, прочитал на одном дыхании

    Reply ↓
88. Bukaska 26.12.2013 at 23:27

    Отличная статья! Много интересного…

    Reply ↓
89. agrustny 26.04.2014 at 01:01

    Это замечательная великолепная статья, я Вас недавно рекламировал!

    Reply ↓
90. Збянтэжаны Саўка 05.11.2014 at 12:07

    ух-ты какая шикарная статья!!!
    
    я в шоке — она меня просто потрясла!!!
    
    спасибо!

    Reply ↓
91. Ndochp 05.02.2015 at 11:20

    (49) Вот ты не пожалел своего времени, так как оно дешевле простоя предприятия и переписал по всей конфе в 100500 местах на «оптимальное» решение с ручным объединением всего и вся.
    
    А потом кто-то сделал движение корректировкой записи регистров, про которую ты забыл. Или у этого регистра добавился регистратор. Какова вероятность, что ты поправишь не в 100500 местах, а в 100499, и предприятие не останавливаясь продолжит работать с неверными данными?
    
    И не больше ли это убытков принесет?

    Reply ↓
92. It-developer 11.09.2015 at 11:07

    На 8.3.5.1383 на файловой версии проверял размеры строк.
    
    Заполнял таблицы под завязку, т.е. 4,2 Гб на внутренние таблицы.
    
    Состав данных — 2 поля:
    
    Поле1 (9 символов),
    
    Поле2 (40 символов)
    
    везде убрал индексирование (хотя к нашей таблице это не имеет значения) и полнотекстовый поиск.
    
    Смотрел внутренние таблицы Tool_1CD.exe
    
    В итоге результаты:
    
    1) Справочник с реквизитами — Поле1, Поле2. Обе строки — переменной длины 4,265,631,632 байт — размер таблицы, 28,063,365 — кол-во элементов в справочнике, т.е. 152 байта на 1 элемент
    
    По принципу, описываемому автором для строк
    
    40x+у+9x+y=152 => 49x + 2y = 152
    
    X = 2, y =(152-49*2)/2=27
    
    X = 3, y =(152-49*3)/2=2.5
    
    Думаю, правильно будет X = 3, y = 3 (?)
    
    ——
    
    2) Для строк фиксированной длины результаты приблизительно те же. 4,265,631,600 байт — размер таблицы 28,437,543 — кол-во элементов, 150 Байт на 1 элемент
    
    похоже тоже на x = 3, y = 0-3
    
    ——
    
    3) Справочник с табличной частью — Поле1, Поле2. Строки переменной длины. 4,265,630,586 — размер таблицы, 33,854,210 — элементов, 126 Байт на 1 элемент
    
    результаты уже другие!
    
    49х+2y=126
    
    X = 2, y = (126-49*2) /2=14
    
    X = 3, y = (126-49*3)/2 = -10.5
    
    Не понятно в общем, но похоже на 2 байта+y. И, скорее всего, нужно какое-то количество байт на всю строку
    
    —-
    
    Мои результаты:
    
    на реквизиты с типом Строка приходится 3 байта на символ + 3,
    
    на реквизиты в табличных частях с типом Строка, я не уверен в результатах, но, скорее всего,
    
    это {2 байта на символ + y байт} (на реквизит) и какое-то количество байт на всю строку

    Reply ↓
93. speshuric 11.09.2015 at 12:57

    (92) It-developer,
    
    Эммм. Извините, очень странное исследование.
    
    Во-первых, данные хранятся, если верить статье блоками по 4 КБ. Т.е. не может на странице храниться часть записи. Так что всё что мы знаем достоверно, что в 4 КБ влезает 27 записей (28 не влезает, 26 — остаётся лишнее). Т.е. запись может быть 146-152 байта.
    
    Во-вторых, есть служебные поля. Минимум для справочника _IDRRef (16 байт в SQL), _Marked (1 байт в SQL), _IsMetadata (1 байт в SQL), _Version (8 байт в SQL). Уточнить можно через ПолучитьСтруктуруХраненияБазыДанных. Если есть Код, Наименование, Группы — то это еще поля. Т.е. даже если вы вы код, наименование занулили и запретили иерархию, то 26 байт тут минимум дополнительных. Обязательно посмотрите для тестируемых таблиц ПолучитьСтруктуруХраненияБазыДанных — это же сразу покажет, какие там еще поля есть.
    
    В-третьих, как именно хранится одна запись в файловой БД я не в курсе, если она хранится в типичном для 1С формате с фигурными скобками, запятыми, кавычками и т.п, то на это тоже нужно место (не менее 10 байт). Но тут я дуб, потому что файловые базы не использую (если честно, то и 1С я открываю сейчас раз-два в месяц, наверное).
    
    В-четвёртых, по _IDRRef (как минимум) индекс будет ВСЕГДА (но это действительно не важно для вашего исследования).

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

    Показывать буду на примере MS SQL Server

    В других СУБД структура схожа, но не до байтов, разумеется.

    В общем, я не понял что исследовалось. Строки в 1С с двухбайтными буквами — это вряд ли где-то отличается. Дополнительные поля не учтены. Страницы не учтены. Дополнительные расходы из этих данных считать нельзя.

    Reply ↓
94. It-developer 11.09.2015 at 16:28

    (93) Спасибо!
    
    Я не учёл _IDRRef (16 байт в SQL), _Marked (1 байт в SQL), _Version (8 байт в SQL) 🙁
    
    _IsMetadata (1 байт в SQL) там нет, но есть пустое _PredefenedID
    
    В общем 16+1+8 = 25 байт.
    
    Т.е. в итоге 2 байта на символ строки 🙂
    
    Моя цель исследования была понять сколько можно запихнуть данных в файловую версию в справочник 🙂
    
    В итоге недосчитался и поэтому написал на форуме 🙂
    
    Понятно, что все в основном пользуются SQL, но бывают разные исключения.
    
    К составным типам да, мои тесты отношения не имеют

    Вообще мне Ваша статья понравилась. Я ранее ее использовал в работе

    Reply ↓
95. speshuric 11.09.2015 at 16:55

    (94) It-developer,
    
    Ну тогда всегда пожалуйста. Жаль, конечно, что для 1С нет аналога такой статьи, по которой можно достаточно точно определить сайзинг.

    Reply ↓
96. speshuric 23.08.2016 at 00:10

    (96) Sergey.Noskov,
    
    Ну дай дураку рекомендацию, он и руки порежет и рекомендацию извратит.

    Reply ↓