Чем PostgreSQL может быть полезен разработчику 1С









В статье будут рассмотрены примеры, которые могут оказаться полезными в повседневной работе разработчика 1С и не только: как можно сделать снимок рабочей базы без файла резервной копии, как можно эффективно использовать табличные пространства СУБД PostgreSQL, а также как организовать простой и удобный доступ к админке СУБД посредством мобильных устройств.

Я как разработчик 1С в последнее время все сильнее и сильнее сталкиваюсь с живыми примерами импортозамещения. И во многом они связаны с используемой в организациях СУБД. Что говорит клиент:

— У нас MS SQL Server, но что-то дорого на новые сервера его закупать, говорят что 1С работает с PostgreSQL, а он, получается, вроде как дешевле. Давай на нем попробуем поработать! — вот как все чаще и чаще стали говорить наши клиенты. На мой взгляд, происходит это потому, что крупный бизнес подстраивается под текущие реалии, в которых традиционное "коммерческое" ПО замещается свободным open source, которое гораздо более приспособлено под задачи бизнеса, в которых основная суть — усиление клиентоориентированности и, логично, наращивание финансового эффекта от этого. Open source ПО открывает широкие возможности при решении такого рода задач, так как, по сути, не имеет границ при горизонтальном масштабировании ИТ — инфраструктуры. И нам под эти реалии также приходится подстраиваться.

Все разработки мы должны вести на очень похожей программной инфраструктуре как у клиента, чтобы затем, в продакшене, ничего плохого не вылезло. Например, у клиента СУБД PostgreSQL, а мы разработку ведем в архитектуре, где в качестве СУБД используется MS SQL. Что может произойти при таком подходе? Да много чего… Например, некоторые запросы будут вести себя совершенно по-другому. То, что MS SQL обрабатывает за пару секунд, PostgreSQL может обрабатывать за пару минут. И наоборот. 

Итак, давайте на практических кейсах посмотрим, чем же PostgreSQL может быть полезна разработчику 1С (и, возможно не только…). В качестве операционной системы, на которой рассматриваются примеры, будет служить MS Windows, поскольку является самой массовой и любимой ОС разработчиков 1С. Но и в случае с Linux based системами, описанные в данной статье примеры, без особых проблем, так же осуществимы (с некоторыми модификациями, которые в данной статье рассмотрены не будут).

Начнем с того, что эффект от использования PostgreSQL сразу же проявляется в ходе установки самой СУБД. Достаточно зайти на https://postgrespro.ru/products/1c и скачать последнюю версию с поддержкой 1С. Установщик занимает порядка 50 mb, и не требует при установке загрузки из интернета дополнительных установочных модулей, что значительно уменьшает скорость установки, которая и так занимает порядка пары минут в режиме "Далее — Далее — Готово". Возможно, потребуется указать каталог «Data», где будет располагаться кластер СУБД с данными баз. Для этого желательно указать достаточно производительный диск. Так же необходимо задать пароль для доступа к кластеру. Помимо того, что PostgreSQL выигрывает у MS SQL Server в размере установщика и времени установки, для работы самой СУБД не требуется большой объем оперативной памяти, что для разработчика 1С несомненный плюс, особенно когда речь идет о разработке на достаточно требовательных к ресурсам машины конфигурациям типа ERP. В дополнении к этому, установленная СУБД не имеет ограничений на число ядер и объем используемой оперативной памяти. 

Давайте перейдем непосредственно к кейсам:

 

1. Необходимо быстро развернуть тестовую базу из рабочей базы минуя процесс создания файла резервной копии рабочей базы. 

 

PostgreSQL позволяет сделать «снимок» базы, обеспечив её транзакционную целостность. В командной консоли MS Windows существует возможность перенаправления вывода результата выполнения команды в поток c использованием операторов перенаправления "|". Команда будет выглядеть следующим образом:

pg_dump -h product_server -U postgres workbase | psql -h test_server -U postgres workbase_copy

здесь: product_server и test_server — имена серверов PostgreSQL, workbase и workbase_copy — имена баз на серверах PostgreSQL

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

Инструмент, которым все это можно проделать будет упомянут в кейсе №4. А как создать чистую базу или очистить существующую — этой информации полно на просторах интернета.

Какая практическая польза с этого:

  • мы не нагружаем излишне диски, все данные передается через сетевой интерфейс с одного сервера на другой, задействуя лишь небольшой дисковый буфер
  • экономим место на дисках
  • значительно экономим время развертывания базы в тестовом контуре. По нашим замерам, эффект от использования такой команды — увеличение скорости развертывания в 1,5 раза! Можно гораздо быстрее приступить к любимой разработке на тестовой базе со свежими данными рабочей базы. 

 

2. Возможность изменения положения предопределенных табличных пространств

 

С версии платформы 8.3.1 появилась возможность использовать отдельные табличные пространства для индексов (пространство v81c_index) и данных (пространство v81c_data) в СУБД PostrgeSQL. (https://its.1c.ru/db/v8310doc#bookmark:cs:TI000000194)

Но почему-то этой возможностью мало кто пользуется либо просто о ней забыли. Я не видел ни одной базы на серверах клиентов в которой бы использовались данные табличные пространства. Что из себя представляют – эти табличные пространства?

Прежде всего, табличные пространства позволяют организовать логику размещения файлов объектов базы данных в файловой системе.

Платформа уже из коробки при работе с СУБД PostgreSQL понимает 2 табличных пространства: v81c_index и v81c_data. Причем, сама СУБД PostgreSQL хранит индексы и данные в разных таблицах, даже кластерный индекс – так же храниться в отдельной таблице. Такой подход позволяет нам организовать хранение информации вообще на разных физических ресурсах. Самое главное что платформа 1С при реструктуризации учтет проделанную нами настройку и ничего не будет нарушено.

Табличные пространства не создаются автоматически и должны быть созданы администратором базы данных. Если дополнительных табличных пространств не создано — используется табличное пространство по умолчанию (pg_default).

После того, как табличные пространства созданы, платформа при развертывании всех новых добавляемых в кластер СУБД баз будет разделять их физическое хранение для данных и для индексов.

«В чем же польза для разработчика?» —спросите Вы. Я для себя нашел хороший пример применения такой фичи. У меня на рабочей машине 3 жестких диска, один из которых SSD, а два оставшиеся HDD по 250 ГБ. Сделав 2 табличных пространства для индексов и для данных на данных 2х HDD я тем самым увеличил суммарный объем дискового пространства, в котором я могу размещать базы для разработки.

 

Как это выглядит в действительности (рис 1, рис 2):

Рис 1. Размещение таблиц данных в табличном пространстве v81c_data

 

Рис 2. Размещение таблиц индексов в табличном пространстве v81c_index

 

Как создать и использовать табличные пространства – посмотрим на примере следующего кейса, так как он является логическим продолжением текущего кейса, но из «коробки» платформа не будет понимать, то, что я предлагаю реализовать.

 

3. Перенос файла конфигурации на более быстрые диски, например SSD

 

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

Рис 3. Перенос файла конфигурации в другое табличное пространство.

 

При реструктуризации все останется на своих местах, файлы конфигурации останутся там, куда мы их поместили.

Для меня данная фича оказалась очень полезной, так как на дисках, на которых была база, конфигурация открывалась очень долго, так же долго происходил процесс сохранения конфигурации, после переноса на SSD данные операции стали выполняться в раза 3 быстрее. Появилось даже некоторое ощущение что "все летает". Такие же изменения можно сделать и для таблицы, в которой храниться конфигурация расширения. Вот перечень таблиц, которые я обычно перемещаю на SSD диски, чтобы процесс разработки шел «бодрее».

Рис 4. Вынесенные таблицы в новое табличное пространство

 

Описание таблиц, к чему они относятся – можно найти на сайте ИТС: https://its.1c.ru/db/metod8dev#content:1798:hdoc:_top:configcas

Можно ли такое проделать и на MS SQL? Такая возможность там тоже имеется. Но меня удивило, что в случае с PostgreSQL — это делается двумя кликами мыши.

Будет ли это являться нарушением лицензионного соглашения фирмы «1С»? По моему мнению — нет не будет. Мы не затрагиваем данных и процесс реструктуризации не влияет на наши изменения.

 

4. Удаленный доступ с любого устройства (если на нем есть интернет).

 

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

Одно время я был озадачен вопросом — можно ли подключиться к серверу СУБД с мобильного устройства. Например, я в дороге, в командировке, но на почту мне приходят данные со счетчиков системы мониторинга, судя по которым на СУБД происходит какая-то беда. Хотелось, не устанавливая RDP клиента для мобильного устройства открыть браузер, перейти на нужную защищенную страничку и попасть в админку сервера СУБД. Можно ли так сделать в случае с MS SQL? Нет, нельзя. А жаль. А можно ли такое проделать такое с PostgreSQL? Можно! Только слегка придется использовать командную строку и подправить пару строк в модулях pgAdmin. На самом деле — все просто.

Первым делом необходимо установить pgAdmin 4 последней версии. В чем особенность 4 редакции? Она работает в режиме веб приложения. Конечно, по умолчанию, из коробки при запуске pgAdmin изначально стартует некий сервер, а затем открывается браузер, в котором открывается клиентская часть. Выглядит это примерно так (рис 5):

Рис 5. Админка pgAdmin. Локальный веб доступ.

 

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

1. Ставим последний Python

https://www.python.org/downloads/

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

Рис 6. Настройки при установке Python

 

1.1. Обновляем pip (система управления пакетами). 

Используем командную строку

python -m pip install --upgrade pip

2. Выполняем в командной строке установку пакета "mod_wsgi", он превратит наш pgAdmin в веб приложение.

pip install mod_wsgi

3. Выполняем 

mod_wsgi-express module-config

Будет выдано сообщение примерно такого вида, его необходимо будет скопировать в буфер обмена.

LoadFile "c:/users/v.fominykh/appdata/local/programs/python/python37-32/python37
.dll"
LoadModule wsgi_module "c:/users/v.fominykh/appdata/local/programs/python/python
37-32/lib/site-packages/mod_wsgi/server/mod_wsgi.cp37-win32.pyd"
WSGIPythonHome "c:/users/v.fominykh/appdata/local/programs/python/python37-32"

4. Устанавливаем Apache web server

Его можно скачать, например, здесь https://www.apachelounge.com/

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

Далее установим Apache в качестве службы с помощью команды (из каталога bin установленного Apache):

httpd.exe -k install

5. Дополнительно скачиваем и устанавливаем через PIP необходимые оставшиеся пакеты.

Без них, к сожалению, ничего не получиться.

pip install flask
pip install flask_babelex
pip install flask_login
pip install flask_mail
pip install flask_paranoid
pip install flask_security
pip install flask_sqlalchemy
pip install simplejson
pip install python-dateutil
pip install flask_migrate
pip install psycopg2
pip install Crypto (возможно стоит удалить pycrypto)
easy_install pycryptodome
pip install sshtunnel
pip install flask_gravatar
pip install psutil
pip install sqlparse
pip install flask_htmlmin

6. Затем, необходимо ознакомиться с руководством установки pgAdmin в качестве сервера.

https://www.pgadmin.org/docs/pgadmin4/dev/server_deployment.html

Если кратко, то в установленном каталоге pgAdmin в подпапке "web" рядом с файликом config.py нужно создать файл config_local.py со следующим содержанием: 

LOG_FILE = 'C:/web/srv/var/log/pgadmin4/pgadmin4.log'
SQLITE_PATH = 'C:/web/srv/var/log/pgadmin4/pgadmin4.db'
SESSION_DB_PATH = 'C:/web/srv/var/log/pgadmin4/sessions'
STORAGE_DIR = 'C:/web/srv/var/log/pgadmin4/storage'

На каталог "C:/web" необходимо дать полные права пользователю, под которым будет запущена служба сервера Apache, а также выполнить следующую команду, чтобы создать базу данных конфигурации: 

python setup.py

После этого в конфигурационный файл Apache необходимо добавить строки, которые мы ранее скопировали в буфер обмена (рис 7)

Рис 7. Добавляем в httpd.conf указанные строки

 

а также в самый конец того же конфигурационного файла вставить следующий текст, где port — номер порта сервера.

<VirtualHost *:port>
ServerName localhost
WSGIScriptAlias / "C:Program Files (x86)pgAdmin 4v3webpgAdmin4.wsgi"
<Directory "C:Program Files (x86)pgAdmin 4v3web">
Require all granted
</Directory>
</VirtualHost>

Сохраняем конфигурацию и запускаем службу сервера Apache.

 

7. Заходим по адресу http://localhost:port 

Если все нормально и при вводе пароля при добавлении сервера СУБД никаких ошибок нет. То все отлично! В противном случае необходимо немного поменять модули питона.

Меняем строки в следующих двух файлах:

  • C:Program Files (x86)pgAdmin 4v3webpgadminrowserserver_groupsservers\__init__.py
  • C:Program Files (x86)pgAdmin 4v3webpgadminutilsdriverpsycopg2

В первом файле строки

password = data['password']
password = encrypt(password, current_user.password)

на

password = bytes(data['password'], 'utf-8')
password = encrypt(password, bytes(current_user.password, 'utf-8'))

и

password = encrypt(password, user.password)

на

password = encrypt(bytes(password, 'utf-8'), bytes(user.password, 'utf-8'))

Во втором файле строки

password = decrypt(encpass, user.password)

на

password = decrypt(encpass, bytes(user.password, 'utf-8'))

Перезапускаем службу Apache. Убеждаемся через браузер что все работает (рис 8):

 

Рис 8. Доступ из любой точки мира и любого браузера, допустим, с ноутбука

Если ты в пути и сервер СУБД лег, то доступ из любой точки мира с мобильного будет весьма нелишним (рис 9).  

Рис 9. Доступ с мобильных устройств.

 

Надеюсь, что данные кейсы окажутся действительно полезными для Вас и найдут применение в повседневной работе!

38 Comments

  1. Darklight

    Интересные кейсы. Жаль очень мало 😉


    Как создать и использовать табличные пространства – посмотрим на примере следующего кейса, так как он является логическим продолжением текущего кейса, но из «коробки» платформа не будет понимать, то, что я предлагаю реализовать.

    Так что там платформа «из коьрбки» не будет понимать и как это решать? Я что-то не понял.

    Ролик создания пространств очень трудно смотреть — всё очень мелко, пояснений нет.

    И распределение таблицы по пространствам нужно будет настраивать для каждой базы самостоятельно?

    Reply
  2. Shmell

    Вы создаете 2 табличных пространства, о которых я написал. Этого уже достаточно, при создании новой базы платформа будет передавать сигнал СУБД о том, что таблицы индексов мы размещаем в одном месте, а таблицы данных в другом. И эти места могут быть на разных физических носителях.

    Эта настройка влияет на все новые создаваемые базы (в т.ч. разворачиваемые из бэкапа или способом, описанным в кейсе N 1)

    Reply
  3. a.doroshkevich

    (1)

    Так что там платформа «из коьрбки» не будет понимать и как это решать?

    Не будет понимать именно вынос файлов конфигурации в отдельное пространство.

    Это придётся делать для каждой базы.

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

    Reply
  4. w.r.
    На мой взгляд, происходит это потому, что крупный бизнес подстраивается под текущие реалии, в которых традиционное «коммерческое» ПО замещается свободным open source, которое гораздо более приспособлено под задачи бизнесаНа мой взгляд, происходит это потому, что крупный бизнес подстраивается под текущие реалии, в которых традиционное «коммерческое» ПО замещается свободным open source, которое гораздо более приспособлено под задачи бизнеса

    Ну ложь же! Как раз именно коммерческое приспособлено лучше под задачи бизнеса. Взять тот же MS SQL Server, который установить и настроить можно даже не обладая квалификацией. «Установил и работает» — вот что нужно бизнесу. Или ваш PostgreSQL, по настройке которого спецов хороших днем с огнем не сыщешь. Лучше один раз заплатить фикс цену и получить работающую систему, чем постоянно потом переплачивать за человеческий труд. Для небольшой фирмы (размер базы до 10 Гб) можно взять MS SQL Express, который вообще бесплатный

    Reply
  5. Shmell

    (4) Задачи бизнеса бывают разноплановые и настолько не вписывающиеся в какие — либо шаблоны, что коммерческое ПО просто не сможет эти потребности закрыть. А open source достаточно гибок, тот же PostgreSQL можно сконфигурировать под свои задачи, достаточно только привлечь разработчика С. Коммерческое же ПО закрыто от такого рода вмешательства. С одной стороны это хорошо, а с другой — может ограничивать определенные «хотелки», которые могут неплохо так протолкнуть бизнес. Тем более в эпоху интернета вещей и микросервисов — коммерческое ПО проявляет себя несколько неповоротливо.

    Reply
  6. w.r.

    (5) эти байки про то, что код открыт — меняй что хочешь, я слышу уже больше 10 лет. А по факту люди брали вместо коммерческого ПО свободное и плевались потом. Поддержка этого свободного ПО посылала этих людей дописывать самим фиксы. А баги вылезали в самых неожиданных местах и в самый неподходящий момент. Скупой всегда платит дважды. Всегда

    Reply
  7. Крококот

    (5)

    Да, это аргумент. Только вот «вроде как дешевле» скорее всего не получится. Получится дороже. Сильно дороже. Или сильно хуже.

    Бесплатный сыр бывает только в мышеловке. Вы не интересовались, сколько тех клиентов, которые ставили себе PG в целях экономии, потом перешли обратно на MS SQL?

    Reply
  8. Shmell

    (7) Пока все клиенты, которые на PostgreSQL не рвутся обратно на MS SQL. При правильном администрировании СУБД PostgreSQL ведет себе достойно. Причем 10 и 11 версии излечены от «детских болячек». Так же не забывайте о версии Pro, которая имеет коммерческую составляющую, но в отличие от MS SQL может быть доработана вендером под конкретные задачи. Да, это будет стоить денег, но в случае с MS SQL мы упираемся в стену, Вам никто ничего в ней не доработает.

    Да и PG не только в целях экономии ставят, есть большой ряд задач, где необходимо использовать стек технологий, в котором по большей части используется open source. Давайте возьмем к примеру «Cистему взаимодействия» от 1С или «Дата акселератор», в котором используется движок СУБД PostgreSQL…

    Reply
  9. Крококот

    (8)

    Ну у вас в самом начале статьи приводится минидиалог с пользователем, где цена указывается как главный аргумент «за» PG… отсюда и восприятие.

    Никто не спорит, что PG имеет свои преимущества. Вот только называть среди них стоимость я бы не стал, если речь ведется про достойное качество, конечно. Правильный админ со знанием PG при прочих равных стоит дороже правильного админа со знанием MS SQL, т.к. в настоящий момент встречается заметно реже. Это оставляя в стороне остроту проблемы поиска правильного админа вообще…

    В общем вы приводите хорошие доводы «за» PG, но «есть нюансы».

    Reply
  10. Shmell

    (9) Да, пожалуй из данного минидиалога так и следует, Вы правы.

    Reply
  11. G.Shatrov

    Кейсы — то что надо! Бери и используй на практике..

    Reply
  12. Darklight

    Высказывания (3) и (2) противоречат друг другу

    1. Либо всё созданные после настройки таблицы, индексы надо каждый раз переносить в нужное файловое пространство

    2. Либо PostreSQL как то (интересно как) сам буде определять куда ему поместить толкьо что созданную таблицы или индекс?

    Думаю, что 2. он не умеет делать

    А по поводу 1-го, раньше платформа 1С Предприятие 8 вообще могла даже при реструктуризации существуюзих таблиц — создать новую и перенести в неё данные из старой, которую затем убив. В результате где окажется такая таблица, связанная даже со старыми метаданными? Правда, сейчас 1С Предприятие 8 применяет иную схему ресруктуризации таблиц, я не знаю — какова вероятность пересоздания таблиц при её применении.

    Reply
  13. Shmell

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

    Для текущих баз все останется как и есть. Все их таблицы будут располагаться в пространстве pg_default. Но! Если вы укажете, например, таблице индекса что она теперь принадлежит пространству v81c_index, реструктуризация ничего не порушит. Таким образом, для существующих баз — либо ручками либо скриптом указать новое табличное пространство. Для новых баз платформа разместит данные и индексы в нужных пространствах, если они существуют.

    Антон Дорошкевич, на сколько я понял, имеет в виду что для таблиц файлов конфигурации и расширения всегда действует правило — размещение в пространстве «pg_default». Но! Если мы переместим в кастомное табличное пространство — реструктуризация ничего не убъет и не переместит обратно.

    Reply
  14. Darklight

    (13)Мда, видимо пока своими глазами не увижу как это работает — не смогу понять как это работает. Уж простите, не удалось для меня это разъяснить!

    Reply
  15. Shmell

    (14) Попробуйте, благо в PG это делается достаточно просто и быстро.

    Reply
  16. Alexjas25

    Вадим, недавно Антон Дорошкевич писал про патч OnlineAnalyze для Postgres такую вещь:

    «В последней сборке Postgres, опубликованной на сайте 1С, к сожалению, этого патча нет. Его просто нет в строчке предкомпилированных библиотек, он в настройках есть и даже внизу включен, но его нет в строчках предкомпилируемых библиотек. »

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

    Reply
  17. a.doroshkevich

    (16)Александр, в разных сборках по разному.

    Но на это точно нужно обратить внимание в файле настроек.

    Причин его отсутствия я, к сожалению не знаю. Никаких рекомендаций от Фирмы 1С об исключении этого патча с определенной версии PG я не видел.

    Да и при реальной работе 1С этот патч сильно повышает скорость.

    Reply
  18. Shmell

    (16)

    В 10 версии в библиотеках есть online_analize. Останется только лишь в конфигурационном файле включить параметр. Я это делаю у себя только для баз, в которых у меня активная запись идет, например, регистр сообщений обмена.

    Reply
  19. ansh15

    (9)

    Правильный админ со знанием PG при прочих равных стоит дороже правильного админа со знанием MS SQL

    Если этот «админ» после череды нажатий кнопок «Установить-Далее-Далее…Готово» может еще подвигать ползунок выделения памяти для СУБД, а чтобы включить режим Shared Memory(потому что где-то слышал, что так надо) идет на форум с вопросом «а где искать это, чтобы включить», то это не знания и не квалификация.

    Кстати, а во сколько раз дороже? 10 лет слышу это устойчивое выражение, но конкретных значений, «в среднем по рынку», так никто и не привел…

    За те же 10 лет, что имею дело с 1С, ни разу не возникло мысли перейти с Linux и PostgreSQL на какую-либо другую платформу.

    Reply
  20. acanta

    (19)

    10 лет слышу это устойчивое выражение, но конкретных значений, «в среднем по рынку», так никто и не привел…

    Это зависит не от квалификации, а от умения продавать, в том числе — себя. Если мы продаем PG(GPL) и имеем конкурентом MS SQL, то мы продаем 1с, и какое-то ПО, которое 1с взяла на буксир. Если мы продаем MS SQL, мы продаем скидку на бандл 1С+SQL. Франчайзи, которые продают 1с, заинтересованы в том, чтобы продажа состоялась, а на установку потратить минимум усилий, поскольку как правило установка входит в стоимость продажи.

    Клиент, отваливаясь от франчайзи, оказывается перед фактом, что СУБД требуется квалифицированное обслуживание, ищет кого-нибудь, после чего этот кто-нибудь в любом случае освоит то что уже установлено — либо PG либо SQL (куда он денется с подводной лодки). Причем чем ниже квалификация изначально, тем он безотказнее.

    Reply
  21. emilliya

    Подскажите, пожалуйста,

    есть ли смысл делать отдельное табличное пространство для индексов на одном и том же жестком диске, что и табличное пространство для данных?

    Reply
  22. Shmell

    (21) Смотрите, если Вы не делаете табличные пространства v81c_index и v81c_data, то используется пространство — pg_default — а это одно и то же место на жестком диске для индексов и для данных. Поэтому, если Вы сделаете два табличных пространства на одном жестком диске — скорее всего никакого эффекта не заметите. Ответ — нет.

    Отдельно выносить индексы в другое табличное пространство, которое расположено на другом жестком диске есть смысл… Например, у Вас в конфигурации используются «затюненные» запросы, в которых все поля получаются в основном из индексов (см. покрывающие индексы), и табличное пространство расположено на быстром диске или на ssd — эффект будет сразу виден (при первичном выполнении запросов, т.к. при последующих — информация будет подтягиваться, по возможности, из оперативной памяти). Другое дело, что для современных типовых решений размер таблиц индексов, на диске получается больше чем размер таблиц данных. Это особенность построения индексов для регистров. В таком случае диск должен быть не только быстрым, но и достаточно объемным.

    Reply
  23. emilliya

    (22) Спасибо, поняла

    Reply
  24. baracuda

    Человеки которые пишут, что для того, чтоб админить Postgresql требуется больше квалификации и опыта, нежели чем для MS SQL, я думаю вам пора пересмотреть свои взгляды на образование.

    Reply
  25. drimer

    Исходные данные :

    КА 1.1.107.4 с мелкими доработками

    Платформа 8.3.9.2170

    СУБД Postgres Pro 9.4

    Все работало стабильно почти 2 года, пока не обновил конфу на релиз 1.1.107.4 .

    Заметил, что перестали восстанавливаться архивы созданные с помощью pg_dump.

    Начал разбираться и выяснил, что pg_dump в процессе архивации выдает ошибки :

    pg_dump: Ошибка выгрузки таблицы «config»: сбой в PQgetResult().

    pg_dump: Сообщение об ошибке с сервера: Р?РЁР?Р’Р?Р?: invalid memory alloc request size 1174829507

    pg_dump: Выполнялась команда: COPY public.config (filename, creation, modified,attributes, datasize, binarydata) TO stdout;

    Переносил базу на другие сервера , менял версии Postgres (9.6 и 10.5), менял платформу (8.3.9.2309 и 8.3.10.2772) — результат тот же, pg_dump не может нормально создать архив.

    При постановке конфы обратно на поддержку архивация начинает работать нормально. Такая же проблема и с УПП 1.3.112

    Вот такой замечательный Postgresql

    Reply
  26. MariusUrsus

    (25) Это проблема не Postgres-а и не платформы, а работы этих конфигураций (УПП и КА) в режиме совместимости 8.2.13.

    PostgreSQL из коробки дробит все таблицы на отбельные файлы по 1Гб. Мало того, что размер конфигурации УПП с включенной возможностью изменений >1.4Гб, так еще и при работе в режиме совместимости 8.2.13 вcя конфигурация лежит в одной ячейке. В итоге таблица вынужденно пилится посередине кортежа и назад уже не собирается (точнее не собирается утилитой pg_dump).

    Тут два путя — попробовать пересобирать PostgreSQL «под себя», либо повышать режим совместимости, либо MSSQL.

    Reply
  27. neyasytyf

    (24) Ссылки для таких

    pgtune

    Настройки PostgreSQL для работы с 1С:Предприятием.

    Приложение I. Настройка Postgres Pro для решений 1С

    Этих трех ссылок уже достаточно, чтобы поднастроить Postgresql.

    Ну и эту ссылку можно глянуть.

    Reply
  28. Shmell

    (27) полезная статья, однозначно в избранное.

    Reply
  29. user619273_alevtina

    Спасибо, полезно.

    Reply
  30. uand

    в 4 кейсе, после строк

    pip install mod_wsgi

    сразу требует установленный Апач

    RuntimeError: No Apache installation can be found. Set the MOD_WSGI_APACHE_ROOTDIR environment to its location.

    после установки и set «MOD_WSGI_APACHE_ROOTDIR=C:Apache24»

    вываливается с ошибкой

    error: Microsoft Visual C++ 14.0 is required. Get it with «Microsoft Visual

    C++ Build Tools»: https://visualstudio.microsoft.com/downloads/

    Нужно обязательно качать Build Tools , полный пакет 11Gb или можно как то проще?

    Reply
  31. Shmell

    (31) Такой ошибки при установке не возникало. Вообще, не должна ошибка падать после установки переменных окружения. Во вложении скрин какие пакеты у меня установлены.

    Reply
  32. Bazil

    «Чем поедание кактуса может быть полезно разработчику 1С».

    Reply
  33. acanta

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

    Reply
  34. oldcopy

    (19) Мы уже довольно давно предлагаем своим клиентам как Windows, так и Linux решения под 1С. Ценник на обслуживание одинаковый. Для нормального админа, что запустить инсталлятор и пощелкать Далее — Далее — Готово, что обновить пакеты в Linux — по времени примерно одинаково.

    По производительности — для малого и среднего бизнеса что MS SQL, что Postgres — субъективно примерно одинаково. Да, Postgres надо немного настроить, но в большинстве случаев будет достаточно выполнить все рекомендации с ИТС.

    После чего считаем разницу в деньгах.

    Reply
  35. Gorod111

    «Используем командную строку…

    «нужно создать файл…

    «Меняем строки в следующих двух файлах..

    «в самый конец вставить следующий текст

    Вся суть постгри, мне как типичному одинэснику мышкой тыкнуть лишний раз лень а они «используем командную строку».

    Reply
  36. ansh15

    (35)

    Ценник на обслуживание одинаковый. Для нормального админа, что запустить инсталлятор и пощелкать Далее — Далее — Готово, что обновить пакеты в Linux — по времени примерно одинаково.

    Разрушаете миф, столь усердно поддерживаемый не одно десятилетие. Как теперь «всей командой франчайзи» отговаривать клиента от решения на Linux и PostgreSQL…

    Reply
  37. oldcopy

    (37)

    Как теперь «всей командой франчайзи» отговаривать клиента от решения на Linux и PostgreSQL…

    Не можешь победить — возглавь. В чем проблема тем же франчам предлагать подобные решения? Прибыль с коробок? Так это один раз, а обслуживать надо постоянно, тем более что с Linux меньше вероятность, что обновлять будет какой-нибудь знакомый студент Вася.

    Хотя франчи бывают всякие, у нас один франч, одно время назад напихал всем КА 1.1, теперь вот приходится разгребать это тяжкое наследие. Ну зачем сети из 12 розничных специализированных магазинов (мясо) КА? Или оптовику, который работает сугубо по воде и безалкогольным напиткам?

    Reply

Leave a Comment

Ваш адрес email не будет опубликован. Обязательные поля помечены *