8.х РОЗ Нуждаюсь в совете по 1С Розница

Добрый день, форумчане! В общем мне нужен совет знатоков по следующей ситуации.
Есть РИБ с основным сервером 1С розница в центральном офисе компании, дальше есть две с небольшим сотни магазинов которые обмениваются с центральным сервером, каждая база магазина хранит в себе только актуальные для нее данные.
Так вот проблема с БД-ых который находятся на узлах магазина. Сложность в том что в магазине работаю с этой базой 3-5 клиентов (ПК) база файловая, находится в "шаре", на каждом ПК стоит ключ клиентской 1С. Самая большая проблема наверное заключается в том что размер файла БД на данный момент составляет.... барабанная дробь... 6 - 8 Гб
И уменьшить эту байду не получается потому как в базе содержится огромное количество справочников с огромным количеством символов.
В этой ситуации ПК "сервер" работает с базой "худо-бедно" а вот клиенты тормозят, что при просмотре таблиц и справочником и документом, или при редактировании посредством торгового оборудования (сканеры ШК) короче базе не хватает ресурсов железа что клиентской что серверных тачек.
Нуждаюсь в совете что можно сделать с этим.
Я понимаю нужду в SQL , но высшие Шефы не пойдут на такие растраты. для них купить 4 клиентских ключа 1С на магазин уже растраты.
Я думал может можно поставить все на Postgre SQL вроде как он бесплатный, поправьте если я ошибаюсь.
Также думал про тонкие или псевдотонкие "толстые клиенты", так как вроде при работе из под терминальной сессии база нагружается меньше чем при работе в "шаре". Как думаете актуально ли? Какие стоит посмотреть менее баксозатратные или бесплатные варианты (только не с краками и пр...)
Уменьшить базу в ближайшее время не получится по размеру, есть только перспективный вариант вынести некоторые справочники и регистры сведений в облако, которое разметим в И-нете, оттуда будет с ними работать и клиент 1С.
А есть еще один момент. База хранит в себе все товародвижение за весь период существования. Хочется узнать есть ли вариант в 1С Розница архивировать старые периоды. Поставить точку актуализации, база пересчитает итоги, запишет их на какую-то дату а все старые данные либо удалит либо создаст архив БД где-то.
Если мои вопросы показались примитивны или некорректно заданы, или требуется еще какая-то информация просьба отпишитесь об этом и поймите меня, я не специалист 1С не программист 1С, я просто технический специалист, которому требуется совет гуру.

И еще вопрос: есть ли какие-то программные средства для замера производительности БД. Типа бенчмарка, хочется сравнить на примере одной БД какой она была и какой она стала, а также зависимость от терминала и "шары" , клиента и сервера. Спасибо!

1) Postgree - бесплатен. Но чтобы работать с ним все равно нужен сервер 1С. А это деньги. 42 000 рублей на один сервер. (Вариантов работы "мимо ключей" мы ведь не рассматриваем?)

2) В рамках одной локалки, особой разницы между тонким клиентом и толстым клиентом вы можете не почувствовать. Т.к. основная "затыка", как правило, происходит не на уровне транспорта пакетов (сети) а на уровне обработки бааааальшого файла БД.

3) Есть вариант без перехода под трехуровневую архитектуру ускорить работу. Гуглите "RAM диск". Но для этого понадоиться компьютер с реально большим объемом ОЗУ (в вашем случае 8 + 2-4 Гб), достаточного чтобы внутри ОЗУ организовать "виртуальный диск" + очень смутные перспективы стабильности.

4) А развернуть БД на стороне центрального офиса на базе хорошего сервера и подключать людей к БД посредством WEB интерфейса, тонкого клиента, RDP ? Чем плох вариант?

5) Бенчмарки? Ну а тупо написать обработку по перепроведению 20-30 документов с выводом времени в начале и конце работы программы? Там всего то 10-20 строк кода потребуется.

В общем то да. Терминалки - дорого. А вот 50 мбит канал - это зависит от офиса где сидят. Кое где в дефолт сити, например - это вполне себе вменяемые деньги для юрика.
Ну что можно предложить?
1 - анализировать БД. Нечто нужны все все все движения? Может достаточно движения иметь за последний год, а предыдущие перенести как типовым решением "остаткми" - резко уменьшив объем БД.

2 - посмотреть WEB интерфейсы, если в них есть все, чем пользуются удаленные склады - пробовать переводить (опять же, нужно смотреть на возможности центрального сервера, потянет ли 200 коннектов?)


Причем второе мне кажется более кошерным т.к.
1) Не нужно будет 100+ баз. Одна база с разделением по регионам.
2) Много проще обслуживать (одна база, централизованное управляемое размещение, SQL и прочее)
3) "Правильные технологии", благодаря котомы развитие компании не "упрется" завтра в "злобных программистов" (в технически-ИТшные вещи).
4) "Правильные технологии" которые повысят "вкусность" специалиста на рынке труда (ну руководству на докладе естественно этого не говорить :angry: )

Не вариант, т.к. если в магазине отключат И-нет то торговля встает раком, поэтому все пересадить на терминалки не имя локальной базы - голяк полный.
где можно достать постгресс заточенный под 1С. Есть ли опыт у кого с каким либо бесплатным Терминальным сервером?

развернул все на бесплатном postgresql ))) буду ждать результатов, но это правда пока что тестовая база и х.з. как замерить производительность (программист в отпуске)
и все таки актуален вопрос про терминальный сервак.
А еще не скинете мне ссылку на прайс лист 1С Серверной версии + 5 клиентов ?

прайс не нужно, нашел у партнеров Раруса )))
подскажите плиз, если я на обьекте разворачиваю базу на постргре (который бесплатен)
то мне остается заплатить только :
4601546080882 1С:Предприятие 8. Клиентская лицензия на 5 рабочих мест руб. 18 000
и
4601546080950 1С:Предприятие 8.2 Лицензия на сервер руб. 42 000

Я правильно понял?

в магазине максимально работают 5 машинок с базой (это в самом большом)
а в мелких (касса + менеджер + товаровед) 3 шт.

Сейчас клиенты (5 машинок в магазине) уже работают?
Она что, у вас работают "мимо" лицензии? Или же у вас для магазинов уже имеется лицензии 1С?
Если да, то только 42 000 рублей на сервер.

И да. Еще парам моментов:
1) Можно ведь попробовать развернуть БД на бесплатном (то есть почти даром) MS SQL Express (правда там есть ограничения на размер БД и заюзываемое железо) - но ИМХО секаса с SQLем меньше чем с Постгри (уворачиваюсь от несвежих томатов).

2) А если попробовать бесплатный вариант DB2? Нужно пилотно пробовать, тестить, гонять производительность, следить за стабильностью. Может все же получше чем Postgre (и снова прячусь под стол от томатов).

в магазинах клиентские ключи есть все верно.
1) базы по 6-8 Гб в MS SQL Express не прокатят =( и уменьшить их размер пока не видятся возможным в ближайших перспективах.
2) По поводу DB2 вот не знаю попробовать можно, а есть ли разница особая между ним и постгре? По тестам, как я читал, в коде постгре ошибок 1 на 35000 записей, а в DB2 1 на 10000 и я не уверен в бесплатности этой СУБД в корпоративных целях.

а под бесплатной DB2 вы имеете ввиду : "DB2 Express-C"?

Да. "DB2 Express-C"
Но если с Postgre из личных знакомых опыт работы имел лишь один человек (и нифига доволен не остался), то с DB2, из личных знакомых - и того меньше (то есть ноль).

Тут уж практика покажет, канает/не канает.
Нужно просить руководство чтобы дали один магазин "на пилот", на нем и обкатывать, пробовать. Как решение выработается - так и расплодить его по магазинам уже типовым.

Вот тут не понял, есть в Рознице какая-то обработка которая позволит удалить всё старое товародвижение, пересчитать итоги и остатки на определенное число.
Это не очень поможет в моем случае но знать вообще полезно. вооьщем что это за типовое решение можно поподробнее.

Вчера посмотрел на базе в 5.7 Гб что там так много весит.
2 Гб справиочник информационых карт (3млн записей и огромное количество столбцов)
и 2 ГБб регистр сведений движение по карточкам (там просто пипец сколько записей а вот столбцов всего 5)
ну и получается 1.7 Гб все документы товародвижения и прочие справочники.

Я его черт знает что это за "информационные карты", может оно там вообще и в пень не сдалось?

А по поводу типового решения, могу сказать что в моем понимании типовое решение выглядит так:
1) Примерно вспоминаем сам принцип "свертки", когда удаляются все движения до определенной даты и переносятся только остатки.
2) Смотрится глазами на БД (ни дня не работал с чистой "типовой" конфой - всегда что то да переделанно) и кумекается чего, куда и сколько.
3) Пишется обработка.
4) Отлаживается обработка.
5) Выполняется обработка на рабочей БД (копию снять предварительно - само собой).
6) ...
7) PROFIT!!!!!

Спасибо за советы, буду внедрять и теребить наших и аутсорсовых программистов! )

возможно кому то это будет полезно...

имелось
1С Розница, платформа 8.1.15.14, конфа 1.0.10
размер базы около 700 Мб

3 рабочих места - отдельные ключи
Основной Windows XP
клиентские Windows XP и Windows 7
все лицензионное

началось все с того что тормозили клиентские 1С-ки тормозили просто жуть как
слегка тормозил основной комп

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

скорость работы увеличилась процентов на 10% примерно

было принято решение ставить сервак SQL
был в наличии относительно старенький, но живой сервер HP 302 с ОС Windows 2003 Standart ,
RAID, RAM 2Gb, CPU Intel Xeon 2.13GHz

на сервер был установлен бесплатный Postgree
Результат: все работает как часики, но тормозят, ОЧЕНЬ тормозят часть моментов

смотрим детально при каких обстоятельствах происходит тормоз

Оказалось ряд запросов при выборке объектов просто не работают на "Постгре"

Делаем тестовый сервак на обычном компе: ставим 2003, MSSQL 2005 - результат 5+

вывод сами понимаете какой...
после переделки проблемных запросов все зашевелилось...

вот уже год как отработало в таком режиме...