1CUnlimited

(13)

Цитата
Поставьте постгреспро с настройками из коробки и попробуйте своим тюнингом выйграть у него хотя бы 15-20%

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

В отличии от того же MS SQL где достаточно одним флагом обойтись T2371 для более частого обновления статистики, и сосредоточится на других вопросах.

Попробуйте
а) Просто подвигайте итоги взад вперед при настройках вакуума по умолчанию . (пример тут https://infostart.ru/1c/articles/1912525/ очень частый кейс по закрытию месяца )
б) Или без synchronous commit=off перепроведение с 20 параллельных процессов.

Это сэкономит время на последующие поиски объяснений - почему один и то же запрос случайным образом показывает разную производительность

Цитата
Последние лет 20 мелкомягкие занимаются только тем что перепрятывают кнопку Пуск, а могли бы сделать новую производительную файловую систему например Итог - рынок смартфонов, рынок планшетов, рынок браузеров начисто проигран, рынок веб серверов нет смысла говорить, рынок СУБД сейчас уже 50/50, остается пролопатить рынок десктопов

Вы невнимательно за потенциальным противником следите. Они во первых уже основные доходы получают от облака и его экосистемы технологий
https://www.finam.ru/publications/item/microsoft-otchitalas-o-rekordnykh-pokazatelyakh-za-1-kvartal-20231025-1240/
более 50%
во вторых даже наглая функция принудительных обновлений , это часть стратегии загона всех в цифровую тюрьму или Windows as service
https://learn.microsoft.com/en-us/windows/deployment/update/waas-overview
понятно большинство свободных граждан на западе сделает правильный однозначный выбор. А бизнес они пока боятся вести в загон, поскольку у него больше возможностей

(11) Реальность в холиваре windows vs linux бывает субьективной и объективной. Объективная подтверждается синтетическими тестами - ну не вижу я на своих синтетических тестов существенной разницы для Postgres.
В общем то я ответил там https://habr.com/ru/articles/776536/comments/#comment_26201940 но диалог развития не получил.
Сделайте свой синтетический тест покажите что Postgres over windows это плохо. Так сказать добейте его , всеравно windows под импортозамещение пойдет в сторону Linux по крайней мере на серверной части на ближайший солнечный цикл.

P S Я если честно после плясок с отключением обновлений вокруг нового ноута с Win11 готов импортозаместится на стабильную сборку Linux лишь оно принудительно не обновлялось. Удерживает только уровень офисного софта под Linux,формально он вроде повторяет функции но по факту Linux way

(8) Контрольные суммы выключены по умолчанию. Да и я пока не проверял сколько они отнимают по производительности для Highload. Postgres и так съедает больше ресурсов CPU по сравнению с MS SQL. Хотя конечно, для контроля целостности базы они нужны поскольку у Postgres с этим не очень.

(5) Все правильно делаете, Когда сели в машину и начали ехать можно не обращать внимание на тормоза, когда понадобится разберетесь если что .

(2) Мой опыт это не подтверждает. Я гонял тест Нагрузочный тест Postgresна сравнимом оборудовании windows vs unix
Принципиальной разницы не заметил. Каких то особых проблем по сравнению с linux (oracle linux 8) так же не нашел. Да и откуда им появится когда структура процессов в Postgres одинакова как на linux так и на windows.
А Windows еще долго пользоваться поскольку что либо на Windows развернуть проще из-за пресловутого Linux way Что такое linux way . Linux спроектирован для админа у которого много времени, а не для разработчика 1С которому нужно быстро поднять инфраструктуру для работы у клиента

В Postgres достаточно подробная документация, и, видимо, поэтому при инсталляции Postgres для 1С большинство параметров приходится выставлять самим. Параметров в Postgres много, а составить эффективную комбинацию не так просто. Все упрощается, если рассмотреть профиль нагрузки, например, 1С это прежде всего профиль OLTP нагрузки – так устроены его метаданные (объекты). Если сосредоточиться на оптимизации профиля OLTP, понимание Postgres сразу упростится.

(3)

Цитата
Оптимизатор оценивает "стоимость" запроса, как вы правильно сказали в "попугаях". Одной из самых важных величин (главным попугаем) влияющих на стоимость является число строк. Начиная с определенного кол-ва строк, становится более выгодным использовать Nested Loops (NL) вместо Merge Join (MJ).

Вы специально убрали при цитировании "Видимо все соединение можно сделать в памяти" т.е. это было предположение а не утверждение, поскольку открытый код оптимизатора MS SQL никто из нас не смотрел.
По поводу расчета стоимости оптимизатором неясно окуда уверенность что MS SQL ее считает верно, тем более что есть Estimated и Fact cost. A nested loop на более чем 100 тыс записей так себе алгоритм,который сядет на одно ядро тем более что параллелизм по рекомендациям 1С выключен
Тут скорее не выводы а констатация факта

(8)

Цитата
Проблема большинства ORM не в записи, а в чтении данных. 1С решила отдельной машинерией механизмов запросов, построителя отчетов, СКД.

Ты как то вбросил этот тезис, из которого следует что в "большинстве " Orm у тебя проблема в чтении данных. У каждого свои проблемы понимаю.
И альтернативу SQL ты предлагаешь

Цитата
1С альтернативой языку SQL является СКД, позволяющая, написав простой запрос к регистру накопления, составлять множество выборок (отчетов) с различными группировками, с различной детализацией с помощью лоукод подхода, изменяя настройки.

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

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

(6)

Цитата
люс машинерией хранения аккумулированных данных в регистрах накопления и регистрах двойной записи. И это главные килерфичи 1С.

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

Цитата
Например ORM Active Record в Ruby предоставляет только аналогичный 1С объектный подход, или прямые запросы к СУБД

Orm Active Record наверняка оперирует объектами - соответствующими отдельным таблицам или View, почему от него ожидают каких то продвинутых абстракций скрытия, разыменований? Поэтому для чтения все кончается прямыми запросами к субд обернутыми в ORM (в Java например так) . Ну это конструктор "сделай сам". Но хотябы есть нормальные средства работы со чтением пусть и прямым запросом (SQL нормальный декларативный язык).
Тогда откуда проблема со чтением в большинстве Orm? Вообще то с чтением ее нет.
Но если хотите все обернуть в объекты
Ищите альтернативы sql https://stackoverflow.com/questions/2497227/what-are-good-alternatives-to-sql-the-language
?
Некоторые уже нашли https://en.wikipedia.org/wiki/Object_Query_Language

(14) Аренда имеет смысл только ради двойного дискового пространства, которое неизбежно потребуется из на особенностей реструктуризации (копии таблиц даже в оптимизированном режиме, переброс данных из Ваших tablespace в Primary )