Ubuntu настраиваем подключение к postgresql из вне. PostgreSQL: установка, настройка, обслуживание

Вопросу, какая же СУБД - Postgresql или MS SQL для 1С является наиболее оптимальной, посвящено множество статей. В этой статье мы рассмотрим шаги оптимизации обоих. Каждая СУБД вендора имеет как собственные рекомендации по настройке, так и рекомендации фирмы 1С. Следует отметить, что в зависимости от оборудования, конфигурации серверов и количества пользователей, задающих разную нагрузку, детали процесса оптимизации СУБД под 1С и реализации рекомендаций могут меняться.

Настройка PostgreSQL под 1С

Опыт эксплуатации баз 1С на PostgreSQL показал, что наибольшей производительности и оптимальной работы 1С и PostgreSQL удалось добиться на linux, поэтому желательно использовать именно ее. Но вне зависимости от операционной системы, важно помнить, что настройки, указанные по умолчанию при установке PostgreSQL, предназначены только для запуска сервера СУБД. Ни о какой промышленной эксплуатации речи идти не может! Следующим шагом после запуска станет оптимизация PostgreSQL под 1С:

• Для начала отключаем Energy Saving (в противном случае могут непредсказуемо вырасти задержки ответов из БД) и запрещаем своппинг разделяемой памяти.
• Настраиваем основные параметры сервера СУБД (рекомендации по настройке описаны достаточно подробно, как на официальном сайте вендора, так и компанией 1С, поэтому остановимся только на самых важных).
• В типовых рекомендациях компании 1С предлагается отключать механизмы HyperThreading. Но тестирование Postgres-pro на серверах, с включенной SMT (simultaneous multi threading), показало другие результаты .

Установка параметра shared_buffers в RAM/4 является рекомендацией по умолчанию, но пример Sql Server говорит о том, что чем больше памяти ему выделяется, тем лучше его производительность (при отключенном сбросе страниц в файл подкачки). То есть, чем больше страниц данных располагаются в оперативной памяти, тем меньше обращений к диску. Возникает вопрос: почему такой маленький кэш? Ответ прост: если shared_buffers большой, то часть неиспользуемых страниц свопируется на диск. Но как отследить момент, когда сброс прекратится, и показатель параметра будет оптимальным? Для достижения и выхода на оптимальный показатель shared_buffers, его значение необходимо поднимать на продуктиве ежедневно (по возможности) с определенным шагом прироста и смотреть, в какой момент начнется сброс страниц на диск (увеличится своп).

Помимо этого, на «большой параметр» негативно влияет работа с множеством мелких страниц, которые по умолчанию имеют размер 8Кб. Работа с ними увеличивает накладные расходы. Что можно с этим сделать для оптимизации под 1С? В версии postgreSQL 9.4 появился параметр huge_pages, который можно включить, но только в Linux. По умолчанию включаются огромные страницы с размером по умолчанию 2048 kB. Дополнительно поддержку данных страниц необходимо включить в ОС. Таким образом, оптимизировав структуру хранения, можно выйти на больший показатель shared_buffers.

work_mem = RAM/32..64 или 32MB..128MB Задает объем памяти для каждой сессии, который будет использоваться для внутренних операций сортировки, объединения и пр., прежде чем будут задействованы временные файлы. При превышении этого объема, сервер будет использовать временные файлы на диске, что может существенно снизить скорость обработки запросов. Данный параметр используется при выполнении операторов: ORDER BY, DISTINCT, соединения слиянием и пр.

Посчитать дополнительно данный параметр можно следующим образом: (Общая память shared_buffers – память на другие программы) / число активных соединений. Это значение можно уменьшать, следя за количеством создаваемых временных файлов. Такую статистику по размеру и количеству временных файлов можно получить из системного представления pg_stat_database.

effective_cache_size = RAM - shared_buffers основная задача этого параметра подсказать оптимизатору запроса, какой способ получения данных выбрать: полный просмотр или сканирование по индексу. Чем выше значение параметра, тем больше вероятность использования сканирования по индексу. При этом сервер не учитывает, что данные при выполнении запроса могут оставаться в памяти, и следующему запросу не надо их поднимать с диска.

Установка PostgreSQL

Установка 1С на PostgreSQL под Windows – достаточно простой процесс. При запуске установочного пакета необходимо указать кодировку UTF-8. По сути, это единственный интересный нюанс и еще какая-то настройка PostgreSQL для 1С 8.3 из-под Windows не потребуется. Установка и настройка PostgreSQL для 1С на ОС linux может вызвать ряд затруднений. Для их преодоления в качестве примера рассмотрим запуск работы (используя дистрибутивы ведущего российского вендора PostgreSQL-Pro и компании 1С) PostgreSQL на сервере Ubuntu 16.04 х64

Установка дистрибутивов 1С для СУБД PostgreSQL

1.Скачиваем указанную позицию дистрибутива СУБД PostgreSQL:

2.Выкладываем PostgreSQL на сервер;

3.Распаковать установщик СУБД PostgreSQL можно командой:

tar -xvf postgresql-9.4.2-1.1C_amd64_deb.tar.bz2

4.Перед установкой дистрибутива СУБД PostgreSQL проверим наличие в системе необходимой локали (по умолчанию ru_RU.UTF-8):

5.Если система, с которой будет работать PostgreSQL, ставилась с языком отличным от русского, необходимо создать новые локали:

locale-gen ru_RU update-locale LANG=ru_RU.UTF8 dpkg-reconfigure locales

6.Если необходимая локаль все же имеется, устанавливаем ее по умолчанию:

locale –a nano /etc/default/locale Заменяем содержимое на LANG=ru_RU.UTF-8

7.После перезагрузки, установим необходимые пакеты для нашей версии PostgreSQL:

apt-get install libxslt1.1 ssl-cert

8.Версия PostgreSQL пакета 9.4.2-1.1C связана с пакетом libicu версии libicu48. В репозитории нужной версии уже нет, ее можно скачать ;

9.Скачиваем и помещаем в каталог, где хранятся скачанные файлы для PostgreSQL;

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

cd <Путь к папке с файлами> dpkg -i libicu48_4.8.1.1-3ubuntu0.6_amd64.deb dpkg -i libpq5_9.4.2-1.1C_amd64.deb dpkg -i postgresql-client-common_154.1.1C_all.deb dpkg -i postgresql-common_154.1.1C_all.deb dpkg -i postgresql-client-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-9.4_9.4.2-1.1C_amd64.deb dpkg -i postgresql-contrib-9.4_9.4.2-1.1C_amd64.deb

11.Готово. Дистрибутив СУБД PostgreSQL установлен.

Установка дистрибутивов PostgreSQL-Pro

Для установки сервера необходимо выполнить подряд следующие команды:

sudo sh -c "echo "deb http:// 1c.postgrespro.ru/deb/ $(lsb_release -cs) main" > /etc/apt/sources.list.d/postgrespro-1c.list" wget --quiet -O - http:// 1c.postgrespro.ru/keys/GPG-KEY-POSTGRESPRO-1C-92 | sudo apt-key add - && sudo apt-get update sudo apt-get install postgresql-pro-1c-9.4

Для доступа к серверу редактируем параметры в файле pg_hba.conf

сd <Путь до каталога pg_hba.conf> cp pg_hba.conf pg_hba.conf.old bash -c "echo "local all postgres trust" > pg_hba.conf" bash -c "echo "host all all all md5" >> pg_hba.conf"

Сам файл имеет следующую структуру:

Файл хорошо документирован, но на английском языке. Кратко рассмотрим основные параметры:

• Local локальное подключение только через unix
• Host подключение по TCP/IP
• Hostssl шифрованное SSL-подключение по TCP/IP (сервер должен быть собран с поддержкой SSL, также требуется установить параметр ssl)
• Hostnossl нешифрованное подключение по TCP/IP

• trust допустить без аутентификации
• reject отказать без аутентификации
• password запрос пароля открытым текстом
• md5 запрос пароля в виде MD5
• ldap проверка имени и пароля с помощью сервера LDAP
• radius проверка имени и пароля с помощью сервера RADIUS
• pam проверка имени и пароля с помощью службы подключаемых модулей

Более подробную и развернутую информацию можно посмотреть в документации к продукту PostgreSQL.

root@NODE2:/home/asd# service --status-all |grep postgres [ - ] postgresql root@NODE2:/home/asd# service postgresql start root@NODE2:/home/asd# service --status-all |grep postgres [ + ] postgresql

После окончания основной установки, необходимо настроить конфигурационный файл сервера postgresql.conf, согласно специфики работы PostgreSQL, сервера 1С и конфигурации сервера Ubuntu.

Оптимизация 1С под MS SQL Server

Устанавливаем последние обновления для SQL Sever.

Операционная система резервирует место и забивает его нулями, что занимает достаточно много времени при следующих событиях:

• Создание базы данных;
• Добавление файлов данных, журнал транзакций, к существующей базе данных;
• Увеличение размера существующего файла (в том числе Autogrow-операций);
• Восстанавливаем базы данных или группы файлов.

Решается данная проблема добавлением роли (под которой запущен сервер) к пункту локальной политики безопасности «Выполнение задач по обслуживанию томов».

При возможности необходимо разнести базу TempDB (особенно интенсивно она используется в режиме управляемых блокировок RCSI) и журнал транзакций на разные диски.

На сервере, где работает SQL сервер, режим энергосбережения должен быть установлен в «Высокая производительность».

В папке с файлами БД не должно быть сжатия.

На вкладке «Память» для сервера устанавливаем минимальную планку в размере 50% от общего объема памяти. Максимальную рассчитываем по одной из формул:

• Максимальная память = Общий объем – размер по ОС – размер под 1С (Если он есть, предварительно замерив счетчиками используемую память) или
• Максимальная память = Общий объем – (1024* Общий объем/16384).

Ограничиваем параметр DOP «Max degree of parallelism» и ставим его в значение «1».

Актуализируем статистику по расписанию. Начиная с SQL Server 2008, обновление статистики вызывает перекомпиляцию запросов и, соответственно, очищает процедурный кэш, поэтому отдельную процедуру по очистке процедурного кэша выполнять не надо.

Периодически проводим реиндексацию таблицы и дефрагментацию индексов.

Устанавливаем правильную политику резервирования. Если вам не надо восстанавливаться на последний момент времени к краху системы, а последние минут 5 или больше для вашего бизнеса не критичны, то установите модель восстановления в «Простая». Этим вы ускорите в разы скорость при записи. Главное, чтобы дифференцированный бекап успевал выполняться за указанное время.

Добиваемся улучшения при работе с TempDB при вводе/выводе посредством создания дополнительных файлов данных. Если логических процессоров меньше 8, рекомендуется создать файл данных для каждого логического процессора. Если логических процессоров больше 8, рекомендуется создать 8 файлов данных и, увеличивая на один при кратности 4, обязательно оценить нагрузку на TempDB.

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

Я же опишу ниже как установить и быстро настроить PostgreSQL 10 на Debian 9

Исходные данные: Debian 9 Stretch (amd64)
Задача: Установить PostgreSQL 10.x

1. Предварительная настройка сервера:

Добавляем на сервер русскую локаль, для начала проверяем её отсутствие/присутствие командой

Locale -a | grep ru

если в ответ ничего нет, то запускаем

Dpkg-reconfigure locales

выбираем в списке локаль ru_RU.UTF-8
и жмем Yes
выбираем локаль по умолчанию en_US.UTF-8

2. Начинаем установку PostgreSQL 10:

Echo "deb http://apt.postgresql.org/pub/repos/apt/ $(lsb_release -sc)-pgdg main" > /etc/apt/sources.list.d/pgdg.list wget --quiet -O - https://www.postgresql.org/media/keys/ACCC4CF8.asc | apt-key add - apt-get update apt-get install postgresql-10 -y

Краткая справка по местоположению основных файлов PostgreSQL 10:
Местоположение баз данных:
/var/lib/postgresql/10
Местоположение логов:
/var/log/postgresql/postgresql-10-main.log
Настройка ротации логов:
/etc/logrotate.d/postgresql-common
Основные файлы конфигурации:
/etc/postgresql/10/main/postgresql.conf
/etc/postgresql/10/main/pg_hba.conf

Первым делом меняем пароль пользователя postgres:

Su - postgres psql postgres=# \password postgres postgres=# \q

3. Тюнинг настроек PostgreSQL:

По умолчанию PostgreSQL принимает соединения только с локальных служб, т.к. слушает интерфейс localhost и это абсолютно правильно с точки зрения безопасности, но если Вы планируете подключения к серверу извне или из локальной сети, то Вам потребуется поменять параметр listen_addresses

Для PostgreSQL 10 открываем основной файл настроек

Vi /etc/postgresql/10/main/postgresql.conf

и раскомментируем строку

Listen_addresses = "localhost"

исправим её на

Listen_addresses = "localhost,192.168.100.1"

таким образом мы укажем PostgreSQL слушать сетевые соединения на интерфейсе localhost и на нашем внутреннем интерфейсе локальной сети с IP адресом 192.168.100.1

Далее смотрим на параметр max_connections , который определяет максимальное количество одновременных соединений, которые будет обслуживать сервер PostgreSQL. В принципе, это число должно определяться исходя из требований к системе. Этот параметр в большей степени влияет на использование ресурсов. Если Вы только запустили БД, устанавливайте это значение небольшим (16…32), по умолчанию он установлен 100. Постепенно можно увеличивать max_connections (по мере необходимости — такой мерой будет получение ошибок от postgresql «too many clients»).
Учтите! На поддержку каждого активного клиента, PostgreSQL тратит немалое количество ресурсов, и если Вам необходимо добиться производительности в несколько тысяч активных соединений, то стоит использовать менеджеры соединений, например: или .
Важно! Значение параметра max_wal_senders должно быть меньше max_connections, поэтому если Вы установили max_connections = 10, то max_wal_senders нужно поменять к примеру на 5

Смотрим на параметр shared_buffers
Этот параметр определяет, сколько памяти будет выделяться PostgreSQL для кеширования данных.
В стандартной поставке значение этого параметра 128 МБ, то есть по сути мизерное — для обеспечения совместимости. В практических условиях это значение следует установить в 15..25% от всей доступной оперативной памяти сервера. Учтите, слово всей доступной, то есть учитывайте память которую занимают текущие процессы и могут занять в случае роста потребления, к примеру у нас 8 ГБ ОЗУ и стоит MySQL, который в текущем состоянии занять 1 ГБ ОЗУ, а при росте количества соединений исходя из настроек может занять все 6 ГБ ОЗУ, тогда для PostgreSQL остается не так много памяти и shared_buffers никак нельзя поставить 2 ГБ. Если у Вас большие активные порции базы данных, сложные запросы, большое число одновременных соединений, длительные транзакции, Вам доступен большой объем ОЗУ или большее количество процессоров, то можно увеличивать значение shared_buffers и смотреть результат, чтобы не привести к «деградации» (падению) производительности. Выделив слишком много памяти для shared_buffers, мы можем получить ухудшение производительности, поскольку PostgreSQL также использует кэш операционной системы (увеличение данного параметра более 40% оперативной памяти может давать «нулевой» прирост производительности).

Параметр effective_cache_size
Этот параметр помогает планировщику postgresql определить количество доступной памяти для дискового кеширования. На основе того, доступна память или нет, планировщик будет делать выбор между использованием индексов и использованием сканирования таблицы. Это значение следует устанавливать в 50%…75% всей доступной оперативной памяти, в зависимости от того, сколько памяти доступно для системного кеша. Еще раз — этот параметр не влияет на выделяемые ресурсы — это оценочная информация для планировщика.

Параметры min_wal_size, max_wal_size, checkpoint_timeout, checkpoint_completion_target, wal_buffers
Существует несколько параметров конфигурации, связанных с WAL, которые влияют на производительность базы данных. На эти и некоторые другие настройки стоит обратить внимание, если у Вас происходит немалое количество записей в БД (для высоконагруженных систем это нормальная ситуация).
Более подробно следует прочитать или .

Параметр work_mem
Важный параметр для запросов, использующих всевозможные сложные выборки и сортировки. Увеличение его
позволяет выполнять эти операции в оперативной памяти, что гораздо более эффективно, чем на диске (еще бы).
Если объём памяти недостаточен для сортировки некоторого результата, то серверный процесс будет использовать временные файлы. Если же объём памяти слишком велик, то это может привести к своппингу.
Будьте внимательны! Это не разделяемая память, work_mem выделяется отдельно на каждую операцию (от одного до нескольких раз за один запрос). Следовательно, если у Вас 10 активных клиентов и каждый выполняет 1 сложный запрос, то значение в 10 МБ для этого параметра скушает 100 МБ оперативной памяти.
Этот параметр стоит увеличивать, если у Вас большое количество памяти в распоряжении. Чем больше max_connections тем меньше должен быть work_mem. В качестве начального значения для параметра можете взять 2–4% доступной памяти. Для веб-приложений обычно устанавливают низкие значения work_mem, так как запросов обычно много, но они простые, обычно хватает от 512 до 2048 КБ. С другой стороны, приложения для поддержки принятия решений с сотнями строк в каждом запросе и десятками миллионов столбцов в таблицах фактов часто требуют work_mem порядка 500 Мб. Для баз данных, которые используются и так, и так, этот параметр можно устанавливать для каждого запроса индивидуально, используя настройки сессии. Например, при памяти 1–4 ГБ рекомендуется устанавливать 32–128 МБ.

Параметр synchronous_commit
Обратите особое внимание на этот параметр! Он включает/выключает синхронную запись в лог файлы после каждой транзакции. Это защищает от возможной потери данных. Но это накладывает ограничение на пропускную способность сервера.
Допустим, в Вашей системе не критична потенциально низкая возможность потери небольшого количества изменений при крахе системы. Но жизненно важно обеспечить в несколько раз большую производительность по количеству транзакций в секунду. В этом случае устанавливайте этот параметр в off (отключение синхронной записи).

Параметр maintenance_work_mem
Задаёт максимальный объём памяти для операций обслуживания БД, в частности VACUUM, CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. По умолчанию его значение - 64 мегабайта (64MB). Так как в один момент времени в сеансе может выполняться только одна такая операция, и обычно они не запускаются параллельно, это значение вполне может быть гораздо больше work_mem. Увеличение этого значения может привести к ускорению операций очистки и восстановления БД из копии, но слишком большие значения приведут к использованию свопа.
Учтите, что когда выполняется автоочистка, этот объём может быть выделен autovacuum_max_workers раз, поэтому не стоит устанавливать значение по умолчанию слишком большим. Возможно, будет лучше управлять объёмом памяти для автоочистки отдельно, изменяя autovacuum_work_mem.
Чтобы операции выполнялись максимально быстро, нужно устанавливать этот параметр тем выше, чем больше размер таблиц в вашей БД. Неплохо бы устанавливать его значение от 50 до 75% размера вашей самой большой таблицы или индекса или, если точно определить невозможно, от 32 до 256 МБ. Например, при памяти 1–4 ГБ рекомендуется устанавливать 128–512 МБ.
Временное увеличение maintenance_work_mem рекомендуют для ускорения загрузки больших объёмов данных в БД. Это приведёт к увеличению быстродействия CREATE INDEX и ALTER TABLE ADD FOREIGN KEY. На скорость самой команды COPY это не повлияет, так что этот совет будет полезен, только если вы применяете какой-либо из двух вышеописанных приёмов.

Более детально о всех параметрах или .

Давайте настроим эти параметры исходя из
— объема свободного ОЗУ в 1 ГБ;
— максимального количества одновременных соединений 10;
— количество CPU — 1;
— сервер будет выполнять задачи БД для Web-приложений;
— база будет располагаться на массиве RAID 1 из 2 дисков SATA HDD;

Max_connections = 10 shared_buffers = 256MB effective_cache_size = 768MB maintenance_work_mem = 64MB checkpoint_completion_target = 0.7 wal_buffers = 7864kB default_statistics_target = 100 random_page_cost = 4 effective_io_concurrency = 2 work_mem = 26214kB min_wal_size = 1GB max_wal_size = 2GB

Хочу заметить, что многие настройки PostgreSQL зависят не только от аппаратной конфигурации, но и от размера базы данных, числа клиентов и сложности запросов, так что оптимально настроить базу данных возможно только учитывая все параметры системы и приложения (например учитывать, SSD диски и влезает ли база в память). Для облегчения первоначальной настройки Pg существует от Алексея Васильева.

Теперь разрешим подключение из локальной сети с любых хостов и к любым БД, для этого в конец файла /etc/postgresql/10/main/pg_hba.conf добавим:

# localnet host all all 192.168.100.0/24 md5

Service postgresql restart

Проверяем открытые порты

Netstat -ltupn |grep postgre tcp 0 0 192.168.100.4:5432 0.0.0.0:* LISTEN 32658/postgres tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 32658/postgres

Отлично! Теперь мы можем подключиться к PostgreSQL c локального сервера и из нашей локальной сети.

На этом все, до скорых встреч.

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

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

Вступление

Я много работал с PostgreSQL и считаю его прекрасной СУБД. У меня многогигабайтная рабочая база (не 1С) обрабатывает моментально огромные массивы данных. PostgreSQL прекрасно использует индексы, хорошо справляется с параллельной нагрузкой, функционал хранимых процедур на высоте, есть хорошие средства администрирования и повышения производительности "из коробки", а сообщество создало полезные утилиты. Но я с удивлением узнал что у многих администраторов 1С мнение о PostgreSQL не на высоте, что он тормоз и едва обгоняет файловый вариант базы, и только MSSQL может спасти положение.

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

И если подход "установка в одну кнопку" применим к MSSQL и вообще многим продуктам под Windows, то к PostgreSQL он, к сожалению, не относится. Настройки по умолчанию очень сильно ограничивают его в использовании памяти, чтобы можно было его установить хоть на калькулятор и он там не мешал работе остального ПО. PostgreSQL обязательно нужно конфигурировать под конкретную систему, и только тогда он сможет показать себя на высоте. В особо тяжелых случаях можно тюнинговать настройки PostgreSQL, базы и файловой системы друг под друга, но это касается в большей степени Linux-систем, где больше возможностей по настройке всего и вся.

Следует напомнить, что для 1С не подойдет сборка PostgreSQL от разработчиков СУБД, только собранная из пропатченных 1С исходных текстов. Готовые совместимые сборки предлагает 1С (через диски ИТС и кабинет для имеющих подписку на поддержку) и EterSoft

Тестирование проводилось в среде Windows, но все рекомендации по настройке не являются специфичными для платформы и применимы к любой ОС.

Тестирование и сравнение

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

Для тестирования я использовал следующую конфигурацию:
Host-машина: Win7, Core i5-760 2.8MHz, 4 ядра, 12Гб ОЗУ, VMWare 10
Виртуальная: Win7 x64, 2 ядра, 4Гб ОЗУ, отдельный физический жесткий диск для размещения БД (не SSD)
MSSQL Express 2014
PostgreSQL EtherSoft 9.2.1
1C 8.3.5 1383

Использовалась БД, dt-выгрузка 780Мб.
После восстановления базы:
размер файла 1CD в файловом варианте - 10Гб,
размер базы PostgreSQL - 8Гб,
размер базы MSSQL - 6.7Гб.

Для теста использовал запрос на выборку договоров контрагентов (21к) с выборкой дополнительных реквизитов из различных регистров, для каждого договора фактически делалась отдельная выборка из регистров. Конфигурацию взял что была под рукой - сильно доработанная на базе Бухгалтерии 3.0.

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

Тестирование одним клиентом:

Выборка на хосте из файлового варианта с размещением базы на SSD - 31с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - 46с
Выборка из MSSQL-базы - первый проход - 25с или 9с (видимо в зависимости от актуальности кэша СУБД) (потребление памяти процессом СУБД составило примерно 1.3Гб)
Выборка из PostgreSQL с настройками по умолчанию - 43с (потребление памяти не превышало 80Мб на подключение)
Выборка из оптимизированного PostgreSQL - 21с (потребление памяти составило 120Мб на подключение)

Тестирование двумя клиентами:

Выборка на хосте из файлового варианта с размещением базы на SSD - по 34с
Выборка из файлового варианта в виртуальной машине (с жесткого диска) - по 56с
Выборка из MSSQL-базы - по 50с или 20с (видимо в зависимости от актуальности кэша СУБД)
Выборка из PostgreSQL с настройками по умолчанию - по 60с
Выборка из оптимизированного PostgreSQL - по 40с

Замечания к тестированию:

1. После добавления третьего ядра PostgreSQL и MSSQL-варианты стали работать в тесте "два клиента" практически с производительностью теста "один клиент", т.е. удачно распараллелились. Что мешало им параллелить работу на двух ядрах для меня осталось загадкой.
2. MSSQL памяти захватил сразу много, PostgreSQL требовал во всех режимах существенно меньше, и сразу после завершения выполнения запроса почти всю высвобождал.
3. MSSQL работает единым процессом. PostgreSQL запускает по отдельному процессу на подключение+служебные процессы. Это позволяет даже 32-разрядному варианту эффективно использовать память при обработке запросов от нескольких клиентов.
4. Увеличение памяти для PostgreSQL в настройках свыше указанных ниже значений не привело к заметному росту производительности.
5. Первые тесты во всех случаях проходили дольше чем в последующих замерах, специально замеры не производил, но MSSQL субъективно стартовал быстрее.

Конфигурирование PostgreSQL

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

В Windows конфигурационные файлы PostgreSQL находятся в каталоге установки в каталоге Data:

• postgresql.conf - основной файл с настройками СУБД
• pg_hba.conf - файл с настройками доступа для клиентов. В частности, тут можно указать каким пользователям с каких IP-адресов можно подключаться к определенным БД, и требуется ли проверять пароль пользователя, и если требуется - каким методом.
• pg_ident.conf - файл с преобразованием имен пользователей из системных во внутренние (вряд ли он потребуется большинству пользователей)

Файлы текстовые, можно править блокнотом. Строки, начинающиеся с # считаются комментариями и игнорируются.

Параметры, относящиеся к объму памяти могут дополняться суффиксами kB, MB, GB - килобайты, мегабайты, гигабайты, например, 128MB. Параметры, описывающие интервалы времени, могут дополняться суффиксами ms,s,min,h,d - миллисекунды, секунды, минуты, часы, дни, например, 5min

Если вы забыли пароль к постгрессу - не беда, можно прописать в pg_hba.conf строку:

Host all all 127.0.0.1/32 trust

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

Оптимизация использования памяти

Настройки использования памяти располагаются в postgresql.conf

Оптимальные значения параметров зависят от объема свободной оперативной памяти, размера базы и отдельных элементов базы (таблицы и индексы), сложности запросов (в принципе, стоит полагаться что запросы будут достаточно сложными - множественные соединения в запросах это типовой сценарий) и количества одновременных активных клиентов. Кстати, PostgreSQL хранит таблицы и индексы БД в отдельных файлах (<каталог установки PG>\data\base\<идентификатор БД>\), и размеры объектов можно оценить. Так же можно используя входящую в поставку утилиту pgAdmin подключиться к базе, раскрыть "Схемы"-"public", и сформировать отчет по статистике для элемента "Таблицы".

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

При настройке сервера для тестирования я полагался на следующие расчеты:
Всего 4Гб ОЗУ. Потребители - ОС Windows, сервер 1С, PostgreSQL и дисковый кэш системы. Я исходил из того что для СУБД можно выделить до 2.5Гб ОЗУ

Значения могут указываться с суффиксами kB, MB, GB (значения в килобайта, мегабайтах или гигабайтах). После изменения значений требуется перезапустить службу PostgreSQL.

shared_buffers - Общий буфер сервера

Размер кэша чтения и записи PostgreSQL, общего для всех подключений. Если данные отсутствуют в кэше, производится чтение с диска (возможно, будут кэшированы ОС)

Если объём буфера недостаточен для хранения часто используемых рабочих данных, то они будут постоянно писаться и читаться из кэша ОС или с диска, что крайне отрицательно скажется на производительности.

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

В тесте использовалось

shared_buffers = 512MB

work_mem - память для сортировки, агрегации данных и т.д.

Выделяется на каждый запрос, возможно по нескольку раз для сложных запросов. Если памяти недостаточно - PostgreSQL будет использовать временные файлы. Если значение слишком большое - может возникнуть перерасход оперативной памяти и ОС начнет использовать файл подкачки с соответствующим падением быстродействия.

Есть рекомендация при расчетах взять объем доступной памяти за вычетом shared_buffers , и поделить на количество одновременно исполняемых запросов. В случае сложных запросов делитель стоит увеличить, т.е. уменьшить результат. Для рассматриваемого случая из расчета 5 активных пользователей (2.5Гб-0.5Гб (shared_buffers))/5=400Мб. В случае если СУБД сочтет запросы достаточно сложными, или появятся дополнительные пользователи, потребуется значение уменьшить.

Для простых запросов достаточно небольших значений - до пары мегабайт, но для сложных запросов (а это типовой сценарий для 1С) потребуется больше. Рекомендация - для памяти 1-4Гб можно использовать значения 32-128Мб. В тесте использовал

work_mem = 128MB

maintenance_work_mem - память для команд сбора мусора, статистики, создания индексов.

Рекомендуется устанавливать значение 50-75% от размера самой большой таблицы или индекса, но чтобы памяти хватило для работы системы и приложений. Рекомендуется устанавливать значения больше чем work_mem. В тесте использовал
maintenance_work_mem = 192MB

temp_buffers - буфер под временные объекты, в основном для временных таблиц.

Можно установить порядка 16 МБ. В тесте использовал
temp_buffers = 32MB

effective_cache_size - примерный объем дискового кэша файловой системы.

Оптимизатор использует это значение при построении плана запроса, для оценки вероятности нахождения данных в кэше (с быстрым случайным доступом) или на медленном диске. В Windows текущий объем памяти, выделенной под кэш, можно посмотреть в диспетчере задач.

Autovacuum - "сборка мусора"

PostgreSQL как типичный представитель "версионных" СУБД (в противоположность блокирующим) самостоятельно не блокирует при изменении данных таблицы и записи от читающих транзакций (в случае 1С этим занимается сам сервер 1С). Вместо этого создаётся копия изменяемой записи, которая становится видна последующим транзакциям, действующие же продолжают видеть данные, актуальные на начало своей транзакции. Как следствие, в таблицах накапливаются устаревшие данные - предыдущие версии измененных записей. Для того чтобы СУБД могла высвободившееся место использовать, необходимо произвести "сборку мусора" - определить какие из записей больше не используются. Это можно сделать явно SQL-командой VACUUM , либо дождаться когда таблицу обработает автоматический сборщик мусора - AUTOVACUUM . Так же до определенной версии сборка мусора была связана со сбором статистики (планировщик использует данные о количестве записей в таблицах и распределении значений индексированных полей для построения оптимального плана запроса). С одной стороны, сбор мусора делать необходимо, чтобы таблицы не разрастались и эффективно использовали дисковое пространство. С другой внезапно начавшаяся уборка мусора дает дополнительную нагрузку на диск и таблицы, что приводит к увеличению времени выполнения запросов. Аналогичный эффект создает автоматический сбор статистики (явно его можно запустить командой ANALYZE или совместно со сборкой мусора VACUUM ANALYZE ). И хотя от версии к версии PostgreSQL совершенствует эти механизмы, чтобы минимизировать негативное влияние на производительность (например, в ранних версиях сборка мусора полностью блокировала доступ к таблице, с версии 9.0 работа VACUUM ускорена), тут есть что настроить.

Полностью отключить autovacuum можно параметром:

autovacuum = off

Так же для работы Autovacuum требуется параметр track_counts = on, в противном случае он работать не будет.

По умолчанию оба параметра включены. На самом деле autovacuum полностью отключить нельзя - даже при autovacuum = off иногда (после большого количества транзакций) autovacuum будет запускаться.

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

Если Autovacuum полностью не отключать, настроить его влияние на выполнение запросов можно следующими параметрами:

autovacuum_max_workers - максимальное количество параллельно запущенных процессов уборки.

autovacuum_naptime - минимальный интервал, реже которого autovacuum не будет запускаться. По умолчанию 1 минута. Можно увеличить, тогда при частых изменениях данных анализ будет выполняться реже.

autovacuum_vacuum_threshold, - количество измененных или удаленных записей в таблице, необходимых для запуска процесса сборки мусора VACUUM или сбора статистики ANALYZE . По умолчанию по 50.

autovacuum_vacuum_scale_factor , autovacuum_analyze_scale_factor - коэфициент от размера таблицы в записях, добавляемый к autovacuum_vacuum_threshold и autovacuum_analyze_threshold соответственно. Значения по умолчанию 0.2 (т.е. 20% от количества записей) и 0.1 (10%) соответственно.

Рассмотрим пример с таблицей на 10000 записей. Тогда при настройках по умолчанию после 50+10000*0.1=1050 измененных или удаленных записей будет запущен сбор статистики ANALYZE , а после 2050 изменений - сборка мусора VACUUM .

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

Таким образом может иметь смысл увеличить интервал autovacuum_naptime, и несколько увеличить threshold и scale_factor. В нагруженных базах может быть альтернативой существенно поднять scale_factor (значение 1 позволит "разбухать" таблицам вдвое) и поставить в планировщик ежесуточное выполнение VACUUM ANALYZE в период минимальной загруженности БД.

default_statistics_target - назначает объем статистики, собираемый командой ANALYZE . Значение по умолчанию 100. Большие значения увеличивают время выполнения команды ANALYZE, но позволяют планировщику строить более эффективные планы выполнения запросов. Встречаются рекомендации по увеличению до 300.

Можно управлять производительностью AUTOVACUUM , делая его более длительным но менее нагружающим систему.

vacuum_cost_page_hit - размер "штрафа" за обработку блока, находящегося в shared_buffers. Связан с необходимостью блокировать доступ к буферу. Значение по умолчанию 1

vacuum_cost_page_miss - размер "штрафа" за обработку блока на диске. Связан с блокировкой буфера, поиском данных в буфере, чтении данных с диска. Значение по умолчанию 10

vacuum_cost_page_dirty - размер "штрафа" за модификацию блока. Связан с необходимостью сбросить модифицированные данные на диск. Значение по умолчанию 20

vacuum_cost_limit - максимальный размер "штрафов", после которых процесс сборки может быть "заморожен" на время vacuum_cost_delay. По умолчанию 200

vacuum_cost_delay - время "заморозки" процесса сборки мусора по достижению vacuum_cost_limit. Значение по умолчанию 0ms

autovacuum_vacuum_cost_delay - время "заморозки" процесса сборки мусора для autovacuum. По умолчанию 20ms. Если установить -1, будет использоваться значение vacuum_cost_delay

autovacuum_vacuum_cost_limit - максимальный размер "штрафа" для autovacuum. Значение по умолчанию -1 - используется значение vacuum_cost_limit

По сообщениям использование vacuum_cost_page_hit = 6 , vacuum_cost_limit = 100 , autovacuum_vacuum_cost_delay = 200ms уменьшает влияние AUTOVACUUM до 80%, но увеличивает время его выполнения втрое.

Настройка записи на диск

При завершении транзакции PostgreSQL начала пишет данные в специальный журнал транзакций WAL (Write-ahead log), а затем уже в базу после того, как данные журнала гарантированно записаны на диск. По умолчанию используется механизм fsync , когда PostgreSQL принудительно сбрасывает данные (журнала) из дискового кэша ОС на диск, и только после успешной записи (журнала) клиенту сообщается об успешном завершении транзакции. Использование журнала транзакций позволяет завершить транзакцию или восстановить базу если во время записи данных произойдет сбой.

В нагруженных системах с большими объемами записи может иметь смысл вынести журнал транзакций на отдельный физический диск (но не на другой раздел этого же диска!). Для этого нужно остановить СУБД, перенести каталог pg_xlog в другое место, а на старом месте создать символическую ссылку, например, утилитой junction. Так же ссылки умеет создавать Far Manager (Alt-F6). При этом надо убедиться что новое место имеет права доступа для пользователя, от которого запускается PostgreSQL (обычно postgres).

При большом количестве операций изменения данных может потребоваться увеличить значение checkpoint_segments, регулирующее объем данных, который может ожидать переноса из журнала в саму базу. По умолчанию используется значение 3. При этом следует учитывать что под журнал выделяется место, расчитываемое по формуле (checkpoint_segments * 2 + 1) * 16 МБ, что при значении 32 уже потребует более 1Гб места на диске.

PostgreSQL после каждого завершения пишущей транзакции сбрасывает данные из файлового кэша ОС на диск. С одной стороны, это гарантирует что данные на диске всегда в актуальном состоянии, с другой при большом количестве транзакций падает производительность. Полностью отключить fsync можно, указав

fsync = off
full_page_writes = off

Делать это можно только в случае если вы на 100% доверяете оборудованию и ИБП (источнику бесперебойного питания). Иначе в случае аварийного завершения системы есть риск получить разрушенную БД. И в любом варианте не помешает так же RAID-контроллер с батарейкой для питания памяти недозаписанных данных.

Определенной альтернативой может быть использование параметра

synchronous_commit = off

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

Если не отключать fsync совсем, можно указать метод синхронизации в параметре. Статья с диска ИТС ссылается на утилиту pg_test_fsync, но в моей сборке PostgreSQL её не оказалось. По утверждению 1С, в их случае в Windows оптимально себя показал метод open_datasync (судя по всему, именно этот метод и используется по умолчанию).

В случае если используется множество мелких пишущих транзакций (в случае 1С этом может быть массовое обновление справочника вне транзакции), может помочь сочетание параметров commit_delay (время задержки завершения транзакции в микросекундах, по умолчанию 0) и commit_siblings (по умолчанию 5). При включении опций завершение транзакции может быть отложено на время commit_delay, если в данный момент исполняется не менее commit_siblings транзакций. В этом случае результат всех завершившихся транзакций будет записан совместно для оптимизации записи на диск.

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

wal_buffers - объем памяти в shared_buffers для ведения транзакционных логов. Рекомендация - при 1-4Гб доступной памяти использовать значения 256КБ-1МБ. Документация утверждает что использование значения "-1" автоматически подбирает значение в зависимости от значения shared_buffers.

random_page_cost - "стоимость" случайного чтения, используется при поиске данных по индексам. По умолчанию 4.0. За единицу берется время последовательного доступа к данным. Для быстрых дисковых массивов, особенно SSD, имеет смысл понижать значение, в этом случае PostgreSQL будет более активно использовать индексы.

В книге по ссылке есть некоторые другие параметры, которые можно настраивать. Так же настоятельно рекомендуется ознакомиться с документацией на PostgreSQL по назначению конкретных параметров.

Параметры из раздела QUERY TUNING, особенно касающиеся запрета планировщику использовать конкретные методы поиска, рекомендуется изменять только в том случае если есть полное понимание что делаете. Очень легко оптимизировать один вид запросов и обрушить производительность всех остальных. Эффективность изменения большинства параметров в этом разделе зависит от данных в БД, запросов к этим данным (т.е. от используемой версии 1С в т.ч.) и версии СУБД.

Заключение

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

Критика и дополнения к этой статье приветствуются.

Полезные ссылки

http://postgresql.leopard.in.ua/ - сайт книги "Работа с PostgreSQL настройка и масштабирование ", наиболее полное и понятное руководство на мой взгляд по конфигурированию и администрированию PostgreSQL

http://etersoft.ru/products/postgre - здесь можно скачать 1С-совместимую сборку PostgreSQL под Windows и различные дистрибутивы и версии Linux. Для тех у кого нет подписки на ИТС или требуется версия под версию Linux, которая не представлена на v8.1c.ru.

http://www.postgresql.org/docs/9.2/static/ - официальная документация на PostgreSQL (на английском)

Статьи с диска ИТС по настройке PostgreSQL

История правок статьи

• 29.01.2015 - опубликована первоначальная версия
• 31.01.2015 - статья дополнена разделом по AUTOVACUUM, добавлена ссылка на оригинальную документацию.

В дальнейшем я намерен провести тестирование работы СУБД в режиме добавления и изменения данные.

С момента выхода прошлой статьи об установке PostgreSQL 8.3 на Windows XP прошло уже довольно много времени. Надеюсь, что она помогла части людей произвести это нехитрое действие. Статья расползлась по другим сайтам, некоторые из которых просто и незатейливо выкинули из неё отметку об авторе. Тем не менее, пришла пора снова написать об одном и том же, хотя установка PostgreSQL и тогда не вызывала никаких проблем, как не вызывает их и сейчас.

Проблема в том, что надо хотя бы обладать какими-то базовыми знаниями в администрировании PostgreSQL, чтобы устанавливать сервер PostgreSQL. На форуме постоянно задают вопросы не зная даже элементарных вещей и основ. Особенно свирепствуют игроки покера и владельцы программы Holdem Manager, которые мало того, что ничего кроме покера не знают, так и знать не хотят. Например, я ведь не прихожу на покерный форум не читая правил покера и не требую на пальцах объяснить мне как выйграть миллион. Мне же тоже не очень интересно поддерживать пользователей коммерческих программ на бесплатной основе, тем более, что эти пользователи никогда ничего не сделают полезного для сообщества PostgreSQL, выступая исключительно как потребители.

Итак! Страдальцами Windows посвящается....

Версии PostgreSQL 9.x и исходные данные

Начиная с версии 9.0 для Windows предоставляются собранные версии как 32-bit так и 64-bit. В данной статье рассматривалась установка 64-битной версии PostgreSQL 9.0.1 на 64-битную версию Windows 7 Home Basic. Установка производилось от пользователя, имеющего административные права. Не вижу причин и каких-либо препятствий, по которым установка 32-битной версии чем-то отличалась от 64-битной, а также каких-то принципиальных различий между Windows 7 Home Basic и другими редакциями Windows 7.

Поехали

Берём архив с установкой PostgreSQL. Я взял версию 9.0.1 прямо с этой странички . Сохраняем в любой временный каталог, например c:\tmp. Запускаем. После стандартного предупреждения Windows о том, что мы пытаемся запустить приложение от стороннего разработчика, на что мы отвечаем утвердительно, начинается процесс установки:

Как видим, сперва появляется картинка, о том, что Windows конфигурирует библиотеку Visual C++. Не зная подробностей, рискну предположить, что эта библиотека распространяется с PostgreSQL для Windows, потому что PostgreSQL на платформе Windows компилировался на Visual C++. Тем не менее, появляется следующая картинка, уже более имеющая отношение к установке:

Это начальное диалоговое окно, предлагающее вам начать установку. Щёлкаем по Next и получаем следующее окно:

В этом диалоговом окне вам предлагается указать каталог, в который будет устанавливаться PostgreSQL. Лично меня вполне устроил путь, предложенный по умолчанию инсталлятором, поэтому я нажал Next и получил следующее окно:

В этом диалоговом окне вам предлагается указать каталог, в котором будут хранится файлы с базами данных. Это довольно удобно и разработчики логично предположили, что многие могут захотеть хранить данные на других дисках, скажем более быстрых, для увеличения производительности БД. Раньше, конечно, это тоже можно было настроить через файл конфигурации, но теперь это можно сделать уже на этапе установки. Лично меня вполне устроил путь, предложенный по умолчанию инсталлятором, поэтому я нажал Next и получил следующее окно:

Ну вот мы и добрались до первого и многочисленного источника вопросов на форуме. Просто куча народу спрашивает какой пароль вводить? Неужели так трудно прочитать что написано? Ну да, я понимаю, что кто-то в школе на уроках английского тупо спал, а кто-то изучал немецкий, но ведь есть же языковые инструменты Google , где в большинстве случаев можно быстро получить вполне осмысленный перевод непонятной английской фразы! Опять ломает? Ладно, перевожу специально для таких: "Пожалуйста, предоставьте пароль для суперпользователя баз данных (postgres) и учётной записи службы (postgres). Если учётная запись службы уже существует в Windows, вы должны ввести текущий пароль этой учётной записи. Если данная учётная запись не существует, она будет создана, когда вы нажмёте Next "

Всё ещё непонятно? Тогда для тех, кто не читал документацию, объясняю на пальцах. Есть в Windows учётные записи пользователей. Наверняка вы сейчас работаете под одной из них, ибо учётная запись всегда имеет имя пользователя. Так вот, PostgreSQL в Windows работает не от администратора, а тоже от имени учётной записи пользователя, имя которого postgres. Сделано это было прежде всего из соображений безопасности, чтобы никакие вредители не смогли получить права администратора, даже если они каким-то образом найдут дыру в безопасности самого PostgreSQL. Далее. В самой СУБД PostgreSQL есть такой специальный пользователь - суперпользователь, который имеет максимальные права внутри СУБД, т.е. может создавать или удалять любые базы данных и любых пользователей. Он тоже имеет имя postgres. Несмотря на то, что имена пользователей учётной записи и суперпользователя PostgreSQL одинаковы - это разные пользователи, никак не связанные друг с другом. Но для того, чтобы вы потом не путались с разными паролями, вам предлагают задать один и тот же пароль для них обоих.

Многие спрашивают: а что делать, если мы ставим PostgreSQL повторно, а старый пароль забыли? Интересно, а голову они дома не забывают, когда уходят на работу или погулять? Иначе как раздолбайством такое не назовёшь. Однако, читайте внимательно специальный FAQ , там есть ответ на вопрос, что можно сделать в таком случае.

В этом окне вам предлагается указать другой порт TCP/IP для PostgreSQL. Не вижу причин менять тот, который предлагается по умолчанию. Щёлкаем Next:

В этом окне вам предлагается выбрать локаль, с использованием которой будет инициализирован кластер баз данных и которая в дальнейшем будет использоваться по умолчанию при создании других баз данных. Это довольно важный шаг, ибо локаль определяет такой важный параметр как кодировка данных в базах. На картинке вы видите, что я выбрал "Russia, Russia". В этом случае, кодировка вашей БД будет windows-1251. Возможно, это именно то, что вам нужно, но большинство людей всё-таки предпочитает работать с кодировкой UTF-8. Эта кодировка будет установлена в том случае, если в данном окне вы выберите локаль по умолчанию: "by default". Перед тем как выбрать локаль хорошенько подумайте. Если вы устанавливаете PostgreSQL для обеспечения работы какого-либо приложения, прочтите документацию к нему, возможно это приложение требует какую-то конкретную кодировку. После того, как вы выбрали локаль, щёлкаете Next:

Инсталлятор вам радостно говорит. что он типа готов наконец начать установку. Щёлкаем Next. Начинается процесс копирования файлов в указанный ранее каталог. После чего в этом же окошке вы увидите:

где советую обратить внимание на слова: "Initialising database cluster" (инициализирую кластер баз данных), означающие, что копирование файлов закончено и создаётся первая база данных, которая будет затем использоваться как шаблон для всех остальных баз. Через некоторое время эта надпись сменяется на "starting database server" (запускаю сервер баз данных), что означает запуск службы сервера PostgreSQL. После чего появляется окно окончания установки:

Здесь нам предлагается ещё запустить инструмент установки дополнительных компонентов PostgreSQL, но мне это не интересно, поэтому снимаю галочку и щёлкаю на Finish

Это всё! Установка завершена! Особо параноидальные товарищи, могут запустить Диспетчер Задач, щёлкнуть по вкладке Службы и убедиться, что PostgreSQL работает:

Вопросы по pgAdminIII

Многие задают вопрос. Вот я запустил pgAdminIII, ярлык на который появляется в меню Пуск сразу после установки, а там мне рисует картинку, где сервер PostgreSQL перечёркнут красным крестиком, вот так:

"памажите, добрые люди, а чо делать та?"

Ну хотя бы соединение с сервером установить для начала, для чего тупо дважды щёлкнуть по этому самому значку сервера, перечёркнутому красным крестиком. Появится окошко, в котором вас попросит ввести пароль для пользователя postgres, тот самый пароль который вы вводили раннее, при установке. Если вы введёте его правильно, красный крестик исчезнет и окно pgAdminIII примет вид:

Подключение к серверу PostgreSQL с помощью утилиты командной строки psql

Показываю на картинке:

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

Ещё обратите внимание на предупреждающее сообщение о несовпадении текущей кодировки в консоли и кодировки сервера. Дело в том, что согласно нашей установке мы выбрали ранее локаль Russia, Russia, что привело к выбору кодировки windows-1251, но консоль (командная строка) Windows работает в кодировке cp866 и это надо понимать и учитывать при дальнейшей работе

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

Postgresql - это объектно-реляционная система управления базами данных, которая все больше и больше вытесняет MySQL и производственных серверов. Ее преимущество в множестве дополнительных функций и улучшений, таких как надежная передача данных и параллелизация без блокировок чтения. Вы можете использовать эту СУБД из различных языков программирования, а ее синтаксис запросов PL/pgSQL очень похож на MySQL от Oracle.

В этой статье мы рассмотрим как выполняется установка Postgresql Ubuntu 16.04, а также как выполнить первоначальную настройку и подготовку к работе этой системы.

Установка Postgresql в Ubuntu 16.04

Это очень популярный сервер баз данных, потому программа есть в официальных репозиториях. Но если вы хотите получить самую новую версию, то придется добавить в систему PPA. Для этого выполните команды:

sudo sh -c "echo "deb http://apt.postgresql.org/pub/repos/apt/ `lsb_release -cs`-pgdg main" >> /etc/apt/sources.list.d/pgdg.list"
$ wget -q https://www.postgresql.org/media/keys/ACCC4CF8.asc -O - | sudo apt-key add -

Затем обновите списки пакетов, чтобы получить самую новую доступную версию:

sudo apt-get update

Установка Postgresl Ubuntu из PPA или официальных репозиториев выглядит одинаково:

sudo apt-get install postgresql postgresql-contrib

Когда установка будет завершена, можно переходить к настройке.

Настройка Postgresql в Ubuntu

Вы знаете как установить Postgresql Ubuntu, но этого недостаточно для начала полноценной работы. Первым делом, откройте терминал и переключите его на пользователя postgres с помощью команды:

sudo su - postgres

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

Это очень похоже на учетные записи Unix, но программа не различает пользователей и групп, есть только роли. Сразу после установки Postgresql пытается связать свои роли с системными учетными записями, если для имени системной учетной записи существует роль, то пользователь может войти в консоль управления и выполнять позволенные ему действия. Таким образом, после переключения на пользователя postgres вы можете войти в консоль управления:

И посмотреть информацию о соединении:

Чтобы выйти наберите:

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

Создание роли Postgresql

Вы уже можете полноценно работать с базой данных с помощью учетной записи postgres, но давайте создадим дополнительную роль. Учетная запись postgres является администратором, поэтому имеет доступ к функциям управления. Для создания пользователя выполните:

createuser --interactive

Скрипт задаст лишь два вопроса, имя новой роли и нужно ли делать ее суперпользователем.

Создание базы данных

Точно также как имена ролей сопоставляются с системными пользователями, имя базы данных будет подбираться по имени пользователя. Например, если мы создали пользователя segiy, то по умолчанию система попытается получить доступ к базе данных segiy. Мы можем ее очень просто создать:

sudo su - sergiy

Заходим в консоль и смотрим информацию о подключении:

Все верно сработало. Мы подключились с помощью роли segiy к базе segiy. Если нужно указать другую базу данных, вы можете сделать это с помощью опции -d, например:

psql -d postgres

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

Создание таблиц

Теперь, когда вы знаете как подключится к базе данных Postgresql давайте рассмотрим как выполняются основные задачи. Сначала разберем создание таблиц для хранения некоторых данных. Для создания таблицы Postgresql используется такой синтаксис:

CREATE TABLE и мя таблицы (
имя_колонки1 тип_колонки ( длина ) ограничения ,
имя_колонки2 тип_колонки ( длина ),
имя_колонки3 тип_колонки ( длина )
);

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

CREATE TABLE playground (
equip_id serial PRIMARY KEY,
type varchar (50) NOT NULL,
color varchar (25) NOT NULL,
location varchar(25) check (location in ("north", "south", "west", "east", "northeast", "southeast", "southwest", "northwest")),
install_date date
);

Мы создали таблицу детской площадки для описания оборудования, которое на ней есть. Сначала идет идентификатор equip_id, который имеет тип serial, это значит что его значение будет автоматически увеличиваться, ключ primary key значит, что значения должны быть уникальны.

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

Вы можете вывести все таблицы, выполнив команду:

Здесь мы видим что кроме нашей таблицы, существует еще одна переменная - playground_equip_id_seq. В ней содержится последнее значение этого поля. Если нужно вывести только таблицы, выполните:

Вставка и удаление данных

У нас есть таблица, но пока что она пуста. Мы можем добавить в нее некоторые данные. Давайте добавим пункт, описывающий качели. Для этого используются такие команды:

INSERT INTO playground (type, color, location, install_date) VALUES ("slide", "blue", "south", "2016-04-28");

INSERT INTO playground (type, color, location, install_date) VALUES ("swing", "yellow", "northwest", "2015-08-16");

Заметьте, что имена столбцов не обязательно заключать в кавычки, а вот имена значений - обязательно. Теперь смотрим что получилось:

SELECT * FROM playground;

Удалять записи можно по любому критерию, например, удалим записи, поле type которых имеет значение slide:

DELETE FROM playground WHERE type = "slide";

И снова смотрим что получилось:

SELECT * FROM playground;

Установка phppgadmin

Не всегда удобно управлять базой данных из терминала. Иногда нужно получить доступ ко всему через веб-интерфейс. Для этого есть программа phppgadmin, но для ее работы нужен веб-сервер Apache. Для установки программы наберите:

sudo apt install phppgadmin

Когда установка будет завершена откройте файл /etc/apache2/conf-available/phppgadmin.conf и закоментируйте строку:

А вместо нее добавьте:

Это необходимо, чтобы открыть доступ к этому адресу не только с локального компьютера, но и их других устройств сети. Заметьте, что вы не сможете войти под учетной записью postgres, это сделано из соображений безопасности. Когда завершите, перезагрузите Apahce:

sudo service apache2 restart

Выводы

Теперь установка Postgresql Ubuntu 16.04 завершена и вы даже прошли краткий экскурс в синтаксис PgSQL, который очень похож на привычный нам MySQL, но имеет некоторые отличия. Если у вас остались вопросы, спрашивайте в комментариях!