Ms sql или postgresql для 1с: Исследование быстродействия СУБД MS SQL Server Developer 2016 и PostgreSQL 10.5 для 1С / Хабр

Производительность 1С:Підприємство с СУБД PostgreSQL или MS SQL. Сравнение.

Затраты на СУБД MS SQL и PostgreSQL:

В связи со стремительной девальвацией гривны, покупать СУБД Microsoft SQL стало очень дорого, а для некоторых компаний стоимость этих лицензий стала совсем «неподъемной». В данный момент чтобы развернуть сервер Microsoft SQL для 20 пользователей необходимо купить такие лицензии:

• 1 лицензия на операционную систему (WinSvrStd 2012R2 )
• 20 лицензий на подключение к серверу (WinSvrCAL 2012)
• 1 лицензия на сервер СУБД (SQLSvrStd 2014)
• 20 лицензий на подключение к СУБД (SQLCAL 2014)

Ориентировочная стоимость такого пакета 11 4957 грн, что для компании, в которой всего 20 человек достаточно дорого. Данных затрат можно избежать, если создать сервер СУБД на свободном ПО. Поставить операционную систему семейства Linux и бесплатную версию СУБД – PostgreSQL. На таком сервере без проблем можно развернуть сервер 1С:Підприємство, а также другие роли, которые потенциально могут быть совмещены c ролью баз данных, например WebServer или файловое хранилище.

Так как использовать свободное ПО очень привлекательно с финансовой точки зрения, было решено проверить, на сколько это хорошо с точки зрения производительности.

Тестирование производительности 1С:Підприємство

Для выполнения теста было взято оборудование и программное обеспечение, указанное в таблице 1. Физический сервер для обоих стендов использовался один и тот же, менялось только ПО. Настройки обоих СУБД использовались по-умолчанию и в статье мы их подробно не расписываем. Дистрибутив PostGreSQL с соответсвующими патчами были взят с сайта вендора, версия — последняя из доступных на данном сайте.

Таблица 1. Тестовые стенды

Для начала был выполнен «тест Гилева», который показал незначительное преимущество стенда номер 2, против стенда со свободным ПО.

Результаты смотрим ниже, разница в значениях получилась всего 3%.

Для информации: «тест Гилева» — популярный синтетический тест 1С:Підприємство, который выполняет ряд стандартных операций – чем быстрее тест выполняется, тем выше оценка. Оценка выполняется в условных единицах. Полученную оценку можно сравнить с прилагаемой к тесту шкале, которая покажет на сколько высока производительность текущей системы.

Рисунок 1. Результат теста Гилева. Стенд №2 СУБД MS SQL

Рисунок 2. Результат теста Гилева. Стенд №1 СУБД PostgreSQL

Далее решено было тестирование выполнить по методике APDEX. Суть метода заключается в измерении времени выполнения основных операций в 1С:Підприємство, замеры проводятся несколько раз на протяжении определенно периода времени. Далее полученный результат сравнивается с приемлемым временем выполнения той или иной операции.

Для этого взяли реальную рабочую базу одной из самых тяжелых конфигураций 1С:Підприємство, характеристики базы указаны в таблице №2.

Таблица 2. Характеристики тестовой базы

Замерялось время выполнения 7-ми стандартных операций с объектами в базе. Каждый тест выполнялся 10 раз и выводилось среднее значение. Замеры проводились с использованием толстого клиента через локальную сеть. Клиент устанавливался на рабочую станцию под управлением Windows 7. Тесты также пробовали запускать с клиента установленного на Ubuntu Linux, но он работал не стабильно и все тесты решено было выполнять только с клиента на Windows.

Таблица 3. Результаты APDEX

В среднем наша реальная база при использовании MSSQL работала на 45% быстрее, чем на стенде со свободным ПО. На некоторых тестах отрыв был очень значителен, а на таких как, например проведение нового документа составлял всего 11%.

Вывод:

• 1C:Підприємство на СУБД MSSQL работает примерно в 1,5 быстрее, чем на PostgreSQL. Соответственно, если есть возможность купить или арендовать лицензии MSSQL, лучше использовать его для более высокой производительности. Для небольших и ненагруженных баз можно попробовать использовать версию MSSQL Express. Тестов с ней мы не проводили, поэтому она может показать себя по производительности как лучше так и хуже PostgreSQL. Данная редакция ограничена использованием 1 процессора и 1 Гб ОЗУ, также не работает с базами более 10Гб. Если база дорастет до такого размера, то она остановиться и перестанет работать полностью, но как показывает практика, если в базе работает 15-20 пользователей, то комфортно можно работать при размере базы 4-5ГБ, далее база начинает сильно тормозить.

• Оценка «тестом Гилева» показывает крайне незначительное превосходство MSSQL, что позволяет сделать предположение о том, что другие базы 1С:Підприємство могут работать на PostgreSQL так же хорошо, как и на MSSQL, а возможно и быстрее. Перед выбором СУБД рекомендуем провести тесты на своей конкретной базе и сравнить полученные результаты.

• Использование СУБД PostgreSQL для развертывания на нем 1С:Підприємство является приемлемым решением в условиях ограниченного бюджета. База будет работать не так быстро как на MSSQL, но зато не нужно платить за лицензии.

Art:
,ID:

• Контент-маркетолог TQM systems (1C / BAS) Nataliya Raevskaya
• 6/2/2020 2:30:22 PM
• articles

Наш опыт внедрения 1С на PostgreSQL

02 ноября 2020

Когда перед нами стал вопрос снижения стоимости серверных 1С, мы начали искать пути экономии без потери качества. И одним из самых очевидных решений стало использование свободно распространяемого ПО, которое по характеристикам не уступает платному. Так наш выбор пал на SQL сервер Postgre, официально интегрированный с продуктами 1С. А приятным бонусом для нас стало импортозамещение, которое мы при прочих равных всегда поддерживаем.

Выбор решения и архитектура

Чтобы упростить переход с MS SQL на базе ОС Windows 2016 Server, мы решили использовать SQL сервер Postgre, представленный на сайте 1С, релиз 11.5-19.1C, и при этом остаться на хорошо знакомой нам Windows 2016. Это решение позволяет более быстро осуществить переход, т.к. администрировать Windows системы нам привычнее, есть масса наработок для резервного копирования и мониторинга производительности. А еще такой подход позволил объективно сравнить показатели производительности 1С на PostgreSQL по сравнению с MS SQL, так как в обоих случаях использовались идентичные по производительности сервера с одинаковыми настройками ОС.

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

Установка и настройка

Скачать дистрибутив можно с сайта релизов 1С. Установка Postgre происходит типовым способом, сервер устанавливается как сервис. Обратите внимание на путь к расположению инстанса, конечная папка назначения и будет именем инстанса (по умолчанию data), не рекомендуем оставлять путь по умолчанию, для каталога данных лучше использовать отдельный диск, отличный от системного.

Далее указываете порт подключения (по умолчанию 5432), задаете пароль для суперпользователя инстанса с логином postgres. При установке требуется, чтобы была запущена служба “Вторичный вход в систему”, а также выданы права к каталогу данных для NETWORK SERVICE .

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

PostgreSQL, как и MS SQL, позволяет запуск нескольких инстансов (экземпляров) на одном сервере. Этот функционал полезен в различных ситуациях, одна из популярнейших утилит резервного копирования БД Postgre — pg_probackup, позволяющая выполнять полное и журнальное бекапирование, обеспечивать валидацию данных, восстановление на произвольный момент времени. Она выполняет бекап полностью всего инстанса, а не отдельных баз, поэтому использование нескольких инстансов для различных баз или групп баз позволит настроить индивидуальные планы резервного копирования, исключит простой баз других инстансов в случае необходимости восстановления единичного инстанса. Также обычный перезапуск службы, например, для изменения конфигурации затронет только единичный инстанс.

Настройка производится стандартными утилитами initdb.exe и pg_ctl.exe, новая инсталляция Postgre SQL не требуется, пример использования:

					"c:\Program Files\PostgreSQL\11.5-19.1C\bin\initdb.exe" --encoding=UTF8 -U "postgres" -D "d:\DataFolder\InstansName"
				

После этого необходимо зарегистрировать службу:

					"c:\Program Files\PostgreSQL\11.5-19.1C\bin\pg_ctl.exe" register -N "OriginalName-5433" -U "NT AUTHORITY\NetworkService" -D "d:\DataFolder\InstansName"
				

Команды выполняются из командного файла или строки с привилегиями администратора.

Результат:

Изменяем в postgresql.conf параметр port = 5432 (стандартный) на другой, например, 5433. При необходимости меняем параметры авторизации службы «OriginalName-5433» и стартуем. На сервере предприятия при создании базы указываем имя хоста сервера и порт в следующем формате — “hostname port 5433”

После этого можем зайти в графический клиент управления Pgadmin 4, настраиваем подключение к серверу по порту 5433 и проверяем успешное создание базы.

Резервное копирование и обслуживание

Для резервного копирования мы выбрали утилиту pg_probackup, так как она обеспечивает нужный нам сценарий резервного копирования. Резервное копирование и обслуживание баз, в отличие от MS SQL, не имеет графического интерфейса, в котором можно настроить Maintenance plan (План обслуживания). Все команды выполняются из командной строки планировщиком заданий Windows. Мы настроили и протестировали архивирование журналов предзаписи (WAL) и создание полных копий 1 раз в сутки с планом хранения в течение 2х недель.

Два бекапа — всегда лучше, чем один, поэтому полные бекапы баз и журналы WAL синхронизируются с облачным объектным хранилищем. С этой задачей нам помогла успешно справится свободно распространяемая утилита Rclone, которая позволяет копировать, переносить, синхронизировать файлы между различными типами хранилищ, обеспечивая высокую скорость за счет многопоточности и гарантируя доставку валидных данных за счет алгоритма хеширования MD5.

Обслуживание инстанса или отдельных баз, как правило, заключается в ежедневном сборе мусора и анализе данных с помощью VACUUM, запускать который желательно перед началом рабочего дня. Для запуска из командного файла по шедулеру требуется учесть настройку авторизации, без которой командный файл не отработает, так как будет ждать ввода пароля. В каталоге %APPDATA%\postgresql\ необходимо создать файл pgpass.conf, формат записей, которые необходимо создать для всех баз : : : : , например, localhost:5432:Dbname:postgres:password. В командной строке обслуживания указываем опцию — w, и авторизация будет использовать данные из конфига.

Пример:

					"c:\Program Files\PostgreSQL\11.5-19.1C\bin\psql.exe" -d Dbname -U postgres -w -c "VACUUM FREEZE VERBOSE ANALYZE;"
				

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

Ну вот мы и готовы приступить к тестированию. Для этого мы выбрали достаточно высоконагруженную базу 1С из прод среды размером около 40 ГБ, в которой ежедневно более 500 подключений одновременно. Загрузка базы в формате DT подготовила нам первый сюрприз — она не залилась полностью, мы убедились в том, что те ошибки, которые прощает разработчикам MS SQL, в PostgreSQL вылазят наружу и требуют более тщательного подхода к написанию кода и организации хранения данных. Мы призвали на помощь наших разработчиков 1С. Они проанализировали ошибки и нашли причину — виной всему оказалось хранение в базе крупных и даже очень крупных объектов, таких как архивы, медиа-файлы и документы. Пришлось выполнить доработки в прод базе — ограничить максимальный объем вложений. Теперь вместо крупных вложений хранятся ссылки на них (ссылки на портал компании или другие облачные хранилища, такие как Google Disk). Автотесты, которые предусмотрены в нашей базе, также не прошли сразу по причине различия правил сортировки, и снова наши разработчики 1С оказались на высоте и удачно устранили все сложности.

После доработок базы приступили к тестированию производительности на PostgreSQL и MS SQL. APDEX показал примерно одинаковые результаты на MS SQL 0.862/0.877 на Postgre 0.898/0.895. Также мы протестировали время бекапирования и восстановления, MS SQL примерно в 1.5 -2 раза превосходит по скорости таких операций, но при объеме данной базы вилка по времени не значительна. Поэтому мы сделали вывод, что использование PostgreSQL вполне оправдано.

Переход

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

На следующее утро никто не заметил наших усилий и перемен, база работала также стабильно. На сегодняшний день она уже больше месяца функционирует на PostgreSQL. Так мы убедились, что PostgreSQL под управлением Windows 2016 Server хорошо справился с обеспечением необходимой производительности. Мы начинали проект с базовым набором знаний в PostgreSQL, в результате мы получили реальные пруфы и прокачали скиллы. Следующим этапом снижения стоимости содержания серверных баз 1С мы планируем использование Linux серверов. Таким образом мы исключим необходимость оплаты лицензий Windows.

Перенос файловой базы 1С в SQL: пошаговая инструкция

Программные продукты фирмы 1С имеют два основных формата хранения базы данных: файловая база данных и база данных, размещенная на SQL Server средствами СУБД

В список поддерживаемых СУБД входят:

• Microsoft SQL Server
• PostgreSQL
• Oracle Database
• IBM Db2.

Файловые базы данных, как правило, используют небольшие компании с 1-5 пользователями, где нет большого объема документооборота, а также не произойдет быстрого роста объема базы данных.

Когда нужно переходить с файловой базы 1С на СУБД MS SQL?

Если конфигурация долго открывается и также долго открываются и проводятся документы, если периодически выскакивают ошибки «Нарушена целостность базы данных» или «Файл базы данных поврежден», файл ИБД *.1СD имеет объем более 5ГБ, планируется рост пользователей или в результате внедрения еще одной конфигурации 1С планируется достаточно быстрый рост объема данных, пора задуматься о вопросе, как перенести файловую базу 1С на SQL поскорее и узнать, что такое сервер 1С.

Рис.1 Формат хранения информационных баз 1С

Преимущества SQL

Доверьте перенос базы на SQL сервер экспертам 1С

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

При высокой отказоустойчивости и поддержке бесконечно большой базы данных SQL-сервер дает возможность одновременной работы большому числу пользователей. Конечно, наиболее мощные СУБД – MS SQL Server/Oracle стоят недешево, но бесплатный вариант PostgreSQL также широко используется в среде 1С. Да, SQL требует настройки сервера 1С и администрирования, но подобные услуги оказывает широкий круг компаний-франчайзи 1С, и конечно же – наша.

Работа с файловой базой плохо защищена, потому что доступ к копированию файла БД открыт любому пользователю, плохо масштабируется и начинает «тормозить», когда пользователей становится больше пяти из-за высокого уровня изоляции транзакций, а также имеет ограничения по размеру в 5-10 Гб. При этом отдельные функции конфигурации при таком варианте просто не работают (к примеру, регламентные задания).

Да, быстрая настройка, отсутствие дополнительного ПО и низкая цена – весьма привлекательные «черты» файловых БД, но выбор в их пользу может иметь место только при построении самой простой информационной системы.

Рис.2 Пример частой ошибки при работе с файловой базой объемом более 5Гб

Этапы перехода на внешнюю СУБД

Для переноса файловой базы 1С 8.3 на сервер SQL проделаем следующие шаги:

Шаг №1 Выгрузка ИБ

Откроем конфигуратор файловой версии базы 1С.

Рис.3 Список конфигураций 1С. Запуск конфигуратора

В конфигураторе выбираем пункт меню «Администрирование» и «Выгрузить информационную базу».

Рис. 4 Формирование файла выгрузки ИБД

Итогом процесса выгрузки будет файл *.dt.

Рис. 5 Файл Выгрузки ИБД

Шаг №2 Создание кластера

Для данного пункта запустим консоль управление сервером 1С.

Рис. 6 Ярлык консоли управления сервера 1С

Важно: Для работы сервера 1С обязательно требуется установка лицензии на сервер 1С.

Лицензия бывает 32х-разрядная и 64х-разрядная. Разрядность определяет количество ОЗУ доступное серверу 1С: у 32х до 4ГБ, а 64х более 4ГБ.

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

В открывшемся приложении выберите «Кластер-Создать кластер», а если кластер уже создан, выберите существующий.

Рис. 7 Администрирование кластера 1С

Шаг №3 Создание базы данных в кластере

Следующим шагом в процессе миграции базы 1С будет создание новой конфигурации в кластере. Существует два возможных варианта создания базы 1С на сервере 1С:

• Через консоль администрирования кластера 1С;
• Через окно запуска 1С:Предприятие.

Создание информационной базы в кластере через консоль администрирования кластера 1С

Чтобы создать базу 1С в СУБД SQL, выбираем «Создание новой информационной базы» и заполнить обязательные поля:

• Имя – название вашей базы 1С;
• Сервер баз данных – указываем имя кластера 1С;
• База данных – название базы данных в вашей СУБД SQL;
• Пользователь сервера БД – логин от администратора СУБД SQL;
• Пароль сервера БД – пароль от администратора СУБД SQL.

Рис. 8 Создание новой ИБД SQL в кластере 1С

Далее добавляем эту ИБД в список 1С для последующего запуска конфигуратора 1С и загрузки ранее подготовленного файла выгрузки базы. После того как база в кластере создана, добавляем ее в список баз 1С. Для этого запускаем 1С:Предприятие и «Добавить…» базу 1С.

Рис.9 Запуск 1С:Предприятие

Далее выбираем «Добавление в список существующей информационной базы» и переходим «Далее».

Рис. 10 Меню выбора действий

После появления формы добавления базы 1С, заполняем последние строки в списке и переключаем режим работы на «На сервере 1С:Предприятие».

Рис. 11 Окно заполнения данных для подключения базы 1С

Запуск 1С:Предприятие и добавление конфигурации

Этот способ быстрее предыдущего и бывает полезен, когда, например, вы не установили у себя компоненту консоли управления при установке платформы. Чтобы им воспользоваться, запускаем 1С:Предприятие и в открывшемся окне приложения жмем кнопку «Добавить».

Рис. 12 Окно 1С:Предприятие

Далее выбираем «Создание информационной базы».

Рис.13 Создание информационной базы

После перехода в следующий пункт меню выбираем « Создание информационной базы без конфигурации для разработки новой конфигурации» или «Загрузки выгруженной ранее информационной базы».

Рис.14 Создание чистой конфигурации

Следующим шагом будет выбор пункта «На сервере 1С:Предприятие».

Рис.15 Создание на сервере 1С

Мы попадем в искомое нами окно заполнения полей для создания базы на сервере 1С.

Рис. 16 Создание ИБД на сервере SQL

Шаг №4 Завершение переноса

Перенос данных 1С

Переходите на новую программу 1С? Проведем бесплатный анализ и перенесем только необходимые данные

Рис. 17 Запуск конфигуратора 1С

После запуска конфигуратора переходим в раздел «Администрирование» и выбираем пункт «Загрузить информационную базу».

Рис. 18 Загрузка информационной базы из файла

Далее выбираем ранее сохраненный файл выгрузки и начинаем непосредственно процесс загрузки базы на СУБД SQL.

Рис. 19 Завершение загрузки ИБД 1С

Готово! Ваша конфигурация успешно переведена из файлового режима на SQL-сервер.

Если повторная работа в конфигураторе не требуется, выбираем вариант «Нет» и запускаем базу в режиме «Предприятия» для проверки ее работоспособности.

Мы рассмотрели процесс миграции файловой базы на сервер 1С. Если в будущем вам потребуется перенос базы 1С SQL на другой сервер или у вас остались вопросы по этому переводу, обратитесь к нашим специалистам за консультацией, мы с радостью вам поможем.

Как работать с базой данных SQL из 1С?

Содержание:

1.       Создание подключения

2.       Выборка данных из базы на языке SQL

3.       Создание, добавление, изменение и удаление записей SQL PostgreSQL

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

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

Для начала необходимо будет скачать драйвер необходимой разрядности с официального сайта. После его установки переходим в конфигуратор 1С. 

1. Создание подключения.

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

Пример кода:

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

После окончания работы с соединением обязательно закрывайте его:

Сами запросы формируются на языке SQL. Он напоминает язык 1С, но имеет англоязычный синтаксис, поэтому советую изучить дополнительную информацию по составлению прямых запросов SQL. 

2. Выборка данных из базы на языке SQL.

Для выборки мы создаем объект «Команда», в которую и будет передан составленный текст прямого запроса. После чего мы выполняем команду «Execute()», получив таким образом выборку данных. Выбираем первую запись «MoveFirst()» (аналог команды 1С РезультатЗапроса.Выбрать()), и в цикле получаем следующие записи «MoveNext()» (по аналогии с командой языка 1С Выборка.Следующий()).

Пример кода: 

3. Создание, добавление, изменение и удаление записей PostgreSQL.

Для добавления/создания записей используется соединение, и команда «Execute», в которую передается текст запроса.

Пример добавления:

Для изменения данных используется такая же конструкция, как и при создании/добавлении, за исключением самого текста запроса в базы данных на языке SQL. Здесь используется оператор UPDATE, где нужно указать, что мы меняем: SET – на какие значения, и WHERE – условие замены/обновления (обычно здесь задается конкретный уникальный идентификатор, если требуется изменить только одну запись).

Пример:

Для удаления используется оператор DELETE. Пример построения запроса очень схож с изменением записей:

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

Специалист компании «Кодерлайн»

Вадим Хоменко

Сравнение MySQL и PostgreSQL. Выбрать субд между mysql, postgresql, mariadb и mssql? Сравнение производительности ms sql server и postgresql

Давайте признаемся честно, хоть 1С Предприятие и совместимо со многими СУБД, но по факту 99 процентов работают либо в MS SQL или в бесплатной PostgreSQL.

Другими словами эти две «субдешки» завоевали рынок клиент-серверной 1С.

И можно смело предполагать, что если компания не работает в MS SQL то, скорее всего, просто используют PostgreSQL.

Соответственно сравнивать «Постгрес» есть смысл разве что только с MS SQL.

Сегодня много пишут, как об MS SQL так и о PostgreSQL, но обычно объективно не сравнивают их.

В этой статье мы же разберем основные технические моменты бесплатной PostgreSQL, сравнивая ее c MS SQL.

Что позволит Вам в будущем сделать оптимальный выбор и быть готовым к разным «неожиданностям» или что будет более правильно «особенностям» работы в этой бесплатной СУБД.

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

Сразу отвечу на вопрос, который волнует многих новичков!

ДА! MS SQL работает быстрее PostgreSQL, это факт! И на это есть ряд причин!

Возможно, я кого-то прямо сразу разочаровал, и возможно, Вы не согласны с таким утверждением, извиняюсь, но сама физика работы этой бесплатной СУБД не позволяет ему опередить MS SQL, особенно если мы говорим о такой связке как «Монстр 1С» и PostgreSQL
.

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

Тем не менее, производительности PostgreSQL вполне достаточно, для того, чтоб пользователи могли комфортно работать в 1С.

Будь это десяток пользователей или даже несколько сотен, одновременно работающих в 1С Предприятии.

Почему «Монстр 1С» ?

Собственно так 1С видит PostgreSQL без установленных специальных «патчей» и расширений.

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

Почему так происходит, и зачем «патчи»?

Дело в том что 1С Предприятие создает огромное количество временных таблиц в процессе своей работы, речь может идти о тысячах таблиц в секунду,
а если взять, например регистр «Срез последних» — «ОстаткиИОбороты», там вполне могут и по миллиону строк
быть.

Дело в том что по умолчанию (без «патчей») PostgreSQL не считает статистику по этим большим временным таблицам, другими словами оптимизатор запросов который руководствуется данными из статистики (а она как помним пуста, нечего считать) грубо говоря, делает выборку методом SELECT *
что конечно будет работать очень и очень медленно!

Отсюда грандиозные тормоза в 1С!

Конечно это не все проблемы, которые нужно решить, чтоб PostgreSQL работал в паре с 1С нормально. Нужны будут и другие «патчи» и специальные расширения и после 15-20 пользователей, еще и доп. настройки в «конфиге»

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

Второе что мне сильно не нравится в PostgreSQL это отсутствие многопоточности в рамках одного запроса
в сравнении с MS SQL.

(Начиная с версии 9.6 сделали первую попытку распараллеливания запросов, но пока работает плохо, иногда эффект обратный). но за попытку 5!)

Что конечно влияет на производительность, чтоб Вы понимали простым языком —

PostgreSQL способен уложить Ваш 48-ми ядерный сервер, одним большим запросом!

Все просто, распараллеливания потоков в рамках одного запроса нет и один большой запрос «грузит» только одно ядро.

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

И чуть не забыл, сравниваем мы PostgreSQL c MS SQL Standard не Express!

Express хоть и можно использовать в коммерческих целях, но целый ряд ограничений

таких как 10 Гб на базу, использование одного процесора, 1 Гб оперативной памяти,

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

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

Так что сравниваем PostgreSQL с популярной версией Standard.

СКРИПТЫ!!!

PostgreSQL это прежде всего скрипты в сравнении с MS SQL, большинство операций приходится делать руками, да можно установить конечно и некоторые базовые вещи выполнять через интерфейс, но подчеркну, что базовые
, а шаг влево шаг вправо и нужно писать скрипт, или БАШ на Линуксе или cmd, powershell наWindows.

Просмотр и анализ трассировок с помощью приложения SQL Server Profiler.

Всем известный SQL Server Profiler в PostgreSQL отсутствует, причем под словом «отсутствует» я имею, введу напрочь, увы, нет ничего подобного в PostgreSQL.

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

Можно настроить лог и потом это все перебирать — но долго!

Вот пример:

Программист 1С пытается отладить какой-нибудь большой запрос, он долго выполняется, например 30 минут, так вот в PostgreSQL, чтоб данные попали в лог, этот запрос должен выполнится! Представляете, как долго можно отлаживать такой запрос?

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

По разновидности создания «бэкапов» Постгресу нет равных!

Здесь Вам и инкрементный «бекап» и полное резервное копирование и непрерывное WAL архивирование.

Как собственно есть и частичное резервное копирование и частичное восстановление данных.

Можно настроить непрерывное архивирование и восстановление на момент времени (Point-in-Time Recovery (PITR))
.

Также репликация
, доступна изначально в PostgreSQl без каких либо «патчей» утилит и дополнений!

• Каскадная репликация
• Потоковая репликация
• Синхронная репликация
• Непрерывное архивирование на резервном сервере

Все это есть, уже изначально в PostgreSQl и конечно нет в «экспрессе» и недоступно на версии MS SQL Standard.

Чтоб получить все выше перечисленное в MS SQL, нужно покупать очень дорогой MS SQL Enterprise, сейчас что-то около 15 000$ долларов.

Чего нет в сравнении с MS SQL ?

НЕТ диференциального «бэкапа»

Да в PostgreSQl нет дифференциального «бэкапа», но есть различные аналоги инкрементного создания «бэкапов».

Например, инкрементный «бэкап» на уровне блоков.

ЕСТЬ разделение TABLESPACE-ов, что уже по умолчанию поддерживает 1С!

Которого к слову нет в MS SQL!

Например, Вы можете настроить на каком диске у вас будут «индексы» и на каком диске будет находиться «таблица», очень удобно при планировании IТ инфраструктуры, когда речь идет о больших базах данных 1С.
ONLINE_ANALYZE
, чтоб пересчитать статистику. Тоже самое касается файла *dt.

Используя PostgreSQl очень редко нужен REINDEX!

Фактически стоит использовать только когда, есть подозрения, что целостность базы данных повреждена.

Можно делать «бэкапы» с исключением таблиц!

Например, у вас в компании работают несколько программистов 1С, они гарантированно будут делать себе резервные копии создавать «бэкапы» для дальнейшей разработки.

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

Так мы лишний раз не нагружаем сетевые устройства, не забиваем канал, тратим намного меньше времени на создание такого «бэкапа»

В итоге все в выигрыше! И пользователи, и программисты и админы спят спокойно.

В этой статье мы разобрали лишь базовые отличия PostgreSQl от MS SQL, (есть и другие) но определится с выбором в пользу той или иной СУБД, статья должна помочь!

Успехов Коллега!

P.S. Сейчас работаю над новым курсом «1С и PostgreSQL» (Уже на стадии записи, ждите, скоро!)

С уважением, Богдан.

В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.

Тема моего доклада «Асинхронная репликация без цензуры, или почему PostgreSQL завоюет мир», и репликация одна из самых больных тем для нагруженных проектов использующих MySQL. Проблем много — корректность работы, стабильность работы, производительность — и на первый взгляд они выглядят несвязанными. Если же посмотреть в историческом контексте, то мы получаем интересный вывод: MySQL репликация имеет столько проблем потому, что она не была продумана, а точкой невозврата была поддержка storage engine (подключаемых движков) без ответов на вопросы «как быть с журналом?» и «как различным storage engine участвовать в репликации». В 2004 году в PostgreSQL рассылке пользователь пытался «найти» storage engine в исходном коде PostgreSQL и сильно удивился, что их нет. В процессе дискуссии кто-то предложил добавить эту возможность PostgreSQL, и один из разработчиков ответил «Ребята, если мы так сделаем, у нас будут проблемы с репликацией и с транзакциями между движками».

The problem is that many storage management systems… often do their own WAL and PITR. Some do their own buffer management, locking and replication/load management too. So, as you say, its hard say where an interface should be
abstracted.

ссылка на это письмо в postgresql mailing list

Прошло более 10 лет, и что мы видим? В MySQL есть раздражающие проблемы с транзакциями между таблицами разных storage engine и у MySQL проблемы с репликацией. За эти десять лет у PostgreSQL появились подключаемые типы данных и индексы, а также есть репликация — т. е. преимущество MySQL было нивелировано, в то время как архитектурные проблемы MySQL остались и мешают жить. В MySQL 5.7 попытались решить проблему производительности репликации, распараллелив её. Поскольку проект на работе очень чувствителен к производительности репликации в силу своего масштаба, я попытался протестировать, стало ли лучше. Я нашёл, что параллельная репликация в 5.7 работает медленней однопоточной в 5. 5, и лишь в отдельных случаях — примерно также. Если вы сейчас используете MySQL 5.5 и хотите перейти на более свежую версию, то учтите, что для высоконагруженных проектов миграция невозможна, поскольку репликация просто перестанет успевать выполняться.

После доклада на highload, в Oracle приняли к сведению разработанный мной тест и сообщили, что попытаются исправить проблему; недавно мне даже написали, что смогли увидеть параллелизм на своих тестах, и выслали настройки. Если не ошибаюсь, при 16 потоках появилось незначительное ускорение по сравнению с однопоточной версией. К сожалению, до сих пор не повторил свои тесты на предоставленных настройках — в частности потому, что с такими результатами наши проблемы всё равно остаются актуальными.

Точные причины такой регрессии производительности неизвестны. Было несколько предположений — например, Кристиан Нельсен, один из разработчиков MariaDB, у себя в блоге писал о том, что могут быть проблемы с перфоманс-схемой, с синхронизацией тредов. Из-за этого наблюдается регрессия в 40%, которая видна на обычных тестах. Oracle-разработчики это опровергают, и меня даже убедили, что её нет, видимо, я вижу какую-то другую проблему (и сколько же их всего?).

В MySQL репликации проблемы со storage engine усугубляются выбранным уровнем репликации — они логические, в то время как в PostgreSQL — физические. В принципе, у логической репликации есть свои преимущества, она позволяет сделать больше всяких интересных штук, об этом в докладе я тоже упомяну. Но PostgreSQL даже в рамках своей физической репликации уже сводит все эти преимущества на нет. Иными словами, почти все, что есть в MySQL, уже можно сделать и в PostgreSQL (либо будет можно в ближайшем будущем).

На реализацию низкоуровневой физической репликации в MySQL можно не надеяться. Проблема в том, что там вместо одного журнала (как в PostgreSQL) их получается два или четыре — смотря как посчитать. PostgreSQL просто коммитит запросы, они попадают в журнал, и этот журнал используется в репликации. PostgreSQL-репликация суперстабильна, потому что она использует тот же журнал, что и при операциях восстановления после сбоев. Этот механизм давно написан, хорошо оттестирован и оптимизирован.

В MySQL ситуация другая. У нас есть отдельный журнал InnoDB и журнал репликации, и нужно коммитить и туда, и туда. А это two-phase commit между журналами, который по определению работает медленно. То есть мы не можем просто взять и сказать, что мы повторяем транзакцию из InnoDB-журнала — приходится разбираться, что за запрос, запускать его заново. Если даже это логическая репликация, на уровне строчек, то эти строчки нужно искать в индексе. И мало того, что приходится сделать большое количество работы, чтобы выполнить запрос — он при этом снова будет писаться в свой InnoDB-журнал уже на реплике, что для производительности явно нехорошо.

В PostgreSQL в этом смысле архитектура на порядок продуманней и лучше реализована. Недавно в нём анонсировали возможность под названием Logical Decoding — которая позволяет сделать всякие интересные штуки, которые очень тяжело сделать в рамках физического журнала. В PostgreSQL это надстройка сверху, logical decoding позволяет работать с физическим журналом так, будто он логический. Именно эта функциональность скоро уберёт все преимущества MySQL репликации, кроме, возможно, размера журнала — statement-based репликация MySQL будет выигрывать — но у statement-based репликации MySQL есть совершенно дикие проблемы в самых неожиданных местах, и не стоит считать её хорошим решением (про это всё я тоже буду говорить в докладе).

Кроме того, для PostgreSQL есть триггерная репликация — это Tungsten, который позволяет делать то же самое. Триггерная репликация работает следующим образом: ставятся триггеры, они заполняют таблицы или пишут файлы, результат отправляется на реплику и там применяется. Именно через Tungsten, насколько я знаю, делают миграцию из MySQL в PostgreSQL и наоборот. В MySQL же логическая репликация работает прямо на уровне движка, и другой ее сделать сейчас уже нельзя.

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

Например, так «выстрелила» компания Percona: они вели MySQL Performance Blog, и в этом блоге было множество статей, в которых рассматривались отдельные моменты эксплуатации MySQL. Это принесло бешеную популярность, привело клиентов в консалтинг, позволило привлечь ресурсы для запуска разработки собственного форка Percona-Server. Существование и востребованность MySQL Performance Blog доказывают, что официальной документации просто недостаточно.

У PostgreSQL фактически все ответы есть в документации. С другой стороны, я слышал много критики при сравнении документации PostgreSQL со «взрослой» Oracle. Но это, на самом деле, очень важный показатель. MySQL с взрослым Oracle никто не пытается сравнивать вообще — это было бы смешно и нелепо — а PostgreSQL уже начинают сравнивать вполне серьезно, PostgreSQL-коммьюнити эту критику слышит и работает над улучшением продукта. Это говорит о том, что он по своим возможностям и производительности начинает конкурировать со столь мощной системой как Oracle, на которой работают мобильные операторы и банки, в то время как MySQL остаётся сидеть в нише веб-сайтов. И проекты-гиганты, доросшие до большого количества данных и пользователей, хлебают горе с MySQL большой ложкой, постоянно упираясь в его ограничения и архитектурные проблемы, которые невозможно исправить, затратив разумное количество сил и времени.

Примером таких крупных проектов на PostgreSQL является 1C: PostgreSQL идёт как опция вместо Microsoft SQL, а Microsoft SQL действительно фантастическая СУБД, одна из самых мощных. PostgreSQL может заместить MS SQL, а попытка заместить его MySQL… давайте опустим завесу жалости над этой сценой, как писал Марк Твен.

PostgreSQL соответствует стандартам SQL-92, SQL-98, SQL-2003 (реализованы все его разумные части) и уже работает над SQL-2011. Это очень круто. Для сравнения, MySQL не поддерживает даже SQL-92. Кто-то скажет, что в MySQL такая цель просто не ставилась разработчиками. Но нужно понимать, что разница между версиями стандарта заключается не в мелких изменениях — это новые функциональные возможности. То есть в тот момент, когда MySQL говорил: «Мы не будем следовать стандарту», они не просто вносили какие-то мелкие различия, из-за которых MySQL тяжело поддержать, они еще закрывали дорогу к реализации многих нужных и важных возможностей. Там до сих пор нет нормально оптимизатора. То, что там называется оптимизацией, в PostgreSQL называется «парсер» плюс нормализации. В MySQL это лишь план выполнения запросов, без разделения. И MySQL к поддержке стандартов придут еще очень нескоро, поскольку на них давит груз обратной совместимости. Да, они хотят, но лет через пять, может, что-нибудь у них появится. В PostgreSQL есть уже все и сейчас.
С точки зрения простоты
администрирования сравнение не в пользу PostgreSQL. MySQL администрировать гораздо проще. И не потому, что в этом смысле он лучше продуман, а просто гораздо меньше умеет делать. Соответственно, и настраивать его проще.

У MySQL есть проблема со сложными запросами. Например, MySQL не умеет спускать группировку в отдельные части union all. Разница между двумя запросами — на нашем примере группировка по отдельным таблицам и union all сверху работала в 15 раз быстрее, чем union all и потом группировка, хотя оптимизатор должен оба запроса приводить в одинаковый, эффективный план выполнения запроса. Нам придется делать генерацию таких запросов руками — т. е. тратить время разработчиков на то, что должна делать база.

«Простота» MySQL вытекает, как можно увидеть выше, из крайне бедных возможностей — MySQL работает просто хуже и требует больше времени и усилий во время разработки. В противоположность этому, у PostrgreSQL есть гистограммы и нормальный оптимизатор, и он выполнит такие запросы эффективно. Но если есть гистограммы, значит, есть их настройки — как минимум bucket size. Про настройки нужно знать и в отдельных случаях их менять — следовательно, нужно понимать, что это за настройка, за что она отвечает, уметь распознавать такие ситуации, увидеть выбрать оптимальные параметры.

Изредка случается, что умелость PostrgreSQL может помешать, а не помочь. В 95% случаев все хорошо работает — лучше, чем MySQL, — а какой-то один дурацкий запрос работает гораздо медленнее. Или всё работает хорошо, а потом внезапно (с точки зрения пользователя) по мере роста проекта некоторые запросы стали работать плохо (стало больше данных, стал выбираться другой план выполнения запроса). Скорее всего, для исправления достаточно запустить analyze или немножко покрутить настройки. Но нужно знать, что делать и как это делать. Как минимум, нужно прочитать документацию PostgreSQL на эту тему, а читать документацию почему-то не любят. Может потому, что в MySQL от неё мало помощи? 🙂

Подчеркну, что PostgreSQL в этом смысле не хуже, просто он позволяет отложить проблемы, а MySQL сразу их вываливает и приходится тратить время и деньги на их решение. В этом смысле MySQL работает всегда стабильно плохо, и еще на этапе разработки люди эти особенности учитывают: делают все максимально простым способом. Это относится только к производительности, точнее, к способам её достижения и к её прогнозируемости. В плане корректности и удобства PostgreSQL на голову выше MySQL.

Чтобы определиться с выбором между MySQL и PostgreSQL для конкретного проекта, прежде всего нужно ответить на другие вопросы.

Во-первых, какой опыт есть у команды? Если вся команда имеет 10 лет опыта работы с MySQL и нужно запуститься как можно быстрее, то не факт, что стоит менять знакомый инструмент на незнакомый. Но если сроки не критичны, то стоит попробовать PostgreSQL.

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

Подводя итог: если у вас простенький интернет-магазин, нет денег на админа, нет серьезных амбиций перерасти в большой проект и есть опыт работы с MySQL — то берите MySQL. Если предполагаете, что проект будет популярным, если он большой, его будет тяжело переписать, если в нём сложная логика и связи между таблицами — возьмите PostgreSQL. Даже из коробки он у вас будет работать, поможет в разработке, сэкономит время, и вам проще будет расти.

Трудно найти организацию, в которой не используются бухгалтерские системы от 1С – даже в мегахолдингах, где давно внедрён SAP или OEBS, они почти всегда используются на том или ином участке. Отрадно, что российское прикладное ПО стало фактическим стандартом для наших компаний, но есть одна тонкость: столь же фактическим стандартом для самого 1C:Предприятия стало использование Microsoft SQL Server в качестве СУБД.

В среде практикующих 1С-ников наиболее распространено мнение, что без коммерческих СУБД от американских производителей ничего хорошего не выйдет, дескать, несколько сотен пользователей неизбежно требуют установки базы на MS SQL, Oracle Database или IBM DB2 в этом случае. Про работу под управлением свободой СУБД PostgreSQL известные нам мнения практиков расходились, но в диапазоне от «совсем не работает» до «пригодно для нескольких десятков пользователей, не более».

Был и ряд правдоподобных объяснений столь скромным оценкам: и активное использование платформами 1С механизмов временных таблиц (которые в Постгресе реализованы слишком «честно» – с транзакционным DDL, всеми возможностями по восстановлению), и особенности работы с текстовыми данными (тогда как в области многоязычных текстов ванильный Постгрес, опять же, слишком консервативен, используя не самые высокопроизводительные системные библиотеки), и ряд других менее значимых аспектов.

Но мы тайно верили в Постгрес, тем более, что в сборке заявлялось о решении всех тех проблем, которыми скептики оправдывали выбор коммерческих СУБД. К тому же нам было важно получить показатели назначения для аппаратно-программного комплекса – построенной на основе санкционно безопасного оборудования и софта машины баз данных для СУБД, разработанной IBS совместно с Postgres Professional.

Из тиражируемых приложений самым очевидным применением для такой машины должны стать, конечно же, системы 1C. И результаты проведённых бенчмарков полностью перевели нас из разряда «тайно верующих» (и даже сомневающихся) в категорию «убеждённых»: теперь мы можем смело утверждать, что 1C:Предприятие версии 8.3 на сборке Postgres Pro EE 1.5 для Скалы-СР / Postgres Pro работает лучше, чем на MS SQL 2012 на том же оборудовании со всеми возможными оптимизациями.

Итак, некоторые детали экспериментов. В плане тестирования производительности у 1С всё системно и научно – есть типовая конфигурация «Стандартный нагрузочный тест », на которой и запускается бенчмарк, поэтапно добавляющий новых пользователей в нагрузку до тех пор, пока приложение работает достаточно отзывчиво для комфортной работы. (Более точно – пользователи добавляются до тех пор, пока стандартный показатель производительности приложений Apdex не опускается ниже порога в 0,85, и максимальное число таких эффективно работающих пользователей и считается результатом бенчмарка.)

Мы использовали версию 8.3.9.1850 1С:Предприятия, стандартный нагрузочный тест в версии 2.0.17.36. Изначально было решено никаких скидок Постгресу не давать: делаем максимальные оптимизации на MS SQL на узле из комплекса Скала-СР / Postgres Pro (ставим Windows на «голое железо», настраиваем по всем канонам , для скорости – делаем ramdisk для временных таблиц), а потом – возвращаем тот же узел в комплекс Скала-СР, накатываем Linux и Postgres Pro EE, и на нём одном (без доступных в комплексе кластерных фишек) – прогоняем тот же тест.

Тест первый: начинаем со 100 рабочих мест, нагрузка 50/50 – половина формирует документы, половина – отчёты. Тест второй: начинаем с 400, нагрузка 70/30. MS SQL «закончился» в первом тесте на 360 пользователях, на втором – на 540, притом ограничителем в обоих пусках стала работа с локальным вводом-выводом, при том, что загрузить процессор удалось в среднем лишь на 30%. Postgres Pro в первом тесте дошёл до 440 рабочих мест, а на втором – до 660, а упёрлось на сервере БД всё в процессор, уходящий в загрузку более 90% на «максимальных пользователях».

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

Серия контента:

1. История развития MySQL и PostgreSQL

История MySQL начинается в 1979 г., у ее истоков стояла небольшая компания во главе с Monty Widenius. В 1996 г. появился первый релиз 3.11 под солярис с публичной лицензией. Затем MySQL была портирована под другие операционные системы, появилась специальная коммерческая лицензия. В 2000 г., после добавления интерфейса, аналогичного Berkeley DB, база стала транзакционной. Примерно тогда же была добавлена репликация. В 2001 г. в версии 4.0 был добавлен движок InnoDB к уже имеющемуся MyISAM, в результате чего появилось кеширование и возросла производительность. В 2004 г. вышла версия 4.1, в которой появились подзапросы, парциальная индексация для MyISAM, юникод. В версии 5.0 в 2005 г. появились хранимые процедуры, курсоры, триггеры, представления (views). В MySQL развиваются коммерческие тенденции: в 2009 г. MySQL стала торговой маркой компании Oracle.

История постгрес началась в 1977 г. с базы данных Ingress.

В 1986 г. в университете Беркли, Калифорния, она была переименована в PostgreSQL.

В 1995 г. постгрес стала открытой базой данных. Появился интерактивный psql.

В 1996 г. Postgres95 была переименована в PostgreSQL версии 6.0.

У постгреса несколько сотен разработчиков по всему миру.

2. Архитектура MySQL и PostgreSQL

PostgreSQL
– унифицированный сервер баз данных, имеющий единый движок – storage engine. Постгрес использует клиент-серверную модель.

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

Клиентский запрос проходит следующие стадии.

1. Коннект.
2. Парсинг: проверяется корректность запроса и создается дерево запроса (query tree). В основу парсера положены базовые юниксовые утилиты yacc и lex.
3. Rewrite: берется дерево запросов и проверяется наличие в нем правил (rules), которые лежат в системных каталогах. Всякий раз пользовательский запрос переписывается на запрос, получающий доступ к таблицам базы данных.
4. Оптимизатор: на каждый запрос создается план запроса – query plan, который передается исполнителю – executor. Смысл плана в том, что в нем перебираются все возможные варианты получения результата (использовать ли индексы, джойны и т.д.), и выбирается самый быстрый вариант.
5. Выполнение запроса: исполнитель рекурсивно проходит по дереву и получает результат, используя при этом сортировку, джойны и т. д., и возвращает строки. Постгрес – обьектно-реляционная база данных, каждая таблица в ней представляет класс, между таблицами реализовано наследование. Реализованы стандарты SQL92 и SQL99.

Транзакционная модель построена на основе так называемого multi-version concurrency control (MVCC), что дает максимальную производительность. Ссылочная целостность обеспечена наличием первичных и вторичных ключей.

MySQL
имеет два слоя – внешний слой sql и внутренний набор движков, из которых наиболее часто используется движок InnoDb, как наиболее полно поддерживающий ACID.

Реализован стандарт SQL92.

С модульной точки зрения код MySQL можно разделить на следующие модули.

1. Инициализация сервера.
2. Менеджер коннектов.
3. Менеджер потоков.
4. Обработчик команд.
5. Аутентификация.
6. Парсер.
7. Оптимизатор.
8. Табличный менеджер.
9. Движки (MyISAM, InnoDB, MEMORY, Berkeley DB).
10. Логирование.
11. Репликация.
12. Сетевое API.
13. API ядра.

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

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

Клиентские запросы в зависимости от их типа на верхнем уровне обрабатываются четвертым модулем (dispatcher). Запросы будут залогированы 11-м модулем. Команда передается парсеру, проверяется кеш. Далее запрос может попасть в оптимизатор, табличный модуль, модуль репликации, и т.д. В результате данные возвращаются клиенту через менеджер потоков.

Наиболее важный код находится в файле sql/mysqld.cc. В нем находятся базовые функции, которые не меняются со времен версии 3.22:
init_common_variables()
init_thread_environment()
init_server_components()
grant_init() // sql/sql_acl. cc
init_slave() // sql/slave.cc
get_options()
handle_connections_sockets()
create_new_thread()
handle_one_connection()
check_connection()
acl_check_host() // sql/sql_acl.cc
create_random_string() // sql/password.cc
check_user() // sql/sql_parse.cc
mysql_parse() // sql/sql_parse.cc
dispatch_command()
Query_cache::store_query() // sql/sql_cache.cc
JOIN::optimize() // sql/sql_select.cc
open_table() // sql/sql_base.cc
mysql_update() // sql/sql_update.cc
mysql_check_table() // sql/sql_table.cc

В хидере sql/sql_class.h определяются базовые классы: Query_arena, Statement, Security_context, Open_tables_state classes, THD. Обьект класса THD представляет собой дескриптор потока и является аргументом большого количества функций.

3. Сравнение MySQL и PostgreSQL: сходство и различия

ACID-стандарт

Стандарт ACID базируется на атомарности, целостности, изоляции и надежности. Эта модель используется для гарантии целостности данных. Реализуется это на основе транзакций. PostgreSQL полностью соответствует стандарту ACID. Для полной поддержки ACID в MySQL в конфиге нужно установить default-storage-engine=innodb.

Производительность (performance)

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

• парциальные индексы;
• компрессия данных;
• выделение памяти;
• улучшенный кеш.

MySQL имеет частичную поддержку парциальных индексов в InnoDB. Если взять MySQL-ский движок ISAM, он оказывается быстрее на плоских запросах, при этом нет блокировок на инсерты, нет поддержки транзакций, foreign key.

Компрессия

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

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

На мульти-процессорности PostgreSQL имеет преимущество над MySQL. Даже сами разработчики MySQL признают, что их движок в этом плане не так хорош.

Типы данных

MySQL: для хранения бинарных данных использует типы TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB, которые отличаются размером (до 4 ГБ).

Character: четыре типа – TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: поддерживает механизм пользовательских данных с помощью команды CREATE TYPE, тип BOOLEAN, геометрические типы.

Character: TEXT (ограничение – max row size).

Для хранения бинарных данных есть тип BLOB, который хранится в файловой системе. Столбцы таблицы могут быть определены как многомерный массив переменной длины. Обьектно-реляционное расширение: структура таблицы может быть унаследована от другой таблицы.

Хранимые процедуры

И PostgreSQL , и MySQL поддерживают хранимые процедуры. PostgreSQL придерживается стандарта Oracle PL/SQL, MySQL – IBM DB2. MySQL поддерживает extend SQL для написания функций на языке C/C++ с версии 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C для написания хранимых процедур.

Ключи

И PostgreSQL , и MySQL поддерживают уникальность Primary Key и Foreign Key. MySQL не поддерживает check constraint плюс вторичные ключи реализованы частично. PostgreSQL: полная реализация плюс поддержка ON DELETE CASCADE и ON UPDATE CASCADE.

Триггеры

MySQL: рудиментарная поддержка. PostgreSQL: декларативные триггеры: SELECT, INSERT, DELETE, UPDATE, INSTEAD OF; процедурные триггеры: CONSTRAINT TRIGGER. События: BEFORE или AFTER на INSERT, DELETE , UPDATE.

Автоинкремент

MySQL: в таблице может быть только один такой столбец, который должен быть проиндексирован. PostgreSQL: SERIAL data type.

Репликации

Поддерживаются и в MySQL, и в PostgreSQL. PostgreSQL имеет модульную архитектуру, и репликация входит в отдельные модули:

• Slony-I – основной механизм репликации в постгресе, производительность падает в квадратичной зависимости от числа серверов;

Репликация в PostgreSQL основана на триггерах и более медленная, чем в MySQL. В ядро репликацию планируется добавить, начиная с версии 8.4.

В MySQL репликация входит в ядро и имеет две разновидности, начиная с версии 5.1:

• SBR – statement based replication;
• RBR – row based replication.

Первый тип основан на логировании записей в бинарный лог, второй – на логировании изменений. Начиная с версии 5.5, в MySQL поддерживается так называемая полусинхронная репликация, при которой основной сервер (master) делает сброс данных на другой сервер (slave) при каждом коммите. Движок NDB делает полную синхронную двухфазную репликацию.

Транзакции

MySQL: только для для InnoDB. Поддержка SAVEPOINT, ROLLBACK TO SAVEPOINT. Уровни блокировки: table level (MyISAM). PostgreSQL: поддерживается плюс read committed и уровни изоляции. Поддержка ROLLBACK, ROLLBACK TO SAVEPOINT. Уровни блокировки: row level, table level.

Уровни привилегий

PostgreSQL: для пользователя или группы пользователей могут быть назначены привилегии.

Экспорт-импорт данных

MySQL: набор утилит для экспорта: mysqldump, mysqlhotcopy, mysqlsnapshot. Импорт из текстовых файлов, html, dbf. PostgreSQL: экспорт – утилита pg_dump. Импорт между базами данных и файловой системой.

Вложенные запросы

Есть и в MySQL, и в PostgreSQL, но в MySQL могут работать непроизводительно.

Индексация

Хэширование индексов: в MySQL– частичное, в PostgreSQL – полное. Полнотекстовый поиск: в MySQL– частичный, в PostgreSQL – полный. Парциальные индексы: в MySQL не поддерживаются, в PostgreSQL поддерживаются. Многостолбцовые индексы: в MySQL ограничение 16 столбцов, в PostgreSQL – 32. Expression-индексы: в MySQL– эмуляция, в PostgreSQL – полное. Неблокирующий create index: в MySQL – частичное, в PostgreSQL – полное.

Партиционирование (Partitioning)

MySQL поддерживает горизонтальное партиционирование: range, list, hash, key, композитное партиционирование. PostgreSQL поддерживает RANGE и LIST. Автоматическое партиционирование для таблиц и индексов.

Автоматическое восстановление после сбоев

MySQL: частичное для InnoDB – нужно вручную сделать backup. PostgreSQL: Write Ahead Logging (WAL).

Data Storage Engines

PostgreSQL поддерживает один движок – Postgres Storage System. В MySQL 5.1 их несколько:

• MyISAM – используется для хранения системных таблиц;
• InnoDB – максимальное соответствие ACID, хранит данные с первичными ключами, кэширует инсерты, поддерживает компрессию, начиная с версии 5.1 – см. атрибут ROW_FORMAT=COMPRESSED;
• NDB Cluster – движок, ориентированный на работу с памятью, кластерная архитектура, использующая синхронную репликацию;
• ARCHIVE – поддерживает компрессию, не использует индексы;
• а также: MERGE, MEMORY (HEAP), CSV.

InnoDB разрабатывается компанией InnoBase, являющейся дочерней компанией Oracle. В 6-й версии должны появиться два движка – Maria и Falcon. Falcon – движок, основанный на ACID-транзакциях.

Лицензирование

PostgreSQL: BSD (Berkeley Software Distribution) open source. MySQL: GPL (Gnu General Public License) или Commercial. MySQL – это open-source продукт. Postgres – это open-source проект.

Заключение

Подводя итоги, можно сказать следующее: MySQL и PostgreSQL – две наиболее популярные open-source базы данных в мире. Каждая база имеет свои особенности и отличия. Если вам нужно быстрое хранилище для простых запросов с минимальной настройкой, я бы порекомендовал MySQL. Если вам нужно надежное хранилище для большого объема данных с возможностью расширения, репликации, полностью соответствующее современным стандартам языка SQL, я бы предложил использовать PostgreSQL.

Мы обсудим вопросы настройки MySQL и PostgreSQL.

Ресурсы для скачивания

static. content.url=http://www.сайт/developerworks/js/artrating/

Zone=Open source, Linux

ArticleID=779830

ArticleTitle=MySQL & PostgreSQL: Часть 1. Сравнительный анализ

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

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

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

Реляционные системы управления базами данных позволяют размещать данные в таблицах, связывая строки из разных таблиц и, таким образом, связывая разные, объединенные логически данные. Перед тем, как вы сможете сохранять данные, необходимо создать таблицы определенного размера и указать тип данных для каждого столбца. Столбы представляют поля данных, а сами данные размещены в строках. Обе системы управления базами данных, и MySQL vs Postgresql принадлежат к реляционным. Дальше мы рассмотрим подробнее чем отличаются обе программы. А теперь перейдем к более детальному рассмотрению.

Краткая история

MySQL

Разработка MySQL началась еще в 90х годах. Первый внутренний выпуск базы данных состоялся в 1995 году. За это время разработкой программы занимались несколько компаний. Разработка была начата шведской компанией MySQL AB, которую приобрела Sun Microsystems, которая, собственно перешла в собственность Oracle. На данный момент, начиная с 2010 года, разработкой занимается Oracle.

Postgresql

Разработка Postrgresql началась в далеком 1986 году в стенах Калифорнийского университета Беркли. Разработка длилась почти восемь лет, затем проект разделился на две части коммерческую базу данных IIlustra и полностью свободный проект Postrgesql, который разрабатывается энтузиастами.

Хранение данных

MySQL

MySQL — это реляционная база данных, для хранения данных в таблицах используются различные движки, но работа с движками спрятана в самой системе. На синтаксис запросов и их выполнение движок не влияет. Поддерживаются такие основные движки MyISAM, InnoDB, MEMORY, Berkeley DB. Они отличаются между собой способом записи данных на диск, а также методами считывания.

Postgresql

Postgresql представляет из себя объектно реляционную базу данных, которая работает только на одном движке — storage engine. Все таблицы представлены в виде объектов, они могут наследоваться, а все действия с таблицами выполняются с помощью объективно ориентированных функций. Как и в MySQL все данные хранятся на диске, в специально отсортированных файлах, но структура этих файлов и записей в них очень сильно отличается.

Стандарт SQL

Независимо от используемой системы управления базами данных, SQL — это стандартизированный язык выполнения запросов. И он поддерживается всеми решениями, даже MySQL или Postgresql. Стандарт SQL был разработан в 1986 году и за это время уже вышло нескольких версий.

MySQL

MySQL поддерживает далеко не все новые возможности стандарта SQL. Разработчики выбрали именно этот путь развития, чтобы сохранить MySQL простым для использования. Компания пытается соответствовать стандартам, но не в ущерб простоте. Если какая-то возможность может улучшить удобство, то разработчики могут реализовать ее в виде своего расширения не обращая внимания на стандарт.

Postgresql

Postgresql — это проект с открытым исходным кодом, он разрабатывается командой энтузиастов, и разработчики пытаются максимально соответствовать стандарту SQL и реализуют все самые новые стандарты. Но все это приводит к ущербу простоты. Postgresql очень сложный и из-за этого он не настолько популярен как MySQL.

Возможности обработки

Из предыдущего пункта выплывают и другие отличия postgresql от mysql, это возможности обработки данных и ограничения. Естественно, соответствие более новым стандартам дает более новые возможности.

MySQL

При выполнении запроса MySQL загружает весь ответ сервера в память клиента, при больших объемах данных это может быть не совсем удобно. В основном по функциям Postgresql превосходит Mysql, дальше рассмотрим в каких именно.

Postgresql

Postgresql поддерживает использование курсоров для перемещения по полученным данным. Вы получаете только указатель, весь ответ хранится в памяти сервера баз данных. Этот указатель можно сохранять между сеансами. Здесь поддерживается построение индексов сразу для нескольких столбцов таблицы. Кроме того, индексы могут быть различных типов, кроме hash и b-tree доступны GiST и SP-GiST для работы с городами, GIN для поиска по тексту, BRIN и Bloom.

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

Производительность

Базы данных должны обязательно быть оптимизированы для окружения, в котором вы будете работать. Исторически так сложилось что MySQL ориентировалась на максимальную производительность, а Postgresql разрабатывалась как база данных с большим количеством настроек и максимально соответствующую стандарту. Но со временем Postgresql получил много улучшений и оптимизаций.

MySQL

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

Postgresql

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

В целом PostgreSQL работает быстрее, за исключениям использования первичных ключей. Давайте рассмотрим несколько тестов с различными операциями:

Типы данных

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

MySQL

MySQL поддерживает такие типы данных:

• TINYINT
  : очень маленькое целое.;
• SMALLINT:
  маленькое целое;
• MEDIUMINT:
  целое среднего размера;
• INT:
  целое нормального размера;
• BIGINT:
  большое целое;
• FLOAT:
  знаковое число с плавающей запятой одинарной точности;
• DOUBLE, DOUBLE PRECISION, REAL:
  знаковое число с плавающей запятой двойной точности
• DECIMAL, NUMERIC:
  знаковое число с плавающей запятой;
• DATE:
  дата;
  DATETIME:
  комбинация даты и времени;
• TIMESTAMP:
  отметка времени;
• TIME:
  время;
  YEAR:
  год в формате YY или YYYY;
• CHAR
  : строка фиксированного размера, дополняемая справа пробелами до максимальной длины;
• VARCHAR:
  строка переменной длины;
• TINYBLOB, TINYTEXT:
  двоичные или текстовые данные максимальной длиной 255 символов;
• BLOB, TEXT
  : двоичные или текстовые данные максимальной длиной 65535 символов;
• MEDIUMBLOB, MEDIUMTEXT:
  текст или двоичные данные;
• LONGBLOB, LONGTEXT:
  текст или двоичные максимальной данные длиной 4294967295 символов;
• ENUM:
  перечисление;
• SET:
  множества.

Postgresql

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

• bigint:
  знаковое 8-байтовое целое;
• bigserial
  : автоматически увеличиваемое 8-байтовое целое;
• bit:
  двоичная строка фиксированной длины;
• bit varying:
  двоичная строка переменной длины;
• boolean:
  флаг;
• box:
  прямоугольник на плоскости;
• byte
  : бинарные данные;
• character varying:
  строка символов фиксированной длины;
• character:
  
• cidr:
  сетевой адрес IPv4 или IPv6;
• circle:
  круг на плоскости;
• date
  : дата в календаре;
• double precision:
  число с плавающей запятой двойной точности;
• inet:
  адрес интернет IPv4 или IPv6;
• integer
  : знаковое 4-байтное целое число;
• interval:
  временной промежуток;
• line:
  бесконечная прямая на плоскости;
• lseg:
  отрезок на плоскости;
• macaddr:
  MAC-адрес;
• money:
  денежная величина;
• path:
  геометрический путь на плоскости;
• point:
  геометрическая точка на плоскости;
• polygon:
  многоугольник на плоскости;
• real:
  число с плавающей точкой одинарной точности;
• smallint:
  двухбайтовое целое число;
• serial:
  автоматически увеличиваемое четырехбитное целое число;
• text:
  строка символов переменной длины;
• time:
  время суток;
• timestamp:
  дата и время;
• tsquery
  : запрос текстового поиска;
• tsvector:
  документ текстового поиска;
• uuid
  : уникальный идентификатор;
• xml:
  XML-данные.

Как видите, типов данных в Postgresql больше и они более разнообразны, есть свои типы полей для определенных видов данных, которых нет MySQL. Отличие MySQL от Postgresql очевидно.

Разработка

Оба проекта имеют открытый исходный код, но развиваются по-разному. Развитие MySQL нравится далеко не всем. И в этом сравнение mysql и postgresql дает много отличий.

MySQL

База данных MySQL разрабатывается компанией Oracle и ходят слухи, что компания намерено тормозит развитие движка. Было создано очень много форков проекта, в том числе форк MariaDB от разработчика оригинальной MySQL. Но все же развитие остается медленным.

Postgresql

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

Выводы

В этой статье мы выполнили сравнение mysql и postgresql, рассмотрели основные отличия обоих систем управления базами данных и попытались понять что лучше postgresql или mysql. В общем результате лучшим по возможностях получается Postgresql, но он сложен и не везде его можно применять. MySQL проще, но не поддерживает некоторых интересных функций. А какую базу данных вы выберите для своего проекта? Почему именно ее? Напишите в комментариях!

На завершение видео с описанием возможностей и перспектив Postgresql:

Платформа «1С:Предприятие» получила поддержку PWA-приложений, ботов и СУБД PostgreSQL 12

Компания «1С» объявила о выпуске обновлённой платформы «1С:Предприятие», предназначенной для автоматизации процессов документооборота, ведения бухгалтерского учёта, управления предприятиями различных сфер деятельности и решения прочих задач в корпоративной среде.

Пользовательский интерфейс «1С:Предприятие» (источник: v8.1c.ru)

Новая версия 8.3.18 программного комплекса получила около сотни доработок и улучшений. Из наиболее интересных изменений стоит отметить поддержку технологии PWA (Progressive Web Apps), позволяющую запускать веб-клиент платформы внутри браузера как обычное нативное приложение без адресной строки и вкладок.

Другим важным нововведением программного комплекса стала встроенная поддержка роботизированных информационных сервисов (ботов), с помощью которых можно настроить приём входящих сообщений от пользователей (в том числе через интеграцию с Telegram и «ВКонтакте») с последующей автоматизированной обработкой полученных данных и выполнением каких-либо операций в системе взаимодействия «1С:Предприятие».

Архитектура «1С:Предприятие» (источник: v8.1c.ru)

Помимо этого, программисты «1С» включили поддержку системы управлениям базами данных PostgreSQL 12, реализовали возможность установки на один ПК под управлением Linux нескольких клиентских версий «1С:Предприятия» и улучшили диагностику исключительных ситуаций на сервере, возникающих из-за ошибок внешних компонентов. Также сообщается о доработках пользовательского интерфейса продукта, планировщика, коммуникационных сервисов и прочих изменениях, с полным списком которых можно ознакомиться по этой ссылке.

В основу «1С:Предприятия» положена клиент-серверная архитектура, поддерживающая интеграцию с Microsoft SQL Server, PostgreSQL, IBM DB2, Oracle Database и файловой СУБД собственной разработки «1С». Серверная составляющая может быть развёрнута в среде Windows или Linux. В качестве клиентов могут использоваться рабочие станции под управлением Windows, macOS и Linux, мобильные устройства на базе Android и iOS, также возможно взаимодействие с платформой через любой современный веб-браузер. Дополнительные сведения о продукте представлены на сайте v8.1c.ru/platforma.

Если вы заметили ошибку — выделите ее мышью и нажмите CTRL+ENTER.

Какую СУБД выбрать для перехода на клиент-серверный режим работы 1С? новость от 04.04.2019

В начале работы с 1С перед организацией может встать вопрос, какую СУБД выбрать для обслуживания базы данных. Сотруднику, который ранее не сталкивался с таким вопросом, будет нелегко разобраться с терминами и сделать выбор. Но нужно помнить, что правильно выбранная СУБД серьёзно облегчит жизнь бухгалтерам, поскольку от этого зависит оперативность обработки всех команд программы 1С. В этой статье разберём работу двух их них – PostgreSQL и MS SQL Server.
Первое, с чего начинается переход на клиент-серверный вид работы 1С, – это бюджет. В этом нет равных PostgreSQL, так как данный программный продукт бесплатный и скачать его можно прямо с сайта обновлений 1С. За MS SQL Server же придётся заплатить, и стоимость зависит от количества пользователей. Вопрос выбора «железа» для сервера оставим в стороне: чем дороже, тем быстрее будет работать.

Главное окно СУБД PostgreSQL:

Второе – это ОС ПК, на котором будет работать СУБД. MS SQL Server работает только под управлением ОС Windows, PostgreSQL же можно развернуть как под Windows, так и под linux. Но стоит учитывать, что если в случае с MS SQL Server его сможет поставить даже начинающий системный администратор, то с PostgreSQL под управлением linux уже стоит поискать более квалифицированного специалиста. Также данные СУБД необходимо будет обслуживать и обновлять, то есть, если найти для этих работ фрилансера, стоит подумать и над будущим сопровождением Системы.

Главное окно СУБД MS SQL Server:

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

Если у вас возникнут дополнительные вопросы по работе в 1С, то вы можете обратиться на Линию консультаций 1С компании «Что делать Консалт». Мы вам с удовольствием поможем!  Работаем без выходных дней с 09:00 до 21:00. Средняя оценка ответов на Линии консультаций – 4,9 из 5 баллов. Первая консультация совершенно бесплатно!

Два важных различия между SQL Server и PostgreSQL

SQL ConstantCare® использует PostgreSQL в качестве серверной части, в частности, AWS RDS Aurora, поэтому в последнее время я потратил много времени на написание запросов Postgres. Вот некоторые отличия, которые я заметил.

CTE — это средства оптимизации.

В SQL Server, если вы напишете этот запрос:

С AllPosts AS (ВЫБРАТЬ * ИЗ StackOverflow. dbo.Posts)
ВЫБРАТЬ *
ОТ AllPosts
ГДЕ Id = 1;

SQL Server создает план запроса для всей операции сразу и передает фильтр предложения WHERE в CTE. Результирующий план запроса эффективен и выполняет только поиск по одному кластеризованному индексу.

В Postgres CTE сначала обрабатываются отдельно, а последующие предложения WHERE применяются позже. Это означает, что приведенный выше запрос работает нормально, но работает ужасно.Вы получите гораздо лучшие результаты, если включите свои фильтры в каждый CTE, например:

С AllPosts AS (ВЫБЕРИТЕ * ИЗ StackOverflow.dbo.Posts ГДЕ Id = 1)
ВЫБРАТЬ *
ОТ AllPosts;

Это далеко не идеально.

Вы не можете сразу перейти к оператору IF.

В SQL Server вы можете просто начать вводить условную логику и выполнять ее:

ЕСЛИ СУЩЕСТВУЕТ (ВЫБРАТЬ * ИЗ StackOverflow.dbo.Users)
ВЫБЕРИТЕ «Ура»
ЕЩЕ
ВЫБЕРИТЕ «Нет»;

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

В Postgres вам нужно сделать небольшую настройку, чтобы объявить, что вы выполняете процедурный код:

DO $$
НАЧИНАТЬ
ЕСЛИ СУЩЕСТВУЕТ (ВЫБРАТЬ * ИЗ правила) ТО
ВЫБЕРИТЕ «Ура»;
ЕЩЕ
ВЫБЕРИТЕ «Нет»;
КОНЕЦ ЕСЛИ;
END $$;

Но и это не работает, потому что вы не можете выводить данные из DO:

.

ОШИБКА: запрос не имеет назначения для данных результатов
ПОДСКАЗКА: если вы хотите отменить результаты SELECT, используйте вместо этого PERFORM.КОНТЕКСТ: PL / pgSQL функция inline_code_block строка 4 в операторе SQL

Вы действительно хотите создать функцию. Это напоминает мне: функции Postgres эквивалентны хранимым процедурам SQL Server.Конечно, пользовательские функции SQL Server имеют действительно плохую репутацию: большинство из них получают неверные оценки строк, препятствуют параллелизму и заставляют настройки производительности указывать и хихикать. Функции Postgres? Абсолютно другой. Просто в основном хранятся проки.

И одно менее важное различие: НАИБОЛЬШЕЕ и НАИМЕНЕЕ.

Время от времени мне нужно найти более высокую (или меньшую) из двух вещей подряд. Скажем, наша таблица dbo.Users имеет два столбца, UpvoteDate и DownvoteDate, и я пытаюсь найти дату, когда они голосовали в ЛЮБОМ порядке.У Postgres есть очень крутой трюк:

ВЫБЕРИТЕ САМЫЙ БОЛЬШОЙ (LastUpvoteDate, LastDownvoteDate) как VoteDate
ОТ dbo.Users;

GREATEST похож на MAX, но по столбцам. GREATEST и LEAST — два условных выражения, которых нет в SQL Server. Отлично.

Перекрестное сравнение SQL Server, MySQL и PostgreSQL

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

.

Функция	Microsoft SQL Server 2005	MySQL 5	PostgreSQL 8.3
ОС — Почему это важно? Почему вы даже мечтаете не работать в Windows? Если вы однажды решите, что Microsoft — не ваш лучший друг во всем мире, вы можете отказаться от них или, по крайней мере, на своем сервере БД (может ли это когда-нибудь случиться?). Кстати, Microsoft в любом случае не может конкурировать с Oracle в Linux / Unix. Если у Microsoft есть не-Microsoft БД, работающая на компьютере клиента, мне интересно, какую базу данных они предпочли бы — Oracle, IBM DB2, Sun MySQL или PostgreSQL?	Windows XP, Windows 2000+	Windows (даже до 98?), Linux, Unix, Mac	Windows 2000+, Linux, Unix, Mac
Лицензирование	Коммерческая — с закрытым исходным кодом, различные уровни функции на основе версии, Free Crippleware	GPL с открытым исходным кодом, коммерческая.Вот интересная запись в блоге на тему бесплатного программного обеспечения MySQL, но не открытого исходного кода. Комментарии на самом деле намного информативнее, чем сама статья.	BSD с открытым исходным кодом
Процесс установки / обслуживания	Самый трудоемкий и самый большой расход ресурсов из трех, даже если он ничего не делает	Самый простой	Средний
Драйверы, уже установленные в Windows	Да — когда у вас есть магазин окон, он огромен, особенно когда вам не разрешено устанавливать какие-либо вещи на клиентские рабочие столы, и вам нужно легко интегрироваться с настольными приложениями. Вот почему использование связанного сервера SQL Server для получения вкусных функций PostgreSQL очень удобно.	Нет	Нет
Доступны драйверы ODBC, JDBC, ADO.NET	Да	Да	Да
Представления только для чтения	Да	Да	Да
Открыть Исходные продукты, доступные для него	Немного, кроме CodePlex / .NET	Многие	Немного, но все больше и больше на PHP, чем SQL Server
Коммерческие	Многие?	Умеренно	Немного, но растет
Обновляемые просмотры	Да — даже для двух представлений таблиц они будут автоматически обновляться если у них есть ключи и обновление не включает более одной таблицы.Вы можете написать вместо триггеров для более сложных представлений, чтобы сделать их обновляемыми	Да — представления одной таблицы обновляются автоматически, некоторые представления двух таблиц могут обновляться, если в них нет левых соединений и не требуется обновление более одной таблицы. Если у вас есть более сложные представления, которые вы хотите сделать обновляемыми — избавление от дороги — нет поддержки триггеров или правил для представлений.	Да, но не автоматический. Вы должны написать правила для представлений, чтобы сделать их обновляемыми, но в результате можете сделать очень сложные представления обновляемыми.
Материализованные / индексируемые представления	Да, но немного отличается в зависимости от того, используете ли вы SQL Express, Workgroup, Standard, Enterprise и многочисленные ограничения на ваши представления, что делает его ограниченное использование	Нет?	Нет, но есть 2 модуля contrib e.грамм. matviews, которые просты и в основном перестраивают материализованное представление
Можно добавлять столбцы и изменять имена, типы данных в представлениях, не отбрасывая	Есть	Есть	Нет — и очень раздражает, если у вас есть представления, которые зависят от других представлений.
Может отбрасывать таблицы (отбрасывать, изменять размер, тип данных столбцов) и представления, используемые в представлениях — возможно, это недостаток, но иногда он может пригодиться, когда вы являетесь пользователем EXPERT 🙂	Да — ура! (но если вы привязываете схему к своим таблицам и представлениям, вы не можете удалить зависимые объекты)	Да — ура!	Нет
Дизайнер графических представлений (e.грамм. вы можете видеть таблицы и выбирать поля, перетаскивать линии для объединения) включены без дополнительной оплаты	Да через SQL Management Studio и Express?	Нет	Нет
Вычисляемые столбцы	Да, но нам все еще нравится использовать представления, за исключением тех случаев, когда нам действительно нужен индексированный вычисляемый столбец, и часто мы просто выполняем триггеры. Вычисляемые столбцы имеют очень ограниченное применение, поскольку они не могут содержать сводные данные.	Нет — но похоже, что его планируется выпустить в будущем.	Нет, но у PostgreSQL есть функциональные индексы, поэтому просто используйте представление.
Функциональные индексы — индексы на основе функции	Нет — но вы можете создать вычисляемый столбец и создать для него индекс	Нет	Есть
Частичные индексы — например, вы хотите создать уникальный индекс, но учитываете только ненулевые значения	Нет — но, как уже указывалось, вы можете добиться аналогичных результатов с индексированным представлением	Нет	Да!
Соответствие ACID — я могу сказать, что это иногда завышается — не все данные создаются равными, и иногда скорость объемной вставки более важна, чем ACID	Есть	Некоторые механизмы хранения e.грамм. InnoDB, а не MyISAM	Есть
Внешний ключ — каскадное обновление / удаление	Есть	InnoDB, а не MyISAM	Есть
Многорядная вставка значений	Нет, но в SQL Server 2008 он будет	Есть	Есть
Логика UPSERT — где вы можете одновременно вставить, если отсутствует, и обновить, если есть	Нет, но SQL Server 2008 получит его через MERGE UPDATE	Да — через INSERT IGNORE и REPLACE	Нет
Репликация — мало что использовал, кроме SQL Server, так что это в основном слуховой аппарат	Да, все виды — доставка журналов, зеркалирование, моментальные снимки, транзакции, слияние и т. Д.и даже может иметь подписчиков на базе Windows, отличных от SQL Server. Все еще сложно заставить работать так, как вы хотите, и затрудняет внесение структурных изменений. Встроенный	Да, включая master-master (встроенный) См. Комментарии ниже и отчеты numerours о большом преимуществе MySQL.	Да, но, судя по отчетам, это наименее доработанный вариант, хотя существует множество сторонних вариантов на выбор, которые являются как бесплатными, так и платными. PostgreSQL 8.4 или выше — это планируется иметь встроенную репликацию — см. примечания основной команды — http://archives.postgresql.org/pgsql-hackers/2008-05/msg00913.php
Может программировать сохраненные процессы / функции на нескольких языках	Да — любой язык, который соответствует CLR, например, VB.Net, C #, IronPython, но вам нужно сначала скомпилировать в dll — это своего рода обман, поскольку вы не можете видеть код Python прямо в своей базе данных. Кроме того, вам не нужен IronPython и т. Д., Размещенный на сервере, но вы также не можете использовать богатую среду Python и вам нужно, чтобы все зависимые библиотеки были явно загружены в GAC SQL Server, настоящий PITA, если у вас много этих зависимостей.	Нет (кроме C и Pl / SQL), но над этим работают	Да, PostgreSQL просто делает это круто — нам нравится, когда наш код находится прямо там, где мы можем видеть, что он делает. Нижний сервер должен содержать языковую среду.
Может определять пользовательские агрегатные функции	Да, любой язык .NET, кроме TRANSACT SQL. Почему Transact-SQL выброшен в пыль?	Да, но только в C как UDF	Да — любой язык PL и встроенный C, SQL, PLPgSQL.
Триггеры	Есть	Есть	Есть
Разделение таблицы	Да — только версия Enterprise — функциональная, ассортимент	Да? (применяется только к кластеру NDB), 5.1 будет значительно улучшена	через наследование таблиц, исключение ограничений, правила и триггеры — в основном RANGE. Проблемы с использованием ограничений внешнего ключа с унаследованными таблицами (планируется улучшить в версии 8.4?)
Может писать функции возврата Set / Table, которые могут использоваться в предложении FROM	Есть	Нет	Есть
Поддержка создания функций — например, СОЗДАТЬ ФУНКЦИЮ	Есть	Есть	Есть
Поддержка создания хранимых процедур — например, СОЗДАТЬ ПРОЦЕДУРУ	Есть	Есть	Sort-Of — CREATE FUNCTION служит той же потребности
Динамический и функциональный SQL в функциях	Нет — но вы можете в хранимых процедурах, но вы не можете вызывать хранимые процедуры из операторов SELECT, что гораздо более ограничительно, чем PostgreSQL	Нет, но может в хранимых процедурах, которые не могут быть вызваны из операторов SELECT, поэтому более ограничены, чем PostgreSQL	Да! — вы можете делать действительно крутые вещи с функциями действий в операторах SELECT
Графический инструмент объяснения — без дополнительной оплаты	Да — SQL Management Studio / Express	Нет	Да — PgAdmin III
Агент планирования заданий, управляемый клиентом DB Manager, для выполнения пакетных заданий sql и оболочки — без дополнительной оплаты (кроме CronTab)	Да — агент SQL (не для Express)	Нет — но скоро 5. 1 будет	Да — PgAgent
Доступ к таблицам из других баз данных на том же сервере	Да — server.db.schema.table, может даже получить доступ к разрозненным источникам данных через связанный сервер или открытый запрос	Да — таблица db.table, но не легко на серверах	Вроде — через Dblink, но гораздо менее элегантно, чем способ MSSQL и MySQL, и гораздо менее эффективен. Также возможен доступ к разрозненным источникам данных через DBI Link
Нечувствительность к корпусу — e.грамм. LIKE ‘abc%’ и LIKE ‘ABC%’ означают одно и то же	По умолчанию регистр не учитывается, но его можно изменить до уровня столбца.	По умолчанию регистр не учитывается	По умолчанию чувствителен к регистру, и неудобно сделать это иначе. Конечно, вы можете использовать ILIKE, но он не индексируется и просто не то же самое, поскольку драйвер ODBC не предоставляет его и не совместим с ANSI. Это раздражает в таких средах, как MS Access, PHP Gallery, где пользовательская нечувствительность к регистру MySQL / MSSQL Server по умолчанию более ожидаема.
Дата и время Поддержка	SQL Server 2005 и ниже просто отстойны. Только Datetime (без поддержки часового пояса или просто DATE). В SQL Server 2008 они будут.	Менее хромает, есть Date и DateTime, но без часового пояса	Best — Date, TimeStamp и TimeStamp с часовым поясом (не путать с меткой времени MySQL, которая обновляется автоматически, или устаревшей меткой времени SQL Server, которая является двоичной)
Аутентификация	Стандартная безопасность Db и аутентификация NT / Active Directory	Standard Db с IP, управляемым таблицей, как безопасность	Extensive — стандартный, LDAP, SSPI (может подключаться к Active Directory, если работает на сервере NT, но все же не так хорошо, как бесшовная интеграция с SQL Server), PAM, доверие по IP и т. Д.
ОТЛИЧИТЬ НА	Нет	Нет	Есть
С РОЛИКОМ	Есть	Есть	Нет
С КУБОМ	Есть	Нет	Нет
Оконные функции НАД ЧАСТЬЮ НА	Есть	Нет	Нет
СЧЕТЧИК (РАЗЛИЧНЫЙ), АГРЕГАТНЫЙ (РАЗЛИЧНЫЙ)	Есть	Есть	Есть
OGC Spatial Support — для моего отца лучше, чем ваш папа, борьба в мире ГИС между SQL Server и PostgreSQL / PostGIS check out Взгляните на PostgreSQL и ArcSDE, также ознакомьтесь с нашим сопутствующим критическим мнением о 3 пространственных предложениях	Нет, хорошо. Надстройка MSSQL Spatial с открытым исходным кодом имеет базовую поддержку, но не так хорошо, как PostGIS.Многие коммерческие поставщики предоставляют пространственные расширения для SQL Server 2005 — например, На ум приходят Manifold.net, MapDotNet, ESRI ArcSDE. SQL Server 2008 будет иметь встроенные и геодезические функции, но многие функции, которые есть в PostGIS, будут отсутствовать.	Да — в основном MBR и пространственные индексы работают только в MyISAM. Ограниченные пространственные функции. Некоторые коммерческие (MapDotNet, Manifold.net) инструменты ГИС с открытым исходным кодом набирают обороты, но все еще больше отстают от PostGIS.	Да, PostGIS великолепен, с множеством пространственных функций и довольно эффективной индексацией, а также с большим количеством открытой и коммерческой поддержки и грядущей ESRI ArcGIS 9.3 это тоже поддерживает.
Схемы	Есть	Нет	Есть
КРЕСТ ПРИМЕНИТЬ	Есть	Нет	Нет, но может по большей части имитировать, помещая набор, возвращающий функции C / SQL, в предложение SELECT и заключая более сложные функции в тело функции SQL.
ПРЕДЕЛ .. СМЕЩЕНИЕ	Нет — имеет TOP и ANSI-совместимые ROW_NUMBER () OVER (ORDER BY somefield) As Row — where..Row> = … AND Row	Есть	Есть
Мастер расширенной настройки базы данных	Да — SQL Management Studio рекомендует добавлять индексы и т. Д. Очень мило. НЕДОСТУПНО для Express или Workgroup.	Нет	Нет
Мастер плана обслуживания	Да, через SQL Management Studio — Workgroup и выше. Очень мило. Мы проведем вас через создание плана резервного копирования, плана переиндексации, проверки ошибок и составим расписание для вас с помощью SQL Agent	Нет	Нет
Сменный накопитель	Нет	Есть	Нет
Коррелированные подзапросы	Есть	Есть	Есть
FullText Engine — он есть у всех трех, но мы не чувствуем себя вправе сравнивать, поскольку мы не использовали каждый из них в достаточной степени, чтобы провести достоверное сравнение. Его раздражает отсутствие установленного стандарта для выполнения полнотекстовых SQL-запросов	Есть	Есть	Есть
Последовательности / Авто номер	Да — через свойство IDENTITY поля int	Да — через AUTO_INCREMENT поля int	Да — через последовательный тип данных или по умолчанию на следующую последовательность существующего объекта последовательности — это лучше, чем простая функция auto_increment в MySQL и SQL Server.Причина, по которой это лучше, в том, что вы можете использовать один и тот же объект последовательности для нескольких таблиц, и вы можете иметь более одного объекта для каждой таблицы. В прошлом последовательность PostgreSQL была сложной задачей, но теперь вы просто создаете ее с серийным типом данных, если вы хотите, чтобы он вел себя как SQL Server и MySQL, и он автоматически сбросит последовательность, если вы удалите таблицу, к которой она привязана.

Сравните возможности SQL Server, MySQL и PostgreSQL

Администраторы баз данных SQL Server абсолютно уверены, что SQL Server — лучшая реляционная база данных. Всегда. Сам я никогда не сомневался.

Что делать, если ваша компания хочет сократить расходы и разместить некоторые информационные ресурсы
в СУБД с открытым исходным кодом? С точки зрения инженера / архитектора данных, которая
вы должны предложить использовать? Открытый исходный код = бесплатно. К сожалению,
очень привлекательный вариант для ответственных за компанию лиц, принимающих решения
бюджет.

Более того, мне всегда было интересно, чем отличаются MySQL и PostgreSQL? Который
функции, которые предлагает каждый, и какие функции они не предлагают?

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

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

Как правило, базы данных MySQL и PostgreSQL полностью поддерживают ACID и могут
обрабатывать большие объемы данных и высокий уровень параллелизма запросов.

Что касается функций MySQL, я в основном буду иметь в виду InnoDB
двигатель хранения.

	MySQL	PostgreSQL	SQL Server
Буферный пул / кэш, обслуживающий запросы	Кэш MySQL, обслуживающий запросы пользователей, называется пулом буферов. Этот кеш может быть установлен на любой размер, оставляя достаточно памяти только для другие процессы на сервере. Вы можете разделить буферный пул на несколько частей, чтобы минимизировать конкуренцию за структуры памяти, и вы можете закрепить таблицы в буферный пул.Сканирование таблицы или mysqldump удаляют старые данные.	PostgreSQL поддерживает разделяемую память для страниц данных и, в связи с тем, что что это система, основанная на процессах, каждое соединение имеет собственный процесс ОС сам по себе и имеет свою память. Процесс освобождает память после казнь закончена. Поэтому имеет проблемы с масштабированием за сотни активных подключений.	Память SQL Server называется буферным пулом, и ее размер может быть установлен как большой. при необходимости нет возможности установить несколько пулов буферов.
Поддержка ограничений	Поддерживает первичные ключи, внешние ключи, ненулевые ограничения, уникальные ограничения, ограничения по умолчанию, не поддерживает ограничения CHECK	Поддерживает первичные ключи, внешние ключи, ненулевые ограничения, проверочные ограничения, уникальные ограничения, ограничения по умолчанию, ограничения исключения	Поддерживает первичные ключи, внешние ключи, ненулевые ограничения, проверочные ограничения, уникальные ограничения, ограничения по умолчанию
Временные столы	Поддерживает CTE, нет поддержки глобальных временных таблиц (доступно за пределами область сеанса) и никаких табличных переменных. Интересный факт: нельзя обращаться к ВРЕМЕННОЙ таблице более одного раза в одном запросе. Например, следующее не работает: SELECT * FROM temp_table JOIN temp_table AS t2;	Поддерживает CTE, глобальные и локальные временные таблицы и табличные переменные (используя имя таблицы как имя типа). Интересный факт: если создать две таблицы с тем же именем одна временная, а другая обычная таблица CREATE TEMP TABLE X (…) и CREATE TABLE X (…), «выбрать * из x» всегда будет приносить данные из временной таблицы.	Поддерживает CTE, глобальные и локальные временные таблицы и табличные переменные.
Окно / Аналитические функции	Поддерживает: CUME_DIST, FIRST_VALUE, LAG, LAST_VALUE, LEAD, PERCENT_RANK, ROW_NUMBER, RANK, DENSE_RANK, NTILE, NTH_VALUE Нет PERCENTILE_CONT, PERCENTILE_DISC функции.	Поддерживает функции: CUME_DIST, FIRST_VALUE, LAG, LAST_VALUE, LEAD, PERCENTILE_CONT, PERCENTILE_DISC, PERCENT_RANK, ROW_NUMBER, RANK, DENSE_RANK, NTILE, NTH_VALUE	Поддерживает функции: CUME_DIST, FIRST_VALUE, LAG, LAST_VALUE, LEAD, PERCENTILE_CONT, PERCENTILE_DISC, PERCENT_RANK, ROW_NUMBER, RANK, DENSE_RANK, NTILE. Пока нет функции NTH_VALUE
Выполнение параллельного запроса	MySQL обычно использует 1 ЦП на запрос.	Планы запросов могут использовать несколько процессоров	Планы запросов могут использовать несколько процессоров
Индексы	Поддерживает таблицы с организацией по индексу — кластерные индексы. Нет поддержка постоянных индексов / материализованных представлений	Поддерживает таблицы, организованные по индексу, но обновления выполняются вручную до ProstgreSQL 11, когда он автоматический. Поддерживается индексы / материализованные представления.	Поддерживает таблицы с организацией по индексу — кластерные индексы, которые автоматически поддерживает порядок строк.
Использование нескольких индексов в одном запросе	Для одного запроса можно использовать несколько индексов.	Для одного запроса можно использовать несколько индексов. Если у нас есть отдельные индексы по x и y, одна из возможных реализаций запроса типа WHERE x = 5 И y = 6 — использовать каждый индекс с соответствующим предложением запроса и затем И вместе результаты индекса для идентификации строк результатов.	Для одного запроса можно использовать несколько индексов (индекс объект пересечения).
Многоколоночные указатели	Многостолбцовые индексы могут содержать до 16 столбцов	Многостолбцовые индексы могут содержать до 32 столбцов	Многостолбцовые индексы могут содержать до 16 столбцов
Частичные индексы (индекс, построенный по подмножеству таблицы с использованием фильтра)	Не поддерживает частичные индексы	Поддерживает частичные индексы	Поддерживает частичные индексы
Алгоритмы соединения	MySQL выполняет соединения между таблицами, используя только алгоритм вложенного цикла или его вариации.	Поддерживает объединения с вложенными циклами, хэш-соединения и алгоритмы объединений слиянием.	Поддерживает алгоритмы соединений с вложенными циклами, хэш-соединений и объединений слиянием.
Повторное использование плана выполнения запроса	Поддерживает кеши для подготовленных операторов и сохраненных программ для каждого сеанса основание. Операторы, кэшированные для одного сеанса, недоступны для других сеансов.	Кэширует планы запросов, пока открыт подготовленный оператор. В план запроса удаляется при закрытии подготовленного оператора.	Имеет общий кеш плана выполнения, чтобы запросы могли повторно использовать выполнение планы
Статистика	Поддерживает постоянную и непостоянную статистику (очищается на сервере). перезапуск)	Поддерживает статистику, используемую планировщиком, они обновляются АНАЛИЗ, ВАКУУМ или СОЗДАНИЕ ИНДЕКСА	Поддерживает постоянную статистику
Таблицы, оптимизированные для памяти	MySQL имеет возможность хранить таблицы в памяти. Таблицы, которые созданы в памяти, не поддерживают транзакции, их данные уязвимы к сбоям. Эти таблицы следует использовать как временную область или только для чтения. тайники.	Не предлагает никакого механизма в памяти.	In-memory OLTP интегрирован в ядро ​​базы данных SQL Server
Магазин-столбец или рядный магазин	MariaDB недавно запустила механизм хранения столбцов для MySQL, который была разработана как база данных с массовым параллелизмом в среде с несколькими серверы.Его можно использовать вместо механизма хранения InnoDB.	Рядный магазин. Не предлагает никакого механизма хранения столбцов.	SQL Server предлагает индексы хранилища столбцов для запроса больших таблиц

Разница между — Oracle, SQL Server, MySQL и PostgreSQL

Oracle, SQL Server, MySQL 5 и PostgreSQL — наиболее часто используемые базы данных, и люди обычно попадают в ловушку сравнения между ними. Неспособность обойти все аспекты сравнения становится ограничением и ведет к нерешительности в отношении того, какую базу данных использовать.

Вот сравнение всех четырех в поточечной манере:

Microsoft SQL Server — реляционная СУБД от Microsoft, но и MySQL, и PostgreSQL — широко используемые СУБД с открытым исходным кодом.

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

Модель вторичной базы данных : это жизненно важный элемент сравнения.

• Хранилище документов: Хранилища документов общие для всех. Их также называют системами баз данных, которые ориентированы на документы и известны своей организацией данных без схемы. Последнее в основном означает, что нет единой структуры записей и может иметь вложенную форму.
• Хранилище ключей: Еще одна распространенная функция — хранилище «ключ-значение», в котором ключи и значения хранятся попарно. Это простая система баз данных, которая не считается подходящей для сложных приложений. Но в основном простота — это главный аспект, который делает его более привлекательным в некоторых особых случаях.
• Graph DBMS: Еще один примечательный атрибут, который можно увидеть только в Oracle и Microsoft SQL Server, — это Graph DBMS.Последний также известен как база данных графов. Здесь база данных представлена ​​в структурах графа в виде узлов и ребер, которые представляют отношения между узлами. Обработка данных упрощается за счет простых вычислений определенных свойств графа. Индексирование на всех узлах реально не предусмотрено.
• Хранилище RDF: Во вторичной модели хранилища RDF видны в Oracle. По сути, это метод описания информации, который изначально был разработан для детализации метаданных ИТ-ресурсов.

Рейтинг :

Прочтите: Лучшие вопросы и ответы на собеседовании с администраторами баз данных Oracle

Согласно последнему рейтингу в январе 2019 года, Oracle имеет наивысший балл и занимает первое место. За ним следует MySQL, затем Microsoft SQL и, наконец, PostgreSQL. В то время как первые три акции близки по результатам, последняя имеет большой разрыв в оценках. Операционная система сервера: у нее есть огромные различия, когда дело доходит до сравнения четырех баз данных. Ниже приведен список ОС, поддерживаемых всеми четырьмя по отдельности:

• Microsoft SQL Server: Он поддерживает Linux и Windows.
• Oracle: Он поддерживает AIX, HP-UX, Linux, OS X, Solaris, Windows, z / OS.
• PostgreSQL: Он поддерживает FreeBSD, HP-UX, Linux, NetBSD, OpenBSD, OS X, Solaris, Unix и Windows.
• MySQL: Он поддерживает FreeBSD, Linux, OS X, Solaris и Windows.

Поддерживаемые языки для программирования : Язык программирования — это структурированный и организованный язык, который содержит различные инструкции для создания различных видов выходных данных.Они в основном используются в компьютерном программировании для создания программ, которые реализуют определенные алгоритмы. Здесь снова наблюдается огромное разнообразие. Oracle явно поддерживает максимальное количество языков, за которыми следует MySQL.

• Microsoft SQL Server: Он поддерживает C #, C ++, Delphi, Go, Java, JavaScript, PHP, Python, R, Ruby, Visual Basic
• Oracle: Он поддерживает C, C #, C ++, Clojure, Cobol, Delphi, Eiffel, Erlang, Fortran, Groovy, Haskell, Java, JavaScript, Lisp, Objective C, OCaml, Perl, PHP, Python, R, Ruby, Scala, Tcl, Visual Basic.
• PostgreSQL: Он поддерживает . Net, C, C ++, Delphi, Java, JavaScript, Perl, PHP, Python и Tcl.
• MySQL: Он поддерживает Ada, C, C #, C ++, D, Delphi, Eiffel, Erlang, Haskell, Java, JavaScript, Objective-C, OCaml, Perl, PHP, Python, Ruby, Scheme и Tcl.

Лицензирование : Это важный критерий сравнения. Microsoft SQL Server использует коммерческое лицензирование с закрытым исходным кодом и включает функции на разных уровнях, основанные на версии и Free Crippleware.Лицензирование для MySQL является открытым исходным кодом, коммерческое использование, а для PostgreSQL это также BSD с открытым исходным кодом. В Oracle люди могут выбирать из ряда служб баз данных, которые основаны на Oracle Cloud.

Доступность драйверов ODBC, JDBC, ADO.NET : они жизненно важны для аспекта подключения к данным, но обычно игнорируются. Они могут значительно повысить производительность, надежность и переносимость приложений. Все это мощно, экономично и просто. Они поддерживаются всеми сравниваемыми базами данных.

Установка и обслуживание : Видно множество вариаций. В то время как Microsoft SQL Server сложнее всего установить и занимает много времени. Это проще всего в случае MySQL и средней сложности для PostgreSQL. В случае с Oracle тоже сложно. Можно добавлять столбцы или изменять имена или представления типов данных без удаления : Это можно легко обработать как в Microsoft SQL, так и в MySQL, но может быть очень утомительным в случае PostgreSQL, особенно в случае представлений, которые зависят от других представлений.

Drop Tables : Это возможно как в Microsoft SQL, так и в MySQL, но невозможно в PostgreSQL. Это также доступно для Oracle.

Прочтите: Oracle — идеальный выбор для успеха организации

Вычисляемые столбцы: Это возможно в Microsoft SQL Server. Это используется реже. Только в том случае, если вам нужно проиндексировать вычисляемые столбцы, вы используете это. Вычисляемые столбцы фактически ограничены в использовании. Однако это невозможно в MySQL и PostgreSQL.Однако в последнем есть функциональные показатели. В MySQL это может появиться в некоторых будущих версиях. В Oracle эта функция полностью отсутствовала, но в 11g новая функция позволяет вам создать «виртуальный столбец», который по сути является пустым столбцом и имеет функцию по отношению к другим столбцам таблицы.

Функциональные индексы : Эти индексы позволяют создать индекс на основе определенного выражения или функции. Они могут иметь множество столбцов, арифметических выражений или даже функцию PL / SQL.Они отсутствуют как в Microsoft SQL, так и в MySQL, но присутствуют в PostgreSQL. В Oracle они были представлены в Oracle 8i.

Частичные индексы : Их можно создать, добавив предложение «Частичное индексирование». Эта функция полностью отсутствовала в Microsoft SQL Server и MySQL, но присутствует в PostgreSQL и Oracle. Oracle уникальным образом эмулирует частичные индексы.

Внешний ключ: Внешний ключ, который имеет каскадное удаление, фактически означает, что если какая-либо запись в родительской таблице будет удалена, то соответствующие записи во всех дочерних таблицах будут удалены по умолчанию.Это также присутствует в Microsoft SQL, PostgreSQL и Oracle. В MySQL это присутствует как InnoDB, а не MyISAM.

Вставка многострочного значения: Этого нет в Microsoft SQL, но есть во всех трех. Оператор INSERT ALL в Oracle используется для добавления множества строк с помощью только одного оператора.

UPSERT Logic : это невозможно в Microsoft SQL Server и PostgreSQL, но присутствует в MySQL и Oracle. По сути, это функция, в которой вы можете одновременно вставлять и обновлять, отсюда и название UPSERT.

Прочтите: Oracle DBA Tutorial Guide for Beginners

Программирование процессов или функций на многих языках : Это присутствует во всех, кроме MySQL, хотя и разрабатывается там же. В Microsoft SQL Server это возможно для любого языка, который соответствует CLR, но сначала он должен быть скомпилирован в dll. В PostgreSQL языковая среда размещается на нижнем сервере.

Динамический и функциональный SQL в функциях : Эта функция отсутствует как в Microsoft SQL Server, так и в MySQL.Однако в обоих случаях это можно сделать в хранимых процедурах. В PostgreSQL и Oracle такая возможность присутствует. Поддержка даты и времени : Хотя эта функция присутствует во всех четырех, она лучше всего подходит для PostgreSQL. Он состоит из даты, отметки времени и отметки времени с часовым поясом.

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

• Microsoft SQL: Он имеет стандартную безопасность базы данных и аутентификацию NT / Active Directory
• MySQL: Он также имеет стандартную безопасность Db с безопасностью на основе таблиц.
• PostgreSQL: Он имеет расширенную безопасность со стандартом, LDAP, SSPI, PAM, доверием и т. Д.
• Oracle: Стандартная безопасность базы данных

Нечувствительность к регистру : в основном это означает, что базы данных чувствительны к регистрам. Ни одна из других баз данных, кроме PostgreSQL, не чувствительна к регистру. Только PostgreSQL по умолчанию чувствителен к регистру

. Заключение:

Все четыре базы данных предлагают уникальные функции, которые имеют большое удобство использования для различной аудитории.Microsoft SQL Server является наиболее предпочтительным выбором для многих и, следовательно, будет иметь большой потенциал в 2019 году. Спланированный и систематический учебный курс может открыть для вас много новых возможностей. JanBask Training предлагает современный комплексный курс обучения, который вы можете адаптировать к своим потребностям. Он включает в себя практический подход, чтобы дать вам практическое представление о том же, и действует как большой усилитель уверенности.

Прочтите: Полное руководство по базам данных — Oracle против SQL Server против MySQL

Курс Oracle DBA
Предстоящие партии

Трендовые курсы

AWS

• AWS и основы Linux
• Amazon Simple Storage Service
• Эластичное вычислительное облако
• Обзор баз данных и Amazon Route 53

Предстоящий класс

1 день 26 фев 2021

DevOps

• Введение в DevOps
• GIT и Maven
• Дженкинс и Ansible
• Докер и облачные вычисления

Предстоящий класс

1 день 26 фев 2021

Наука о данных

• Введение в науку о данных
• Обзор Hadoop и Spark
• Python и введение в программирование на R
• Машинное обучение

Предстоящий класс

8 дней 05 мар. 2021

Hadoop

• Архитектура, HDFS и MapReduce
• Оболочка Unix и установка Apache Pig
• Установка HIVE и пользовательские функции
• Установка SQOOP и Hbase

Предстоящий класс

8 дней 05 мар.2021

Salesforce

• Введение в конфигурацию Salesforce
• Процесс безопасности и автоматизации
• Облако продаж и обслуживания
• Программирование Apex, SOQL и SOSL

Предстоящий класс

1 день 26 фев 2021

QA

• Введение и тестирование программного обеспечения
• Жизненный цикл тестирования программного обеспечения
• Автоматизация тестирования и тестирования API
• Разработка фреймворка Selenium с использованием тестирования

Предстоящий класс

2 дня 27 фев 2021

Бизнес-аналитик

• BA и обзор заинтересованных сторон
• BPMN, выявление требований
• BA Инструменты и проектная документация
• Анализ предприятия, Agile и Scrum

Предстоящий класс

1 день 26 фев 2021

MS SQL Server

• Введение и запрос к базе данных
• Программирование, индексы и системные функции
• Процедуры разработки пакетов служб SSIS
• Дизайн отчета SSRS

Предстоящий класс

8 дней 05 мар. 2021

Python

• Особенности Python
• Редакторы Python и IDE
• Типы данных и переменные
• Операция с файлом Python

Предстоящий класс

1 день 26 фев 2021

Искусственный интеллект

• Компоненты AI
• Категории машинного обучения
• Рекуррентные нейронные сети
• Рекуррентные нейронные сети

Предстоящий класс

2 дня 27 фев 2021

Машинное обучение

• Введение в машинное обучение и Python
• Машинное обучение: обучение с учителем
• Машинное обучение: обучение без учителя

Предстоящий класс

15 дней 12 мар.2021

Таблица

• Знакомство с Tableau Desktop
• Методы преобразования данных
• Настройка сервера таблиц
• Интеграция с R & Hadoop

Предстоящий класс

16 дней 13 мар. 2021

— Выберите курс -AzureSalesforceQA TestingSQL ServerБизнес-аналитикHadoopAWSDevOpsНаука о данныхJavaЦифровой маркетингDotnetPMPSeleniumСтоит посетитьМашинное обучениеPythonOracle DBADАналитик данныхТаблицаauSixmaScrum MasterBlockchain IT-интеллектAndroidCyber ​​SecurityVMware 9000

— Категория — СтатьяУчебникиВопросы для интервью

— Выберите время — Эта неделя, этот месяц, этот годСамые просматриваемые

Курс Oracle DBA
Предстоящие партии

Получите последние материалы и предложения по курсу Oracle DBA

Битва титанов

Как говорится, перемены — единственная постоянная в жизни.Интересно, что это также относится к миру технологий и программного обеспечения. Oracle Database была признанным во всем мире решением на протяжении десятилетий, но есть восходящая звезда под названием PostgreSQL, которая завоевывает доверие разработчиков со всего мира.

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

Оракул в двух словах

Oracle — один из крупнейших поставщиков систем управления реляционными базами данных (СУБД) на рынке сегодня.Это широко известно как Oracle Database или Oracle DB. Oracle Database используется многими компаниями в ИТ-индустрии для обработки транзакций, бизнес-аналитики, а также для приложений бизнес-аналитики.

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

В попытке удовлетворить потребности компаний различного размера, Oracle Database в настоящее время доступна в версиях Enterprise Edition, Standard Edition, Express Edition и Oracle Lite. Oracle Database работает на всех основных платформах, таких как Windows, UNIX, Linux и MacOS. Его самым большим традиционным конкурентом был популярный Microsoft SQL Server.

Что такое PostgreSQL (Postgres)?

PostgreSQL, широко известный как Postgres, — это система управления объектно-реляционными базами данных с открытым исходным кодом. Он был написан на языке C и разработан командой разработчиков-добровольцев. PostgreSQL не поддерживал SQL до 1994 года и изначально требовал, чтобы QUEL запрашивал у него данные, что делало его далеко не идеальным.Но с тех пор все изменилось.

Знаете ли вы?

Лицензия PostgreSQL — это свободная лицензия с открытым исходным кодом. Вы можете свободно использовать, изменять и распространять PostgreSQL в любой форме.

PostgreSQL пошел по пути открытого исходного кода в 1996 году, после чего была добавлена ​​полная поддержка SQL. Теперь он поддерживает все функции СУБД с добавлением других функций, таких как представления, хранимые процедуры, индексы и триггеры, в дополнение к функциям первичного ключа, внешнего ключа и атомарности.

Функциональные возможности этой системы могут быть расширены пользователями путем изменения существующих функций, добавления новых функций и свободного распространения. Он работает на основных платформах, таких как UNIX, MacOS, Windows, Linux и т. Д., При этом поддерживая программные интерфейсы для таких языков, как C / C ++, Java, Python, Perl, а также возможность подключения к открытым базам данных.

PostgreSQL управляет параллелизмом с помощью Multi-Version Concurrency Control (MVCC), который дает каждой транзакции «снимок базы данных», позволяя вносить изменения, не затрагивая другие транзакции.Это устраняет необходимость в блокировках чтения, гарантируя, что база данных поддерживает принципы ACID.

PostgreSQL против Oracle: разборки

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

1. Соотношение цены и качества — PostgreSQL
   Oracle — коммерческое решение с довольно высокими ценами и дополнительными платежами, необходимыми для дополнительных функций. PostgreSQL легко подтверждает это сравнение, поскольку приобретение, установка и поддержка совершенно бесплатны. Сам по себе этот фактор может оказаться решающим, когда речь идет о малых и средних организациях.
2. Поддержка — PostgreSQL
   Еще одна победа для решения с открытым исходным кодом.PostgreSQL имеет чрезвычайно активное сообщество, где можно легко найти исправления, настройки, обновления и многое другое. Даже ответы на вопросы, возникающие при установке или обновлении, можно легко найти с минимальными задержками. Это не относится к Oracle, где поддержка стоит денег.

   Крупные организации, которые решили внедрить PostgreSQL, также могут выбрать платных специалистов по поддержке, чьи услуги обычно дешевле, чем их коллеги из Oracle.

3. Функциональные возможности — Oracle
   База данных Oracle отступает благодаря многолетнему опыту и высокому уровню знаний в области разработки.Он не только обеспечивает больше транзакций в секунду, чем PostgreSQL, но и, возможно, обеспечивает более высокий уровень безопасности. Однако следует отметить, что многие функции безопасности Oracle требуют дополнительных затрат.

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

   PostgreSQL не сутулится в функциональности. Он предлагает три уровня изоляции транзакций: фиксированное чтение, повторное чтение и сериализуемый.Он невосприимчив к грязному чтению. Запрос уровня изоляции транзакции «Чтение незафиксированных» вместо этого обеспечивает фиксацию чтения. PostgreSQL поддерживает полную сериализацию с помощью изоляции сериализуемых моментальных снимков (SSI).

4. Масштабируемость — Draw
   Хотя оба решения вполне подходят для этой категории, PostgreSQL обладает преимуществом благодаря своим характеристикам открытого исходного кода. Он не только намного легче Oracle, но и не требует дополнительных затрат на расширение инфраструктуры.PostgreSQL полностью поддерживает любой объем данных.
5. Совместимость — PostgreSQL
   Oracle имеет надежный язык в PL / SQL, однако PostgreSQL позволяет писать обработчики языков на нескольких языках (Python, R и т. Д.) Непосредственно в базе данных.

   PostgreSQL также явно имеет преимущество, когда речь идет о совместимости с операционными системами, что чрезвычайно важно в сегодняшних разнообразных и сложных средах разработки. FreeBSD, HP-UX, Linux, NetBSD, OpenBSD, OS X, Solaris, Unix и Windows совместимы с PostgreSQL, что является большим преимуществом.

Знаете ли вы?

PostgreSQL в настоящее время поддерживает 12 систем аутентификации, включая LDAP, Kerberos, GSSAPI, RADIUS, аутентификацию на основе пароля или даже на основе доверия.

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

Автоматизируйте свой PostgreSQL для достижения оптимальных результатов

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

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

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

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

Мир DevOps эволюционировал с одновременной работой нескольких платформ, языков и сред. Всесторонняя автоматизация стала необходимостью для безошибочной разработки и обеспечения соблюдения политик для согласования действий всех команд и баз данных. Устраните мошеннический код и конфликты прямо сейчас с помощью автоматизированного PostgreSQL!

ИНТЕГРИРОВАТЬ АВТОМАТИЗАЦИЮ В ВАШ POSTGRESQL И ВАШ ORACLE

Воспользуйтесь преимуществами PostgreSQL или Oracle, а также плавной автоматизацией выпуска для непрерывного цикла разработки.

MySQL против PostgreSQL — выберите правильную базу данных для своего проекта

Выбор системы управления базами данных обычно является запоздалым, когда начинается новый проект, особенно в Интернете. Большинство фреймворков поставляются с некоторым инструментом объектно-реляционного сопоставления (ORM), который более или менее скрывает различия между различными платформами и делает их все одинаково медленными. Использование опции по умолчанию (в большинстве случаев MySQL) редко бывает ошибочным, но об этом стоит подумать.Не попадайтесь в ловушку привычки и комфорта — хороший разработчик всегда должен принимать обоснованные решения среди различных вариантов, их преимуществ и недостатков.

Производительность базы данных

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

PostgreSQL, также известный как Postgres, позиционирует себя как «самая продвинутая в мире реляционная база данных с открытым исходным кодом».Он был построен так, чтобы быть многофункциональным, расширяемым и соответствовать стандартам. В прошлом производительность Postgres была более сбалансированной — чтение, как правило, было медленнее, чем у MySQL, но он мог более эффективно записывать большие объемы данных и лучше обрабатывал параллелизм.

В последних версиях различия в производительности MySQL и Postgres в значительной степени исчезли. MySQL по-прежнему очень быстро читает данные, но только при использовании старого движка MyISAM. При использовании InnoDB (который допускает транзакции, ключевые ограничения и другие важные функции) различия незначительны (если они вообще существуют). Эти функции абсолютно критичны для корпоративных или потребительских приложений, поэтому использование старого движка недопустимо. С другой стороны, MySQL также был оптимизирован для уменьшения разрыва при записи больших объемов данных.

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

Преимущества Postgres над MySQL

Postgres — объектно-реляционная база данных, а MySQL — чисто реляционная база данных. Это означает, что Postgres включает такие функции, как наследование таблиц и перегрузка функций, которые могут быть важны для определенных приложений. Postgres также более строго придерживается стандартов SQL.

Postgres обрабатывает параллелизм лучше, чем MySQL, по нескольким причинам:

Postgres реализует Multiversion Concurrency Control (MVCC) без блокировок чтения
Postgres поддерживает планы параллельных запросов, которые могут использовать несколько процессоров / ядер.
Postgres может создавать индексы неблокирующим образом (с помощью синтаксиса CREATE INDEX CONCURRENTLY ) и может создавать частичные индексы (например, если у вас есть модель с мягким удалением, вы можете создать индекс, который игнорирует записи, помеченные как удалено)
Postgres известен тем, что защищает целостность данных на уровне транзакций.Это делает его менее уязвимым для повреждения данных.

Установка по умолчанию и расширяемость Postgres и MySQL

Установка Postgres по умолчанию обычно работает лучше, чем установка MySQL по умолчанию (но вы можете настроить MySQL для компенсации). MySQL имеет некоторые откровенно странные настройки по умолчанию (например, для кодировки символов и сопоставления).

Postgres очень расширяемый. Он поддерживает ряд расширенных типов данных, недоступных в MySQL (геометрические / ГИС, типы сетевых адресов, индексируемый JSONB, собственный UUID, временные метки с учетом часовых поясов).Если этого недостаточно, вы также можете добавить свои собственные типы данных, операторы и типы индексов.

Postgres действительно имеет открытый исходный код и управляется сообществом, в то время как MySQL имеет некоторые проблемы с лицензированием. Он был запущен как продукт компании (с бесплатной и платной версиями), и приобретение Oracle AB в 2010 году вызвало у разработчиков некоторые опасения относительно его будущего статуса открытого исходного кода. Однако существует несколько форков оригинального MySQL с открытым исходным кодом (MariaDB, Percona и т. Д.), Поэтому в настоящее время это не считается большим риском.

Когда использовать MySQL

Несмотря на все эти преимущества, у использования Postgres все же есть некоторые небольшие недостатки, которые вам следует учитывать.

Postgres по-прежнему менее популярен, чем MySQL (несмотря на то, что в последние годы догоняет), поэтому доступно меньшее количество сторонних инструментов или разработчиков / администраторов баз данных.

Postgres создает новый процесс для каждого нового клиентского подключения, который выделяет нетривиальный объем памяти (около 10 МБ).

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

Это лишь некоторые из факторов, которые разработчик может учитывать при выборе базы данных. Кроме того, поставщик вашей платформы может иметь предпочтение, например, Heroku предпочитает Postgres и предлагает операционные преимущества для его запуска. Ваш фреймворк также может предпочесть один другому, предлагая лучшие драйверы. И, как всегда, у ваших коллег может быть свое мнение!

Если у вас есть мнение о выборе базы данных, пожалуйста, добавьте комментарий ниже — мы будем рады услышать ваше мнение. Если вам это понравилось, подпишитесь на нас в Twitter. Посетите наш канал на YouTube, где мы публикуем скринкасты и другие видео.

Доля рынка PostgreSQL и отчет о конкурентах

О POSTGRESQL

PostgreSQL — это система управления реляционными базами данных с открытым исходным кодом, разработанная всемирной командой добровольцев.

4,40%

Microsoft SQL Server	29908	17,97%	Microsoft
MySQL	25328	15.22%	Oracle
Microsoft Access	21360	12,83%	Microsoft
Oracle Database (RDBMS)	9,468	5,69%	Oracle
	NoSQL
MongoDB	5,770	3,47%	MongoDB
Табличный Microsoft SSAS	4,399	2. No related posts. Share : Добавить комментарий Отменить ответ Ваш адрес email не будет опубликован. Обязательные поля помечены * Комментарий * Имя * Email * Сайт