Планы запросов - это просто!

Публикация № 643479

Администрирование - Производительность и оптимизация (HighLoad)

план запроса оптимизация

315
Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"? В данной статье я не дам вам исчерпывающих инструкций по чтению планов запроса. Но я постараюсь объяснить доходчиво - что это такое и с какой стороны к ним подойти.

Введение

Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"?

После чего 1С-ник идет на форум, а там ему говорят - надо смотреть план запроса. Он смотрит, и ничего не понимая, навсегда забрасывает идею оптимизации запросов через планы, продолжая сравнивать варианты простым замером производительности.

В результате, на машине разработчика запрос начинает просто летать, а затем в боевой базе при увеличении количества записей все умирает и начинаются жалобы в стиле "1С тормозит". Знакомая картинка, не правда ли?

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

Более того, я не считаю себя хорошим оптимизатором запросов, поэтому, в статье весьма вероятны фактологические косяки. Ну тут пусть гуру меня поправят в каментах. На то мы тут и сообщество, чтобы помогать друг-другу, верно? 

Если вы уже умеете читать планы запросов, то, наверное, стоит пропустить статью. Тут будет самое простое и с начала начал. Статья ориентирована на тех разработчиков, которые пока еще не выяснили, что это за зверь - план запроса.

Как работает компьютер

А начну я издалека. Дело в том, что компьютеры, к которым мы привыкли, они не такие уж и умные. Вы же наверняка помните первые уроки информатики, или младшие курсы ВУЗа? Помните сортировку массивов пузырьком там, или чтение файла построчно? Так вот, принципиально нового ничего не изобретено в современных реляционных СУБД. 

Если на лабораторках вы считывали строчки из файла, а потом записывали их в другое место, то вы уже примерно представляете, как работает современная СУБД. Да, разумеется, там все намного (совсем намного) сложнее, но - циклы они и в Африке циклы, чтение диска все еще не стало быстрее чтения ОЗУ, а алгоритмы O(N) все еще медленнее алгоритмов O(1) при увеличении N. 

Давайте представим, что к вам, простому 1С-нику пришел человек и говорит: "смотри, дружище, надо написать базу данных. Вот тут файл, в нем строчки какие-нибудь пиши. А потом оттуда читай". Представим, что отказаться вы не можете. Как бы вы решали эту задачу? 

А решали бы вы ее точно так же, как решают ее ребята из Microsoft, Oracle, Postgres и 1С. Вы бы открыли файл средствами вашего языка программирования, прочитали бы оттуда строки и вывели бы их на экран. Никаких принципиально отличных алгоритмов, от тех, что я уже описал - мир не придумал. 

Представьте, что у вас есть 2 файла. В одном записаны контрагенты, а в другом - договоры контрагентов. Как бы вы реализовывали операцию ВНУТРЕННЕЕ СОЕДИНЕНИЕ? Вот прямо в лоб, без каких-либо оптимизаций? 

Контрагенты

ID

Имя

1

Петров

2

Иванов

3

Сидоров

 

Договоры

ID

IDКонтрагента

НомерДоговора

1

1

ИК-1002399

2

1

БМ-0010/УУ

3

2

Счет 09200

 

Давайте сейчас для простоты опустим нюансы открывания файлов и чтения в память. Сосредоточимся на операции соединения. Как бы вы его делали? Я бы делал так:

Для Каждого СтрокаКонтрагент Из Контрагенты Цикл
    Для Каждого СтрокаДоговор Из Договоры Цикл
        Если СтрокаДоговор.IDКонтрагента = СтрокаКонтрагент.ID Тогда
            ВывестиРезультатСоединения(СтрокаКонтрагент, СтрокаДоговор);
        КонецЕсли;
    КонецЦикла;
КонецЦикла;
 

В примере ф-я ВывестиРезультатСоединения просто выведет на экран все колонки из переданных строк. Ее код здесь не существенен. 

Итак, мы видим два вложенных цикла. Внешний по одной таблице, а потом во внутреннем - поиск ключа из внешней простым перебором. А теперь, внезапно, если вы откроете план какого-нибудь запроса с СОЕДИНЕНИЕМ в любой из 1С-ных СУБД, то с довольно высокой вероятностью увидите там конструкцию "Nested Loops". Если перевести это с языка вероятного противника на наш, то получится "Вложенные циклы". То есть, в "плане запроса" СУБД вам объясняет, что вот тут, для "соединения" она применила алгоритм, описанный выше. Этот алгоритм способен написать любой школьник примерно 7-го класса. И мощные боевые СУБД мирового уровня применяют этот алгоритм совершенно спокойно. Ибо в некоторых ситуациях - он лучшее, что есть вообще. 

И вообще, чего это я сразу с "соединения" начал. Давайте предположим, что вам нужно просто найти контрагента по наименованию. Как бы вы решали эту задачу? Вот есть у вас файл с контрагентами. Напишите алгоритм. Я напишу его вот так:

Для Каждого СтрокаКонтрагент Из Контрагенты Цикл
    Если СтрокаКонтрагент.Имя = "Иванов" Тогда
        ВывестиРезультат(СтрокаКонтрагент);
    КонецЕсли;
КонецЦикла;

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

Индексы

А как же мы можем ускорить поиск данных в таблице? Ну правда, всё время пересматривать всё - это же зло какое-то.  

Вспомним картотеку в поликлинике или библиотеке. Как там выполняется поиск по фамилии клиента? В деревянных шкафчиках стоят аккуратные карточки с буквами от А до Я. И пациент "Пупкин" находится в шкафчике с карточкой "П". Просматривать подряд все прочие буквы нет необходимости. Если мы отсортируем данные в нашей таблице и будем знать, где у нас (под какими номерами строк) находятся записи на букву "П", то мы существенно приблизимся к быстродействию тетеньки из регистратуры. А это уже лучше, чем полный перебор, не так ли?  

Так вот, слово "Индекс" в данном контексте означает (опять же, в переводе с языка вероятного противника) "Оглавление". Чтобы быстро найти главу в книге, вы идете в оглавление, находите там название главы, потом смотрите номер страницы и идёте сразу на эту страницу. 

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

В виде кода это может выглядеть примерно так:  

Индекс = Новый Соответствие;

// бла-бла

НомерЗаписи = Индекс["Иванов"]
ВывестиРезультат(ТаблицаКонтрагентов[НомерЗаписи]);

Известно, что чудес не бывает, поэтому, память под Соответствие "Индекс", а также поиск в самом соответствии - это небесплатные операции. Но они намного дешевле, чем прямой перебор всех данных. Ах, да, это Соответствие придется постоянно поддерживать в актуальном состоянии при добавлении или изменении основных данных. 

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

Вспомним, как вообще ведется запись в файл. 

fseek(file, position); // переход к нужному адресу
write(file, dataArray, dataLength); // запись dataLength байт из массива dataArray

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

Вернемся к индексу. Пользователь хочет вставить что-то в середину. Хочешь не хочешь, а придется двигать данные, либо исхитряться с хранением данных в "страницах", связанных между собой в список. Физически писать в конец, или в пустое место, но как будто в середину таблицы. И потом еще обновлять в оглавлении номера записей. Они же теперь сдвинулись и индекс показывает не туда куда нужно. Вы, наверное, слышали, что индексы в БД ускоряют поиск, но замедляют вставку и удаление. Теперь, вы знаете, почему это так. 

Ну так вот, мы еще не решили проблему поиска по разным полям. Мы же не можем хранить данные в файле в разном порядке. Одному пользователю по имени, а другому, скажем - по дате. Причем одновременно. Как бы вы решали эту задачу? По-моему, решение очевидно - нужно хранить отдельно данные и отдельно оглавления, отсортированные по нужным полям. Т.е. в базе данные лежат, как придется, но рядышком мы создадим файлик, где записи отсортированы по имени. Это будет индекс по полю "Имя". А еще рядышком будет другой такой же файлик, но отсортированный по полю "Дата". Для экономии места мы будем хранить в индексах не все колонки основной таблицы, а только те, по которым выполнена сортировка (чтобы быстро тут искать, находить номер записи и моментально прыгать к ней, чтоб прочитать остальные данные).

Ребята, которые пишут взрослые СУБД тоже не придумали ничего лучше. Индексы в БД устроены именно так. Все данные из таблицы лежат отсортированными рядышком в отдельной сущности. По сути, индекс, это просто еще одна таблица. И места она занимает пропорционально размеру основной таблицы, что логично. Да, там еще есть разные ухищрения, типа сбалансированных деревьев и всякого такого, но смысл не сильно меняется. 

Кстати, если записывать данные в основную таблицу сразу упорядоченными, то можно не делать отдельно хранимый индекс и считать индексом саму таблицу с данными. Здорово, правда? Такой индекс называют "кластерным". Логично, что поле, по которому отсортированы записи в таблице должно стараться монотонно нарастать. Вы же помните про вставку в середину, верно?

Планирование выполнения запроса

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

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

Вот тут уже я бы не стал браться за работу по написанию планировщика, не защитив предварительно диссертацию. Как он там работает и как умудряется делать это вполне сносно - не знаю. Поэтому, ограничимся документацией СУБД. Из нее следует, что на основании статистики планировщик строит несколько возможных вариантов пошагового выполнения запроса, а потом выбирает из них наиболее подходящий. Например, первый попавшийся. Тоже ведь эвристика, разве нет? 

"Что мне сделать сначала" - думает планировщик: "обойти всю таблицу А, отобрав записи по условию, а потом соединить с таблицей Б вложенными циклами, или же найти индексом все подходящие записи таблицы Б, а уже потом пробежаться по таблице А"? Каждый из шагов имеет определенный вес или стоимость. Чем больше стоимость, тем сложнее выполнять. В плане запросов всегда написана стоимость каждого из шагов, которые выполнил движок СУБД, чтобы собрать результаты запроса.

Устройство оператора плана

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

interface IQueryOperator {
    DataRow GetNextRow();
}

для тех кто не понял, что тут написано, поясню. Каждый оператор плана запросов имеет метод "ДайСледующуюЗапись". Движок СУБД дергает оператор за этот метод и при каждом таком дергании добавляет полученную запись к результату запроса. Например, оператор фильтрации записей на входе имеет всю таблицу, а на выходе - только те, которые удовлетворяют условию. Далее, выход этого оператора подается на оператор, например, ПЕРВЫЕ 100, а далее на оператор агрегации (СУММА или КОЛИЧЕСТВО), которые точно так же, внутри инкапсулируют всю обработку, а на выход выдают запись с результатом.

Схематично это выглядит так:

ВсеДанные ->Фильтр(Имя="Петров")->Первые(100)->Аггрегация(КОЛИЧЕСТВО)

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

Каждый оператор имеет некие параметры: количество обработанных записей, стоимость, количество операций ввода/вывода, использование кэшей и прочее и прочее. Все это позволяет судить об эффективности выполнения запроса. Scan таблицы, пробежавший миллион записей и выдавший две на выходе - это не очень хороший план запроса. Но лучше планировщик ничего не нашел. У него не было индекса, чтобы поискать в нем. А может, наврала статистика и сказала, что в таблице три записи, а на самом деле туда успели написать миллион штук, но статистику не обновили. Все это предмет для разбирательства инженером, который изучает запрос.

План запроса - это пошаговый отладчик запроса. Вы пошагово смотрите, что именно, какой алгоритм (в буквальном смысле) применила СУБД, чтобы выдать результат. Примеры самих алгоритмов вы видели - они чрезвычайно сложны, ведь там есть циклы и условия. Даже порой несколько циклов вложены, вот ведь ужас. Важно понимать, какие процессы происходят внутри каждого оператора. Какой алгоритм применялся к массиву записей в процессе выполнения и сколько он работал.

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

315

Специальные предложения

Комментарии
Избранное Подписка Сортировка: Древо
1. spezc 599 04.07.17 03:35 Сейчас в теме
В принципе интересно написано)
Manoshkin; +1 Ответить
2. rusmil 182 04.07.17 08:13 Сейчас в теме
Спасибо, написано очень доступно для понимания
frkbvfnjh; Bazil; +2 Ответить
3. DenisCh 04.07.17 08:29 Сейчас в теме
написано живенько, для новичков вполне подойдёт
andron77777; theelectric; Silenser; +3 Ответить
4. vasilev2015 1490 04.07.17 09:14 Сейчас в теме
я тоже пытался раскрыть тему скорости соединений http://infostart.ru/public/534444/
Но что-то пошло не так )))

Надеюсь, Андрею повезет больше. Удачи.
Evil Beaver; +1 Ответить
5. Famza 82 04.07.17 09:27 Сейчас в теме
опять же, в переводе с языка вероятного противника

Зачет!
RussXXX; NN2P; theelectric; herfis; DarkUser; pozdeev-artem; корум; artbear; +8 Ответить
6. asved.ru 36 04.07.17 09:44 Сейчас в теме
Самое главное упущено:

Большая часть операторов плана работает построчно, т.е. для того, чтобы вернуть первую строку, им достаточно получить от нижестоящего оператора одну строку, подходящую по условиям.
Однако некоторым операторам для возврата первой строки необходимы все строки, возвращаемые предыдущим оператором. Это Sort (Что логично, пока мы не получим последнюю строку, мы не можем завершить сортировку), это для одного из наборов строк - Hash join и т.п.

Т.е. когда мы видим оператор Sort в запросе динамического списка - можно начинать ругаться не глядя :)
В последних версиях платформы, кстати, добавили ограничение на использование полей для сортировки списков. Вот именно по этой причине.
Kinestetik; _LYNX; sulfur17; brr; +4 Ответить
8. Evil Beaver 6397 04.07.17 09:49 Сейчас в теме
(6)отчего же упущено? Написано же: на входе одно множество, на выходе - другое. Сортировка сюда подходит.
16. asved.ru 36 04.07.17 13:42 Сейчас в теме
(8) вопрос в том, сколько строк будет прочитано для получения множества, ограниченного TOP.
7. asved.ru 36 04.07.17 09:45 Сейчас в теме
А вот неплохой доклад по теме:
https://www.youtube.com/watch?v=4yHc8-Idf-w
logarifm; Kinestetik; Zircool; sulfur17; herfis; jif; Evil Beaver; +7 Ответить
9. Новиков 291 04.07.17 10:13 Сейчас в теме
Мне кажется, для 1сника будет интересен также ответ на вопрос: что происходит в субд, когда он жмет F5 (или какую-то другую команду на выполнение) в среде исполнения запроса. По MS SQL такой инфы с нуля я не находил. По PostgreSQL есть шикардосная статья: Путешествие запроса Select через внутренности Постгреса
user811769; _LYNX; sulfur17; artbear; Evil Beaver; +5 Ответить
10. brr 178 04.07.17 10:50 Сейчас в теме
Спасибо, как раз хотел объяснить дочери (4 класс) реляционные базы, она интересовалась, текст как основа подойдет. "Быстродействие тетеньки из регистратуры" это пять.
NN2P; rovenko.n; корум; +3 Ответить
11. swimdog 693 04.07.17 10:55 Сейчас в теме
Статью не читал, но имею сказать по существу) "Наверное, каждый 1С-ник задавался вопросом "что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"?" - лучше чем проверка разных вариантов практически, ничего нет. Один и тот же запрос на разных базах может работать по разному. Например, в одной базе номенклатуры 1000, а в другой 100000. И хорошо работающий запрос из базы с небольшой номенклатурой будет дико тормозить в другой базе. Но если вы не писатель типовых программ или отраслевых решений, то достаточно замеров времени выполнения на вашей конкретной базе. А для понимания работы запросов советую курсы. Они быстрее помогут разобраться новичкам, как писать текст запросов, чем копание в планах запроса. Это совет, но ни в коем случае не отрицательный отзыв на статью!
12. Evil Beaver 6397 04.07.17 11:15 Сейчас в теме
(11)
Статью не читал... хорошо работающий запрос из базы с небольшой номенклатурой будет дико тормозить в другой базе...достаточно замеров времени выполнения...чем копание в планах запроса


Вот это я прямо в рамочку поставлю!
user811769; RFP; mikeA; haereticus; acanta; zarucheisky; sasha777666; Dementor; JohnyDeath; Бубузяка; DeD MustDie; корум; Sergey.Noskov; Новиков; artbear; +15 Ответить
19. swimdog 693 04.07.17 14:49 Сейчас в теме
(12) 1) Идея была в другом. Сначала набрать основу, как правильно писать запросы, а потом лезть внутрь SQL. Набрать основу проще всего: 1) на курсах 2) читая статьи на ИТС или спецресурсах 3) спрашивая на форумах. Поэтому я предложил сначала получить базу на курсах.
2) Я могу предположить, что план запросов в разных базах будет разным, даже в зависимости от наполнения таблиц, статистики и прочего. И план запроса может также ввести в заблуждение, как и замер времени на пустой базе.
3) Для простых случаев не вижу ничего плохого в использовании замера времени. Вот когда замеры вопроса не решают, тогда да. Тогда и КИП лишним не будет.
53. ArchLord42 69 06.10.17 05:15 Сейчас в теме
(11) по секрету вам скажу, изучив планы запроса несколько раз, через какое-то время, вы начнете писать запросы, которые будут одинакого быстро работать в разных базах с первого раза! только тссс...
55. swimdog 693 06.10.17 10:56 Сейчас в теме
(53) Только недавно пришлось разбираться в плане запросов, так как все остальное себя исчерпало. Но то ли я дурак, то ли лыжа не едут)) Ничем мне не помогла портянка запроса в терминах SQL. Да, я увидел, что совсем криминального там ничего нет, но причины зависания запросов я так и не нашел. В результате максимально выкинул все возможное и ограничив оставшееся через "выразить". Тогда запрос начал работать стабильнее.
В общем, пока остался при своем мнении, что план запроса последняя мера. По крайней мере для меня, в сегодняшних реалиях.
56. ArchLord42 69 06.10.17 16:12 Сейчас в теме
(55)
Ну уж ограничить лишние запросы к составному реквизиту это пожалуй "маст хев" для более менее больших, возможно в будущем больших таблиц, тут даже в план не надо лезть :)
А вообще есть в инете много инфы как работать с планом запроса и профайлером, ну и советую курс от Гилева по подготовке к 1с эксперту, сам его проходил, там очень много посвящено работе с планом запроса и как раз много практических примеров.
13. FreeArcher 89 04.07.17 11:49 Сейчас в теме
Я, даже как знакомый с планами запросов, прочитал с удовольствием и открыл для себя даже новое (я например думал что СУБД гораздо умнее).
Вобщем очень хорошо информация ложится в голову с такими простыми примерами.
Автору спасибо!
14. artbear 1164 04.07.17 12:12 Сейчас в теме
(0) Очередная отличная юморная статья от владельца статуэтки Инфостарт :)
wowik; zarucheisky; kuzyara; +3 Ответить
20. Evil Beaver 6397 04.07.17 15:05 Сейчас в теме
(14) это не статуэтка, а параллелепипед )
15. kolya_tlt 11 04.07.17 12:14 Сейчас в теме
Хорошая статья, но кажется не законченной, так как всё равно нет ответа на поставленной вопрос:
"что быстрее, соединение или условие в ГДЕ?" или, например, "сделать вложенный запрос или поставить оператор В()"?
17. asved.ru 36 04.07.17 13:43 Сейчас в теме
(15) Ответа на этот вопрос не существует: сам вопрос поставлен некорректно.
Кстати, в случае достаточно простых условий план для этих вариантов будет один и тот же.
Evil Beaver; +1 Ответить
18. sommid 04.07.17 14:43 Сейчас в теме
спасибо, ждем-с продолжения
21. swimdog 693 04.07.17 15:17 Сейчас в теме
22. starik-2005 1979 04.07.17 15:18 Сейчас в теме
Дочитал до nested loops, пришла мысль, что автор недопонимает, но осилил дочитать до конца, после чего понял, что нужно дочитывать до конца.
Dementor; DeD MustDie; корум; +3 Ответить
23. Evil Beaver 6397 04.07.17 15:52 Сейчас в теме
(22) прочитал комментарий до конца. Два раза, после чего, так и не понял, это была критика или одобрение?
корум; brr; +2 Ответить
24. starik-2005 1979 04.07.17 15:55 Сейчас в теме
(23)
это была критика или одобрение?
Как сказала наш тренер по публичным выступлениям и работе с аудиторией, что если чувства после реплики противоречивые, то однозначно вами манипулируют!
25. HAMMER_59 193 05.07.17 07:05 Сейчас в теме
Какой кошмар написан про индексы, ведь полно статей на инфостарте, где все правильно расписано.
"Пользователь захочет записать в середину индекса" придётся всё двигать? Какой ужас.
Еще в начале статьи написано, что дальше массивов никуда не ушли. А как же STL, как же списки, очереди?
Индексы хранятся в виде бинарных деревьев: во первых хранятся блоками, где заранее предусмотрено место под вставку, во вторых передвинуть блок в дереве не проблема, проблема - сбалансировать дерево.
26. Evil Beaver 6397 05.07.17 07:31 Сейчас в теме
(25) а вам не пришло в голову, что это необходимое упрощение?

Ну и про STL посмеялся, спасибо. На дрсуге подумайте, как реализованы ваши списки и очереди.
juker; sasha777666; artbear; starik-2005; +4 Ответить
29. HAMMER_59 193 05.07.17 12:32 Сейчас в теме
(26) Может Вам лучше всё-таки узнать как утроены деревья, а не смеяться на тем чего не знаете? Я Вам конкретно указал, что не существует выдуманной Вами проблемы вставки элемента в середину дерева. Списки, деревья, каталоги, очереди - это уже совсем не массивы, про которые Вам рассказали в школе. Стандартная библиотека шаблонов, довольно, кардинально изменила подход в работе с данными.

Необходимое упрощение? Т.е. эта такая мелочь, что именно с помощью индексов достигается масштабируемость?

Лично я не вижу смысла заглядывать в план построения запроса, не беспокоитесь заглядывал, просто не вижу в этом никакого смысла, когда задачу можно решить куда более простым путём.

Консоль запросов - умеет замерять затраты на отдельные части запроса. Видим, в каком месте проблема, а проблема всегда в одном - не используются индексы. И разбираемся почему не используются, как правило, запрос написан так, что SQL или другой СУБД слишком сложно разобрать запрос. Проблема решается, как правило, дроблением огромного запроса, на несколько мелких.

Также нужно понимать, какие индексы строит 1С, что местами не очень очевидно, например в случае с периодическими регистрами сведений, мало того, концепция построения индекса для периодического регистра сведений различная, для различный версий программных файлов.

Подытожим:
Какой смысл заглядывать в план построения запроса? Чтобы найти узкое место? Так его можно найти намного проще.
В статье написано, что вот мол на маленькой базе всё нормально, а при большом количестве данных начинает всё тормозить. Т.е. заранее сможете по плану построения запроса сделать прогнозы? Так это враньё, т.к. лишний раз СУБД не будет использовать индексные файлы, и план построения запроса будет зависеть от состояния БД, мало того ещё и от статистики будет зависеть.
35. Evil Beaver 6397 05.07.17 18:03 Сейчас в теме
(29)
выдуманной Вами проблемы вставки элемента в середину дерева


Я такого не писал. Я писал о невыдуманной мной проблеме вставки в середину файла. И написал, как она решается. Кроме того, сбалансированные деревья я также упомянул.

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

Поверьте, довольно большой процент "программистов 1С" на собеседованиях не знает даже этого. У них есть мантра "включить индексирование", а что это и зачем, и как вообще выглядит - не знают.
30. HAMMER_59 193 05.07.17 12:56 Сейчас в теме
(26)
Да собственно в чем проблема, долго пример списка привести, все остальные объекты (деревья, очереди, словари и т.д.) подобны списку.

Для списка мы храним ссылку на первый элемент, в случае пустого списка храним NULL.

Каждый элемент, хранит
- Ссылку на данные.
- Ссылку на следующий элемент списка. Последний элемент хранит NULL.

В чём проблема вставить элемент в середину списка? Сколько это займёт времени?
31. starik-2005 1979 05.07.17 13:19 Сейчас в теме
(30)
В чём проблема вставить элемент в середину списка?
Всегда интересовался, как в таком списке найти некий элемент X. Приведите пример его поиска, отличного от scan.
Evil Beaver; sasha777666; +2 Ответить
33. HAMMER_59 193 05.07.17 14:28 Сейчас в теме
(31)
На Си со времен института не писал, могу ошибаться в названии объектов.
Создаём MultiSet, в этот объект добавляем ключ (реквизит по которому будем осуществлять поиск), и ссылку на элемент списка. Собственно индексы подобным образом и работают.
А поиск по MultiSet очень быстро отработает.

Говоря языком 1С, то же самое что добавить индекс к таблице значений.
34. starik-2005 1979 05.07.17 15:59 Сейчас в теме
(33)
А поиск по MultiSet очень быстро отработает.
Тут есть одна проблема: когда мы добавляем индекс, то нам нужно при вставке каждый раз этот индекс расщеплять на часть до и часть после. Вот есть у Вас тот мультисет - это просто список с хештаблицей к элементам, полагаю. Вот добавили вы его - и вроде все хорошо, добавился элемент. Но дальше вам нужно этот индекс сохранить - это запись. Допустим у Вас есть какая-то недозанятая страница и Вы просто в нее пишите. Если вставлять подряд кучу данных, то однажды незанятые страницы закончатся и нужно будет какую-то страницу расщеплять на две, в итоге будут две наполовину пустые страницы. Но при этом в саму таблицу Вы вставляете элементы в конец и не особо паритесь с поиском, ибо есть индекс. Но когда есть кластерный индекс, то при каждой вставке будет искаться свободная страница для самой таблицы, и если ее нет - она будет расщепляться, ибо кластерный индекс задает упорядочивание самой таблицы.

Дальше Вам надо что-то по кластерному индексу найти. В итоге это уже или скан, что нехорошо, или сик. Второе - это поиск в кластерном индексе (читай - в таблице) по полям этой таблицы, которые уже лежат в неком списке со ссылкой на элементы, которые больше, и на элементы, которые меньше -B-TREE. Так вот и индекс в виде такого дерева хранится, а не в виде мультисета (если, конечно, это обычный индекс, который юзается в 1С, а не gist/hash-индексы, которые в 1С не юзаются).
juker; JohnyDeath; Evil Beaver; sasha777666; +4 Ответить
37. HAMMER_59 193 06.07.17 07:14 Сейчас в теме
(34)
Вот есть у Вас тот мультисет - это просто список с хештаблицей к элементам, полагаю.

Неверно предполагаете, мультисет - это дерево, а дерево это есть частный случай списка.

Структура списка:
- Ссылка на данные
- Следующий элемент

Структура дерева :
- Ссылка на данные
- Левая ветвь
- Правая ветвь

Поэтому я никак не могу вас понять почему в список быстро вставлять, а в дерево (в индекс) долго. Дерево - это частный случай списка.

Не вижу никакой проблемы вставлять элементы в дерево. Вы каждый упоминаете кластерный индекс, но его используют далеко не везде и не всегда.
А я пишу про обычное дерево (обычный индекс), и я не вижу никаких проблем в добавление нового элемента в дерево. Да, каждый раз перед записью будет происходить поиск нужного узла дерева, но это не так долго, для глубины дерева в 20 элементов это уже 1 млн значений, и чем больше глубина тем больше разница, т.е. при глубине дерева 30 элементов это уже 1 млрд. значений.
Да, при количестве элементов в 1 млн, при каждой записи будет осуществлен перебор до 20 элементов (может и с первого раза повезет), но 20 элементов перебрать всяко лучше чем 1 млн.
38. Evil Beaver 6397 06.07.17 09:36 Сейчас в теме
(37) я не совсем понимаю, с чем конкретно вы пытаетесь спорить, и в чем нас убеждаете?
39. HAMMER_59 193 06.07.17 10:57 Сейчас в теме
(38) Так Вы читайте, а не только пишите и станет всё понятно.
Не ленивый, повторю ещё раз.
Почему Вы решили, что запись в индекс происходит долго? Я не вижу никаких оснований, т.к. индекс не что иное как дерево, а дерево это частный случай списка.

Ну и так по мелочи:
Я так и не понял зачем лезть в план запроса.
Во-первых план запроса не является статичным, и для одного и того же запроса меняется в зависимости от ситуации. Я думаю, с этим встречался практически каждый когда один и тот же запрос, в одной и той де базе отрабатывает очень по разному.
Если нужно найти узкое место, зачем лезть в план построения запроса? Можно и без этого получить данные какая часть запроса отрабатывает медленно, и сделать соответствующие выводы.
41. Evil Beaver 6397 06.07.17 13:39 Сейчас в теме
(39)
Можно и без этого получить данные какая часть запроса отрабатывает медленно, и сделать соответствующие выводы.


Поделитесь, пожалуйста, как можно ДОСТОВЕРНО получить сведения о том какая часть запроса отрабатывает медленно, не заглядывая в план запроса. Эмпирически, основываясь на собственном опыте - да можно. Но эта информация будет носить вероятностный характер. План запроса ДОСТОВЕРНО показывает - какая часть запроса работает медленно здесь и сейчас. Вот и вся причина туда заглядывать.
juker; artbear; +2 Ответить
42. HAMMER_59 193 06.07.17 14:15 Сейчас в теме
(41)
Поделитесь, пожалуйста, как можно ДОСТОВЕРНО получить сведения о том какая часть запроса отрабатывает медленно, не заглядывая в план запроса.

Уже отвечал на этот вопрос - консоль запросов позволяет получить исчерпывающие ответы.
Цитата текста its.1c.ru:

При разработке запросов в конфигураторе, как правило, требуется проводить отладку запроса на реальных данных. Данный инструмент позволяет вести разработку запроса (или пакета запросов) параллельно с просмотром результата. При работе с инструментом в толстом клиенте можно воспользоваться конструктором запросов, как и при работе в конфигураторе. Возможности по анализу результата запроса включают:

вывод данных временных таблиц;
замер времени выполнения запроса и числа строк;
подсветку указанных ячеек в результате запроса;
интерактивное сравнение двух результатов запроса (только в толстом клиенте);
вывод результата запроса в новом окне;
вывод плана выполнения запроса, а также SQL-текст запроса, сформированного в СУБД. Для СУБД Microsoft SQL Server план выполнения выводится в виде дерева, а для остальных СУБД – в текстовом формате технологического журнала. Для упрощения анализа запросов также предусмотрено два режима отображения текстов запросов: с именами таблиц и колонок СУБД или с именами объектов метаданных и реквизитов конфигурации (только в обработке для "1С:Предприятие" версии 8.3).
43. artbear 1164 07.07.17 10:00 Сейчас в теме
(42) Сами себе противоречите :(
(39) - Я так и не понял зачем лезть в план запроса.
Во-первых план запроса не является статичным, и для одного и того же запроса меняется в зависимости от ситуации. Я думаю, с этим встречался практически каждый когда один и тот же запрос, в одной и той де базе отрабатывает очень по разному.
Если нужно найти узкое место, зачем лезть в план построения запроса? Можно и без этого получить данные какая часть запроса отрабатывает медленно, и сделать соответствующие выводы.


(42)
консоль запросов позволяет получить исчерпывающие ответы.
...
вывод плана выполнения запроса, а также SQL-текст запроса, сформированного в СУБД. Для СУБД Microsoft SQL Server план выполнения выводится в виде дерева, а для остальных СУБД – в текстовом формате технологического журнала. Для упрощения анализа запросов также предусмотрено два режима отображения текстов запросов: с именами таблиц и колонок СУБД или с именами объектов метаданных и реквизитов конфигурации (только в обработке для "1С:Предприятие" версии 8.3).
45. HAMMER_59 193 07.07.17 12:43 Сейчас в теме
(43)
Сами себе противоречите :(

В чём Вы видите противоречие?

Я утверждал, что узкое место можно обнаружить и не заглядывая в план запроса. Разве это не так?

Консоль позволяет вывести план запроса, и? С чего вы решили что раз позволяет, значит это крайне ценная информация?

Несерьезно какая-то у Вас тут атмосфера. Показал Вам инструмент, чтобы Вы колесо не изобретали. Сразу все на меня накинулись: "Да как я могу иметь другую точку зрения". У Вас тут что, секта?
46. starik-2005 1979 07.07.17 14:40 Сейчас в теме
(45)
Я утверждал, что узкое место можно обнаружить и не заглядывая в план запроса. Разве это не так?
Не совсем так. Например, в запросе, который вы крутите в консоли запросов, при отборе по высокоселективным данным у Вас может и не быть затыка, если же потом отбор измениться, то селективность другого значения может оказаться иной (низкой) и тот же самый запрос с тем же самым планом запроса, сохраненным в процедурном кеше, выполнится за весьма длительное время.

У меня на практике встречались случаи, когда реально скорость одного и того же запроса могла измениться со временем. Консоль, допустим, покажет, какой конкретно запрос (а подзапрос?) тормозит, но в реальной жизни может оказаться, что этот запрос тормозит только на определенных отборах, а на других работает хорошо. И механизм преодоления таких проблемных ситуаций лежит за пределами консоли запросов - он в профайлере, в планах запросов, в планах обслуживания, в создании нескольких запросов для разных отборов, чтобы планировщик для каждого из них подобрал оптимальный вариант, а не использовал сохраненный в процедурном кеше план.
40. HAMMER_59 193 06.07.17 11:58 Сейчас в теме
(38)
70% статьи написано, про то, что индексы значительно ускоряют поиск.
Я не согласен с самой подачей материала. Для меня индекс - это метод дихотомии, который я могу объяснить очень просто.
Допустим, у Вас нет операции извлечения квадратного корня, напишите функцию нахождения значения.
Допустим, с точностью до 0,001 знака, находим квадратный корень из 150. А дальше все просто если мы используем перебор, нам придется сделать:
12 247 вычислений, прежде чем мы найдем верное значение.
А для метода дихотомии до нужного значения мы дойдем на 19 шаг.

И прямо тут же можно добавить, а вот если бы искали с точность до 1 (т.е. значений было бы всего 150 а не 150 000), получилось бы одинаковое количество вычислений - по 12, и ничего бы мы не выиграли от использования индекса, а только потеряли время на построение индекса.

Оставшаяся часть статьи совсем не понятно про что. СУБД строит план выполнения запроса по неким волшебным алгоритмам, которые нам не подвластны и не понятны.
Я бы сформулировал по-другому. Если вы написали запрос так, что там сам чёрт ногу сломит, не рассчитывайте, что с ним разберётся СУБД, поэтому будьте проще, учитесь писать простые и понятные запросы, если запрос сложный - упрощайте, используйте вложенные таблицы.
59. starik-2005 1979 28.05.19 15:04 Сейчас в теме
(37)
Поэтому я никак не могу вас понять почему в список быстро вставлять, а в дерево (в индекс) долго. Дерево - это частный случай списка.
Да, мультисет - это не просто список, а упорядоченный список, т.е. упорядоченное хранилище кеу->value с прямым и обратным итератором. Вставка и поиск в мультисете - это log2(N), при этом в неупорядоченный список вставить можно за О(1). А для вставки в деревья SQL-базы необходимо записать страницу, в которую вставили данные или индекс, на диск, а т.к. на диск пишется не просто двадцать, допустим, байт индекса, а кластер целиком, то стоимость операции вставки при множестве индексов равна как минимум времени случайной записи такого количества кластеров, которое равно количеству индексов плюс один - сама таблица с данными. При этом если страницы хранения индекса не хватит, то придется на каждый такой индекс и таблицу записать еще по одному кластеру. И если у нас дисковая подсистема допустим выдает 40к IOPS на операциях записи 4к-блоков, то в лучшем случае вставка у на с в индексированную таблицу ограничится этими IOPS деленными на количество индексов + таблица. Из-за этого БД могут эксплуатировать дисковую систему при множественных непоследовательных вставках достаточно сильно, выдавая этакие 1к TPS при записи (тот же pg_bench).
36. Evil Beaver 6397 05.07.17 18:06 Сейчас в теме
(30) проблема вставки в середину списка заключается в поиске середины списка. Мне неизвестно иного способа, кроме сканирования списка.
27. МимохожийОднако 129 05.07.17 08:53 Сейчас в теме
Начало статьи было хорошее. Планируется продолжение? Осталось ощущение недосказанного, оборванного вдруг...
32. DarkUser 05.07.17 13:51 Сейчас в теме
44. herfis 285 07.07.17 10:24 Сейчас в теме
Отличный слог, хорошие статьи. Пишите еще!
Ссылка на вашу "Под капотом управляемых форм" у меня вообще, можно сказать, в буфере обмена. Раздаю направо и налево.
Эта тоже хороша, жалко для меня пользы нет. Ждем продолжения :)
primara; artbear; +2 Ответить
47. JohnyDeath 295 07.07.17 23:14 Сейчас в теме
Неповторимый слог Андрея, повествующих о, казалось бы,замороченных вещах в очень доступной и простой форме.
Ты точно будешь удостоен вторым параллелепипедом!
48. Serg O. 181 08.07.17 00:12 Сейчас в теме
Отлично написано!
Объяснить сложные вещи простым языком - это дано не каждому.

На фразе "тут мы приближаемся к быстродействию тетеньки из регистратуры"
- ржал минут 10, это просто супер!!

Большой респект автору.
juker; корум; primara; jif; JohnyDeath; +5 Ответить
57. juker 213 28.05.19 13:04 Сейчас в теме
49. Поручик 4332 02.10.17 11:08 Сейчас в теме
Статью прочитал и понял, что планы запросов как не смотрел никогда, так и не буду, скорей всего, смотреть.

зы Статуэтка от Инфостарта есть.
50. mvxyz 147 02.10.17 23:07 Сейчас в теме
Спасибо за статью! Написано живо и доходчиво. Ждем продолжения.
51. JohnConnor 34 03.10.17 05:02 Сейчас в теме
52. primara 43 04.10.17 10:10 Сейчас в теме
Большое спасибо! Наконец-то нашелся автор, который объяснил наглядно и доходчиво! Даже мне все стало понятно) Очень жду продолжения!
54. ArchLord42 69 06.10.17 05:19 Сейчас в теме
Статья хороша для тех, кто еще не знаком с планами запроса, жалко ее небыло тогда, когда я проходил курсы на эксперта по 1С, потратил бы меньше времени на осознание :)
58. juker 213 28.05.19 13:06 Сейчас в теме
Статья отличная. Давно не читал технических статей написанных таким живым языком.
Спасибо автору.
Оставьте свое сообщение

См. также

Онлайн-интенсив "Бизнес-процессы для подготовки к экзамену 1С:Специалист по платформе" 12 декабря 2019 г. Промо

На интенсиве будут рассмотрены все теоретические вопросы, связанные с устройством механизма бизнес-процессов – это необходимо для успешной сдачи экзамена 1С:Специалист по платформе. Также, в качестве практического примера, будет решена задача, аналогичная экзаменационной.

777 рублей

Весёлые картинки о работе Performance Monitor на Windows Server 2016 Std по мотивам расследования потери производительности на базе 1С 17

Статья Системный администратор Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация посвящена одной особенности Performance Monitor на Windows Server 2016 Std. Как понимать графики Performance Monitor на Windows Server 2016 Std при расследовании проблем в работе 1С.

22.10.2019    2670    EugeneSemyonov    10       

Подборка программ для взаимодействия с ЕГАИС Промо

ЕГАИС (Единая государственная автоматизированная информационная система) - автоматизированная система, предназначенная для государственного контроля за объёмом производства и оборота этилового спирта, алкогольной и спиртосодержащей продукции. Инфостарт рекомендует подборку проверенных решений для взаимодействия с системой.

Мониторинг высоконагруженной системы 38

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Администрирование данных 1С

Высоконагруженной системе (более 8000 клиентских сессий) мониторинг необходим. Про опыт использования инструментов для мониторинга – самописной системы информирования, написанной на C#, и конфигурации «Центр контроля качества» в связке с системой отображения данных Grafana, на конференции Infostart Event 2018 Education рассказал Олег Репников.

13.09.2019    4619    Repich    4       

Использование Zabbix для сбора информации о серверных вызовах и управляемых блокировках с сервера 1С Предприятия, работающего на платформе GNU/Linux 75

Статья Системный администратор Программист Нет файла v8 Linux Бесплатно (free) Администрирование данных 1С Zabbix

Описанные в данном опусе механизмы ни в коей мере не противопоставляются тому, что реализует КИП от 1С или какие-либо другие инструменты (решения)! Это всего лишь еще один взгляд на "проблему", который может быть полезен в некоторых ситуациях.

10.09.2019    9138    Sloth    11       

Готовые переносы данных из различных конфигураций 1C Промо

Рекомендуем готовые решения для переноса данных из различных конфигураций 1C. C техподдержкой от разработчиков и гарантией от Инфостарт.

Анализ производительности APDEX 65

Отчеты и формы Системный администратор Программист Внешний отчет (ert,erf) v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Отчет для просмотра и анализа замеров производительности в конфигурациях на базе БСП.

31.08.2019    4229    93    YPermitin    7       

Перенос документов, остатков и справочников КА 1.1 => КА 2 / УТ 11. Обновлено до КА 2.4.10.х и УТ 11.4.10.х! Промо

Более 130 компаний выполнили переход на КА 2 или УТ 11 с помощью нашей разработки! Позволяет перенести не только остатки и справочники (как типовая обработка), но и документы за нужный период времени. Предоставляем техподдержку, оперативно исправляем замечания, выпускаем обновления при выходе новых релизов программ 1С. Вы можете проверить разработку до покупки: сделаем бесплатный тестовый перенос из вашей базы КА 1.1 и предоставим доступ к базе-результату через веб-клиент!

29700 руб.

Неочевидные проблемы производительности: важность системного подхода при анализе 50

Статья Программист Нет файла v8 Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

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

19.07.2019    5084    Филин    12       

Ловля блокировок на связке "Microsoft SQL server - 1С" 38

Статья Системный администратор Программист Нет файла v8 v8::blocking MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Материал относится к базам данных на связке «1С - MS SQL Server». Один из способов отлова блокировок в бд 1С . Переход к управляемым блокировкам через режим "Автоматический и управляемый".

16.07.2019    4624    fhqhelp    0       

1С:Предприятие через Интернет. 1С:Fresh Промо

Ведение бухгалтерского и налогового учет, сдача отчетности, управление бизнесом из любой точки мира. Привычные программы «1С» через Интернет без приобретения коробочных программ.

Анти-оптимизация: как мы ускорили запрос в 4 раза, сделав его неоптимальным 57

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Решение задач на 1С:Специалист Разработка

В этой статье приведен пример неочевидной "оптимизации" запроса, которая противоречит всем правилам, описанным в книгах для подготовки к сертификации "1С:Эксперт по технологическим вопросам", а также преподаваемым на курсах подготовки экспертов.

02.07.2019    6845    igordynets    119       

Программы для исполнения 488-ФЗ: Маркировка товаров Промо

1 января 2019 года вступил в силу ФЗ от 25.12.2018 № 488-ФЗ о единой информационной системе маркировки товаров с использованием контрольных (идентификационных) знаков, который позволяет проследить движение товара от производителя до конечного потребителя. Инфостарт предлагает подборку программ, связанных с применением 488-ФЗ и маркировкой товаров.

Ускорение чтения правил обмена в УПП 1.3 в 20 раз! 70

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Способ оптимизации чтения правил обмена конвертации данных. Может понадобиться при большом размере правил и высокой периодичности обмена.

27.06.2019    5719    YPermitin    16       

Хотите снизить нагрузку на процессор сервера в 2 раза? 21

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

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

27.06.2019    4955    Дмитрий74Чел    6       

Подборка решений для взаимодействия со ФГИС «Меркурий» Промо

С 1 июля 2019 года все компании, участвующие в обороте товаров животного происхождения, должны перейти на электронную ветеринарную сертификацию (ЭВС) через ФГИС «Меркурий». Инфостарт предлагает подборку программ, связанных с этим изменением.

Непридуманные истории по оптимизации. История 1 82

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Первая статья из планируемого цикла об оптимизации приложений на базе 1С. Без теории. Одна практика.

13.06.2019    8378    Repich    117       

Оптимизация: неэффективные запросы 7

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad) Практика программирования Разработка

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

13.06.2019    3298    slayer-ekb    10       

Очный семинар по регулярному менеджменту Александра Фридмана "Вы или Хаос", 12 декабря 2019 г. , Санкт-Петербург Промо

Семинар по регулярному менеджменту от Александра Фридмана для собственников, первых лиц и топов. Технология управленческого планирования, комплексного управления временем и другими ресурсами, выполнением поручений, делами, информацией, контактами (встречи-звонки-почта).

от 11000 до 29000 рублей

За 5 шагов добавляем мониторинг счетчиков производительности серверов MS SQL и 1С 91

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Статистика базы данных Производительность и оптимизация (HighLoad)

Мы расскажем и покажем, как добавить данные счетчиков производительности серверов 1С и MS SQL в нашу базу мониторинга за 15 минут. Приведем список наиболее важных из них, опишем основные особенности.

28.05.2019    9455    ivanov660    5       

Не думать о секундах свысока... 56

Статья Программист Нет файла v8 1cv8.cf Бесплатно (free) Производительность и оптимизация (HighLoad)

Несколько примеров оптимизации типовой конфигурации УТ11. Описанные приемы подходят для многих других конфигураций.

21.05.2019    5160    vasilev2015    21       

Перенос данных УТ 10.3 => УТ 11 / КА 2 / ERP 2 (ЕРП 2) (документы, остатки и справочная информация из "1С:Управление торговлей, ред. 10.3" в УТ 11 / КА 2 / ERP 2). Обновлен до УТ 10.3.56.х, УТ 11.4.10.х, КА 2.4.10.х и ERP 2.4.10.х! Промо

Уже более 100 компаний приобрели перенос и выполнили переход на УТ 11 / КА 2 / ERP 2 с помощью нашей разработки! Обработка перехода с УТ 10.3 на УТ 11 / КА 2 / ERP 2 позволяет перенести не только остатки на указанную дату (как типовой перенос), но и все возможные документы за выбранный период. При выходе новых релизов этих программ оперативно выпускаем обновление обработки. Предоставляем техническую поддержку. Можем сделать бесплатный тестовый перенос!

29700 руб.

Альтернативная стратегия управления блокировками 45

Статья Программист Архив с данными v8 v8::blocking 1cv8.cf Россия MS SQL Бесплатно (free) Производительность и оптимизация (HighLoad)

Данная публикация освещает одну из альтернативных стратегий блокирования данных на уровне MS SQL Server, которая недоступна средствами 1С, но может быть весьма полезной. Разбирается практический пример.

20.05.2019    4526    zhichkin    15       

Как работают управляемые блокировки 122

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

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

29.04.2019    14710    comol    198       

Вакансия Автор новостных обзоров на тему 1С и бухучета, По совместительству Промо

Редакция Infostart.ru будет рада сотрудничеству с 1С-специалистом, умеющим и любящим излагать свои мысли в письменной форме. Если вы работали в IT-изданиях или имеете опыт ведения технологического блога/канала/группы, если сможете сделать обзор обработок из каталога infostart.ru/public/all/, то у вас большое преимущество.

Странное потребление места на диске С 33

Статья Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Решение проблемы постоянного роста папки %AppData%/Local/Temp.

26.04.2019    11296    kuzyara    12       

Включение встроенного в платформу механизма "Копии базы данных" и использование "Дата Акселератора". Новый стандартный механизм использования баз OLAP в 1С 51

Статья Системный администратор Программист Нет файла v8 Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

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

25.04.2019    9320    Elf1k    27       

1СПАРК РИСКИ. Сервис оценки благонадежности контрагентов. Промо

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

5 простых шагов и 15 минут на разворачивание инструмента мониторинга проблем производительности базы 1С 202

Статья Системный администратор Программист Нет файла v8 Windows Бесплатно (free) Производительность и оптимизация (HighLoad)

В этой статье мы разберем механизм использования конфигурации "Анализ технологического журнала" на практике, и всего через 15 минут работы вы получите функциональный, удобный инструмент мониторинга проблем производительности базы 1С.

18.04.2019    19822    ivanov660    68       

Как разбить базу на файлы и не сойти с ума 108

Статья Системный администратор Программист Нет файла v8 Бесплатно (free) Производительность и оптимизация (HighLoad)

Разбиение базы данных 1C на файлы и последующее сопровождение. Нюансы, грабли и прочее.

06.04.2019    10143    YPermitin    29       

Перенос данных УПП 1.3 => ERP 2 (ЕРП) / УТ 11 / КА 2.х (обработка переноса документов, остатков и справочников из "1С:Управление производственным предприятием, ред. 1.3" в ERP / УТ 11 / КА 2). Обновлен до УПП 1.3.127.х, КА 2.4.10.х и ERP 2.4.10.х! Промо

Обработка позволяет переносить из УПП 1.3 в ERP 2 документы за выбранный период и остатки. Типовая обработка от фирмы 1С документы не переносит. Также исправлены ошибки типовой обработки. При выходе новых релизов обновление высылается бесплатно в течение года. Разработка будет полезна фирмам-франчайзи, которые периодически выполняют такой перенос данных для заказчиков. Вы можете один раз приобрести обработку переноса, и потом бесплатно получать обновления при выходе новых релизов конфигураций 1С.

29700 руб.

Как одно изменение конфигурации PostgreSQL улучшило производительность медленных запросов в 50 раз 125

Статья Системный администратор Программист Нет файла v8 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

В связи с санкциями и другими событиями сейчас все более и более актуальна тема перевода ПО компаний на отечественное и свободное программное обеспечение. Одной из самых востребанных СУБД на рынке на данный момент является PostgreSQL - надежная, высокопроизводительная и хорошо масштабируемая СУБД, которая является прямым конкуретном таким крупным компаниям с их топовыми продуктами, как Oracle, IBM и Microsoft. Однако каждый, кто переходит на PostgreSQL, сталкивается с трудностями, прежде всего с настройкой и производительностью. Не обошли проблемы с производительностью "слоника" и меня. Предлагаю вашему вниманию перевод статьи "How a single PostgreSQL config change improved slow query performance by 50x" автора Pavan Patibandla, которая мне помогла улучшить производительность PostgreSQL.

18.03.2019    10939    w.r.    23       

Простое программное решение проблем с блокировками SQL 17

Статья Системный администратор Программист Нет файла v8 v8::blocking 1cv8.cf Россия Бесплатно (free) Производительность и оптимизация (HighLoad)

Описание одного из способов программного решения проблемы блокировок при проведении документов в клиент-серверной 1С.

06.03.2019    6646    dmitrydemenew    38