Может кто знает, как настроить совместную работу v7DBNet и 1sqlite?
Первый запрос к таблице всегда очень медленный, прям катастрофически, как черный,
а затем, видимо после кэширования таблицы, последующие запросы уже летают нормально.
v7DBNet 2.5.1.3
1sqlite 1.0.2.6
Если запросы по сети, то никак.
Я не работал так, но есть вероятноястность что увеличение кэша в v7DBNet и предварительный прогрев (запросами по актуальным данным) для кеширования таблиц, то это ускорит.
ИМХО, ускорить на холодном кэше это невозможно.
Ну, я так работаю. Не вижу проблем. Первое обращение к таблице, да, тянется по сети, потом из кэша. Но совсем не как чорный, гораздо быстрее. Кроме увеличения и прогрева кэша варианты — только изменение архитектуры данных и/или робот-сеанс ('регламентные' задачи и очередь тяжёлых предварительных расчётов) на 'сервере'.
Ой, ты мне выстрелил в печень, "тяжелые предварительные запросы на сервере", жуть какая...
Это же придется котика в 7.7 рисовать, который отрезанные тестикулы пытается вылизывать...
Неть! Моя на такое не пойдет, разве что расстерялять пообещают, если не сделаю, или пообещают сделать таким же котиком. оО
Цитата: Djelf от 12 августа 2025, 16:49Если запросы по сети, то никак...
Спасибо, Djelf, именно Вас я и хотел услышать.
Цитата: Arbuz от 13 августа 2025, 17:10... Но совсем не как чорный, гораздо быстрее...
Номенклатура 20 000, первый банальный запрос like около минуты зависает, чес слово.
А робот это интересная мысль, только как его реализовать без отдельного потока?
Туплю, попробую завтра через обработку ожидания.
Цитата: item от 13 августа 2025, 22:36Цитата: Arbuz от 13 августа 2025, 17:10... Но совсем не как чорный, гораздо быстрее...
Номенклатура 20 000, первый банальный запрос like около минуты зависает, чес слово.
А робот это интересная мысль, только как его реализовать без отдельного потока?
Значит надо делать локальный файловый кэш на базе 1sqlite и использовать fts поиск триграм, будет невероятно быстро, ну кнопку повесить "Обновить кэш"
https://forum.mista.ru/topic/886147#69
Цитата: item от 13 августа 2025, 22:36Номенклатура 20 000, первый банальный запрос like около минуты зависает, чес слово.
Специально у себя проверил: сеть 100мбс, холодный старт на клиенте, 33390 элементов в номенклатуре
первый запрос 3540 миллисекунд
SELECT DISTINCT
Товары.code Код,
Товары.id [Товар :Справочник.Номенклатура]
FROM Справочник_Номенклатура as Товары
JOIN Справочник_Единицы AS Единицы
ON Товары.id = Единицы.parentext
WHERE Товары.isfolder=2 and Товары.ismark <> '*'
AND Товары.descr LIKE '%92023%' ESCAPE '@'
ORDER BY Товары.id DESC
последующие, менее 200 мсек
Собственно, единицы джойнятся для запросов типа
SELECT DISTINCT
Товары.code Код,
Товары.id [Товар :Справочник.Номенклатура]
FROM Справочник_Номенклатура as Товары
JOIN Справочник_Единицы AS Единицы
ON Товары.id = Единицы.parentext
WHERE Товары.isfolder=2 and Товары.ismark <> '*'
AND Товары.descr LIKE '%81233%' ESCAPE '@'
AND Единицы.ШтрихКод LIKE '%480012%'
ORDER BY Товары.id DESC
Только сейчас заметил ;D , что джойнится всегда, ну, на скорость не влияет, оптимизатор скулайта делает своё дело и ладно...
<OFFTOP>
Цитата: Djelf от 13 августа 2025, 21:05Ой, ты мне выстрелил в печень, "тяжелые предварительные запросы на сервере", жуть какая...
Антон, что-то ты в последнее время стал как-то излишне éдок, что ранее за тобой не наблюдалось в таком масштабе. ??? Ты там в порядке? Безо всякой издёвки. Ты нам нужен, такими людьми не разбрасываются...
</OFFTOP>
Да, если бы не Антон - где бы мы были?! В Караганде какой нибудь. А так - надо для него хвалительный день устроить
Увы, с возрастом обычно становишься все вреднее и упрямее.
У меня это видимо еще в начале этапа моего превращения в монстра типа Волшебника ::)
Мечта: заведу свой форум и буду всех там банить, не меньше 10 пользователей в день!
Не беспокойтесь, я обычно ничего из того что накипело не отправляю, бывают исключения, когда зож уже нарушен на 100500й порядков...
Та не! Это ты загнул! Ты же книгу по 8-ке не написал ещё? От протеинов не отказался (и других излишеств)? Устойчивой группой подпевал и подлизал (эээ), в которых поплёвываешь и попинываешь, не окружил свою высочайшую особу? Так что не рассчитывай. ;D
Искренне извиняюсь перед топикстартером за увод темы в неконструктивное русло.Не помню как там в оригинале но у меня в таблице номенклатуры
DESCR |object description |C |100 |0
и сам dbf справочника весит около 12 МБ. У меня есть подключения на 10 Мб/с и там первый запрос, да, где-то около 30 секунд.
Цитата: Arbuz от 14 августа 2025, 16:57...извиняюсь перед топикстартером за увод темы...
Ты тоже, Arbuz, вредничаешь.
Общайтесь на здороаье.
Для предварительного разогрева ведь like не нужен, какой запрос будет наиболее быстрым и эффективным?
Цитата: item от 14 августа 2025, 20:31Для предварительного разогрева ведь like не нужен, какой запрос будет наиболее быстрым и эффективным?
Да чорт его знает как Виртш сделал кеширование, декомпилировать и копаться так себе удовольствие...
Немного мыслей вслух...
Частичное кеширование объекта очень маловероятно, это потребовало бы для каждого поля в объекте создавать отдельную структуру. Отметаем этот вариант, как тормозной и очень сложный в реализации.
Следовательно объект должен бысть кеширован целиком, но без табличной части, она должна быть кеширована отдельно.
Что по факту делает лайк? Он перебирает все объекты и для каждого проверяет соответствие. Это идет в цикле.
Т.е. у нас есть небольшой лаг связанный с проверкой лайка и позиционированием на следующий элемент.
И вот этот лаг, вроде бы совсем небольшой, микросекундный, может в цикле при сетевой задержке и приводить к тормозам при запросе без прогрева.
Видимо просто select descr from справочник_номенклатура, или не descr, а id, будет эффективным для прогрева.
И! Можно затем проверить любое другое поле справочника на скорость выборки, после прогрева, если кеширование частичное, то будет лаг, если полное, то будет одинаково быстро по каждому полю справочника.
Еще один момент: чорный запрос из 1с может быть более эффективен для прогрева, чем прямой запрос 1sqlite, я это не утверждаю, но это возможно. Это надо проверять.
Цитата: item от 14 августа 2025, 20:31Для предварительного разогрева ведь like не нужен, какой запрос будет наиболее быстрым и эффективным?
что-то типа, но он по определению будет не самым быстрым, а наоборот:
SELECT MAX(rowid) AS cnt FROM Справочник_Номенклатура
descr нельзя использовать, т.к. это индексированное поле и wirth кэширует страницами, то нужен полный скан таблиц. И я неправильно понял про скорость — max(rowid) будет самым быстрым полным сканом.
Мне кажется, что любой запрос с перебором будет не эффективным с точки зрения клиента.
Все рано весь справочник будет передан на клиент, возможно что объект Запрос этот момент ускорит.
Это включит другой механизм платформы, я точно это не знаю, но это возможно.
Мы туда не залезали... это неисследованная область клюшек, хрен знает где это вообше находится и в какой библиотеке... я не нашел...
В общем, парни, результат у меня такой.
Сетка 100Мб, сервер X3440, SSD бюджет, 8 юзеров, номенклатура ~25000.
Протестированы четыре запроса:
#1. "SELECT descr as Наименование, id as [Элемент :Справочник.Номенклатура] ..."
#2. "SELECT id as [Элемент :Справочник.Номенклатура] ..."
#3. "SELECT MAX(rowid) AS cnt FROM [Справочник.Номенклатура]..."
#4. Штатный "ТекущийЭлемент = Справочник.Номенклатура.ТекущийЭлемент| Без итогов"
Результаты первичных запросов практически идентичны, все укладываются по времени в 50-60 сек
(#1 и #2 ~ 55 сек, #3 ~ 50 сек, #4 ~ 60 сек), и все кэшируют таблицу полностью.
Результаты повторных запросов разнятся относительно существеннее:
#1 ~ 0.27 сек, #2 ~ 0.21 сек, #3 ~ 0.18 сек, #4 ~ 4.5 сек.
В общем, нет смысла кэшировать descr, достаточно только id,
а поскольку запрос #3 чуток быстрее, я на нём и остановился.
Респект, друзья, от начинающего 1sqlite-щика.
Какие вы все умные!
Цитата: item от 28 августа 2025, 15:22В общем, парни, результат у меня такой.
Результаты первичных запросов практически идентичны, все укладываются по времени в 50-60 сек
(#1 и #2 ~ 55 сек, #3 ~ 50 сек, #4 ~ 60 сек), и все кэшируют таблицу полностью.
Результаты повторных запросов разнятся относительно существеннее:
#1 ~ 0.27 сек, #2 ~ 0.21 сек, #3 ~ 0.18 сек, #4 ~ 4.5 сек.
Тест отличный!
Результаты в пределах погрешности.
Но 60 секунд на заполнения кэша не очень комфортно...
1. Что выдает по скорости копирование этих файлов по смб?
25000 записей могут быть очень разным по размеру файла.
2. Если есть длинные строки? Науке не известно кеширует ли их Wirth.
Можно проверить на копии, просто грохнуть длинные строки (это предположение, возможно такого кэша нет).
Этот тест надо делать в разделенном режиме, 2-3 пользователя минимум, монопольный режим очень сильно отличается по скорости.
3. Можно включить монопольный режим доступа в sqlite, это сильно ускорит кеширование, но кто-то может отвалится на транзакции.
Но если это ускорит наполнение кэша раз в 10, то это будет довольно эффективно и не будет сильно заметно всем остальным пользователям.
Ну... или вообще забить на это и работать по rdp?
Вроде я все мои идеи на текущий момент описал, не понятно что еще придумать.
Кидайте идеи...
Цитата: Djelf от 29 августа 2025, 15:223. Можно включить монопольный режим доступа в sqlite
Это что имеется в виду?