PT
Ну заведите виртуальный диск в оперативке что ли я не знаю.
Size: a a a
2020 December 05
PT
И сделать так, чтобы таблица "актуальных" остатков зеркалилась в отдельную скл базу на этом вирт. диске. Возможно 1С : Дата акселератор будет полезен ещё.
АМ
Годная идея с точки зрения производительности, но по надежности может быть не очень.
Проще тогда на файловой базе сделать
Проще тогда на файловой базе сделать
КЧ
За полдня редис можно развернуть и код по работе с ним написать :)
Если человек из экосистемы 1С не вылезл то почти гарантировано у него винда, а значит он полдня только с докером будет разбираться, а потом плюнет и уйдёт в запой =)
AC
Вопрос в том, что не хочется в принципе нагружать базу лишними запросами остатков. Отсюда и вопросы про кеширование.
Понятно, что я сейчас занимаюсь некоторым "фантазированием" на тему, а что если. Это связано с тем, что есть очень мало информации по предполагаемой нагрузке, а я хочу перестраховаться на случай если нагрузка правда будет большая.
Понятно, что я сейчас занимаюсь некоторым "фантазированием" на тему, а что если. Это связано с тем, что есть очень мало информации по предполагаемой нагрузке, а я хочу перестраховаться на случай если нагрузка правда будет большая.
преждевременная оптимизация — корень всех зол. © Д. Кнут
АМ
преждевременная оптимизация — корень всех зол. © Д. Кнут
Вопрос не в оптимизации, а в самом подходе. Пойти по простому пути я знаю как. Я хотел услышать мысли про альтернативные подходы. Есть ли они и на сколько вменяемые.
EM
Кирилл Черненко
Если человек из экосистемы 1С не вылезл то почти гарантировано у него винда, а значит он полдня только с докером будет разбираться, а потом плюнет и уйдёт в запой =)
Если винда, то можно и без докеров. Apache + php + pRedis + Redis. Если хоть немного знаком с веб-разработкой это все делается за час с чаем по мануалам.
EM
не самый свежий редис, но для простого кэша и этих возможностей за глаза
GV
А memcached не подойдёт что ли?
NG
А memcached не подойдёт что ли?
да можно и его. только он тоже не на 1с :)
EM
плюсом для php есть прикольный redis-админ с гуём
EM
А memcached не подойдёт что ли?
лично я, как человек не выросший на memcache/d испытал некоторый когнитивный диссонанс что memache и memcached это хоть и похожие но разные вещи, и регуглярно испытвал проблемы с мануалами, и внезапно отвалившимся библиотеками на хостинге, после внезапного обновления) Нейминг просто на отличненько) Потому плюнул и в очередном релизе приложения перешел на редис
GV
да можно и его. только он тоже не на 1с :)
Так у него клиент подо все есть. Может найдется псих который и для 1С напишет компоненту
NG
Так у него клиент подо все есть. Может найдется псих который и для 1С напишет компоненту
сере-кхе-кхе-бряная кхе-пу-кхе-кхе-кхе-ля
GV
сере-кхе-кхе-бряная кхе-пу-кхе-кхе-кхе-ля
При наличии клиентской библиотеки для пакетного менеджера эти компоненты на коленке делаются хоть пачками..
ss
я хотел практический совет, а не теоретическое рассуждение
Практический совет по кешированию остатков:
1. Повторное использование сеансов в http-сервисе
2. Служебный справочник с одним элементом - версия этого элемента = флаг чтения остатков из БД или из кеша
3. Модуль повторного использования с функцией возврата остатков, где один из параметров функции - версия справочника из п.2
Запрос на получения версии справочника из п.2 легкий и быстрый, модуль повторного использования сам будет отслеживать, кеш возвращать или остатки из СУБД брать. Но надо понимать, что обновление версии элемента справочника из п.2 - это узкое место параллельности работы с остатками. Т.е. данная схема подходит в том случае, если остатки меняются намного реже, чем идут запросы на чтение остатков.
1. Повторное использование сеансов в http-сервисе
2. Служебный справочник с одним элементом - версия этого элемента = флаг чтения остатков из БД или из кеша
3. Модуль повторного использования с функцией возврата остатков, где один из параметров функции - версия справочника из п.2
Запрос на получения версии справочника из п.2 легкий и быстрый, модуль повторного использования сам будет отслеживать, кеш возвращать или остатки из СУБД брать. Но надо понимать, что обновление версии элемента справочника из п.2 - это узкое место параллельности работы с остатками. Т.е. данная схема подходит в том случае, если остатки меняются намного реже, чем идут запросы на чтение остатков.
VP
sdf1979 sdf1979
Практический совет по кешированию остатков:
1. Повторное использование сеансов в http-сервисе
2. Служебный справочник с одним элементом - версия этого элемента = флаг чтения остатков из БД или из кеша
3. Модуль повторного использования с функцией возврата остатков, где один из параметров функции - версия справочника из п.2
Запрос на получения версии справочника из п.2 легкий и быстрый, модуль повторного использования сам будет отслеживать, кеш возвращать или остатки из СУБД брать. Но надо понимать, что обновление версии элемента справочника из п.2 - это узкое место параллельности работы с остатками. Т.е. данная схема подходит в том случае, если остатки меняются намного реже, чем идут запросы на чтение остатков.
1. Повторное использование сеансов в http-сервисе
2. Служебный справочник с одним элементом - версия этого элемента = флаг чтения остатков из БД или из кеша
3. Модуль повторного использования с функцией возврата остатков, где один из параметров функции - версия справочника из п.2
Запрос на получения версии справочника из п.2 легкий и быстрый, модуль повторного использования сам будет отслеживать, кеш возвращать или остатки из СУБД брать. Но надо понимать, что обновление версии элемента справочника из п.2 - это узкое место параллельности работы с остатками. Т.е. данная схема подходит в том случае, если остатки меняются намного реже, чем идут запросы на чтение остатков.
Для особо взыскательных есть вариант и без создания горлышка, асинхронный так сказать в плане записи признака измененности остатков
ss
Vassily Poupkine
Для особо взыскательных есть вариант и без создания горлышка, асинхронный так сказать в плане записи признака измененности остатков
Можно и в фоновое вынести
VP
sdf1979 sdf1979
Можно и в фоновое вынести
Нельзя