Реальный опыт использования postgresql на винде
☑
0
vfrcbv
20.10.15
✎
10:37
Всего мнений: 5
Добрый день.
Рассматриваем вариант установки на сервер win2012 postgresql для работы около 30 пользователей в БП 3.0, но так как практического опыта работы с данной СУБД нет, прошу опытных товарищей рассказать о проблемах с которыми возможно придется столкнуться? Насколько стабильно работает данная СУБД? Можно ли её рассматривать, как полноценную бесплатную замену mssql?
1
ildary
20.10.15
✎
10:44
Могу рассказать свой опыт — УТ11 3Гб, компьютер средней производительности (i5) вместе с сервером 1С, база лежит на SSD, скорость работы сначала была очень хорошая, за 3 месяца стала терпимой. Глюков postgree не было (9.2.4-1 x64). Будем пробовать под линуксом, на форуме недавно было обсуждение, что там скорость должна быть повыше.
Другое
2
Lama12
20.10.15
✎
10:52
Копии баз, не рабочую держим на постгри. Там порядка 50-60 развернутых баз. С настройками пришлось разобраться. По умолчанию СУБД настроена только на то, что б запуститься. После настроек, скорость работы с базой увеличилась в 5-10 раз.Фактически загрузка из dt шла сутки, а после настроек стала занимать 2-3 часа.
На винде глючит использование памяти если несколько экземпляров СУБД работают одновременно. Пока не планируем переходить на Linux, но если очень потребуется будем. Ищи ветку авторов изменений для 1С.
Да. В тестовых базах не более 3-4 пользователей одновременно работают и нагрузка, в основном, на чтение. Изменения там не делают. Поэтому настройки делали именно под такую нагрузку. И результат очень устраивает. Судя по параметрам, которые изучали, можно настроить и под высокую нагрузку записи. В общем — изучайте мануалы
Другое
3
mehfk
20.10.15
✎
10:55
(1) C MS SQL Express не пробовали сравнить?
4
Lama12
20.10.15
✎
11:01
(0) ИМХО. Как полноценную замену рассматривать можно. Как бесплатную — вряд ли. Она бесплатна как продукт, но для нормальной работы требует хорошей настройки и нормального администрирования. Для этого требуется дорогой админ. Решай сам. MS SQL можно не настраивать (под озвученную задачу). Администрировать может и студент.
5
ДенисЧ
20.10.15
✎
11:02
Главная проблема — найти панель задач — установка и удаление программ. Чтобы снести эту под(д)улеку
6
ildary
20.10.15
✎
11:08
(3) пробовали mssql express — не заметили сильного прироста (точнее postgree оказался быстрее, но с тех пор скорость postgree упала).
7
Гёдза
20.10.15
✎
11:09
на винде не работает префетч
8
Гёдза
20.10.15
✎
11:10
на кб лежит статья по настройке
9
cw014
20.10.15
✎
11:10
Ставили УПП
Отрицательный
10
Гёдза
20.10.15
✎
11:12
ЗУП 2.5 точно не работает на постгре
11
Маратыч
20.10.15
✎
11:12
(9) Кстати, да, какой-то релиз УПП вообще взлетать не хотел на постгри.
12
Маратыч
20.10.15
✎
11:13
+(11) А еще (тоже какой-то релиз) УПП на оракле взлетал только после лютых плясок с бубном. В общем, стопроцентно поддерживается только MS SQL и нативная файловая БД.
13
stix2010
20.10.15
✎
11:14
на дефолтных настройках БП3 может и не взлететь
14
zak555
20.10.15
✎
11:15
БП 3.0 на сервере 2012 — 5 юзеров
БП 3.0 на винХР — 5 юзеров
сервер 1С — минисервер, БД постгрис
тормозов нет по сравнению с файловым вариантом
Положительный
15
thargon
20.10.15
✎
12:30
У одного клиента на БП 2.0 опыт был отрицательный (иногда вылезала адская проблема при обновлениях), но если верить документации — проблема была из-за 32-битного постгреса. Если железо и ОС позволяет поставить x64 постгрес — то использовать можно.
Другое
16
thargon
20.10.15
✎
12:32
+(15) у другого клиента архивная копия УТ 10.3 крутится под постгресом (продакшен под MS SQL) — проблем нет. Давным-давно, когда только появилась поддержка постгреса в платформе, этот вариант тестировали и все дико тормозило, но через какое-то время поддержку допилили до нормального состояния и вариант оказался рабочим.
17
mikecool
20.10.15
✎
12:32
(0) при грамотном админе(довелось с таким работать) под постгри на винде крутилась упп без упр блокировок(2007 год) с 70 пользователями
блокировки были очень редки
но постгри настраивался наверное с неделю
18
stix2010
20.10.15
✎
12:43
(15) Кстати да, использовать только 64 бит, столкнулся с конфой, в которой в макетах лежали бинарные данные, в итоге cf в 32 битном не загружался в базу.
Postgres — это мощная и надежная система управления базами данных, которую многие предпочитают использовать в своих проектах. Однако, если Вы планируете запускать Postgres на операционной системе Windows, то, возможно, Вам стоит задуматься о другом варианте. В ролике расскажем, почему использование Postgres на Windows может быть плохой идеей.
Таймкоды:
00:00:00 Вступление
00:00:10 Файловая система
00:00:53 Сравнение Linux и Windows
У Вас остались вопросы по теме? Свяжитесь с нами:
Ответим на все вопросы, свяжитесь с нами:
8 (8142) 67-21-20 или 8 (8142) 79-88-87
promo@neosystems.ru
______________________________________________________________________________________
Будьте в курсе всех новостей и акций!
Подпишитесь на нашу новостную рассылку и получайте свежие новости и специальные предложения первыми
Специальное предложение для пользователей базовых версий 1С — прямо сейчас Вы можете перевести свою программу на новые выгодные условия использования и в этом вам поможет облачный сервис 1С:Fresh
Акция действительна до 31 декабря 2024 года
Подробнее
Потому что Google Sheets.
Первоначально PostgreSQL назывался POSTGRES, ссылаясь на свое происхождение как преемника базы данных Ingres, разработанной в Калифорнийском университете в Беркли
В свою очередь «Ingres была создана как научно-исследовательский проект в Калифорнийском университете в Беркли в начале 1970-х годов.»
Я же познакомился с этой СУБД в середине 80-х годов. СУБД Ingres входила в состав операционной системы МОС ЕС, советского клона операционной системы Unix для ЕС ЭВМ. При чем она работала и на больших машинах и на персоналках ЕС18xx. И мы тогда тоже пропагандировали постулат одной ОС (Unix) и СУБД Ingres:
Я присоединяюсь к словам автора:
я никого не сбиваю с толку, предлагая пользоваться
Postgres
К ним стоит прислушаться.
есть клон mysql не от оракла, называется mariadb и думаю большинство уже mariadb используют. у mysql есть киллер фича — там сильно круче ядро, сторидж енжин не один (и они легко подключаются) и главное — реализован UNDO log в стиле оракла. в результате нет vacuum и апдейты на таблицы с индексами не так бьют производительность. почитайте историю Uber, они очень подробно расписали проблему и почему они свалили на mysql. когда-то постгрес пытался UNDO log реализовать, но говорят Zheap инициатива сдохла, потому что в постгрес сторидж енжин прибит гвоздями и как у mysql не подменить.
но с другой стороны у mysql как-то криво реализовано чтение, похоже у них нет понятия латча и при апдейте всего одной строки на таблицу без индекса, он врубает full scan который блокирует нафиг всю таблицу. плюс у mysql сильно хуже оптимизатор.
Если брать профессиональные базы за деньги, то MSSQL вне конкуренции. А в нашей специфике конечно мне, как спецу по MSSQL одна дорога, на теплотрассу
Мне вот недавно потребовалось сделать на mssql аналог intarray из postgres. Это когда в колонку пишется массив int-ов, и дальше можно фильтровать выражениями типа (1|3)&4&5. И мы расшибли лоб, и так ничего вменяемого и не придумали.
Важна не эта конкретная задача, а то что в mssql если чего-то нет, то это даже сколхозить не из чего: типы данных не добавить, даже массив положить в колонку не во что, и передать в функцию нельзя. T-SQL — просто издевательство, а альтернатив нет. Что-то можно изображать на CLR, но облачные mssql в него не умеют.
И вроде вот они данные, лежат в правильных b-tree как надо, алгоритмы понятно какие надо сделать. Но подлезть не дают.
Обидно даже за нее — т.к. на низком уровне она хорошо сделана.
Мне недавно понадобилось на Феррари перевезти картошку, как я делал это на Жигулях, но не получилось. Чтоб я не делал.
Хотя и там и там ТС. И там и там передвигаться предназначено. Но объективно по разному сделано(хотя в основе мотор и колеса).
Не понятно зачем сложности такие, но ок. В MsSQL есть пользовательские типы — реализуй любой. В MsSQL есть расширенные процедуры — создавай свою логику над данными.
Ну по сути как и в постгре. Никто не обещал хранить и обрабатывать «любые данные» (хотя для них есть двоичные типы/поля или даже filestream). Мне вот постгря не нравится после перехода с MsSQL, там неудобно, тут избыточно, там кавычки одинарные/двойные не забывай писать, там тип неудачный. Но потихоньку вкатываюсь и где-то привыкаю к «неудобству», где-то улыбаюсь от «красивой» фичи, а где-то использую не замечая разницы концептуальной.
Зы: но администрирование постгри — это дичь. Там где MsSQL из коробки работает на 100%, постгрю настраивать/подстраивать для тех же результатов (на одной ОС/машине). Но это дело привычки и навыков.
Да, я вот слышал что для бэкапа нормального (не костыля в виде pgdump) надо на Постгре собирать кластер и делать холодный бэкап и на второй ноде
При этом не забыть скопировать все файлы. Потому что симлинки могут ввести в заблуждение. И про то, что бэкап неполный, вы не узнаете до момента, когда обратитесь к таблице, которой не повезло
Зы: но администрирование постгри — это дичь. Там где MsSQL из коробки работает на 100%, постгрю настраивать/подстраивать для тех же результатов (на одной ОС/машине). Но это дело привычки и навыков.
Отчасти это «заслуга» академического прошлого базы, пошедшей от проекта университета Беркли, как написали выше, а отчасти от Unix way. Когда я первый раз узнал, что каждая таблица в PG это 3-5 файлов (Карл!), после оракл где все таблицы можно упаковать в 1 файл и настроить их так, чтоб фрагментация была минимальна, у меня глаза на лоб полезли. Понятно, что сейчас в SSD разница в доступе сильно нивелировалась, но раньше на хардах, это ж какой ад наверное был!
Примерно то же самое с настройками — база из коробки преднастроена так, чтобы запуститься на любом тапке, ни о какой производительности речь совершенно не идет, когда ставят такую цель. И да, много чего надо покрутить в конфиге, чтоб оно нормально заработало
А я вот наоборот, при работе с мускулом, если есть такая возможность, включаю режим innodb_file_per_table. Потому что когда у вас innodb упадёт, а она упадёт по питанию или ещё как, снести table_storage для одной таблицы с каким-нибудь журналом будет сильно быстрее и проще, чем двое суток вытаскивать данные из одного гигантского файла (я уж молчу про разделы, хотя оно и такое умеет, вообще без ФС)
Обычно постгресу ставят в минус тот факт, что он работает с файлами исключительно поверх ФС, не занимается самостоятельно кэшированием и т.д. Но почему-то забывают про жирнющий плюс от этого решения.
В постгре и оракл после падения по питанию обычно достаточно запустить базу — она сама восстановится если wal/redolog файлы целые. Но ведь если мы пишем через операционку, она ведь гарантирует что всё честно записано на диск, правда-правда (fsync, и всё такое)?
С файлами обычно приходится возиться когда уж совсем всё пошло не так.
Когда я первый раз узнал, что каждая таблица в PG это 3-5 файлов (Карл!), после оракл где все таблицы можно упаковать в 1 файл и настроить их так, чтоб фрагментация была минимальна, у меня глаза на лоб полезли. Понятно, что сейчас в SSD разница в доступе сильно нивелировалась, но раньше на хардах, это ж какой ад наверное был!
а как одно зависит от другого? Диск это блочное устройство, он про файлы ничего не знает. Даже если у вас 1 файл на все таблицы, то скорее всего там есть выравнивание по размеру блока или даже кратно ему. Единственное на что влияет количество файлов в директории это на время операции ls
Как это не влияет? Допустим у нас full scan. Тогда если 1 файл и небольшое число экстентов на таблицу (косвенно зависит от свойств таблицы — сколько места добавлять когда оно кончается), то имеем последовательное чтение. А если записью в таблицу/файл ведает операционка, то получим кучу раскиданных по диску блоков. и полное чтение файла выльется в рандомный доступ к диску, что для HDD сильно медленнее.
Понятно что пример несколько утрирован, но если уж нам по каким-то причинам нужен fullscan (аналитику например делаем), то и так запрос будет не быстрым, а мы его еще дополнительно кратно замедляем.
1 файл может быть фрагментирован больше, чем 3 отдельных файла.
1 файл создается сразу нужного размера (условно «пустой») и в дальнейшем если нет опции autoextend не ресайзится
Хорошо, если с фулскан пример так себе, то допустим нам надо прочитать 1 строку. В оракле мы прочитаем 1 блок диска — 1 чтение. В постгре в каких-то случаях на придется прочитать данные из 3 файлов — 3 операции чтения.
А если записью в таблицу/файл ведает операционка, то получим кучу раскиданных по диску блоков
Зачем операционке раскидывать блоки одного файла по диску? По-моему наоборот, она будет всеми силами стараться класть блоки этого файла на диск оптимальным образом: близко друг к другу и упорядочено, и еще дефрагментацию будет запускать время от времени. А когда у вас 1 огромный файл, который содержит в себе все сразу — то такую дефрагментацию придется делать самой базе. Т.е. На уровне базы надо придумывать алгоритмы дефрагментации и работать с диском напрямую. Наверно можно извлечь плюсы, но и кактус надкусить тоже возможно.
Хорошо, если с фулскан пример так себе, то допустим нам надо прочитать 1 строку. В оракле мы прочитаем 1 блок диска — 1 чтение. В постгре в каких-то случаях на придется прочитать данные из 3 файлов — 3 операции чтения.
так и в оракле чтобы прочитать 1 блок с диска скорее всего придется читать еще какие-то другие блоки, чтоб понять откуда читать этот блок. В общем это уже все из разряда микробенчмарка и реальное влияние тут не спрогнозировать теоретически, потому что могут быть дополнительные побочные факторы.
Как-то я себе с трудом представляю операционку, которая в заботе о монолитности файла оставляет дыры в свободных блоках HDD или тем более что-то куда-то двигает. Главная забота операционки — транзакционное поддержание целостности файловой системы.
Дефрагментация файлов на серваке СУБД? Такая себе затея. И так диски база дрючит, а тут еще дополнительная нагрузка.
На самом деле наш спор в нынешнее время сугубо академический. С приходом SSD никто кроме контроллера не знает где физически живет блок и никто кроме контроллера его не подвинет.
свободное место конечно не оставит, это может сделать и база в принципе я думаю никто не мешает сделать схожий механизм работы с ораклом, просто в оракле один файл, а в постгресе 3 на каждую таблицу, а сам характер взаимодействия похожий. Я часто встречаю мнение, что 1 файл лучше чем 100, но в ситуации когда эти файлы большие, читаются произвольно и независимо — на мой взгляд разницы никакой в скорости нет, по этому за ваше утверждение зацепился.
Как-то я себе с трудом представляю операционку, которая в заботе о монолитности файла оставляет дыры в свободных блоках HDD
Это называется delayed allocation.
или тем более что-то куда-то двигает.
А это copy-on-write.
С приходом SSD никто кроме контроллера не знает где физически живет блок и никто кроме контроллера его не подвинет.
Я даже более скажу, современные СХД с WAFL или подобными приемами сами эффективно такие проблемы решают.
Согласен. Диалог носит скорее академический характер с целью разобрать тонкости баз/хранилищ
В PostgreSQL, таблица без индексов и out-of-storage полей — один файл. Out-of-storage — отдельный файл. Каждый индекс — тоже отдельный файл.
Если речь идет об одной физически первой записи таблицы без out-of-storage полей, то в и в Oracle, и в PostgreSQL это будет чтение одной страницы. Аналогично, при наличии out-of-storage полей, например, строки длинее 4000 байт (упрощенно, так как тут еще отдельная тема с TOAST, но мы ее опустим), в обоих СУБД потребуется чтение двух страниц. Ну и наконец, если запись с out-of-storage полем извлекается по первичному ключу и в индексе она оказалась уже в корневой странице индекса, то в обоих СУБД будет прочитано три страницы.
А количество файлов — это уже проблемы файловой системы. Собственно говоря, это и есть основная причина более медленной работы PostgreSQL под Windows (на NTFS), чем под Linux (на XFS или EXT4).
Что касается самостоятельного распределения страниц в едином файле, то тут у СУБД возможностей меньше, чем у файловой системы. Потому что она, в отличии от файловой системы, не имеет понятия, в каких экстентах (непрерывных участках) расположен файл. То есть, последовательно расположенные в файле страницы БД могут оказаться в разных экстентах, а файловая система не знает и не может знать, что они относятся к одной таблице. Тогда как если данные одной таблицы — отдельный файл, то файловая системе может оптимизировать их размещение, зная физическую структуру экстентов на диске. Для понимания, например, в NTFS, максимальный размер екстента всего лишь 2 МБ. То есть, на NTFS любой файл больше 2 МБ точно фрагментирован, как минимум, на два экстента и изменить это нельзя.
В PostgreSQL, таблица без индексов и out-of-storage полей — один файл
А как же карта свободного пространства и карта видимости? 1 таблица всё-таки 3 файла даже если нет TOAST. Хотя карта свободного пространства есть и в оракл (в системных таблицах кажется), так что чтений будет плюс-минус одинаково.
Что касается самостоятельного распределения страниц в едином файле, то тут у СУБД возможностей меньше, чем у файловой системы. Потому что она, в отличии от файловой системы, не имеет понятия, в каких экстентах (непрерывных участках) расположен файл.
Поэтому оракл создает файл нужного размера сразу, чтоб фрагменированность была минимальной. Есть конечно autoextent, но тут уж разработчику решать включать его или добавлять дополнительные файлы к tablespace
С другой стороны ФС совершенно ничего не знает про данные — какой прирост данных будет в файле, с какой интенсивность. А база знает если это ей сказал разработчик или если включен сбор статистики. Вроде ораклоиды призывали отказаться от ерунды вида ручного задания свойств таблиц, мол база умная, сама порешает, но что-то у меня сомнения.
А как же карта свободного пространства и карта видимости?
А они не нужны для вышеописанных трех сценариев выборки одной записи.
Поэтому оракл создает файл нужного размера сразу, чтоб фрагменированность была минимальной.
Я же указал выше, что фрагментированность всё равно будет. Причем сам Oracle даже не будет знать, где в файле заканчивается один экстент и начинается другой. И, тем более, ничего не знает о sunit и swidth, что весьма актуально уже для любого RAID, в том числе и на SSD.
С другой стороны ФС совершенно ничего не знает про данные — какой прирост данных будет в файле, с какой интенсивность.
СУБД тоже об этом мало знает. Обычно, только в рамках одной транзакции. Но и файловая система будет сбрасывать кеш на диск только после завершения транзакции и получения sync(), а лишь тогда аллоцировать место на диске под закешированные данные. При этом статистикой записи в каждый файл она тоже располагает, эвристически вычисляя allocsize в каждом случае.
Ну, в лоб бы я попробовал 2 варианта: кастомный дата тайп и свежую STRING_SPLIT. Потом, возможно, ещё «нормализовал» бы в COLUMNSTORE. Можно покопаться в сторону битовых масок.
А у вас @jakobz какие были итерации и что получилось в итоге? Просто интересно…
Что-то можно изображать на CLR, но облачные mssql в него не умеют.
Из-за безопасности, поди? SQLCLR всем хорош. Я бы даже сказал, это киллер-фича MS SQL. Но из-за секьюрных ограничений даже в локальной инсталляции с ним слишком много геморроя.
Я уже указывал выше, что из-за архитектуры MS SQL один процесс и множество нитей, уложить всю СУБД, CLR там легко и просто. При этом возможности python или rust в качестве процедурных языков PostgreSQL даже шире, чем у CLR.
Понятно, что бесплатного ничего не бывает. Зато можно удобно из триггера через OLE Automation сгенерировать отчёт по таблице и приаттачить блобом. Я так делал. Я даже управление всем этим хозяйством обобщил в виде таблицы с правилами. Люблю таблицы.
Не знаю, как с поддержкой чисто майрософтовских технологий типа OLE обстоят дела в питоне, но подозреваю, не так хорошо, как в дотнете. Кроме того, это просто очень комфортный способ писать процедурный код (хотя мне кажется, слово «императивный» тут подошло бы больше). Для меня — вообще самый. В первую очередь благодаря FCL.
Не знаю, как с поддержкой чисто майрософтовских технологий типа OLE обстоят дела в питоне, но подозреваю, не так хорошо, как в дотнете.
Точно так же, как .net через Win32 API и COM. И точно так же это не будет работать в любой операционной системе, отличной от Windows, как в ,net, так и в Python. Попытки сделать COM кросcплатформенным оказались безрезультатны, так что, если уж очень хочется аналогии с OLE/COM, сейчас лучше смотреть в сторону D-Bus, чем «откапывать стюардессу».
это просто очень комфортный способ писать процедурный код
Никто не запрещает использовать .net (С# или F#) в качестве процедурного языка PostgreSQL. Но, на мой взгляд, Rust в этих целях более предсказуемый из-за отсутствия GC.
https://github.com/Brick-Abode/pldotnet
Теперь и в постгрес
я бы не сказал. в техническом плане оракл с его UNDO log заметно красивей. mssql пишет версии строк от версионности в tempdb, который и так узкое место. ну и кластер RAC/Exadata. в техническом плане оракл пока красивей, но цена делает их обоих мало кому интересными вне облаков.
PostgreSQL как раз очень сильный конкурент MS SQL. «Вы просто не умеете его готовить» (c).
Я тоже спец по MS SQL с более чем двадцатилетним стажем. У MS SQL множество преимуществ перед PostgreSQL. Но верно и обратное. Одни только массивы и композитные типы (включая массивы композитных типов) многого стоят. CLR в MS SQL — костыль, которым легко можно уложить весь сервер. Например, только при создании кастомных агрегатов я нарывался на это несколько раз. Вызов кода на других языках через sp_execute_external_script и launchpad — медленный и не эффективный. А все по той причине, что MS SQL — один процесс с множеством нитей на все соединения, тогда как PostgreSQL выполняет fork() для каждого соединения, порождая отдельный процесс. Что и позволяет безопасно в этом процессе выполнять код на любом из множества процедурных языков. При возникновении критической ошибки упадет только форкнутый процесс и одно соединение, а не вся СУБД.
Это даже не говоря о намного более широких возможностях расширения PostgreSQL, по сравнению с MS SQL. Я бы сказал, что между MS SQL и PostgreSQL +-паритет. Что то проще и/или эффективней делается на первом, что то на втором. Но мне ещё не встречались случаи, когда что то запрошенное заказчиком можно было реализовать на MS SQL, но нельзя на PostgreSQL. И наоборот.
Так ведь эта особенность c процессами под подключение жесткий такой косяк postgres, разве нет? Настолько, что сам по себе сервер мало лишь кто юзает, всегда в связке с пулером?
До сих пор страдаем с лимитом подключений кластера, пытаясь распределить их между юзерами. В mssql с его потоками даже не задумывались о такой проблеме, про пул воркеров вообще узнал, когда полез разбираться, почему там в этом плане все тип-топ)
P. S. А, и бэкап только кластера целиком та еще фича)
Это не косяк, а идеология, позволяющая моментально вызывать хранимые процедуры на python, R, Rust и т.п. напрямую, а не через отдельный сервис launchpad, как в MS SQL, медленно и печально.
При этом пулер позволяет решить проблему с большими издержками на создание процесса, вместо нити. А проблему медленного выполнения sp_execute_external_script в MS SQL можно решить, только отказавшись от него в пользу CLR. Но уже с риском уложить всю СУБД и только через разработку и тестирование.
До сих пор страдаем с лимитом подключений кластера
Там еще проблема в том, что они не стали заморачиваться глобальным кэшем для prepared statement, а сделали это на уровне сессии (процесса), сразу выделяя под него место на старте процесса. Мало того что это оверхэд на подготовку запроса, так еще оно и памяти немало ест когда сессий много. Возможно, если у вас так много сессий, поможет уменьшение размера этого кэша (хотя решение довольно спорное, надо смотреть по ситуации)
У сиквеля крах треда тоже не кладет сервер.
Правильней, не всегда кладет сервер. Но если погуглите «An unhandled Microsoft .Net Framework exception occurred in sqlservr.exe», то найдете массу примеров.
> Я бы сказал, что между MS SQL и PostgreSQL +-паритет. Что то проще и/или эффективней делается на первом, что то на втором.
Я начинал писать подобный вашему ответ и решил стереть, потому что не умею всё сразу и по полочкам. Со своей колокольни сравнивал бы как винду и линукс — всё те же непримиримые стороны, всё та же суть где одно лучше для одного, другое для другого и также стандартами от первого нельзя подходить ко второму и наоборот.
Тем не менее я согласен с тем кому вы отвечаете, что спецу с МССКЛ может быть тяжело переключиться на ПГ, если подходить к нему со своей привычкой. То есть проще его смотреть с нуля и опыт МС поможет в некоторых вещах. Администрирование абсолютно разное, а вот квери в более половины случаев совпадают (при изменении синтаксиса).
спецу с МССКЛ может быть тяжело переключиться на ПГ
Кому как. Мне, в свое время, переходить с IDMS на ADABAS, или с ADABAS на DB/2 было намного сложнее, чем потом с DB/2 на MS SQL и с MS SQL на PostgreSQL.
В IT подобные переходы — дело обычное и к ним нужно быть готовым.
Администрирование абсолютно разное
В IDMS многие административные операции требовали макроассемблер или COBOL. После этого администрирование PostgreSQL меня уже никак напугать не могло. С другой стороны и в MS SQL я подавляющее большинство административных операций выполнял средствами T-SQL, а не GUI.
> в MS SQL я подавляющее большинство административных операций выполнял средствами T-SQL, а не GUI.
К этому все приходят, когда нужна гибкость
Да, сложно. Во времена версий PostgreSQL 9.4 я себя буквально заставил. Ни разу не пожалел.
Главным толчком послужила попытка поставить на нетбук с Atom на борту, «лёгкий» SQL Server Express. После 4-х часов установки, я понял, что даже в случае успеха, перестановка и трабл шутинг могут занять бесконечное время. И попробовал поставить PostgreSQL. Установка заняла 3 минуты. Таких стендов предполагалось сотня, выбор был очевиден.
Оракл купил mysql, чтобы убить её развитие. Поэтому сейчас mysql хуже postgre.
Оракл купил mysql чтобы залезть в другую лигу. Postgresql во многом копирует oracle, и, хотя вечно в роли догоняющего, является прямым конкурентом на рынке условного enterprise.
/*дальше сугубо мое субъективное мнение поскольку с mssql знаком слабо*/ Mysql же когда-то была «простой базой для сайтов», с тех пор много чего поменялось, но все равно как мне кажется она позиционируется как более простая СУБД без этих вот всяких заморочек.
Простите, а когда мускул был лучше постгреса? Во времена MyISAM?
Чисто по фичам это СУБД разных классов. Для личных бложиков это может и неважно, но для чего-то более серьёзного, где там появляются хранимые процедуры и т.п. — мускул отваливается.
С другой стороны, для совсем топовых вещей, ну там банков, не знаю, уже и постгреса не хватает. В оракле вы можете начать транзакцию на боевой базе, накатить миграции схемы, запустить тесты, и если не понравилось — через полдня сделать rollback. Если, конечно, железо вытащит, но тем не менее.
В MySql давным давно есть хранимые процедуры, а движок InnoDB — замечательный. Но Оракл уже 10 лет почти не развивает MySql.
Facebook и ВК сделаны на MySql. Были. Возможности упущены. Теперь уже нельзя рекомендовать MySql для серьёзных проектов.
Ах, ну да, oracle купил не мускул, а Sun, которой принадлежал мускул. Ну и «группа энтузиастов в красных шапках» сначала писала жалобы в ФАС и её аналоги в других странах, а потом резко сделала форк (MariaDB).
Вы ошибаетесь. Большинство используют MySQL. Вся суть MariaDB это страх что Oracle её закроет. На этом страхе они (контора что рулит MariaDB) и живут на весьма немалые деньги, ничего не привнося.
Рейтинги в сети есть. db-engines.com, как пример.
Автор свалил всё в кучу, пробежал верхами, местами ввёл в заблуждение и не сказал про действительно важные моменты. Прежде всего, СУРБД — это системы с очень широкой областью применения, они подойдут в большинстве задач. В то время, как остальные перечисленные системы — это более узкоспециализированные инструменты, которые обычно требуются для решения специфических проблем. Кроме того, PostgreSQL требует намного меньше ресурсов, чем например MongoDB или Datomic. Кстати про Datomic, это графовая СУБД, а не реляционная.
Сравнивать и не упоминать https://jepsen.io/analyses ?
у неё нет каких-то невероятных скрытых преимуществ
Для MySQL существуюет galeracluster и percona xtradb cluster. Они при помощи galera replication позволяют сделать multi-master. Что позволяет получить очень простую и эффективную отказоустойчивость с нулевым временем фейловера про потере одной из баз — достаточно просто воткнуть перед кластером балансер, типа хапрокси. И никаких проблем с улетевшими не на ту базу запросами — в мульти-мастере они просто спокойно выполнятся.
Для postgresql похожий уровень отказоустойчивости можно получить, только применяя всякие сложные сторонние решения. Для сопровождения которых, по моим ощущениям, потребуется отдельный DBA, глубоко разбирающийся в вопросе.
Для Percona XtraDB используем ProxySQL в качестве балансировщика. А там уже правила + кеш и прочее.
Я слышал, что на PostgreSQL жалуются девопсы, мол там сложнее её обслуживать чем Oracle или MsSQL. Хотелось бы конкретики, чем бесплатный PostgreSQL, хуже платных «ынтэрпрайз» решений, и если это незначительные вещи, тогда совет имеет смысл.
Если платные решения покупают, то значит это зачем-то нужно. Но вот хотелось бы понять, это из-за моды или же есть реальный случаи когда платные версии нужны.
Платные версии в первую очередь приобретают из-за технической поддержки
Я не девопс, но немного разобрался в этой теме. Поправьте если пишу ерунду.
Автовакум в постгресе иногда вызывает проблемы схожие со сборкой мусора, это в случае множества апдейтов рядов.
Насколько я понял чтобы обновить постгрес по сути база реимпортируется, там все завязано на бинарных форматах, без даунтайма почти никак. Может уже нерелевантно. В Мариадб просто ставишь новую версию и она работает со старым журналом.
В Постгресе надо коннекшены пулить, как и в Оракле. В Маридб и Мускуле это делать необязательно, те проблем с этим нет.
В мускуле и марии индексы создаются автоматически на форейн ки. В постгресе это надо делать руками.
Постгрес в моем бенче был на 40% быстрее при вставке чем Мария. Мария была на 10% быстрее в чтении. Возможно где-то это важно.
В Марии Мускуле нет схем и прочих пермишеннов, в каком-то смысле тикетов к девопсам с запросом прав будет меньше. Им проще.
В Постгресе есть 1 сторадж энжин. При супербольших таблицах в оракле марии и мускуле можно выключить транзакции и какие-то фичи и получить около 2.5х прибавку к производительности.
В мускуле и марии вроде бы как лучше тулинг для репликации по сравнению с пг. Уж то что он более старый и проверенный сомнений нет.
доступ к которой выполняется через границу сети.
может, пограничные сети?
Автор может ответить почему не ClickHouse
Если серьезно — там специфичный SQL, в котором например не работают correlated subquery. Но с другой стороны там работает много другого всего. Всему своё применение вобщем.
Я думаю, потому что речь была о OLTP, а не OLAP. Достаточно один раз сунуться в CH с INSERT/UPDATE по одной записи, чтобы понять, что для такого профиля нагрузки он совершенно не пригоден.
Ну и columnstore и join плохо совместимы по определению. Из-за чего в CH приходится дублировать массу полей в таблицах, что ставит жирный крест на консистентности.
При работе с реляционной базой данных можно перейти от получения всех домашних питомцев человека к получению всех владельцев домашнего питомца, добавив в таблицы один-два индекса.
Скорее не индекса, а внешних ключа.
Внешние ключи никак не влияют на производительность выборки данных. Это вид ограничения. А вот индексы действительно позволяют избежать сканирования данных. А иногда вообще исключить обращение к страницам данных.
Внешние ключи никак не влияют на производительность выборки данных
Я где-то утверждал обратное?
Смотрите внимательно: есть таблица, содержащая виды (типы) домашних питомцев. Всё верно? В оригинале:
можно перейти от получения всех домашних питомцев человека
Есть таблица владельцев домашних животных. В оригинале:
перейти … к получению всех владельцев домашнего питомца
Таблица: Владельцы Таблица: Домашние Животные
+----+------------+ +----+------------+------------+
| ID | Имя | | ID | Вид | Владелец_ID|
+----+------------+ +----+------------+------------+
| 1 | Иван | | 1 | Кошка | 1 |
| 2 | Анна | | 2 | Собака | 1 |
| 3 | Ольга | | 3 | Хомяк | 2 |
| 4 | Павел | | 4 | Попугай | 3 |
+----+------------+ +----+------------+------------+
Получить владельцев домашних питомцев можно создав реляцию между этими двумя таблицами. И индексы здесь не при чём.
Нам нужно ключевое поле, на которое можно ссылаться и индекс по нему может быть вообще не построен. И внешний ключ. Строго говоря, внешний ключ тоже не обязателен. Но для целей самодокументирования и обеспечения ссылочной целостности — крайне желателен.
Вот и получается, что Вы не поняли о чём идёт речь, но минус влепили.
Всё верно?
Нет, так как фраза «к получению всех владельцев домашнего питомца» уже подразумевает, что у домашнего питомца могло быть несколько владельцев.
Получить владельцев домашних питомцев можно создав реляцию между этими двумя таблицами.
Между тремя. Таблицами. Вот только реляция далеко не всегда обозначает ограничение внешним ключом.
И индексы здесь не при чём.
Индексы позволяют избежать сканирования таблиц.
Теперь пример. Почти из жизни.
CREATE TABLE owners (
Id integer NOT NULL,
Valid daterange NOT NULL, -- период действия записи
Name varchar NOT NULL, -- человек может сменить имя
CONSTRAINT owners_PK_idx
EXCLUDE USING GIST (Id WITH =, Valid WITH &&)
);
CREATE TABLE pets (
Id integer NOT NULL,
Valid daterange NOT NULL, -- период действия записи
Name varchar NOT NULL, -- у питомца могут изменить кличку
CONSTRAINT pets_PK_idx
EXCLUDE USING GIST (Id WITH =, Valid WITH &&)
);
CREATE TABLE owners_to_pets (
Id integer NOT NULL,
Valid daterange NOT NULL,
own_id int NOT NULL,
pet_id int NOT NULL,
CONSTRAINT owners_to_pets_PK_idx
EXCLUDE USING GIST (pet_id WITH =, Valid WITH &&)
-- в конкретный период у питомца может быть только один владелец
);
Никакие внешние ключи сюда не прикрутите, хотя консистентность можно контролировать триггерами.
Выборка всех владельцев питомца возможна по индексу owners_to_pets_PK_idx без сканирования таблицы owners_to_pets. А вот для того, чтобы наоборот, найти всех питомцов владельца на конкретный момент времени без сканирования таблицы, потребуется еще один индекс, например:
CREATE INDEX owners_to_pets_reverse_idx ON owners_to_pets
USING GIST (own_id, Valid) INCLUDE (pet_id);
Нет, так как фраза «к получению всех владельцев домашнего питомца» уже подразумевает, что у домашнего питомца могло быть несколько владельцев.
Абсолютно согласен. Просто было лениво рисовать pivot таблицу. Но рад, что Вы наконец-то внимательно прочитали текст сообщения и даже потратили время на аргументацию. Жаль, что минус не отозвали.
Индексы позволяют избежать сканирования таблиц.
Каким образом это утверждение соотносится с утверждением автора:
При работе с реляционной базой данных можно перейти от получения всех домашних питомцев человека к получению всех владельцев домашнего питомца, добавив в таблицы один-два индекса.
Никакие внешние ключи сюда не прикрутите, хотя консистентность можно контролировать триггерами.
Да ладно?
CREATE TABLE owners_to_pets (
Id integer NOT NULL,
Valid daterange NOT NULL,
own_id int NOT NULL,
pet_id int NOT NULL,
CONSTRAINT owners_to_pets_PK_idx
EXCLUDE USING GIST (pet_id WITH =, Valid WITH &&),
-- в конкретный период у питомца может быть только один владелец
-- Внешние ключи
CONSTRAINT fk_owners
FOREIGN KEY (own_id)
REFERENCES owners(Id)
ON DELETE CASCADE,
CONSTRAINT fk_pets
FOREIGN KEY (pet_id)
REFERENCES pets(Id)
ON DELETE CASCADE
);
Держите внешние ключи. Но будет и без них работать, как я и написал выше. Просто просторечно поля вида own_id и pet_id называют внешними ключами, хотя внешние ключи могут быть и не построены.
Выборка всех владельцев питомца возможна по индексу owners_to_pets_PK_idx без сканирования таблицы owners_to_pets. А вот для того, чтобы наоборот, найти всех питомцов владельца на конкретный момент времени без сканирования таблицы, потребуется еще один индекс …
Я откровенно не понимаю, почему Вы прицепились к сканированию таблицы?
Поясняю, даже без единого индекса, СУБД найдёт искомые записи, уж как оно будет это делать, эффективно или нет, неважно. НАЙДЁТ!
А вот если выкинуть поля own_id и pet_id — НЕ НАЙДЁТ!
В оригинале не идёт речь о том, что можно получить всех владельцев домашнего питомца без использования seq scan. А о том, что их можно получить, добавив…
Вот на мой взгляд, добавив ключевые поля. А никак не индексы.
Жаль, что минус не отозвали.
Как я могу отозвать то, что не ставил?
Да ладно?
Хотя бы сами попробовали бы такие внешние ключи создать, чтобы полюбоваться на сообщение «ERROR: there is no unique constraint matching given keys for referenced table «owners»».
Там же по таблицам видно, что смена имени у владельца вовсе не влияет на принадлежность ему питомца. Так же как смена имени у питомца не влияет на принадлежность его владельцу. А смена владельца у питомца может быть без изменения имени питомца и имен прежнего или нового владельцев.
Поэтому нет и не может быть однозначного соответствия между записями owners и pets. Оно однозначно только для момента времени, но не для всего периода в owners_to_pets.
Я откровенно не понимаю, почему Вы прицепились к сканированию таблицы?
Потому что это первое на что смотришь в плане запроса. У меня в практике еще не попадались проекты, где допускалось сканирование таблицы, если данные в ней занимают больше, чем несколько страниц и выбираются единицы или доли процентов от общего количества записей.
В оригинале не идёт речь о том, что можно получить всех владельцев домашнего питомца без использования seq scan. А о том, что их можно получить, добавив…
Ну это лично Ваше восприятие. У меня оно противоположное. Я чуть ли не каждую неделю леплю Decline на PR именно из-за SeqScan в плане запроса. Даже по крошечной таблице из тысячи строк.
Как я могу отозвать то, что не ставил?
Прошу искренне извинить. Из контекста на Вас подумалось.
Потому что это первое на что смотришь в плане запроса
Так я ведь с этим и не спорю. Все знают, что seq scan на больших объёмах данных это нехорошо.
Ну это лично Ваше восприятие
Ну да. Это моё восприятие. Мне показалось, что автор имеет ввиду, что для поиска соподчинённых данных нужно всего лишь добавить ключевые поля. Даже своё восприятие аргументировал. А тут мне минусы лепят и рассказывают очевидные вещи о пользе индексирования. Я уж весь мозг изломал, что же я такого крамольного написал.
Хотя бы сами попробовали
О, и верно. Был не прав.
Внешние ключи никак не влияют на производительность выборки данных
Ну, смотря насколько «умён» движок — он может проверить первичный ключ во внешней таблице и если там пусто по фильтру, то тупо не пойдёт в запрашиваемую таблицу.
Я не понял о чем Вы. Приведите пример EXPLAIN ANALYZE для описываемого Вами случая.
Не, ну то, что автор первым делом начинает сравнивать сабж с SQLite, которая вообще не столько СУБД, сколько библиотека доступа к данным с SQL-синтаксисом — для многих читателей это будет сигналом закрыть статью и не открывать её больше. Да, ниже уже упоминаются Oracle и MS SQL Server, но до этого места надо ещё дойти. Понятно, что автор хотел упростить себе задачу (преимущества PostgreSQL перед SQLite, разумеется, показать, куда легче), но эффект, боюсь, для читателей, которые что-то знают про базы данных, получился прямо противоположным. Если бы сразу начать сравнение Postgre vs Oracle — статья бы выглядела более серьёзной.
Упоминание NoSQL-решений… Вообще, это крайне холиварная тема, но правильнее всего было бы упомянуть, что реляционные и нереляционные СУБД можно не противопоставлять, а сочетать. И в некоторых крупных проектах так и делают (если не ошибаюсь, про авито был такой доклад, и кажется, там PostgreSQL и упоминался, но это неточно). А так да, если человек не собирается делать миллионы транзакций в минуту и сразу тащит в рот NoSQL исключительно из соображений того, что он сэкономит время на проектировании структуры данных — он делает неправильно, тут соглашусь с автором.
Наконец, если кто-то затевает долгоиграющий проект с сильно более чем одним внедрением — ему стоит подумать над тем, чтобы сделать СУБД «сменной». У меня, например, есть опыт разработки проекта, где хранилище могло быть либо клиент-серверным (PostgreSQL), либо локальным (внутренняя СУБД — SQLite плюс выгрузка-загрузка в XML либо JSON, для пользователя локального варианта это выглядит просто как работа с XML-файлами), при этом по необходимости можно было легко перейти от одного варианта к другому, просто загрузив XML в PostgreSQL утилитой импорта. При этом порядка 90% SQL-запросов работали одинаково на обеих СУБД (кое-где таки пришлось сделать СУБД-специфичные ветки и то, главным образом, для оптимизации).
Я несколько раз пытался делать кросс sql решения. Всегда получалось не очень. Может руки не от туда… Согласен с тем, что sqlite очень крута тем, что она либа. Очень клёво бы было заиметь аналогичную реализацию postgres.
Слышал, какие-то чуваки скомпилили postgresql в javascript и запускали в браузере.
Wasm, все же, а не js. И компиляция идет в LLVM, а уже оттуда — в wasm. В некоторых случаях, через промежуточный asm.js.
Так, а самый главный конкурент MariaDB почему не упомянут? Там обещают и совместимость с оракловскими процедурами и какие-то другие фишки и совместимость с MySql с лучшим перформансом
Справедливости ради в MariaDB 11.4 добавлена возможность использования пакетов (CREATE PACKAGE) вне режима совместимости с ORACLE.
автор очень аккуратно не упомянул Firebird…
ваша шутка оч. могучая, конечно. Впрочем, если автор оригинального текста живет в США, то там — да, Firebird не имеет популярности. А вот в Бразилии, России, и ряде стран Европы — очень даже.
Firebird активно развивается. Другое дело, что по функциональности ему до PostgreSQL очень далеко. Если поддержку JSON/XML хотя бы обещают, то, например, про секционирование таблиц в нем я вообще не слышал, так сначала надо туда параллельные планы запросов завезти. Так что они просто пока в разных весовых категориях.
ну так и sqlite не в одном ряду с ораклом стоит… хотя и рядом в этой статье
Это уже, скорее, претензия к статье. Я вижу смысл сравнения PostgreSQL только с универсальными SQL RDBMS того же класса. Иначе невольно приходим к сравнению теплого с мягким.
Если вы видите, что студент или выпускник использует MongoDB, то остановите его. Ему нужна помощь. Его ввели в заблуждение.
Пожалуйста, ставьте плюсы статье и автору только за эту цитату, я вас прошу. Господи, наконец-то на хабре правда!
Ещё преимущество MSSQL, например, что T-SQL умеет бекапить в 1 файл и не было такого, что бэкап не полный или не работал. И он легко бэкапит на ходу. Но его подымет только текущая или любая последующая версия MSSQL. По мне хороший компромисс за предсказуемость и стабильность бекапов, про сравнению с PostgreSQL.
Смешались в кучу люди, кони…
Чем холодильник лучше микроволновки?
Полезная статья.
Действительно postgres сейчас развивается очень быстро и наверное совсем скоро навяжет конкуренцию oracle db.
1С и Linux
Пишу для себя, чтобы не забыть как делал. 95 % рабочее. На комментарии отвечаю, когда увижу.
суббота, 23 марта 2019 г.
Тест 1С и PostgreSQL Windows vs PostgreSQL Linux on Windows
Сравним на одной Windows 10 машине тест гилева(без настройки postgresql.conf)
с PostgreSQL, версия 10.5-24.1C
на Windows
с PostgreSQL, версия 10.5-24.1C на Linux на виртуальной машине vbox сервер 1с на Windows
На той же Windows машине 1C и PostgreSQL под Linux на vbox guest host на Windows
Тест расчета зарплаты на 3000 сотрудников (с оптимизацией postgresql.conf):
с PostgreSQL, версия 10.5-24.1C на Windows
Заполнить 317
Провести 215
с PostgreSQL, версия 10.5-24.1C на Linux на виртуальной машине vbox сервер 1с на Windows
Заполнить 465
Провести 371
На той же Windows машине 1C и PostgreSQL под Linux на vbox guest host на Windows
3. Заполнить 740
Провести 647
Провести и закрыть: 215
Короче миф не нашел подтверждения.
Посокольку не ставил целью сравнивать работу из под windows с нативным линуксом, не подготовил стенд, сравним с тем что было измерено ранее:
Более слабое железо, ниже частота процессора, SATA2
G2020
с настройкой postgresql.conf и без тж
Заполнить: 229 с
Провести: 222 с
1cfresh.com
Заполнить: 225 с
Провести: 260 с
i7-6700
1. Без настройки postgresql.conf и без тж
Заполнить: 156 с
Провести: 114 с
Вывод (сравниваем с G2020 более слабое железо):
1. под Linux (при установке Linux непосредственно на железо) система 1С + PostgreSQL работает минимум в 1,5 раза быстрее (скорее в 2), чем аналогичная на Windows.
2. Linux установленный поверх Windows на виртуальной машине (VirtualBox), даёт замедление работы 1С + PostgreSQL на Linux по сравнению с 1С + PostgreSQL установленной на Windows.
3. PostgreSQL установленный на Linux установленный поверх Windows (cредства виртуализации VirtualBox под Windows) даёт замедление работы 1С (Windows)+ PostgreSQL (Linux) по сравнению с 1С + PostgreSQL установленной на Windows.
Источник
Статьи / PostgreSQL: Linux VS Windows!
15.06.2018 г., перевод статьи JMG
В сентябре, по приглашению Dalibo, я был в Париже на Postgresql Sessions. Еще раз спасибо за приглашение! Это было событие, которое изменило мою жизнь!
Во время разговора с некоторыми сотрудниками Dalibo, один из них сделал замечание, которое я воспринял как внутренний вызов. Он сказал, что PostgreSQL на ОС Linux, запущенной в виртуальной машине на Windows, работает быстрее, чем PostgreSQL на той же Windows .
Поскольку я новичок в мире PostgreSQL/Linux, я был озадачен этой информацией, но когда я спросил точные цифры, у него их не было. Тогда я понял, что это была просто шутка (я быстро понимаю шутки, особенно со второго или третьего повтора), и что он просто имел в виду, что PostgreSQL на Linux работает быстрее, чем на Windows.
Архитектура Linux в сравнении с архитектурой Windows
Чтобы понять его заявление о скорости работы, нужно знать основное, в данном случае, различие в архитектуре между Windows и Linux.
Linux может использовать fork, а Windows – нет!
Но, что, черт возьми, это такое – fork? Если кратко, то fork – это системный вызов, который позволяет процессу создавать дочерние процессы, при этом продолжая работу параллельно с ними. Они могут делиться своей памятью и взаимодействовать друг с другом.Это стандартный метод разработки в среде Unix/Linux, но он не может быть применен в Windows. поскольку fork не существует в Windows.
Fork не поддерживается архитектурой Windows и, чтобы реализовать его функционал, нужно использовать потоки или платформу .NET с его async. Но если fork не существует в Windows, но команды PostgreSQL одинаковы и для Linux и для Windows, как это работает?
Разработчики PostgreSQL создали клиент для Windows, который эмулирует работу fork. с помощью потоков! Хвала им за это, потому что теперь у нас есть PostgreSQL на Windows!
Но вернемся к шутке. Предполагается, что из-за необходимости эмулировать fork, PostgreSQL в Windows работает медленнее, чем в Linux. Как и в случае с выражением «Pics or it didn’t happen! (пруф или не было!)», я жаждал получить доказательство этого утверждения. Единственным бенчмарком, который я смог найти, был тест, проведенный Red Hat. Некоторые могут сказать, что сравнение может быть предвзято из-за того, что его проводила Red Hat.
Ситуация
У клиента, с которым я сейчас работаю, инфраструктура полностью построена на Windows, и они планируют внедрять все больше и больше PostgreSQL, потому что. $ORACLE$!
Поэтому, прежде чем работать дальше с PostgreSQL на Windows при создании новых приложений, я бы хотел быть уверен, что это лучший вариант, и он соответствует моим требованиям:
- Он должен поддерживаться продолжительное время (в настоящее время мы работаем с системой, написанной в 1993 году, в тот момент, когда были выпущены браузер Mosaic и первый процессор Pentium! Поэтому, вполне возможно, новые приложения, которые мы создадим сегодня, будут работать и в 2037 году);
- Он должен быть надежным;
- Он должен быть эффективным.
Если нам необходимо перейти на Linux, то лучше сделать это сейчас, чем раньше, тем лучше.
Итак, по каждому пункту я сделал заключение:
- Оба семейства – и Windows и Linux уже существовали в 1993 году и поддерживаются до сих пор, что идеально подходит для меня (Windows NT и Slackware были запущены в 1993 году);
- PostgreSQL появилась в 1995 году, и многие пользователи работают с ней сейчас без каких-либо проблем. А недавно Gartner поставил PostgreSQL в лидеры квадранта, что также подтверждает его надежность;
- У меня не хватает информации, чтобы утверждать наверняка, что лучше – Windows или Linux.
Какой лучший способ сделать выводы об эффективности систем? Провести свой собственный тест!
Проведение теста
Для этого бенчмарка я хочу:
- Очень простой сценарий;
- Изолировать компоненты бенчмарка;
- Узнать, работает ли PostgreSQL в Linux быстрее/медленнее, чем в Windows с тем же клиентом (потому что я хочу протестировать сервер!);
- Быть как можно ближе к сценарию «реальной жизни»;
- Работу в облаке. Зачем? Потому что в облаке будет создано много будущих приложений. и у меня нет достаточной инфраструктуры дома, чтобы проверить это.
create table table_a( thread_id int, a_value int);
create index on table_a(thread_id);
insert into table_a(thread_id,a_value)
select * from generate_series(1,10) as thread_id ,generate_series(1,100000) as a_value;
Сервер Windows 2012 R2 на Amazon, тип m4.xlarge, со всеми настройками по умолчанию. Клиентское «приложение» состоит из 3 консольных приложений, каждое из которых запускает 5000 задач, доступных на github.
Каждая задача делает 1 выбор и 1 обновление случайной записи на table_a. Выходные данные приложения состоят из следующих результатов.
ApplicationId | Running Tasks | Task Duration | EndTime |
7fef1. c1 | 31 | 9530868 | 03:46:01 |
Значение Task Duration выводится в тактах, но я взял на себя смелость преобразовать его в секунды при анализе результатов.
Консольное приложение написано на C# и использует NPGSQL 3.0.3.
«Сервер Windows Postgresql» (далее – WS)
Сервер Windows 2012 R2 на Amazon, тип m4.xlarge, со всеми настройками по умолчанию.
Postgresql 9.4.5 установлен с помощью мастера.
Я изменил max_connections на 300, listen_addresses на * и внес необходимые изменения в pg_hba.conf для подключения к работе.
«Сервер Linux Postgresql» (далее – LS)
Amazon Linux AMI, тип m4.xlarge, со всеми настройками по умолчанию.
Postgresql 9.4.5, установленный с yum (мне пришлось немного погуглить эту часть, поскольку раньше я не делал этого).
Я внес те же самые изменения в postgresql.conf и pg_hba.conf, которые я делал для Windows.
Результаты
Для начала вот время, затраченное на создание таблицы:
Мой ноутбук
Запрос успешно возвращен: 1000000 строк обработано, время выполнения 14624 мс.
WS
Запрос успешно возвращен: 1000000 строк обработано, время выполнения 9374 мс.
LS
Запрос успешно возвращен: 1000000 строк обработано, время выполнения 3859 мс.
Такие результаты сбили меня с толку. Linux был определенно быстрее (и теперь мы видим, что мой ноутбук очень медленный, я не буду включать его в другие тесты).
Подробный разбор
Как я уже говорил, тест состоит из 15 000 задач, каждая из которых делает 1 выбор и 1 обновление случайной записи на table_a.
Во время выполнения теста на LS у меня возникло 8 ошибок «Тайм-аут при получении соединения из пула». Честно говоря, я ожидал, что в Windows будет больше ошибок, чем в Linux, однако это оказалось стереотипом, основанным на предположениях…
При возникновении ошибки во время выполнения выводится значение -1 для Task Duration, как показано ниже:
7fef1. c1 | 31 | 541229671 | 03:47:09 |
7fef1. c1 | 31 | -1 | 00:00:00 |
Исходя из этого я должен удалить эти 8 результатов из своего анализа. Также мне нужно удалить такое же количество выполненных задач из результатов WS. Я долго думал над тем, какие из них удалить, и не придумал ничего лучше, чем удалить их по медианному значению.
Server | Minimum | Maximum | Average | Median |
WS | 0,1093749 sec | 121,6842917 sec | 1,0363515 sec | 0,8280406 sec |
LS | 0,1249964 sec | 108,2615642 sec | 1,0234334 sec | 0,9374624 sec |
Итак, что мы можем предположить из этого?
На минимальных значениях WS был почти на 15% быстрее, но на максимальных – на 10% медленнее LS.
Среднее значение (Average Duration) WS на 1% медленнее, чем LS. Но, как говорится, если моя голова находится в духовке а мои ноги в холодильнике, то в среднем мне комфортно.
Из-за медианы, находящейся в половине результатов, и того факта, что у нас есть 14992 действительных результата (15000-8 ошибок), медиана равна результату № 7496.
WS на 10% быстрее, если учитывать только время; но если мы посмотрим на полные результаты, мне пришлось перейти к выполнению WS № 8543 с длительностью 0,93746 сек.
Таким образом, более 1000 раз команда на WS выполнялась быстрее, чем медиана на LS.
Время отклика и пропускная способность
Я не хотел анализировать трафик/пропускную способность, потому что чаще всего это бесполезно, особенно в отношении приложения, которое я сделал, и с учетом того факта, что я использую облако. Я считаю, что в этих условиях трудно производить точные замеры, каждый раз это будет похоже на Кота Шрёдингера.
Больше меня интересовало время отклика, поскольку я всегда помнил о прочитанном исследовании Якоба Нильсена, которое описывает влияние времени отклика на комфорт при работе с приложением:
- 0,1 секунда – предельное значение для того, чтобы ответ системы, полученный пользователем за это время, воспринимался бы как мгновенный, то есть не требующий никакой обратной связи для вывода результатов на экран;
- 1,0 секунда – предельная длина промежутка времени, в течение которого ход мыслей пользователя не прерывается, даже если он и замечает задержку. Обычно обратная связь не требуется, если задержки больше 0,1 и меньше 1 секунды, но пользователь уже не чувствует, что он работает непосредственно с данными;
- 10 секунд – предел, в течение которого пользователь сфокусирован на диалоге. Если задержки дольше, то пользователь начинает заниматься другими делами, пока дожидается окончания работы компьютера. В этом случае следует сообщить ему, что задача выполняется, но нужно немного подождать. Обратная связь во время задержки особенно важна, если время ответа может сильно изменяться, так как пользователи в этом случае не будут знать, какое время им следует ожидать.
Я предположил, что если БД (база данных) + веб-сервер должны ответить менее чем за 10 секунд, то половину времени я бы отдал БД, из чего следует:
Server | Выполнено быстрее чем за 5 секунд |
WS | 14913 |
LS | 14926 |
Разница между WS и LS составляет всего 0,001%.
Каждая операция в более чем 99% случаев выполнялась быстрее пяти секунд в обеих системах.
Давайте сложим все вместе:
Критерий | Windows | Linux | Победитель |
Количество задач | 15.000 | 15.000 | Одинаково |
Количество ошибок | 0 | 8 | Windows |
Минимальное значение | 0,1093749 sec | 0,1249964 sec | Windows |
Максимальное значение | 121,6842917 sec | 108,2615642 sec | Linux |
Среднее значение | 1,0363515 sec | 1,0234334 sec | Linux |
Медианное значение | 0,8280406 sec | 0,9374624 sec | Windows |
Выполнено менее чем за 5 секунд | 14913 | 14926 | Linux |
При проведении тестирования я использовал инфраструктуру Amazon, что, возможно, могло повлиять на полученные результаты. Это, кстати, всегда будет актуальным, если вы используете облако.
Более того, разницу в результатах можно отнести к статистической погрешности, ИМХО, но вы всегда можете оспорить это.
На основе полученных данных я не могу сказать, что PostgreSQL работает на одной ОС быстрее, чем на другой.
Для меня производительность PostgreSQL в Windows не лучше и не хуже, она одинакова с Linux!
Источник
Затраты на СУБД MS SQL и PostgreSQL:
В связи со стремительной девальвацией рубля, покупать СУБД Microsoft SQL стало очень дорого, а для некоторых компаний стоимость этих лицензий стала совсем «неподъемной». В данный момент чтобы развернуть сервер Microsoft SQL для 20 пользователей необходимо купить такие лицензии:
-
1 лицензия на операционную систему (WinSvrStd 2012R2 )
-
20 лицензий на подключение к серверу (WinSvrCAL 2012)
-
1 лицензия на сервер СУБД (SQLSvrStd 2014)
-
20 лицензий на подключение к СУБД (SQLCAL 2014)
Ориентировочная стоимость такого пакета 275 000 руб., что для компании, в которой всего 20 человек достаточно дорого. Данных затрат можно избежать, если создать сервер СУБД на свободном ПО. Поставить операционную систему семейства Linux и бесплатную версию СУБД – PostgreSQL. На таком сервере без проблем можно развернуть сервер 1С предприятия, а также другие роли, которые потенциально могут быть совмещены c ролью баз данных, например WebServer или файловое хранилище.
Так как использовать свободное ПО очень привлекательно с финансовой точки зрения, было решено проверить, на сколько это хорошо с точки зрения производительности.
Для выполнения теста было взято оборудование и программное обеспечение, указанное в таблице 1. Физический сервер для обоих стендов использовался один и тот же, менялось только ПО. Настройки обоих СУБД использовались по-умолчанию и в статье мы их подробно не расписываем. Дистрибутив PostGreSQL с соответсвующими патчами были взят с сайта компании 1С, версия – последняя из доступных на данном сайте.
Таблица 1. Тестовые стенды
№ |
Характеристики |
Стенд №1 |
Стенд №2 |
1 |
Операционная система |
CentOS 6 |
Windows Server 2012R2 |
2 |
СУБД |
PostgreSQL 9.3.3 |
Microsoft SQL Server 2012R2 |
3 |
Центральный процессор |
Intel Core i5 3330 (3.0 Ghz) |
|
4 |
Оперативная память |
24 GB DDD3 1333 Ghz |
|
5 |
Жесткий диск |
SSD 240 Gb Intel |
Для начала был выполнен «тест Гилева», который показал незначительное преимущество стенда номер 2, против стенда со свободным ПО.
Результаты смотрим ниже, разница в значениях получилась всего 3%.
Для информации: «тест Гилева» – популярный синтетический тест 1С, который выполняет ряд стандартных операций – чем быстрее тест выполняется, тем выше оценка. Оценка выполняется в условных единицах. Полученную оценку можно сравнить с прилагаемой к тесту шкале, которая покажет на сколько высока производительность текущей системы.
Рисунок 1. Результат теста Гилева. Стенд №2 СУБД MS SQL
Рисунок 2. Результат теста Гилева. Стенд №1 СУБД PostgreSQL
Далее решено было тестирование выполнить по методике APDEX. Суть метода заключается в измерении времени выполнения основных операций в 1С, замеры проводятся несколько раз на протяжении определенно периода времени. Далее полученный результат сравнивается с приемлемым временем выполнения той или иной операции.
Для этого взяли реальную рабочую базу одной из самых тяжелых конфигураций 1С, характеристики базы указаны в таблице №2.
Таблица 2. Характеристики тестовой базы
Конфигурация |
Редакция |
Объем базы |
Управление производственным предприятием |
1.3.57.1 |
16,3 Гб |
Замерялось время выполнения 7-ми стандартных операций с объектами в базе. Каждый тест выполнялся 10 раз и выводилось среднее значение. Замеры проводились с использованием толстого клиента через локальную сеть. Клиент устанавливался на рабочую станцию под управлением Windows 7. Тесты также пробовали запускать с клиента установленного на Ubuntu Linux, но он работал не стабильно и все тесты решено было выполнять только с клиента на Windows.
Таблица 3. Результаты APDEX
Ключевая операция |
Тип |
Время выполнения в секундах |
Отклонение |
|
Стенд №2 (MSSQL) |
Стенд №1 (Свободное ПО) |
|||
Открытие документа |
Заказ клиента |
0,348 |
0,617 |
77% |
Проведение документов |
Заказ клиента |
0,399 |
0,568 |
42% |
Проведение нового документа |
Документ объект: Заказ клиента |
0,185 |
0,205 |
11% |
Сформирован отчет |
Анализ доходов расходов |
0,733 |
1,022 |
39% |
Сформирован отчет |
Ведомость по партиям товаров |
4,104 |
4,912 |
20% |
Сформирован отчет |
Ведомость по товарам на складах |
0,316 |
0,508 |
61% |
Сформирован отчет |
Расчеты с клиентами |
0,200 |
0,334 |
67% |
В среднем наша реальная база при использовании 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, но зато не нужно платить за лицензии.
В конце 2017 года мы провели новые тесты и опубликовали их в очередной статье.
Ещё одним способом сэкономить при использовании 1С является решение – взять сервер 1С в аренду.