Выбрать субд между mysql, postgresql, mariadb и mssql? Сравнение MySQL и PostgreSQL Автоматическое восстановление после сбоев

А мне вот все лень сделать аналогичное. Только хотел проверить реальную базу на 300гигов. Поднять на скуле, на постгря, сделлать основные операции, типо проведения года, отмена проведения, тестирование и исправление со всеми галочками, бекапы, основные отчеты.
Но вот смотрю по заголовку вашей статьи и думаю - вау, круто... Теперь не надо париться, вот человек хороший сделал уже что то:) Открываю статью... Ан нет, все то же - бесполезные тесты, тема ни о чем, еще и в пдф, еще и аж 2 страницы... И даже без объяснения тестов... Ну хорошо, что они от гилева или нет? Т.е. в статье ничего не подняли, перенесли все в пдф? зачем? $m мало? Попросите - я вам перечислю. Но не надо таких вещей, с такими умными анонсами - делать так убого. Люди не правильно поймут.

Ну теперь по делу давайте:

Некоторые авторитетные товарищи прямо и недвусмысленно отказываются отвечать на вопрос: "Какая СУБД лучше?". Другие - менее авторитетные товарищи - говорят: "Только MS SQL Server принесет счастье в ваш дом". Третьи - уже совсем не авторитетные товарищи - несут в массы мнение об опенсорсе как единственном обладающем реальной производительностью железа ПО; а в продуктах Microsoft через строчку Sleep(random) понатыкано.

В целях выяснения - кто же прав - и была задумана эта статья. А поскольку каждое мнение должно быть аргументировано - было проведено сравнительное тестирование производительности для следующих продуктов:

Microsoft SQL Server 2008 R2
PostgreSQL для Linux
PostgreSQL для Windows

Круто:) Вот тут явно не хватает данных из пдф, так как если бы я тут увидел что вы все это разворачивали на XP, то я бы просто закрыл эту статью:) Далее веселее - виндовс x86, сервер 1с x64, эммм... ну ладно.

Если бы вы читали анонсы 1С, то вы бы увидели, что они ооооочень много нового сделали именно под MSSQL2012, т.е. вы заведомо сравнивали не пойми что с не пойми чем.

Про разные уровни изоляций систем - вы сказали вскольз, это улыбнуло. Давайте подумаем - почему 1С вешают на скуль в 99% случаях? верно - многопользовательский режим, блокировки и т.д., но вы сочли это мелкой задачей - на которую не стоит обращать внимание:)

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

З.З.Ы. Ставлю плюс авансом и надеюсь на более расширенный анализ.

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

Трудно найти организацию, в которой не используются бухгалтерские системы от 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С, где количество одновременно работающих пользователей – самый проблемный ограничивающий фактор, это замечательный результат, а главное, говорящий о том, что эти важнейшие российские прикладные системы могут не просто функционировать и без западных коммерческих СУБД, но даже делать это заметно лучше.

И сейчас встал выбор СУБД для хранения основных данных. Начинал разработку на MySQL, но сейчас не уверен в выборе. Переезд на другую СУБД на данном этапе для меня не составит проблем (использую PDO). далек от ясного понимания что такое «высокие нагрузки» для СУБД. Просто по моим расчетам примерно через год база будет весьма увесистой (см. ниже)

Основной выбор стоит между MySQL, PostgreSQL, MariaDB. Также, возможен, но не приветствуется вариант Microsoft SQL Server на Windows Azure

Ситуация такова:

1. Сложных запросов к базе нет. Максимум JOIN из двух таблиц
2. Бо льшая часть запросов - чтение
3. Есть одна самая важная и «главная» таблица (структура таблицы ниже под спойлером). Таблица будет расти примерно на 10-30 тысяч записей в сутки. Запись данных в эту таблицу - самое главное!
4. Бо льшая часть запросов на чтение будет как раз к «главной» таблице. По этой таблице будет осуществляться поиск по любому из полей (в крайне редких случаях ~0.5% - по нескольким сразу). Поиск должен осуществляться быстро (не смотря на пункт №3)
5. К «главной» таблице скорее всего будут добавлены индексы к каждому из полей сразу для двух полей (ownerID и Имя поля т.к. ownerID будет указан во всех запросах). Быстрый поиск будет нужен по любому из полей, но это не столь приоритетная задача. (Или лучше использовать Sphinx?)
6. Львиная доля запросов (~80%) на чтение к «главной» таблице - простые select"ы по индексам from и personalID с limit = 20. Остальные запросы по любым другим полям по индексам (которых пока нет) ownerID и Имя поля, также с limit = 20
7. Изменения данных в записях «главной» таблицы будут происходить крайне редко. Никакие записи из таблицы удаляться не будут.
8. Поддержка транзакций и внешних ключей не обязательна
9. Нужна возможность репликации данных типа master-slave
10. Возможность шардинга на уровне СУБД приветствуется
11. Крайне важна надежность БД (т.е. такой крах, как у MyISAM с ручным восстановлением сразу отпадает)
12. К «главной» таблице могут добавляться новые поля. Это конечно крайне редкое явление и далеко не самое важное требование, но добавление нового столбца к таблице размером с десяток ГБ для MySQL весьма длительный процесс, а выносить новые поля в отдельную таблицу очень не хочется
13. Всё это по-началу будет крутиться на таком вот выделенном сервере
14. Другие таблицы будут расти медленно, и обращения к ним будут достаточно редкими, за них я не переживаю. Часто обновляемые данные у меня крутятся в redis"e

Структура «главной» таблицы CREATE TABLE IF NOT EXISTS `clients` (`id` bigint(11) NOT NULL AUTO_INCREMENT, `personalID` int(11) NOT NULL, `ownerID` int(11) NOT NULL, `fromID` int(11) NOT NULL DEFAULT "4", `fromDomain` varchar(255) NOT NULL, `datetime` datetime NOT NULL, `status` int(11) NOT NULL DEFAULT "0", `paid` tinyint(1) NOT NULL DEFAULT "0", `paymentType` tinyint(4) NOT NULL DEFAULT "1", `wmSum` float NOT NULL DEFAULT "0", `wmCommission` float NOT NULL DEFAULT "20", `sysNumber` varchar(14) NOT NULL, `sysNumberLastUpdate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, `sysNumberStatus` varchar(250) NOT NULL, `timezone` float NOT NULL, `comment` varchar(500) NOT NULL, `countryID` int(11) NOT NULL, `postIndex` varchar(6) NOT NULL, `region` varchar(500) NOT NULL, `city` varchar(500) NOT NULL, `address` varchar(500) NOT NULL, `fio` varchar(500) NOT NULL, `phone` varchar(15) NOT NULL, `email` varchar(255) NOT NULL, `price` float NOT NULL, `quantity` int(11) NOT NULL DEFAULT "1", `label` varchar(30) NOT NULL, `tag` int(11) NOT NULL, `ip` varchar(15) NOT NULL, `referer` varchar(200) NOT NULL, PRIMARY KEY (`id`), KEY `from` (`ownerID`,`fromID`), KEY `paid` (`paid`), KEY `status` (`status`), KEY `label` (`label`), KEY `sysNumberLastUpdate` (`sysNumberLastUpdate`), KEY `personalID` (`ownerID`,`personalID`)) ENGINE=InnoDB DEFAULT CHARSET=utf8;

P.S. Желающих отправить меня гуглить прошу даже не отвечать. Найти информацию по сравнению актуальных версий разных СУБД мне не удалось, а изучать возможности, плюсы и минусы PostgreSQL, Microsoft SQL Server и MariaDB для человека, который с ними не работал весьма долгая задача. Да и в MySQL я далеко не эксперт, и подобный крупный проект для меня дело новое, да и возможности MySQL от версии к версии отличаются. Единственное, что я точно знаю, так это то, что таблицы типа MyISAM в MySQL мне точно не подойдут

• Вопрос задан более трёх лет назад
• 39571 просмотр

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

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С Предприятие и совместимо со многими СУБД, но по факту 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» (Уже на стадии записи, ждите, скоро!)

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