Всем добрый день!

Собственно сабж.

ТЗ формируется во внешней обработке 30 минут.
Нужно сформированную ТЗ так сохранить, чтобы в следующие разы она загружалась 10 секунд (или ещё быстрее).

Сейчас использую ЗначениеВФайл (один раз, чтобы сохранить) и ЗначениеИзФайла (столько раз, сколько надо).
Загрузка в ЗначениеИзФайла занимает 70 секунд. Хочется побыстрее.

Никак

Временное хранилище

Общий модуль с галочкой Повторное использование, но это если памяти достаточно

ЗначениеИзФайла должно быть тоже быстро, если нет индексов или версия платформы 8.3.10 или 8.3.17

(4) И нет ссылок на объекты

Заданием формировать ТЗ, когда надо, по нужному расписанию или событию.
Запихнуть в РС и брать из него, когда надо.

НаборЗаписей = РегистрыСведений.РС.СоздатьНаборЗаписей();
НаборЗаписей.Отбор.КакоеТоИзмерение.Установить(КакоеТоИзмерение);
НаборЗаписей.Загрузить(ТЗ);
НаборЗаписей.Записать();

(6) Имхается скоро в платформе 1С реализуют программные РС

(0) Голосую за табличку в скульной базе. Хоть в mySQL? хоть в MSSQL хоть еще какая.

(4) 8.3.16.1148

(4) 70 секунд. В принципе быстро. Но медленно. Хочется чтобы прямо ти-ууу.

(0) поставить нормальные диски и быстрый проц

хранить на рамдрайве

(5) Никаких ссылок. Только строки. Колонок = 19 штук.

(9) индексы есть?

(13) а строк?

(11) Не вариант. На разных машинах будет запускаться. Просто надо выжать максимум скорости. 1 300 000 строк в ТЗ

(14) Индексов нет

(16) что значит "наразных машинах"? нафиг оно на клиенте вообще?

(0) В одном сеансе? Или нужно один раз сформировать и чтобы из разных сеансов можно было загружать?

(18) В том плане что на нескольких разных серверах.

Разбить не несколько файлов, грузить в несколько потоков, потом соединить

"Никаких ссылок" "1 300 000 строк в ТЗ"
т.е. это не ТЗ, это txt

(19) Открыл обработку - сформировал ТЗ - сохранил. Полежал, отдохнул и поехали: снова открыл обработку и мгновенно (максимально быстро) загрузил ТЗ.

(22) Ну как бы наверное да. Но у меня этот объект в отладчике обзывается ТаблицаЗначений.

(24) если это твой отладчик поменяй, но нет? )) жесть

(23) Если в одном сеансе, тогда (3). При благоприятных условиях она вообще будет оставаться в памяти (т.е. все мгновенно). В неблагоприятных условиях будет автоматическая сериализация-десериализация.

(26) + При этом код абсолютно прозрачный. Без каких-то явных сохранений и загрузок.

(27) И как туда (в этот общий модуль) правильно написать текст чтобы всё получилось именно так как задумано?

(28) тебе надо начать с Радченко или купить у ДенисЧ

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

Всем спасибо за участие а dka80 за подсказку. Пошел пробовать.

история
alf2006x     18:07
alf2006x     30.06.20
alf2006x     01.04.20
alf2006x     17.03.20
сделайте кнопку или виджет

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

Смотрю на ветку и понимаю, что что-то не то

Как сохранить огромную ЗП на севере чтобы мгновенно ее разгрузить

у меня пустая Тз 1М строк из строки внутненней создается за 1с.

(0) создай регистр сведений и храни в нем

(31) Просто вопросов мало.
Но уж если возникают - точно знаю куда надо идти. )

(34) У меня файл, из которого я вытягиваю мою ТЗ весит 700 Мб.
ЗначениеИзФайла() замерял секундомером: получается 60 (+/- 5) сек.

Еще не проверял, но вдруг подумал, чисто теоретически: если создать параметр сеанса
с типом ХранилищеЗначения (вдруг оно целиком в памяти будет храниться?)
Это как долго меня тут будут пинать за такие мысли?

(33) :-)

(0)
Мне кажется, что сама такая постановка задачи говорит, что планируется какой-то дикий закат солнца вручную.
С ТЗ то что потом делают хоть?

(38) И временное хранилище и параметр сеанса хранятся одинаково - в памяти сервера 1с, пока он не сбросил ее в сеансовые данные.

(38) ХранилищеЗначения -  таже строка внутреняя.

(42) нет . соврал. строка внутренняя, сжатая deflate

Как показала практика - строковые функции при поточном чтении работают очень быстро.
К чему я это.
ТЗ преобразуется в csv файл.
Потом как то хранится, желательно в БД не помещать, а в какую нить шару специально для этого созданную.
Потом файл потоком считывается и переводится снова к виду ТЗ.
Но нужно понимать, что тупое добавление 1кк строк в ТЗ займет секунд 5. (НоваяСтрока = ТЗ.Добавить() я про это)
Само чтение построчное - 2-3 секунды
Строковые функции преобразования несколько секунд.
ИМХО в лоб чисто средствами платформы я хз что еще быстрее предложить. Но в 10 секунд мысленным экспериментом, если будут только функции СтрРазделить и поячейное обращение к колонкам строки ТЧ - уложиться можно.
Если делать промежуточную структуру с ЗаполнитьЗначения свойств то еще пара секунд сверху.

(0) Если не получится сделать так как предлагают выше кури тему в вот каком направлении: если тебе смотреть-редактировать - подсасывай с сервера динамически, если обработка всего этого - делай на сервере.
При хранении в хранилище сжатие может как сработать в плюс, так и в минус - нужно пробовать и замерять.
Если структура ТЗ статичная - я-бы использовал РС.

(38) в сторону сжатия можно подумать. Сжатие может быть быстрее передачи между сеансами несжатого

Попахивает кривой архитектурой...

(47) и очень сильно

это так себестоимость сейчас считают?

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

(40) Да не, не похоже. Суть простая. Есть поставщики туруслуг (в данном случае гостиниц). Хотелбук, Островок, Броневик (и многие другие).
Все имеют свой АПИ для раздачи интересующей информации. В том числе массивов со странами, городами и собственно гостиницами.
Мы всё это матчим с объектами в нашей базе (например по примерному совпадению соответствующих геокоординат, либо по другим признакам).

И вот один из поставщиков отдаёт всю инфу в виде мегамассива (всё-превсё включено: и страны и гостиницы и адреса объектов и телефоны и описание, короче - полный фарш). Отдаёт JSON размером 10 629 381 Мб (~10,5 Гб). Вот это файло читается построчным ЧтениемJSON 30 минут. Читается и впихивается обработкой в ТЗ (а куда ещё?). А дальше идет работа в полуавтомате. Получеловек-полуандроид, глазками (и частично интеллектом), проверяет что найденный объект в нашей базе и есть то самое что мы матчим с загруженными данными. Если сомнений нет - тычет галку и оно привязывается путем сопоставления кода поставщика и объекта в базе (РегистрСведений). К слову, форма естессно управляемая.

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

(45) В целом согласен. РС - надежный и практически мгновенный вариант.
Тут уже порядок исчисления уходит в миллисекунды.
Возможно именно так и буду реализовывать.
Видимо изначально задача выглядела так, что не подразумевала какие-либо доработки конфигурации.
И до последнего мозг бьется за то чтобы конфу не трогать. Если ТЗ будет грузиться хотя бы 30-40 секунд,
то ну и ладно. Но морально я уже готов на РС.

Нормализовать данные и хранить в регистре сведений, читать выборками.

(53) Да, да, спору нет. Тут одни плюсы. В том числе динамическое считывание (это же имеется в виду под "выборками"?).

(51) Я читаю большие CSV-файлы запросом ADODB.Recordset в ТЗ. ТЗ в текстовый файл сохраняется методом Записать в СКД. И то и другое работает тоже очень быстро.

(55) Интересная мысль. Сюда ещё не думал )

(55) Тока не понял что за метод "Записать" в СКД?

(57) Примерно так:

        Результат = Новый ТабличныйДокумент;

    СхемаКомпоновкиДанных = ЭтотОбъект.ПолучитьМакет("Макет");
    КомпоновщикМакета = Новый КомпоновщикМакетаКомпоновкиДанных;
    МакетКомпоновки = КомпоновщикМакета.Выполнить(СхемаКомпоновкиДанных, СхемаКомпоновкиДанных.НастройкиПоУмолчанию);
    ПроцессорКомпоновки = Новый ПроцессорКомпоновкиДанных;
    ПроцессорКомпоновки.Инициализировать(МакетКомпоновки, , , Истина);
    ПроцессорВывода = Новый ПроцессорВыводаРезультатаКомпоновкиДанныхВТабличныйДокумент;
    ПроцессорВывода.УстановитьДокумент(Результат);
    ПроцессорВывода.Вывести(ПроцессорКомпоновки);

    Результат.Записать(КаталогЛокальный + ИмяФайла, ТипФайлаТабличногоДокумента.TXT);

(58) А где тут ТЗ?

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

(59) ТЗ в СКД. Читаешь свою таблицу, а выводишь текстовое пользовательское поле такого типа Колонка1+";" + Колонка2+";" и т.д.

(61) Это чтобы оно стало CSV?

(62) ну да, сохраняешь в текстовый файл с разделителями, а потом читаешь запросом.

(61) А этот формат где настраивается? В макете?

(64) вот пример поля ТЕКСТ из реальной обработки:

Код + ";" + МагазинКод + ";" + Формат(Цена, "ЧЦ=12; ЧДЦ=2; ЧН=0; ЧГ=0") + ";" + Строка(Выбор
    Когда ДнейДоставки > 99
        Тогда -1
    Иначе ДнейДоставки
Конец) + ";" + Строка(ЕстьКП) + ";" + Строка(СогласовыватьЦену) + ";" + Формат(МинЦена, "ЧЦ=12; ЧДЦ=2; ЧН=0; ЧГ=0") + ";" + Формат(Остаток, "ЧЦ=12; ЧДЦ=0; ЧН=0; ЧГ=0") + ";"

(65) Мощно. То есть колонка в ТД будет всего одна, правильно?

(65) Никогда не использовал "Формат()" в запросе. Быстро работает?

(66) выводится только пользовательское поле ТЕКСТ с разделителями в табличный документ, который потом записывается в csv-файл методом записать

(67) это не в запросе, это пользовательское поле в СКД. В запросе у тебя поля твоей ТЗ, возможно с отборами. Кстати и текстовый файл можешь читать не весь, а с установленными отборами

(69) оригинально

Скоро вернусь (уходит засучивая рукава и с блестящими от внезапно нахлынувшего интереса глазами)

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

(72) Пользователи похоже под спидами - очень быстро работают.

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

Весело тут у вас.
Опять магия ADO появилась.
Причем, абсолютно зря.

(51) в РС запиши этот файл и пускай хоть обчитаются. НаКлиенте всё равно больше 10-20-50 строк за раз невозможно видеть.

+(76) открытие будет от 0.01 до 5 секунд, смотря насколько печально всё с сервером.

(76) не файл, а таблицу. извините.

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

а почему Нельзя json прочитать во внешнюю sql базу и там с ним работать? тогда и грузить ничего не надо.

(75) а свой вариант?
PS тут не только АДО, тут и например в РС и подтягивать порциями предлагают, что имхо может взлететь

(81) Тогда проще создать "универсальный РС" с кучей Колонка1, Колонка2 и т.д. и его использовать.
А в какой колонке что и по какой индексированной отбирать хранить отдельно

(65) аццкий код. Функционала с гулькин нос, а читать и изменять такой код чрезвычайно неудобно

Автор, ты страдаешь какой-то ерундой. Погугли как устроены онлайн-карты на уровне БД, и делай что-то подобное

(0) Позови 1С-архитектора. Да просто 1Сника хотябы чуть чуть думающий над архитектурой.