Ускорить ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.<> [Вопрос 1С Эксперт]

1. headMade 144 01.06.17 13:35 Сейчас в теме
Задача с экзамена 1С Эксперт. (частично обсуждение было тут (форум Гилева))

Текст задачи:
"В базе работают 1000 пользователей. Есть регистр сведений в нем 100 млн записей. запрос select count выполняется t= 60 сек. Необходимо сделать так, чтобы данные были получены за t = 1c."

Можете ли Вы подсказать, пожалуйста, в каком направлении мыслить/искать? Преподаватель говорит, есть порядка 12 способов решить задачу.

Коллеги отвечали преподавателю (Александру Морозову) по-разному, мы заранее придумали что можно отетить и отвечали
1) требуется выполнение всех регламентных операций, дефрагментация, реиндексация
2) требуется создание некластерного индекса или сделать регистр таким, чтобы был хотя бы один некластерный индекс, т.к. scan по нему быстрее скана по кластерному индексу

Первые два совета недостаточны.

3) Пробовали ответить, что нужно хранить заведомо где-то количество в этом регистре, типо константы и при записи наборов записей или удалении - следить за тем, сколько у нас записей (жертвуем записью ради запроса по выбору количества записей) - тоже не подходит
4) Коллеги предлагали из DMV представлений или статистики получать значение - тоже преподаватель говорит нарушение лиц.соглашения, нельзя в обход rphost подключаться к SQL базе напрямую
5) может быть нужно секционирование предложить было? Но Вы писали где-то, что его оч.сложно настроить и нужны знания сертифицированного специалиста MS SQL
6) Может быть надо MDOP = 1 выставить? Т.к. если 60 секунд выполняется сканирование - может быть происходит блокировка параллельных сканов или что-то такое.
7) Мы предлагали преподавателю перестроить бизнес-логику решения. Тоже не "прокатило".


Если подскажете, что можно было бы сделать, или где почитать (направление), очень многие люди будут благодарны!
Сейчас это задание как триггер, отсеиватель, добрая часть людей отсеивается просто в самом конце экзамена:)

Спасибо!!!
METAL; user660224_laa; +2 Ответить
По теме из базы знаний
Ответы
Подписаться на ответы Инфостарт бот Сортировка: Древо развёрнутое
Свернуть все
99. ImHunter 318 09.06.17 18:10 Сейчас в теме
Закинул уважаемым товарищам в скайп:
Добрый день. Мы (сообщество Инфостарт) ломаем голову над вопросом. Может подскажете чего-то? Очень (прямо чрезвычайно) будем признательны! Ссылка http://forum.infostart.ru/forum9/topic172403/ . Тема Ускорить ВЫБРАТЬ КОЛИЧЕСТВО(*) ИЗ РегистрСведений.<> [Вопрос 1С Эксперт]
Может таки чего-то напишут...
100. ImHunter 318 09.06.17 18:51 Сейчас в теме
(99) Упс.. Отправлял через толком не работающее соединение RDP. Повторю им почтой.
101. DJDUH 17 12.06.17 12:15 Сейчас в теме
Кто начнёт с №1 из 12 способов - описывать решение?
102. Dream_kz 129 12.06.17 12:19 Сейчас в теме
(101) Удалить 99 миллионов записей)
104. DJDUH 17 12.06.17 12:58 Сейчас в теме
(102) )))) и на удаление уйдёт несколько дней/недель/месяцев))))
Anchoret; +1 Ответить
103. herfis 506 12.06.17 12:22 Сейчас в теме
105. KazanKokos 11 13.06.17 11:34 Сейчас в теме
А воз и ныне там.
Задача которую за такое время не смог решить весь инфостарт :) ))
108. DJDUH 17 13.06.17 11:56 Сейчас в теме
(105) по ходу тема не актуальная стала вовсе - забросили её)
109. KazanKokos 11 13.06.17 12:45 Сейчас в теме
(108) пост http://forum.infostart.ru/forum34/topic172310/ наводит на размышления по этой теме:)
110. herfis 506 13.06.17 12:51 Сейчас в теме
(109) Например на такие - "причем тут этот пост, если сейчас в 1С и так RCSI?"
Ну, если мы, конечно, не обсуждаем устаревшие решения или какой-нить DB2
112. KazanKokos 11 13.06.17 13:59 Сейчас в теме
(110) прочитал. да. согласен :)
106. rintik 19 13.06.17 11:53 Сейчас в теме
Жалко нет регистра на 100 млн записей проверить. Может компоновка данных красивее считает?
107. KazanKokos 11 13.06.17 11:54 Сейчас в теме
111. nvv1970 13.06.17 13:52 Сейчас в теме
(106) быстрее СУБД не считает никто
(78) Откуда вдруг уши выросли про разделенный режим???
Если будет разделение, то вместо быстрого скана будет seek по индексу разделяющего реквизита. Кажется так.
Но про это речи не было ни здесь в топе, ни по ссылке у гилева.
113. Gilev.Vyacheslav 1915 15.06.17 14:54 Сейчас в теме
со слов автора поста похоже что преподаватель страдает херней: можно пожертвовать чем то ради скорости, тогда будет быстрее
например можно пожертвовать достоверностью и в каждой строке хранить номер строки, иметь индекс по полю с номером чтобы крайний номер соответствовал количеству строк и спрашивать самый большой номер таким образом с некоторой достоверностью можно быстро получить количество

также можно получить статистику субд и оттуда определить количество, но это тоже жертвовать достоверностью
возможно платформа тоже в каком то методе получает кэшированное значение

но то что преподаватель говорит про не лицензионность то это "жалкий" аргумент, он же сам поднял технический вопрос
METAL; KazanKokos; +2 Ответить
114. herfis 506 15.06.17 16:21 Сейчас в теме
(113) Мотивация аргументов в данном случае не имеет значения. Это всего лишь условия задачи, довольно синтетической. Ты же не придираешься к надуманности условий в арифметических задачках из учебников :)
Преподавателю ведь нужно не реальную проблему решить любой ценой. Он добивается какого-то очень конкретного известного ему ответа, который удовлетворяет сформулированным ограничениям и до которого должны додуматься экзаменуемые.
В сформулированные ограничения по версии ТС вошли:
1) не использовать прямые запросы со стороны 1С
2) не хранить количество записей "сбоку", жертвуя скоростью и параллельностью записи
Опираться на некую нумерацию - очень сомнительная идея, так как процент погрешности при этом фактически неконтролируем - вплоть до полной недостоверности.
120. zarucheisky 15.06.17 18:00 Сейчас в теме
(114) ИМХО, тогда ковырять в сторону получения статистики и плана выполнения запроса средствами платформы.
Технологический журнал, вероятно, не покажет т.к. требует, по-идее, выполнения запроса.
Сама постановка задачи говорит о получении статистики иным способом.
Может объект СхемаЗапроса при установке текста опрашивает план выполнения запроса?
115. DimDiemon 79 15.06.17 16:25 Сейчас в теме
Про жертву достоверности подумалось: А может быть решение на основе знаний о размере таблицы регистра?
116. herfis 506 15.06.17 16:28 Сейчас в теме
(115) Может. Только дальше будет анекдот про мышек и сову-стратега. Потому как откуда у тебя в 1С вдруг возьмутся знания о размере таблицы регистра?
117. DimDiemon 79 15.06.17 16:29 Сейчас в теме
(116)Не знаю. Я в эту сторону не копал...
118. KapasMordorov 428 15.06.17 17:14 Сейчас в теме
Добавить числовое измерение. Проиндексировать.
Пронумеровать с 1.
При добавлении записи брать максимальное значение измерения, прибавлять 1, записывать.
При удалении записи запоминать значение измерения, находить запись с максимальным значением, записывать в этой записи сохраненное значение удаляемой записи.
Т.о. будет поддерживаться сплошная нумерация.
Количество записей получать по максимальному значению этого измерения.

Но это решение "сбоку", хотя вроде бы не попадает в
Первые два совета
.
119. herfis 506 15.06.17 17:59 Сейчас в теме
(118)
При добавлении записи брать максимальное значение измерения, прибавлять 1, записывать.
При удалении записи запоминать значение измерения, находить запись с максимальным значением, записывать в этой записи сохраненное значение удаляемой записи.
Т.о. будет поддерживаться сплошная нумерация.

Остроумно :)
Но во избежание дублей номеров придется отказываться от параллельной записи, что по сути не отличается от хранения счетчика записей в константе.
121. cj512 29 15.06.17 18:11 Сейчас в теме
Запись в константу зависнит на ожиданиях.

Возможно такое решение:

1. Создать служебный РС (периодический(?)) с ресурсом "Количество записей"
2. При записи в основной регистр добавлять запись в служебный РС, предварительно прочитав из него СрезПоследних и прибавив 1
3. Фоновым заданием чистить старые записи

Небольшие потери при записи, но моментальные при чтении.
125. KapasMordorov 428 16.06.17 09:10 Сейчас в теме
(119)
В константах совсем нехорошо, там в таблице одна строка, которая блокируется на запись при записи любой константы, в т.ч. отличной от обсуждаемой.
122. Dream_kz 129 15.06.17 18:28 Сейчас в теме
(121) Любая запись, для поддержания актуальности, потребует устанавливать блокировку на чтение
123. cj512 29 15.06.17 19:51 Сейчас в теме
(121) хотя... другой вариант:

1. Создать служебный РС с измерением момент времени в миллисекундах и ресурсом "Количество записей"
2. Пишем на начало дня количество записей
3. В течение дня при записи в основной регистр добавляем значение "+1", при удалении добавляем "-1"
4. Фоном ночью сворачиваем и повторяем с п.2

Соответственно, в запросе берем сумму по полю "Количество записей" уже из второго регистра. Псевдостатистика своими силами.
126. herfis 506 16.06.17 09:16 Сейчас в теме
(125) Ок. Не суть. Не в константе. В предопределенном элементе служебного справочника.
124. ImHunter 318 16.06.17 07:12 Сейчас в теме
(123) Тогда уж лучше регистр накопления. И итогами собирать.
Но это претит постановке задачи - нужно обойтись без доп. объектов.
127. DJDUH 17 16.06.17 09:26 Сейчас в теме
Кто-то уже был на этом экзамене - какой там ответ!?
128. KapasMordorov 428 16.06.17 09:34 Сейчас в теме
Да какая разница, какой ответ.
У 1С есть:
- ИТС с документацией;
- ТВКВ;
- партнерский форум с обсуждениями;
- книга по проф. разработке;
- курсы.
Всё это по 4-м (8.0, 8.1, 8.2, 8.3) платформам, также добавьте режимы совместимости, в источниках есть противоречивая информация.

Автор вопроса также мог ошибаться.

Оптимизация работы с данными зависит от анализа и статистики использования данных. Про регистр ничего не известно. Может это адресный классификатор и изменения в нем делаются раз в месяц?
129. DJDUH 17 16.06.17 10:12 Сейчас в теме
(128)
Да какая разница, какой ответ.
У 1С есть:
- ИТС с документацией;
- ТВКВ;
- партнерский форум с обсуждениями;
- книга по проф. разработке;
- курсы.


Ну стало бы для меня есть разница - меня интересует ответ!?
130. spe1c 5 16.06.17 11:58 Сейчас в теме
(128) Я в 89 и 90 постах приводил результаты замера на своей базе, получение 50+ млн записей, время от 0,3 до 2,5 секунд (верхний предел видимо в момент пиковой нагрузки на регистр со стороны пользователей), так что 100 млн прочитать за 1 сек вполне реально. Поэтому вряд ли автор вопроса ошибся. Все обсуждения с доп регистрами, реквизитами, константами не прокатят, уже писалось что сдающие экзамен на эксперта всё это предлагали и не прокатило. Тут скорее всего ключевая фраза - это то, что читают одновременно 1000 пользователей, видимо с этим такая задержка связана.
152. cj512 29 16.06.17 16:44 Сейчас в теме
(130) и что к таким результатам привело? какие действия?
154. spe1c 5 16.06.17 17:04 Сейчас в теме
(152)Ничего не привело, это один из вариантов как ответить, не лучше и не хуже чем все озвученные тут.
131. ekaruk 4933 16.06.17 12:11 Сейчас в теме
Как вариант, заменить регистр сведений на регистр накопления. Ну или добавить регистр накопления параллельно. Тогда количество будет определяться за миллисекунду по таблице итогов.
Krio2; Shmell; +2 Ответить
132. spe1c 5 16.06.17 12:13 Сейчас в теме
(131)Вы по сслыке в топике ходили? Там написано:
Мы предлагали преподавателю перестроить бизнес-логику решения. Тоже не "прокатило".
133. spe1c 5 16.06.17 12:15 Сейчас в теме
И это:
Хранение в отдельном регистре так же напоследок предложила, но этот вариант не подошел
134. ekaruk 4933 16.06.17 12:18 Сейчас в теме
(133) Вопрос про средства платформы.
Думаю, дополнительный регистр накопления не поменяет логику решения.
Отдельный регистр сведений с информацией о количестве, который скорее всего имелся в виду прошлом ответе, это плохое решение, будет блокироваться при обновлении.
А вот отдельный дополнительный регистр накопления, по-моему, вполне вариант.
137. spe1c 5 16.06.17 12:47 Сейчас в теме
(134)Да, просто отдельный регистр уже предлагали, не прокатило. Да и не нужно, я же выше написал что 100 млн прочитать и так реально за 1 сек (эксперимент показал, что 50 млн реально от 0,3 сек)
135. KapasMordorov 428 16.06.17 12:20 Сейчас в теме
Там похоже время запроса <1 сек без пользователей.
При 1000 пользователей - 60 сек.
Транзакции, блокировки - далее приглашение посетить курсы.
164. Gilev.Vyacheslav 1915 22.06.17 14:38 Сейчас в теме
(135) При 1000 пользователей если работа в режиме версионника, то можно получить давление на tempdb (при размещении там "версий"), но поскольку мы читаем крайнюю строку всего одну, то максимум будет 1000 версий и
60х кратного ухудшения не будет, разве что админ с кривыми руками

кроме того не понятно что люди пишут "не прокатит" хранить значение крайнего номера строки, что значит ломается бизнес-логика, аргументации - ноль

хотелось бы для начала увидеть оригинал "постановки задачи"

и для какой реальной задачи идет подсчет строк
166. DJDUH 17 22.06.17 16:54 Сейчас в теме
(164) ну все отталкивались "от шапки" - оригинал - только у препода на экзамене)
136. DimDiemon 79 16.06.17 12:23 Сейчас в теме
Вариант: Раз 100 млн записей читает 60 секунд, то регистр без индексов. Надо добавить индекс по измерению и будет работать быстрее.
В условиях задачи не сказано же что регистр сделан оптимально...
138. spe1c 5 16.06.17 12:50 Сейчас в теме
(136)Совсем без индексов? Но 1С по умолчанию строит ведь индексы?
140. herfis 506 16.06.17 12:55 Сейчас в теме
(136) Перечитай сабж внимательнее.
139. DimDiemon 79 16.06.17 12:50 Сейчас в теме
(138)Если "ведущее" и "основной отбор" нигде галочку не поставить, что будет?
141. spe1c 5 16.06.17 12:55 Сейчас в теме
(139)В желтой книжке пишут:
Непериодический регистр

Измерение1+Измерение2...+ИзмерениеN
Этот индекс создается, если есть хоть одно измерение регистра.


Если вы про регистр без измерений, то согласен.
142. dmpas 418 16.06.17 13:11 Сейчас в теме
(141) регистр без измерений с миллионом записей??
143. spe1c 5 16.06.17 13:27 Сейчас в теме
(142)Это не ко мне вопрос, я только ответил на (139).
144. DimDiemon 79 16.06.17 15:22 Сейчас в теме
(142)А чо бы и нет? Задача то "сферическая в вакууме"...
145. Sashares 35 16.06.17 15:40 Сейчас в теме
(144)В не подчиненном не периодическом регистре сведений без измерений может быть только 1 запись же.
Гриффин; monkbest; zarucheisky; +3 Ответить
146. zarucheisky 16.06.17 15:46 Сейчас в теме
(144) Вполне реальная, кстати, задача.
163. Gilev.Vyacheslav 1915 22.06.17 14:22 Сейчас в теме
(146) можно привести пример "реального"
165. spe1c 5 22.06.17 16:24 Сейчас в теме
(163)Можно, даже два:
1) преподу нужно завалить как можно больше людей, чтобы эксперты не слишком расплодились.
2) нужно как можно больше людей загнать на эксклюзивные платные курсы, которые он сам и ведет.
Вот такие реальные задачи:)
mamonth; talych; Brawler; KazanKokos; +4 Ответить
147. spe1c 5 16.06.17 15:59 Сейчас в теме
А почему бы пользователям не запретить средствами платформы читать количество записей в таблице со 100 млн строк? Ибо нефиг на работе фигней страдать.
148. zarucheisky 16.06.17 16:07 Сейчас в теме
(147) Хотя бы потому, что так исторически сложилось
149. spe1c 5 16.06.17 16:28 Сейчас в теме
(148)Я имел в виду, может быть это один из правильных ответов: настроить по правам, всем запретить, одному (начальнику) оставить, тогда параллельного чтения не будет, начальник спокойно будет получать нужные данные за 1 сек, остальные - брать при необходимости эти данные по служебной записке.
153. cj512 29 16.06.17 16:45 Сейчас в теме
(149) это нарушение бизнес-логики
155. spe1c 5 16.06.17 17:05 Сейчас в теме
(153)С чего это настройка прав и ролей пользователей является нарушением бизнес логики?
150. Vitaly1C8 16.06.17 16:29 Сейчас в теме
Перед выполнением запроса, Установить монопольный режим ?!
151. spe1c 5 16.06.17 16:33 Сейчас в теме
(150)Возможны варианты, например всем запретить запускать внешние обработки, встроенную консоль запросов (если есть).
156. Vitaly1C8 19.06.17 08:50 Сейчас в теме
Ну а например такой вариант: попросить всех юзеров выйти, внести изменения в конфу. Затем каждый юзер при входе выполнит небольшой запрос к БД и результат запишет ... Мы просуммируем результаты ...
157. KazanKokos 11 19.06.17 16:40 Сейчас в теме
(156) в одну секунду юзеры не уложатся
158. herfis 506 19.06.17 17:13 Сейчас в теме
(156) Вариант параллельных вычислений уже обсуждался, но как-то вяло. Главный вопрос - как бить по диапазонам.
Теоретически можно завести дополнительный индексированный ресурс, куда писать МАКСИМУМ плюс один для каждой записи. И пофиг, что там могут быть дырки и дубли. Если такое допустимо по условию задачи (а это не до конца понятно), то тогда может и получится эффективно распараллелить.
159. headMade 144 20.06.17 13:23 Сейчас в теме
накопал тут Удерживать таблицу в оперативной памяти PostgreSQL.
Может есть аналогичная технология применительно к MSQL?

Применительно к MSQL:
1. Как вариант создать RAM диск и выкинуть на него эту таблицу (через файловые группы)
или
2. Microsoft SQL Server. Таблицы в памяти (in-memory tables) или когда-то softpoint-а Фиксирование таблиц баз данных MS-SQL в памяти как я понимаю что это Технология In-Memory OLTP (для SQL Server 2014) т.е. фактически означает нарушение лицензионного соглашения.
160. herfis 506 20.06.17 14:36 Сейчас в теме
(159) prewarm, насколько я понимаю, это всего лишь предварительный "прогрев" кэша, чтобы сразу при старте работы пользователей критичные данные уже находились в кэше и пользователи начинали работу без лагов. Т.е. оно тупо выполняет предварительные обращения к данным таблиц. Никакого "удержания таблицы в памяти" при этом не происходит - происходит обычное кэширование СУБД. Не, ну если таблица небольшая, а память отведенная СУБД для кэша позволяет - то ессно будет в памяти находиться какое-то время.
161. headMade 144 20.06.17 15:53 Сейчас в теме
(160) да. В документации прописано что эти данные из кэша могут быть затем вытеснены
162. herfis 506 20.06.17 16:49 Сейчас в теме
Помню, Лустин в сумбурном вебинаре по правильной готовке постгри для 1С использовал "прогрев" таблиц с конфой и еще чего-то там.
Только, EМНИП, для этого использовалось не отдельное расширение, а чей-то гитхабовский скрипт то ли на перле, то ли на питоне.
167. starik-2005 3052 22.06.17 21:28 Сейчас в теме
Ну и срач развели, при том на сайте потгреса давно все сказано: http://wiki.postgresql.org/wiki/Slow_Counting
Shmell; Сурикат; +2 Ответить
168. Сурикат 399 22.06.17 23:42 Сейчас в теме
(167)
Но для MS SQL такой прием не работает, проверяли
169. starik-2005 3052 23.06.17 12:27 Сейчас в теме
(168) для мелкософтовского на стеке так написано: https://stackoverflow.com/questions/11130448/sql-count-performance
For the other two queries, SQL Server would use the following rule. To perform a query like SEL ECT COUNT(*), SQL Server will use the narrowest non-clustered index to count the rows. If the table does not have any non-clustered index, it will have to scan the table.

Also, if your table has a clustered index you can get your count even faster using the following query (borrowed fr om this site Get Row Counts Fast!)

По сцылке разбираются три запроса, один из которых выполняется мгновенно, а два других - очень долго. На это отвечают, что скул использует "самый узкий" некластерный индекс для того, чтобы получить количество строк. Если нет некластерных индексов - используется скан таблицы (= скан кластерного индекса, ибо он и есть в случае 1С таблица). Ну и дальше, если только кластерный индекс у таблицы, предлагают использовать динамические представления и прочие системные таблицы.

Отсюда как бы один простой ответ вытекает. Сами догадаетесь или нужно подсказать?
georgebgk; farukshin; +2 Ответить
170. DJDUH 17 23.06.17 12:44 Сейчас в теме
(169)
For the other two queries, SQL Server would use the following rule. To perform a query like SEL ECT COUNT(*), SQL Server will use the narrowest non-clustered index to count the rows. If the table does not have any non-clustered index, it will have to scan the table.

Also, if your table has a clustered index you can get your count even faster using the following query (borrowed fr om this site Get Row Counts Fast!)


Да, подскажите, как это всё реализовать средствами платформы 1С!?
MagnusRed; KazanKokos; +2 Ответить
171. starik-2005 3052 23.06.17 14:11 Сейчас в теме
(170)
как это всё реализовать средствами платформы 1С
По сути нужно:
1. Некластерный индекс (самый узкий). Читаем об индексации соответствующей таблицы в 1С (измерение1, ...), чтобы его получить.
2. Меняем запрос, добавляя в него условие по индексированному полю и агрегат по количеству этого поля.
3. Профит.
172. Gilev.Vyacheslav 1915 23.06.17 17:12 Сейчас в теме
(171) всмысле сканирование менее емкого индекса вместо более емкого?
173. starik-2005 3052 24.06.17 17:56 Сейчас в теме
(172) нечто типа. На сколько я знаю, если добавить поле с индексом в регистр, то 1С создает по нему отдельный индекс.

Вот интереса ради для постгреса получил такой план запроса для таблицы _inforg167 теста Гилева:
SELECT COUNT(_recorderrref)
  FR OM public._inforg167

"Aggregate (cost=168.50..168.51 rows=1 width=8)"
-> Seq Scan on _inforg167 (cost=0.00..156.00 rows=5000 width=17)


В общем и целом не удалось мне никоим образом заставить это работать иначе, как "Seq Scan on _inforg167" - т.е. всегда в постгресе сканируется таблица.
174. Gilev.Vyacheslav 1915 24.06.17 23:22 Сейчас в теме
(173) и так ходят слухи что теперь 1С:Эксперт должен уметь кодить на перле чтобы парсить ТЖ (бугага), а после задания заменить один скан на другой в моих глазах уровень этого курса/экзамена опустился ниже плинтуса
175. herfis 506 25.06.17 10:41 Сейчас в теме
(174) Не было такого задания. По-поводу недостаточности использования некластерного индекса написано прямо в сабже, если его вообще хоть кто-то читал. Никто тут не знает, чего именно добивался преподаватель.
180. papami 56 25.06.17 22:05 Сейчас в теме
176. starik-2005 3052 25.06.17 15:55 Сейчас в теме
(174)
должен уметь кодить на перле чтобы парсить ТЖ
Ну не на перле, а хотя бы grep юзать и уметь регулярки писать. Но для некоторых "экспертов" видимо это равнозначно "кодить на перле". Бедные люди )))
georgebgk; +1 Ответить
177. Gilev.Vyacheslav 1915 25.06.17 16:13 Сейчас в теме
(176) бедные люди - это которые не умеют разбирать логи тж 1С кодом 1С, но учат перлу
все таки мы наверное говорим о специалистах по технологиям фирмы 1С, и только потом по всему остальному вторично
talych; DarkUser; Brawler; Silenser; Fox-trot; +5 Ответить
178. starik-2005 3052 25.06.17 17:34 Сейчас в теме
(177)
учат перлу
Кто учит? Кого? Регулярки и перл - не одно и то же. Но регулярки куда лучше для анализа логов, чем 1С. Перл тут ни при чем. Хотя... Похоже у кого-то тут проблемы с перлом (или с регулярками - этому могу научить) )))
179. Gilev.Vyacheslav 1915 25.06.17 20:25 Сейчас в теме
(178)
Но регулярки куда лучше для анализа логов, чем 1С.
на этом можно закончить дискуссию
выросло поколение, которое "плохую" 1С заменяет "хорошим" другим "не 1С"...

люди с одним из самым престижных сертификатов от 1С говорят что 1С гов.о...

фиерия, чего тогда требовать от более слабых специалистов
master555; Boulala; talych; Shmell; Anchoret; Brawler; Новиков; Danil.Potapov; zarucheisky; KazanKokos; +10 Ответить
181. starik-2005 3052 25.06.17 22:43 Сейчас в теме
(179)
выросло поколение, которое "плохую" 1С заменяет "хорошим" другим "не 1С"
Выросло поколение, которое кроме 1С ничего не хочет знать.

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

Ну вот за сколько 1С сможет вытащить из лога в пару ГиБ отфильтрованные значения? Grep это сделает на порядок быстрее. Так зачем использовать 1С? Какая разница, на чем написать анализатор логов? Да, можно и на 1С, но если есть более простые и скоростные механизмы, то зачем так себя ограничивать-то?

ЗЫ: есть. конечно, те, кто в свое время остановился в развитии (о чем может свидетельствовать, например, тест Гилева, который до сих пор работает в толстом клиенте и не умеет асинхронно подгружать результаты, асинхронно выполнять сам тест, что приводит к фризу окна, что весьма неприятно смотрится в Unity, не говоря уже об Aero) - они нашли себе нишу и живут там в своей зоне комфорта. Им, предположу, обидно, что они не в состоянии развиваться дальше, поэтому они утешают себя мыслью о том, что развиваться нужно в глубь того, что уже есть, сужая горизонт до точки. Их право.
georgebgk; o.nikolaev; babys; farukshin; Гриффин; Lem0n; mickey.1cx; +7 Ответить
182. spe1c 5 26.06.17 09:35 Сейчас в теме
(181) Это всё хорошо, но каков ответ на вопрос из сабжа? Новое измерение и неклатреный индекс не подходит, как в сабже писали.
185. zarucheisky 26.06.17 10:21 Сейчас в теме
(182) Доступ к статистике через ТЖ не выполняя запрос скорее всего.
184. zarucheisky 26.06.17 10:20 Сейчас в теме
(181)

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

Про претензии в плане интерпретации кода собственного языка:
Зачастую все эти претензии суть кривого кода не в платформе, а в конфигурации.

Про баг с ошибкой запроса POST к данным формы:
Если Вы запустили тягомотный процесс и передали контекст формы на сервер, то клиент может зависнуть.
Это вполне ожидаемо.

Про многопоточность:
А что с легкостью позволяет создавать многопоточные механизмы?
Erlang, Scala? Да и, многопоточность в каком именно смысле Вам понадобилась?
Gilev.Vyacheslav; +1 Ответить
186. starik-2005 3052 26.06.17 13:17 Сейчас в теме
(184)
Если Вы запустили тягомотный процесс и передали контекст формы на сервер, то клиент может зависнуть.
Клиент точно зависнет, пока сервер не отработает. Но это не должно приводить к проблемам с формой (ошибка POST приводит к безоговорочному закрытию платформы).

По поводу интерпретации, то даже в PHP5 цикл работает быстрее, чем в 1С, не говоря уже о питоне или PHP7, в которых производительность выше.

По поводу многопоточности, что любой функциональный язык паралеллит процесс вычислений, так что можно сказать, что программист в этом случае даже не заморачивается - за него все делает интерпретатор или компилятор. Но если говорить об управляемой многопоточности, то в тех языках, где она используется прямо, есть и общие хранилища, и средства избегания коллизий - семафоры, мьютексы, блокировки. По-сути, СУБД для 1С - это как раз механизм, с которым одновременно работает множество инстансов 1С (сеансов), которые коллективно конкурируют за ресурсы, в связи с этим так много внимания уделяется блокировкам и разделителям, уровням изоляции и прочим механизмам обеспечения непротиворечивости данных. Для самого языка таких механизмов нет, что создает определенные трудности реализации алгоритмов распараллеливания вычислений.
187. zarucheisky 26.06.17 14:26 Сейчас в теме
(186) у меня к самой платформе в плане производительности "языкового" движка претензий нет.
>>что создает определенные трудности реализации алгоритмов распараллеливания вычислений
ИМХО, всё зависит от задач. Можно получить, например остатки и продажи параллельно, да еще и асинхронно, если оно того стОит.
188. starik-2005 3052 26.06.17 15:59 Сейчас в теме
(187)
у меня к самой платформе в плане производительности "языкового" движка претензий нет
Не поверите, но у меня тоже нет претензий, но есть сравнительная информация о том, что можно работать и на порядок быстрее. Вот, например, почему в файловой базе тест Гилева при режимах сбалансированной производительности и максимальной производительности не особо отличается (ИМХО, вообще не отличается), а в серверном варианте - в 1,5-2 раза (у меня на Ryzen 5 1600 в OnDemand - 24,5, а в Performance - 36,78)? Вроде одно дела делают, да?
190. Gilev.Vyacheslav 1915 27.06.17 00:02 Сейчас в теме
(181)
Так зачем использовать 1С? Какая разница, на чем написать анализатор логов?
может быть потому что не надо писать, уже есть готовые обработки анализа логов

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

конечно, те, кто в свое время остановился в развитии
на последнем инфостарте мы презентовали обработку, способную анализировать запросы на неоптимальности http://www.gilev.ru/#ConsoleGilevRu и выдавать готовые рекомендации по исправлению, фирма 1С и франчайзи пока к этому уровню не приблизились, может сначала догоните?

(188)
Вроде одно дела делают, да?
так разными способами в разной архитектурой да еще и с разным уровнем обеспечения возможности коллективной обработки данных

если же возвратиться к обсуждению 1С:Эксперта и в частности к решаемой задаче, то осталось ощущение что правильней провести ревизию условий задачи, похоже что важные акценты при трансляции сюда были потеряны
talych; Сурикат; zarucheisky; +3 Ответить
191. starik-2005 3052 27.06.17 08:54 Сейчас в теме
(190) дейстаительно, в задаче чтото не так, ибо без подмены запроса получить колво элементов за приемлемое время средствами 1с нереально.

А по поводу инструментов, которые уже есть - это хорошо. Но grep regexp написать в некотором количестве случаев будет банально быстрее. Ну и sed'ом изменить конфиг файлы тоже куда легче, чем открывать это в редакторе. А так - есть ЦУП, который много чего умеет, хоть и не так быстро.
194. Gilev.Vyacheslav 1915 28.06.17 10:18 Сейчас в теме
(191) есть наши инструменты, которые бесплатно с приемлемой скоростью парсят ТЖ (быстрее не надо), но из-за "политики фирмы 1С" их не замечать усложняют жизнь специалистам на 1С:Эксперте

откуда это вообще взялось "быстрее обсчитать логи тж"? это ложная цель

есть два класса задач - оперативные для оценки ситуации
и аналитические для реализации решений

с учетом того что исправленный код надо сначала а) написать б) протестировать в копии в) найти технологическое окно вкатить изменения в продуктив - обсчитать логи за 3 минуты или 10 минут погоды не делает вообще, даже цуп может сгодится
ну а качественно решать аналитические задачи можно только если собирать логи круглосуточно для полностью репрезентативной картины производительности (кроме наших инструментов я альтернативы не знаю)

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

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

не надо имхо на экзамене 1С:Эксперт требовать все больше и больше знаний (я то был на самом первом потоке) - это путь в никуда, в итоге получится специалист "по вершкам знаний", и ничего глубоко
Boulala; talych; Krio2; Shmell; Brawler; mitia.mackarevich; корум; Сурикат; KazanKokos; +9 Ответить
195. starik-2005 3052 28.06.17 12:45 Сейчас в теме
(194)
даже цуп может сгодится
Точно!

(194)
если же говорить про скорость обсчета логов, то во-первых победить в этой задачке сомнительный приз, так как это промежуточный этап
А вот тут не совсем. Этот промежуточный этап вряд ли будет однократным, т.к. отладка одних механизмов выкидывает в топ другие, которые сейчас вот прямо пока не видны. Экономить 20 минут один раз и 20 минут 100 раз - несопоставимые цифры. Для экспресс-анализа как раз grep лучше всего, но уметь им пользоваться - личное дело специалиста. Не умеет - пусть покупает сервисы, умеет - может и бесплатно проанализировать с помощью подручных средств (да и быстрее).

Как писали Стругацкие: "Инструкция - это для тех, кто не умеет". Вот те, кто не умеет, - пусть и пользуются средствами, которые это умеют за них. Но повышать уровень 1С-ников - задача необходимая, ибо какой эксперт может быть из человека, который в Linux ни в зуб ногой. А если уж разобрался, то и grep освоил.
talych; mickey.1cx; +2 Ответить
196. Gilev.Vyacheslav 1915 29.06.17 16:45 Сейчас в теме
(195)
Экономить 20 минут один раз и 20 минут 100 раз - несопоставимые цифры.

откуда такие цифры, что вы там сто раз делаете то?!! (в ужасе)

Для экспресс-анализа как раз grep лучше всего,
т.е. лучше потратить время на написание чем воспользоваться готовым?

Не умеет - пусть покупает сервисы
тут сразу два ложных посыла:

1. те кто покупают ничего не умеют -
и это ЛОЖЬ!

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

2. хорошие сервисы не бывают бесплатными
и фирма 1С в своей книге 1С:Эксперт тоже подпевает
но и это ЛОЖЬ!

наши сервисы типа http://www.gilev.ru/querytj/ дублируют цуповский функционал БЕСПЛАТНО, уже 6й год как

Андрей Бурмистров для наших курсов сделал такую обработку http://infostart.ru/public/557477/ - она мало того что бесплатна, так еще ваш grep такой экспресс-анализ не сможет сделать

"Инструкция - это для тех, кто не умеет"

ну и по поводу инструкций: чтобы делать не по инструкции, надо сначала научиться делать по инструкции

ибо какой эксперт может быть из человека, который в Linux ни в зуб ногой
возможно эксперт в 1С-технологиях или эксперт по Windows-технологиям...
talych; METAL; +2 Ответить
197. starik-2005 3052 29.06.17 16:59 Сейчас в теме
(196)
1. Откуда цифры? И это САМ Гилев меня спрашивает? Что, не в курсе про итерационный подход к решению проблем производительности? Есть запросы, который вываливается в ТОП 10. Он модифицируется так, чтобы работать быстрее. После этого в ТОП 10 могут оказаться другие запросы, которые вообще не входили в эту группу (полагаю, Вы в курсе, почему так, да?). В итоге весь анализ нужно еще раз произвести. И так далее до достижения того самого APDEX на уровне 0.98-0.99. Это не однократная работа по разору логов. И этот ТОП 10 запросов можно и дополнительными средствами разобрать, а можно и селектом к сохраненной профайлером в базе таблице длительности запросов.
2. Готовое анализирует что-то комплексно, создавая какое-то дерево представлений всего произошедшего, из которого нужно выковыривать данные. grep может сразу без дополнительного анализа по регулярному выражению отобрать нужные строки (например, запросы с включенной какой нибудь константой "МЕТКА_0001/2/3..."), получив их количество и общее влияние, если это необходимо. Да, научиться пользоваться регулярками несколько сложнее, чем ЦУП'ом, но оно того стоит. Кто не умеет, тот - редиска!
3. Бесплатно - это тоже не плохо, только зачем, если есть тот же ЦУП (раз уж занялись производительностью, то как без него, да?) Лень, конечно, никто не отменял, поэтому я не предлагаю отказываться от анализаторов запросов, предлагающих автоматически какие-то оптимизации, но это не касается архитектуры решения, в которой может быть проблема. Архитектурные вопросы такие механизмы не решают.
4. А инструкция - это в Вашем случае что?
198. herfis 506 29.06.17 17:07 Сейчас в теме
Вот что с одинэсниками linux животворящий делает. И это только grep/sed.
А если до awk доберутся? Страшно представить...
talych; корум; starik-2005; +3 Ответить
199. Gilev.Vyacheslav 1915 29.06.17 17:32 Сейчас в теме
(198) не думаю что уловили суть
(197) делаю вывод что нашим инструментом вы просто не пользовались
Бесплатно - это тоже не плохо, только зачем, если есть тот же ЦУП
может потому что:
а) бесплатно
б) настраиваются наши инструменты проще
в) анализируют быстрее и что важнее не создают рисков не стабильной работы продуктива

собственно мы пользовались ЦУП, выяснили недостатки и избежали их в своих инструментах
нам например при анализе на двух десятках серверов не надо постоянно переключаться между этими серверами, бегая в локальные базы по разным впн и т.п.

grep может сразу без дополнительного анализа по регулярному выражению отобрать нужные строки
вы думаете что проводите ликбез сейчас что ли? я вам показал обработку http://infostart.ru/public/557477/ которую запустил и увидел блокировки практически сразу, не требуется тратить время на написание выражений и фильтров, если конечно понимаете что такое рентабельность работ

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

мне тут один программист предложил переписать код конфигурации 1С на java, чтобы "работало быстрее", тоже "из ваших" - видимо можно объяснить все, но не всем...
METAL; KazanKokos; +2 Ответить
200. starik-2005 3052 29.06.17 17:46 Сейчас в теме
(199)
один программист предложил переписать код конфигурации 1С на java, чтобы "работало быстрее"
Кое-что можно и на Java переписать.

1. Инструментами, действительно, не пользовался - это ленивым нужно, я не из них.
По поводу экономии времени, то ответьте честно, сколько времени тратится на работы по оптимизации в среднем? Для разработки нагрузочного тестирования только 1 человек-месяц, если писать полный сценарий, а именно на этом настаивают "жирные" клиенты. Им не нужен полуфабрикат чего-то оценочно-прекрасного. Я, кстати, предварительно как раз люблю пользоваться именно тестом Гилева, а не какими-то стандартными нагрузочными тестами с миллионом окошек от 1С - тут Ваш продукт однозначно выигрывает, позволяя получить некоторую синтетическую цифру. Не так давно Филиппов что-то подобное реализовал (по крайней мере о запуске 25к фоновых заданий).
2. Блокировки - это важно, конечно, но они тоже поменяются после произведенных изменений (Вы же не будете говорить о том, что после всех измерений мы ничего не поменяли, да?) При анализе собирается много данных, часть из них более важны, часть - менее. Какие-то данные можно получить grep'ом (думаю, все), какие-то - в окошках потыкавшись. Все дело в том, к какому подходу привык. Тем более я юзаю в основном Linux'овые ОСи и мне там привычнее пользоваться и elasticsearch, и прочими механизмами, для которых есть хорошие инструменты анализа.
3. Куда уж нам до темных очков - у нас и так глаза красные)))
201. Gilev.Vyacheslav 1915 29.06.17 17:51 Сейчас в теме
(200)
По поводу экономии времени, то ответьте честно, сколько времени тратится на работы по оптимизации в среднем?
4 дня
Для разработки нагрузочного тестирования только 1 человек-месяц, если писать полный сценарий, а именно на этом настаивают "жирные" клиенты.
колоссальное количество денег на ветер
мне там привычнее
вот мы и выяснили настоящую причину требований преподавателя
204. starik-2005 3052 29.06.17 17:56 Сейчас в теме
(201)
вот мы и выяснили настоящую причину требований преподавателя
А что не так? Кому-то привычнее одни инструменты, кому-то - другие. Кто-то к Linux'у привык и мастдай его бесит, кто-то - наоборот не может разобраться с Linux, предпочитая тыкание мышкой в окнах настройки командной строке. Для меня точно командная строка куда быстрее, чем тыкание в сотнях окон.

4 дня - это хорошо. Я как-то работал в конторе, куда Вас приглашали. Не в курсе, сколько дней там ушло, но я особой разницы не заметил - все и так работало нормально. Но я в то время не занимался производительностью - я занимался математикой.

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