В общем, планируется перевести пользователей на клиент-серверную версию (доступ по РДП, филиалы из разных городов) 1С. Выбираем между Postgre и MS SQL. Появились вопросы, которые никак не могу нагуглить уверенно.
Во первых - порядок лицензирования сервера. То есть в прайсе 1С есть такая вещь как "1С:Предприятие 8.3 ПРОФ. Лицензия на сервер", надо объяснить клиенту, зачем оно нужно.
Ну и порядок лицензирования MS SQL, если его выберем (postgre как я понял бесплатен, просто нуждается в грамотном админе).
Есть статья на хабре или еще что-нибудь?

Деньги есть - бери мс.
Нет денег, но есть грамотный админ - бери пг.

(1) А по поводу лицензирования. И сколько брать лицензий

доступ по РДП - если есть возможность, то VPN и вэб-доступ

на этом форуме бартрумов писал , что для виндоус они даже не тестируют постгрес.

(4) Сейчас вопрос в том, что предлагать и какую сумму озвучивать. Для этого надо разобраться в способе "монетизации" SQL. Хотя бы стандартный набор.

(2) Сколько пользователей будет * 1.5 столько лицензий.

Пользовательских. И серверную...

Плюс вопрос такой - насколько MS SQL любит виртуализацию, потому что админ очень ее любит, но я хз, читал, что нежелательно для сервера использовать виртуалку

(7) это всё плюсом к лицензиям 1С, я правильно понимаю? То есть условно есть 20+ лицензий 1С, на это дело еще надо 30 лицензий на сервак?

А терминальные лицензии винты посчитал?

И вроде помню было обсуждение, что для использования "нестоковых" настроек, нужна КОРП лицензия, так?

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

(0)
Гляньте MS SQL Express, если влазите в ограничения. Она бесплатна, хорошая штука.
Postgre я пока не стал рекомендовать ни одному заказчику, ибо требует допилки.

(13) Там ограничение в размере базы вроде как 10 Гб

(14) Да.
И максимум два ядре в моменте используются, остальные курят.

(13) Postgre привлекает многих этакой "бесплатностью"

(16)
на именно что "в кавычках"

(17) Ну "толковый админ" должен идти в комплекте с любым сервером. Из других подвохов помню только про требование КОРП лицезнии и всё вроде.

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

(0) в 2020 покупать нужно не просто "1С:Предприятие 8.3 ПРОФ. Лицензия на сервер", а  "1С:Предприятие 8.3 ПРОФ. Лицензия на сервер (x86-64)"

(20) Ну да, без этого никак)

(0)>Ну и порядок лицензирования MS SQL
есть два принципиально разных варианта лицензирования
- сервер + клиенты
- по количеству ядер
если MS SQL будет использоваться только под 1С, то в прайсе 1С есть льготные лицензии:
- MS SQL Server 2019 Std Runtime - 18660 руб.
+ CAL по 9450 руб. за каждое рабочее место

(22) Спасибо. Скачал прайс для РК, нашел эту позицию, считаю теперь)

(23) а у вас че особенный прайс? ....

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

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

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

И еще... Если за постгри денег платить не нужно - ну так поставьте его и поработайте ну хотя бы 1 день или 2 дня, если админ у вас все равно будет хоть какой-то.
Ответьте сами себе честно - адин у вас есть? А если есть, то дайте ему задание и посмотрите на результат. Уровень использования у вас один фиг не доберется до каких-то критичных событий.

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

Теперь же, не взирая на то, что на самих дистрибах 1С выкладывается сборка постгри, которая жестко глючить не будет, а проблемы могут появиться только если система будет реально нагружена, ну даже не знаю... может после 200 или 250 пользователей будут проблемы, а может и не будет...
А на 50, на 70, на 100 пользователей проблем не наблюдается.

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

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

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

Я честно говоря не понял, Постгри тоже на Виндовозе рассматриваете в качестве СУБД?
Думаю, что настоящая стихия этих открытых СУБД: Posgres, MySQL, Oracle, sqlite является Linux. Тогда уж надо капитально переезжать на Linux, ставить стабильный CentOS 7, качать 1с сервер rpm пакеты, разворачивать субд, в вашем случае постгри на ней, тогда будет круто, а на винде это тухлый вариант, лучше оставаться на MS SQL.

(27) В прошлой организации столкнулся с тем, что при переходе не более новый релиз постгри, предоставленный 1С, начали сыпаться ошибки по правам к таблицам и связам на уровне СУБД. Начал копать, находил нечастые случаи аналогичных ошибок. По совету на одном из форумов скачал и поставил сборку от ПГПро - завелось, ошибок СУБД не нашлось.

Вывод: все, что делаете - на свой страх и риск. Есть бабло, берите мс. С точки зрения производительности, функционала и несложности использования не прогадаете, тем более, если будете пользоваться гуем. С баблом напряг, постгри - ваш вариант. Но только на линуксе. Есть свои нюансы. Есть готовые решения с патчами. Работать можно. Одно из "но" - рано или поздно, когда заходите обновить СУБД, можете уткнуться в проблему с модульной (пакетной) совместимостью на уровне ОС, на которой стоит СУБД. Но это все решаемо - гуглится.

Спасибо всем за информацию) что-то я где-то слышал ранее, что-то было новое)

(27) К сожалению, стратегия построения плана запроса в постгресе так и не поменялась. И всё так же он жестко лажает при запросе с подзапросами, запуская нестедлуп по таблицам с миллионами записей вместо оптимизированных на размер стратегий. И вряд ли это исправят, без радикальной переписки ядра постгреса, чтобы план строился не на запрос в целом, а уточнялся по мере исполнения подзапросов. А оно надо только 1сникам.

Мифы это все, что для "Postgre нужен дорогой гура-админ". С типовыми УТ, РТ, БП абсолютно нормально Postgre работает "из коробки". На Винде, да. Но конфиг-файл лучше, конечно, подправить под возможности железа. Никакой отдельный "гура-админ Postgre" не нужен. Это, если мы говорим про внедрения в малом бизнесе (а 50-100 пользователей - это оно и есть). Если мы говорим о внедрениях на 1000 голов - то все может быть иначе.

(33) Гуру - не гуру, но когда организация дорастает до наличия сервера и филиалов в разных городах - за этим сервером надо кому-то следить и настраивать

(34) нормальный админ нужен всегда. Не важно в штате или готовый прибежать в течении дня.

(0) Сроки есть? В случае MS SQL закладывайте 45 дней на проверку того, что вы не подпадаете под санкции США.

(26) PostgreSQL без грамотного админа может уйти в себя на сутки при выполнении не самого сложного запроса типовой конфигурации. MS SQL даже с настройками  по дефолту и без обслуживания себе такого не позволяет.

(27) На 1 пользователе можно словить проблемы. Просто 1 ядро грузится на 100% от получаса до суток. И хорошо если это отчет, а не проведение документа. И это на дистрибутиве от 1С.

(36) Ну до конца года скорее всего не будет перехода. Мы не в РФ, так что вроде без санкций)
(37) вот вот.
Сейчас главное правильно выбрать вектор. Чтобы потом не лохануться, вертать взад может быть дорого по взаимоотношениям с клиентом

(39) вообще то, РК это Республика Крым.
И то что вы не под санкциями, не значит толком ничего. У нас с вами общее экономическое пространство, поэтому, что у нас нет половины мировых новинок автомобилей, что у вас..что в Белоруссии..

(39) Тогда в чем выбор-то? Рекомендуйте клиенту MS SQL, если ему дорого - делите с ним ответственность.

Postgres это дешево, сердито, работает. Слышал 100раз. То что Postgres круче чем MS SQL - ни разу. Грамотный, вменяемый, доступный админ понадобиться рано или поздно в любом случае.

(40) РК - Республика Казахстан)

(39) На санкции проверяют всех. Вдруг вы на 50% принадлежите кому-то из санкционного списка? Там надо раскрутить всю цепочку юр. лиц до конечных собственников, и если вдруг найдут что-то подозрительное - могут и отказать вообще.

(41) Ну мы не любим советовать то, что им явно излишне на их количестве пользователей. И если рекомендовать - надо сразу понять так сказать "счет на оплату" выкатить, чтобы каждый пункт я мог объяснить, почему столько и чего.

(44) Ну то что вам на мисте сказали, это же тоже не аргумент? Вы постгрес ставили/настраивали хоть раз? А MS SQL? Проведите изыскания: поставьте, прогоните тесты, сравните. Погуглите и все вопросы отпадут.

P.S. Мне Постгрес нравиться ровно тем, что я умею его готовить. MS SQL не умею, в редакциях не разбираюсь, ценники не видел. Но еще ни разу не слышал, что он работает хуже Postgres.

(45) Ставил MS SQL версию для ознакомления (Express вроде называется) и пробно прогонял. Но это же не дает никакого реального опыта. Но есть надежда тут встретить опытных людей, кто сможет хотя бы дать начальное понимание, что и куда.

(0) SQL просто работает. C Postgree надо быть готовым к сюрпризам.
Как вариант: начать с бесплатного Postgree. Если не осилите - переезжать на MS SQL.

(47) Тоже склоняюсь к такому варианту судя по комментариям выше. От Постгре потеряем только время на перенастройку, если не взлетит

Почти 2 года рекламировал ПГ ..... пока в одной из баз не начались "приколы"  ....

(49) Можно подробности? Я в курсе, что ПГ - это не 2 пальца, как говорится. Но со всем же можно справиться, если разобраться

(38) Это он пытается построить хоть сколько-нибудь выполнимый план примерно такого запроса postgesql долго выполняет запрос срез последних
Старые конфы(ББУ, БГУ 1.0, в моем случае) этим когда-то(давно) грешили. Пг-админ почти ничем не поможет, разве что только выключить в оптимизаторе nested loops для ряда конкретных случаев.
Если учитывать подобные особенности, серьезных проблем возникать не должно.

(50) вот-вот - нужно смотреть именно подробности, потому что вероятность словить такие же точно подробности может быть и существует, но это ...

Ну работают в моем опыте, дай бог памяти, ну где-то еще до 2010 года начали использовать ПГ в базах.

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

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

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

Инфы же нет никакой в топике. Хотя рассуждать, что МС Сиквел однозначно рулит всегда вегде и для всех - ну можно, что тут сомневаться ваапще?!

Вот для уравновешивания ссылки на обсуждение постом выше еще одна ссылка

Восстановление работоспособности ИБ после поломки

(51) Это же победили.

(52) УТ (аналог вашей 11.3 или 11.4) и БК 3.0 (аналог вашей БП 3.0)
Смысл зарождения сервера именно в появлении филиалов в других городах. Пользователей то не очень много, просто раз решили делать сервак, то лучше сразу потратиться на нормальный, чтобы потом не перенастраивать. Условно - 10-15 сейчас, ожидается до 30 пользователей. Возможно часть будет работать через web, часть через РДП.

(55) понятно.

Мой совет такой. Если жестких, каких-то сумасбродных и радикальных допилов никто не успел на базы навернуть, то с точки зрения работы платформы разницы, скорей всего, не заметите. Хоть один, хоть другой вариант на этом режиме нагрузки не доберутся до критичных состояний. Однако...!

Не нужно забывать о безопасности работы, когда вдруг внезапно, по каким-то обстоятельствам внезапно приключится потребность хотя бы поднять базу и архива,
а при этом окажется, что их просто нет. Т.е. что-то вроде описанного в (53)
Будет это база в любом формате, но такая технология безопасной эксплуатации должна быть продумана и отработана практически до мелочей.
Сколько на такое обеспечение будет потрачено денег - это уже второй вопрос, тем более, что на таком количестве пользователей и не самый тяжёлый.

(54)Еще не все об этом знают.

(27) + 100!

Там вроде не так много параметров. Можно отправную точку настроек postgresql.conf взять отсюда: https://pgtune.leopard.in.ua

(59) В сборках от постгреспро https://1c.postgres.ru/ при установке конфиг подгоняется под железо.

(60) Хорошо, если так. Интересно, настройки они так же из pgtune берут, или какой-то свой алгоритм реализовали?

(61) Ну поставь да сравни конфиги.

(62) угу, как будет нечем заняться, сразу сделаю

Ни разу не видел ПГ у которого попугаев больше 28 по тесту Гилева

Вот на компе для разработки 16 Gb, 4 ядра, SSD

autovacuum_max_workers = 6
autovacuum_naptime = 20s
autovacuum_vacuum_cost_limit = 400
bgwriter_delay = 20ms
bgwriter_lru_maxpages = 400
bgwriter_lru_multiplier = 4.0
checkpoint_completion_target = 0.9
datestyle = 'iso, dmy'
default_text_search_config = 'pg_catalog.russian'
dynamic_shared_memory_type = windows
effective_cache_size = 8GB
escape_string_warning = off
lc_messages = 'Russian_Russia.1251'
lc_messages = 'en_EN.utf-8'
lc_monetary = 'Russian_Russia.1251'
lc_numeric = 'Russian_Russia.1251'
lc_time = 'Russian_Russia.1251'
listen_addresses = '*'
log_destination = 'stderr'
log_file_mode = 0640
logging_collector = on
maintenance_work_mem = 128MB
max_connections = 500
max_locks_per_transaction = 256
max_wal_size = 1GB
min_wal_size = 80MB
online_analyze.enable = on
online_analyze.local_tracking = 'on'
online_analyze.table_type = 'temporary'
online_analyze.verbose = 'off'
plantuner.fix_empty_table = 'on'  
port = 5432
random_page_cost = 1.5
shared_buffers = 768MB
shared_preload_libraries = 'online_analyze, plantuner'
standard_conforming_strings = off
synchronous_commit = off
temp_buffers = 32MB
work_mem = 128MB


(64) за бесплатно? 28? еще и не глючит на ровном месте? дайте две!

(64) Делали стенды

(0) Переход с Микрософта на Линукс, ценник будет интереснее, работы под ключ

(64) а кому они нужны эти попугаи?
Тест гилева - это тест однопоточной записи большого количества маленьких объектов. Все.

(65) Ну настройки явно не одинаковые, pgtune такие предлагает:
linux:
max_connections = 500
shared_buffers = 4GB
effective_cache_size = 12GB
maintenance_work_mem = 2GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 500
random_page_cost = 1.1
effective_io_concurrency = 200
work_mem = 2097kB
min_wal_size = 4GB
max_wal_size = 16GB
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 4
max_parallel_maintenance_workers = 2


win:
max_connections = 500
shared_buffers = 512MB
effective_cache_size = 12GB
maintenance_work_mem = 1GB
checkpoint_completion_target = 0.9
wal_buffers = 16MB
default_statistics_target = 100
random_page_cost = 1.1
work_mem = 2708kB
min_wal_size = 1GB
max_wal_size = 4GB
max_worker_processes = 4
max_parallel_workers_per_gather = 2
max_parallel_workers = 4
max_parallel_maintenance_workers = 2

(51) В теме postgesql долго выполняет запрос срез последних описал как решить проблему "запрос срез последних"

(70) См. (32) Проблема не решается в принципе. Только если ставить enable_nestloop=off с потерей общей производительности.

(71) А ничего, что в актуальных релизах типовых _все_ выборки данных по _любым_ отдельно взятым регистрам и их производным спрятаны в виртуальные таблицы ?

(72) И? Любая виртуальная таблица 1с - это подзапрос в sql. Со всеми вытекающими из этого.

А что не так с PostgreSQL? Ставил в одной фирме 1с, еще на Centos 6.2, лет 9 назад. С тех пор только поднимаю релизы и протираю пыль с сервака. Полет нормальный (УНФ + БП + ЗУП, около 20 пользователей). Еще в одной фирме уже на Centos 7 PostgreSQL на хосте + виндовый терминальный сервер в виртуалке KVM - лет 6 уже работает, никто не жалуется (БП + ЗУП, баз 25-30 крутится, пользователей раньше было около 20, сейчас 3 осталось - фирма подыхает.). Ну и еще кучка примеров... Postgres нужно один раз хорошо настроить и все ...

Типовые давно пишутся исходя из того, что будут крутиться га постгри. Насчёт дорогого админа - фигня полная. По настройкам - в 90% случаев достаточно рекомендаций от 1С. На линуксе постгри конечно эффективнее чем на окнах, делали тесты разные челы получалось что разница примерно в 1,3-1,4 раза. Постгри - версионник, мс-скл - страничник и всё этим сказано, страничник меньше накладывает блокировок, но требует несколько больше ресурсов проца, с другой стороны не такой требовательный к памяти. Ставил и немного тюнил настройки постгри для Док.корп, пиковая нагрузка порядка 1100 сеансов.... на окнах, т.к. ставить на сервер линукс админы отказались... всё норм работает.
Насчёт выбора - ставь то, с чем готов работать.

(71) Решается только на PostgreSQL 12 версии от PostgrePro, так как они пофиксили баг когда после vaccum слетал план выбора правильного индекса
а проблема в том что у регистров сведений есть 2 индекса которые весят одинаково а порядок колонок разный из за этого выбирается не оптимальный индекс

проблему обсуждали еще в прошлом году тут https://t.me/PostgreSQL_1C_Linux/38861

(75) "Типовые давно пишутся исходя из того, что будут крутиться га постгри. "
Адаптация к постгре - отказ от подзапросов к виртуальным таблицам. И было бы неплохо, чтобы проблема была решена платформой 1с раз и навсегда. Чтобы генератор sql-запросов из запросов 1с перестраивал подзапросы на временные таблицы, если используется постгрес.

(76) Это не та проблема. Речь не о выборе плохого индекса при соединении, а в выборе метода соединения. Постгрес не может правильно оценить количество выдаваемых подзапросом строк во время компиляции запроса в целом. И применяет nested loop, который хорош только на мелких присоединяемых таблицах.

(78) Ну и как этот метод влияет на базы в 30-50 пользователей?

(79) речь про время выполнения запросов (больше зависит от размера таблиц, загруженности сервера СУБД, чем от кол-ва пользователей)

(80) А загруженность сервера от чего зависит? или размеры таблиц?

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

Что то не адекватного выбора ни одного. Буду первым.

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

Для типовых наиболее массовый режим совместимости с платформой 8.3.14 , а конфигах ДО и ДО-КОРП и даже еще выше, но я давненько в них не заглядывал. Не хватает времени просто еще и на них.

(79) И конечно так, всё правильно пишешь - на внедрениях в пределах средних 30-50 (причем, именно в одной базе) эта вся проблема никоим образом не может и не способна себя проявить.

(84) Гарантируете, что проблема решена платформой? Или всё-таки костылями, в виде адаптации всех запросов, включая запросы СКД и RLS, под использование явных временных таблиц?
(79) Даже при 1 пользователе тормозит. С нестедлупами расчет зарплаты жарит процессор сервера почём зря несколько минут, без него - пара секунд.

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

А вообще, годный наброс. Холиваристый.

Еще и с голосовалкой теперь... Но я думаю, что тема стухнет. Это вам не УА и не РБ

(88) конечно сдохнет ибо не первый десяток раз всплывает

(88) Для кого-то наброс, для кого-то реальная ситуация) У меня опыта такого еще не было, так что читаю все мнения)

У постгре есть огромный минус: если бесперебойника нет и свет часто мигает, все базы падают несколько раз в год. Интересно, а у МС есть такие проблемы?
Это не стёб, а удивление от личного опыта. Я не знал, что базы СУБД так легко валятся. Мне казалось, что у них там многократное наслоение надёжности.

(91) У кого есть деньги на МС - на бесперебойник найдут ))

(91) Вот просто нет у нас в наличии ни одной базы на МС СКЛ и что-то ни разу не могу припомнить именно такой проблемы.
Бесперебойники имеются в обязательном порядке и даже не из-за того, что капризничает конкретно 1С - там и без 1С хватает критичного к падениям ПО.

(91) у МС тоже проблемы с этим случаются

(94) И да, насчет проблем, просто в качестве примера ссылка в этой ветке была. На соседнюю и обсуждаемую прямо в эти дни :-)

(91) Бесперебойник - маст хэв же. И проверка работоспособности раз в квартал

Контроллер RAID с батарейкой и обычными SAS 15К дисками, а также SSD с защитой данных от потери питания, просто подключенныe к SATA на матплате, сохранили все данные до последнего байта, в этом году пришлось столкнуться.
PostgreSQL просто сказал "Подождите, я сейчас сделаю рекавери".
Да - за батарейкой надо следить, а серверный SSD стоит в несколько раз дороже домашнего..

Тоже адекватный выбор )

(87) Да нет, это факт известный, зря вы его отрицаете. Я пробовал с постгресом лет 5 назад поднять ЗУП. Было что-то с чем-то. Какие-то действия могли выполняться долго, с 100% загрузкой процессора процессом постгреса. Недаром даже сама 1с рекомендовала отключать нестлуп в настройках.
https://its.1c.ru/db/metod8dev/content/4692/hdoc

(91) Кластер нужно создавать с переменной --data-checksums, сборки от 1С это не делают

(99) За 5 лет много изменилось в PostgreSQL, хорошие улучшения пошли с 11 версии

(99) Главное все-таки по больше верить и все получится. Вот пример с другой ветки.
---
Ботаник Гарден Меран RU/Москва
27 - 18.11.20 - 10:38
« х     
Сейчас во всех конфигурациях универсализация и обфускация алгоритмов.
БП, например.
При смене договора в документе дошел до строк:

Если ВладельцыБезСообщений[ИндексВладельца] = Неопределено Тогда
    // Получаем сообщения от владельца
    ВходящееСообщение = ВсеСообщения[ИндексВладельца];

Чувствуется, пора (на пенсию - увы рано еще) в тестировщики или в питон куда-нибудь.    28
29
ø    bolder RU/Москва
28 - 18.11.20 - 10:46
« х     
(27) там НЕ забыли)
ø    Lama12 RU/Москва
29 - 18.11.20 - 10:51
« х     
(27) Это универсализация. Да, другое мышление, но зато так здорово! :-)    30
ø    Ботаник Гарден Меран RU/Москва
30 - 18.11.20 - 10:56
« х     
(29)
Я вот тоже думал, ну чему там в БП тормозить.
Вот оно во всей красе: сначала собираются все настройки, под них все данные, и где-то на седьмом-восьмом уровне вложенности процедур по фильтрам получается значение нужной настройки.

В сервисе ошибок при поиске по слову "postgresql" находится немало "существенного замедления работы", как в конфигурациях, так и в платформе.
Из-за этого тормозила зарплата - https://bugboard.v8.1c.ru/error/000002673 приходилось держать ее на 8.2, до того как исправили. Сейчас на подобное реагируют гораздо быстрее, в том числе и на ошибки с СУБД.

(103) Это, мне кажется, из-за 1cfresh. Тут 1С для себя суетится.

Конфигурации под управляемые приложения работают в PostgrSQL достаточно шустро. Проблемы только в разработчиках 1с, которые набили себе руку на кривых отчетах и перепиливать за ними нет никакого желания. Но проблема из-за этого остается даже на высоко-производительных серверах с MSSQL на борту. Попытка уменьшения стоимости запроса в MSSQL приводит к ступору 1с, MSSQL кричит, что ему не хватает показателя 100500 в регуляторе запросов. И особенно этим грешат базы в которых нужно посчитать каждую алкогольную марку. Ощущение такое, что скоро на каждую булку будут требовать акцизную марку, чтобы жизнь медом не казалась.

В общем качественно пилить нужно все конфы, чтобы работа не встала колом.

(104) Да, тем более, что у них есть и федеральный проект на том же фреш https://www.cnews.ru/news/top/2018-12-06_informsistema_kaznachejstva_i_minfina_sekonomit

(100) >> Кластер нужно создавать с переменной --data-checksums, сборки от 1С это не делают
Там даже такое есть?

Я ПГ для дома поставил, поэтому и с бесперебойником перебои. Наверное надо переставлять боевую часть на N-ку и колдовать с обратной связью от ИБП. J-ка 61 минуту держалась на батарейке 7х12, больше не пробовал. Но вдруг свет отрубят на много часов, а я не дома.

"--data-checksums
Применять контрольные суммы на страницах данных для выявления сбоев при вводе/выводе, которые иначе останутся незамеченными. Расчёт контрольных сумм может повлечь заметное снижение производительности. Когда контрольные суммы включены, они рассчитываются для всех объектов и во всех базах данных" - из документации.
Надо будет попробовать.

(108) Определил сервер, что страница с данными битая, а что дальше? Отвал базы в suspect (или как там оно у постгреса)? Это же не избыточное отказоустойчивое кодирование, а всего лишь контрольная сумма..

А как избыточность сделать?

(82) Мне лень развивать, но смысл диалога сведется к конечному,

среднему пользователю в вакууме и количество сервисов интегрированных на среднего пользователя в вакууме, и далее мы увидим, что в 80% оценка по среднему пользователю в вакууме будет верна, и понятна, за исключением 20% когда требуется уточнить есть ли наличие спец задач

(110) для постгри избыточность это онлайн-бэкап

(109) Один из основных разработчиков СУБД считает, что " I think this feature is: being able to very quickly and
easily know that a problem originated outside of the PostgreSQL code" - https://postgrespro.ru/list/thread-id/2486488
Ну, а дальше остановить СУБД, заменить диск(и) и восстановить кластер из непрерывного архива WAL, наверное. Так сказать, PITR, на любую секунду до возникновения ошибок. Они там все убеждены, что эта штука должна быть обязательно включена.
Насколько, при этом, будет замедляться, надо смотреть.

(113) замедления минимальны. Я тоже убежден, что PITR должн быть включен и настроен на всех инсталяциях Postgres. Не потому что постргес может упасть, а потому что это мега-крутая фишка. И нашу контору пару раз она спасала от огромных проблем.

Я на SQL тестировал
None
TornPage
Checksum
так и не увидел разницы.

Но я тестировал из 1С, все упиралось, как всегда в ядро сервера 1С, надо бы попробовать из чистого SQL, хотя, зачем, если узкое горло в 1С :-)

(114) Согласен, что фича нужная, и следовало бы её по умолчанию включать.

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

(117) ну так в соседней же ветке буквально свежий пример новосстановимого архива из мс-скл :-)

(117) Я, раз в квартал, тестирую возможность восстановления БД. И из pg_dump и из pg_basebackup-a + накатка транзакций. Есть админы которые неделают бекапы, есть админы которые делают, а есть те которые их регулярно тестируют)

(118) а что за ветка?

(120) Восстановление работоспособности ИБ после поломки

(99) "Я пробовал с постгресом лет 5 назад поднять ЗУП" - а более свежего опыта нет? А то за 5 лет многое могло измениться как в ядре 1С-ины, так и в СУБД.
В частности 16.02.2019 пресс-релиз: "Оптимизирована работа виртуальных таблиц оборотов регистров накопления и бухгалтерии в случае использования группировок по дню, месяцу или году, а также при использовании функции языка запросов НачалоПериода(). Оптимизация используется для любых версий поддерживаемых СУБД, кроме Microsoft SQL Server, где оптимизация действует, начиная с версии 2012."

(121) Там админ/адинэсник не делает бекапы перед обновлением. Да и вины SQL сервера нет, что-нибудь в этом духе словили бы и на постгресе. Так что неканает.

(123) очень даже канает.

Подари дуракам хрустальный хер - они его и разобьют и руки порежут.

(124) Бекап там восстановимый, просто вчерашний. Падения самого SQL-сервера не было. Для SQL все штатно, как настроили так и работает. Вот если бы там после ребута все базы легли бы, тогда канало бы.

(125) Да даже если было, бекап на то и бекап, что с него нужно уметь восстанавливаться, а не делать круглые глаза- не получилось

(126) Лет пять назад, помнится, нужно было плясать с бубном, чтобы поднять бэкап базы 1с в постгресе. Там на какие-то определяемые типы mvarchar ругалось, если загружать бэкап в пустую базу. Приходилось заново создавать базу из управления сервером 1с, и только потом можно было загрузиться. Костыльно. Сейчас иначе?

А сейчас с точностью до наоборот: Приходится сначала из консоли postgres создать пустую db (create database) и в нее уже загружать. При этом оно точно также ругается.

Костыль? Да! Работает? Да.

Если бекапить pg_basebackup и архивировать журнал транзакций - все работает штатно, как в доке написано. Но для всех баз в кластере.

(127) У каждого восстановления есть необходимость проверить работоспособность, по поводу специфики, спрошу конечно, но судя по тому, что мы уже восстанавливались и это проблем никаких не заняло, просто уведомили о простое в пару часов, то думаю что, или решено, или как написал Стопа, нюансы, но никак не проблемы

(128) ИМХО. Постгрес это не то, чтобы установить и спать спокойно. По крайней мере для 1с. По крайней мере для небольших контор.
По моему мнению, постгрес удачное решение для барыг-облачников, которые предоставляют 1с как сервис. Это здорово позволяет сэкономить, но лишь при наличии квалифицированных админов, которые на этом постгресе много собак съели. Это не та СУБД, которая "просто работает".

(130) Все то же самое, или сразу настроят бекапы и прочие восстановлялки, или будут париться при восстановлении

(131) Просто есть СУБД, которые более дружественны к админу. Та же mssql мощная СУБД, с кучей возможностей - но бэкап сделать и восстановить сможет любой школьник с базовыми навыками. А настройки по умолчанию работают быстро и не вызывают особых проблем.
Или вот например firebird - легкая, простая, админить как два файла переслать. К сожалению, 1с её не поддерживает.

(132) Ну при условии что мы берем за обслуживании связки Никсов+ ПГ от 10к в месяц, это не сильно повлияет на любой бюджет

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

Сохраняем:
pg_dump -Fc --clean somebase > /opt/backup/1cv82/somebase.out

Восстанавливаем
dropdb newbase
createdb newbase

pg_restore -d newbase /opt/backup/1cv82/somebase.out

Вполне дружественно, я считаю.

Или сейчас модно как-то по-другому делать архивацию на пг?

(117) ну если взять чужой скрипт и не проверять...
И да, есть такой момент: если ты делаешь рестракт и в это время делается бэкап с очень высокой вероятностью выкинь бэкап а dev/null

(122) именно по ЗУПу есть особенности желательные (более агрессивный автовакуум, например)...

(129) справедливости ради: если ты не админ, а одинэсник для тебя ньюанс может стать проблемой... пока не найдёшь решение

(134) или так под окна:
pg_dump.exe"  -i -b -v -E UTF-8 -f C:\PG_Backup\Dump\dump_erp.sql

createdb
psql.exe -f C:\copying\dump_erp.sql >restore.log

Короче, слоны не летают

(139) ещё как! Только не забываем обслуживать БД

(139) (140) Слоны - птицы гордые...
Не пнёшь - не полетят...

Короче, если забить болт на обслуживание базы, то она протухнет в любой версии

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

относится к любой версии баз и вообще к любому ПО

(143) Ну всё-таки постгрес это не "любое ПО", а весьма специфичное и в экосистеме 1с чужеродное. Даже сами разработчики постгреса скептически относятся к тому, что его выбрали для 1с. Где-то читал, что они заявляли, что характерные для 1с нагрузки и структура хранения данных плохо укладываются на постгрес..

(144) А что такого экстремального в 1с, что сервер базы данных (реляционной) не может её вытянуть?

(145) Там говорилось про количество таблиц в базе и характерные запросы с подзапросами.

(146) Хм... То есть разработчики признали, что они сделали какашку и потом упорно заворачивают её в красивую бумажку?

(147) Разработчики, кстати, упорно рекомендуют использовать постгрес на линуксе, а не на винде. Потому что линукс лучше работает с десятками тысяч файлов в одном каталоге.

(148) ну вот чисто из вредности и дурного настроения в это сегодняшнее утро, спрошу с ехидцей :
а что у тебя и пруф имеется на разработчиков именно платформы (а не самописных конфигураций) и такие их рекомендации действительно имеются относительно 1С+постгри ?

(148) А вот мсу не надо "лучше работает с десятками тысяч файлов в одном каталоге."...

(149) Извини, пруфов нет, это на инфостарте одна бабка сказала) ну и смотрел видео от постгреспро, где они всячески распинались почему не ну никак не получилось сделать чтобы 1с не тормозила без переписывания запросов.

(142) но мс-сиквел дохнет прилично дольше

(148) нет, потому-что в линуксе другая работа с памятью и постгри под ней заточен