Комментарии 78
MS SQL Server недостаточно хорош для business critical? Или другая причина движения в сторону постгре?
MS SQL, конечно, достаточно хорош для бизнес-критикал систем, и многие компании его так и юзают.
Просто у нас так сложилось, что где-то MS SQL, а где-то — PostgreSQL.
У многих просто жаба
В целом замечателен. Только Enterprise лицензия больше $5к за ядро. А сейчас ядер в пухлом (и относительно недорогом!) сервере под сотню. А Enterprise нужен, если памяти >128ГБ (ёлы-палы, 128 ГБ это сейчас комфортный комп разработчка, а не сервер предприятия). И если двигаться в сторону микро- или хотя бы мини- сервисов, то лицензиями придётся покрывать несколько больших серверов.
В том числе и это.
Хотя часто Standard хватает+можно получить существенную скидку у партнёров при большой закупке.
И ещё вопрос сколько по деньгам обойдётся кастомизация открытого (не бесплатного!) решения и его сопровождение. На сколько стабильно и безопасно работают те или иные возможности. И в случае чего кому предъявлять притензию.
А если ещё использовать ORM, то при росте данных можно получить реальные проблемы в производительности.
Здесь очень хорошо эти и другие моменты описаны особенно в конце.
Добрый вечер из будущего
IIF в MS SQL это новодел (с SQL 2016), а так всегда был CASE. Ещё не описаны оконные функции, хотя они указаны для удаления дубликатов.
Все конструкции описать-цели такой не стояло.
Только самое часто встречаемое.
Много чего нет в материале, это так.
Однако, есть то, что встречалось часто при переводе нескольких проектов.
Т е материал создавался из опыта (не теории).
IIF тоже нужно было перенести-потому он и описан в материале.
CASE-выражение есть и в MS SQL Server, и в PostgreSQL.
Добавил CASE, чтобы не вводить путаницу
Годно, давно искал подобную статью, этот наверное самый подробный)
В "I. Регистрозависимое обращение к схемам, таблицам (представлениям) и их полям и другим объектам базы данных" - о квотировании сказано, а вот именно о регистрозависимости - ни полслова.
Не понял "V. Тернарный оператор IIF" - написано так, словно MS SQL не поддерживает CASE...
Также, помимо PL/pgSQL, в PostgreSQL можно встраивать и другие языки, такие как PL/Python и PL/Perl
А в MS SQL Server можно встраивать Python и R. Вроде R c 2016, а Python с 2017, если ничего не путаю.
А с 2021 еще и C# можно встраивать если не ошибаюсь
Дайте ссылку на доку
А разве с момента появления SQL Server 2016 нельзя создавать сборки на C#? https://learn.microsoft.com/ru-ru/sql/t-sql/statements/alter-assembly-transact-sql?view=sql-server-2016#b-adding-a-file-to-associate-with-an-assembly
На хабре была статья, где чел разработал тузлу для анализа БД, в том числе и для просмотра исходного кода сборок на C# https://github.com/skaeff/SqlRex
К сожалению не могу найти ссылку на статью на хабре.
Я занимаюсь переводом кода из MS SQL Server в PostgreSQL с начала 2019Интересно, возможно ли в этом случае программное конвертирование исходного кода? На самой первой своей работе я когда-то заглядывал в чужой исходный текст конвертера для программ на FORTRAN из операционной системы DOS/360 в OS/360. Конвертер был написан на ассемблере DOS/360. Различия FORTRANов были незначительными, но изменение большого количества текстов вручную было бы сложной задачей (нужно помнить, что это была еще эпоха префокарт). Кстати, сама система, для которой создавался конвертер, была довольно дурацкой и состояла чуть ли не из тысяч фортрановских подпрограмм. Для описанных различий диалектов SQL программное конвертирование кажется вполне реальным
Думаю вполне возможно. По крайней мере еще в ВУЗе была лаба по переносу (не всего конечно, но опять же основных конструкций) из VB.NET в C#.NET и наоборот с учетом вложенности типов. Потому здесь тоже можно причем со временем даже почти все переносить в обе стороны (ну что поддается переносу, т е если есть точное соответствие). Однако, на это уйдет очень много времени+постоянно что-то новое выходит.
Но судя по версии 1С очень старое решение, а новые фичи появляются чаще, чем раз в год. Так что в любом решении важно зафиксировать версии откуда и куда и чтобы они соовтетствовали тому, на чем будет решение применено.
В пункте "Регистронезависимое сравнение и поиск данных" наверное стоит упомянуть, что регистронезависимость сравнения будет зависеть от выбранного значения параметра Collation конкретной БД. Т.е. при значении Collation, например, SQL_Latin1_General_CP1_CS_AS, сравнение строк будет учитывать регистр (_CS - Case Sensitive), а также аксоны и диакритические знаки ('e' <> 'è', _AS - Accent Sensitive), тогда как при SQL_Latin1_General_CP1_CI_AI - нет.
Кстати, есть ли нечто подобное в PostgreSQL?
Сравнение производительности для 1С для конкретных задач проводилась ранее между MS SQL Server и PostgreSQL и ссылка дана на результат и о том как проводились тесты вначале публикации.
С Oracle сам не сталкивался, потому не могу ничего сказать по этому поводу.
Но Вы можете описать как тестировали и что получили в своей публикации.
Думаю это будет очень интересно и полезно.
А где можно почитать подробнее как настраивали обе СУБД, характеристики железа каждого сервера под СУБД (Вы же понимаете, что если обе СУБД на одном сервере, то нужно будет выключать ту СУБД, которую в данный момент не тестируете), настройки ОС (тут опять же нужно смотреть какая ОС лучше подходит под конкретную СУБД), настройки файловой системы и настройки системы ввода-вывода?
И полностью код теста для каждой СУБД тоже важно видеть.
Потому что в интернете много чего пишут, но по факту забыли что-то настроить должным образом и результаты получились ошибочными. В частности, часто забывают в Windows выключить индексирование диска, в следствие чего делают вывод, что в линуксе ФС быстрее на 40%. Если индексирование выключить, то получится примерно одинаково.
Потому важно полное и детально описание настроек и характеристик, и сам код для тестирования под каждую СУБД.
В первую очередь, PostgreSQL равняется на стандарт SQL, хотя не отказывается от своих расширений. То, что oracle гораздо ближе по синтаксису к стандарту, чем mssql (взять хотя бы конкатенацию строк - зачем выдумывать свой оператор), это, наверное, исторически сложилась из-за типичной для microsoft тех лет стратегии захвата рынка, а oracle развивался вместе со стандартами (или даже до них: взять хотя бы особый синтаксис сравнений, заменяющих left join-ы, он появился до появления left join-а в стандарте).
Единственный компонент oracle, на который postgresql ориентирован - язык pl/psql, но всё-таки, синтаксис у них отличается в деталях, подозреваю, что pl/sql был всего лишь хорошей идеей для повторения чего-то похожего, а задача обеспечения совместимости не ставилась.
Рекурсивные CTE - гораздо более понятный синтаксис, чем start with/connect by. Причём всё, что можно сделать через start with/connect by, можно выразить и через рекунсивный cte, а вот в обратную сторону это не выполняется, так что этот синтаксис еще и более расширенный.
Что касается скорости - про 100 раз хотелось бы пруфов с корректным измерением, но боюсь, что лицензия Oracle вам не позволит без согласования с ними опубликовать тест сравнения с другой СУБД.
А как лицензия может запретить публиковать тест сравнения с другой СУБД?
Здесь я Вас успокою, консультировались с юристами по этому поводу в плане скуля-эти требования в лицензии ничтожны. Компания может написать что угодно в лицензии, но ограничивать права и свободы, не относящиеся к раскрытию исходного кода, который является закрытым, не может. Аналогично думаю и с ораклом.
Вы же тоже по договору понимаете какие пункты ничтожны относительно местного законодательства (или проверяете) или верите тому, что написала одна сторона даже пусть большая компания?
Также в лицензиях часто пишут, что Вы приобретаете не право на продукт, а право использовать продукт, что отсюда вытекает, что не можете в случае потерь для бизнеса или личных целей требовать возместить потери. Однако, в российском законодательстве есть две статьи: про качество услуги/товаров и ещё что-то, благодаря чему можно и нужно в том числе через суд взыскать потери с компании, которая произвела некачественное решение в виде ПО или сервиса и для которой Вы приобрели платную лицензию, т е заплатили.
Примеры судебных решений много в интернете.
Также можно через суд поставить гиганта на место в случае аннулирования лицензии по основаниям, противоречащим местному законодательству. И такие примеры есть в интернете.
Важно иметь штат юристов, хорошо понимающих в этой сфере.
Или если не хотите возможных судебных тяжб, то обычно создают временно компанию-дочку и от её имени публикуют или выступают (причём можно даже бренд головной компании оставить) , а потом в случае чего, это не Ваша компания была, а вообще сторонне юрлицо и что право выступать с брендом Вашей компании не было дано.
Т е я не я, лошадь не моя.
Всё, прицепиться не к чему.
Вам не кажется, что публикация сравнения производительности двух субд - слишком малозначительная причина для того, чтобы создавать дочернее юр.лицо или нанимать/нагружать юристов дополнительной работой (если, конечно, они не наняты для другого и временно простаивают)?
Тем более что по хорошему, тестировать надо под конкретный профиль использования СУБД, а он у каждого будет свой. Плюс, нужно учитывать способности имеющихся в наличии разработчиков (если не нанимаем новых под конкретный проект). А значит, любое тестирование (на сколько оно правильным бы не было), для другого проекта может оказаться, как минимум, малополезным, как максимум - неприменимым. При этом, в худшем случае, человек, почитая подобное сравнение, примет неправильное решение (и даже не узнает об этом).
Приведу пример: есть в одной компании биллинг, написанный на Oracle. Админов попросили оценить требуемый сайзинг для случая перевода биллинга на PostgreSQL. Они смигрировали таблицы и запустили несколько отчётов (каждый из них - SQL-запросы на несколько листов исходного кода). На выходе получили просто невозможный сайзинг (увеличение мощности RAC-а из трёх серверов в десятки раз). При этом, зная, как оптимизируются запросы у разработчика биллинга, уверен, что многие места в этих отчётах захинтованы, чтобы Oracle не выбирал заведомо неподходящий план. Естественно, в PostgreSQL это не применимо и многие вещи пришлось бы переписать.
Другой пример: у нас есть ряд SQL-запросов, генерирующих иерархический json (демонстрация того, как это делать - http://sqlfiddle.com/#!17/b0d7a/7). На Oracle такого 1:1, скорее всего, не написать, поэтому когда коллеге надо было сделать подобный функционал под Oracle, он посмотрел на наши примеры, решил, что это слишком сложно, и написал рекурсивную функцию на pl/sql. В итоге один такой оракловый запрос выполняется дольше чем у нас десяток (совсем честное сравнение не делалось, но железо было примерно похожее, а объём генерируемого json-а и уровень вложенности у нас был, в основном, больше) и им пришлось вставить кеш таких json-ов с ручным сбросом. При чём им повезло с тем, что кеш применим, у нас json-ы генерируются свои под конкретного пользователя.
Абсолютно с Вами согласен.
Однако, увы, неправильные решения в том числе именно так и принимаются причём повсеместно и даже сейчас.
Всегда нужно взвешивать все за и все против, а также сравнивать именно под кокретные условия, а не абстрактно в общем. И тем более ставить под сомнения любые выводы даже авторитетов-все перепроверить под конкретные нужды, условия и задачи. И тем более ставить под сомнения те выводы, в которых нет детализации как проводилось сравнение и как делался вывод.
Схемы в PostgreSQL не прибиты к юзерам, так что этот ваш "ужос" - вкусовщина.
Зато исполнение кода в PostgreSQL не блокирует програмные объекты. В оракле на высоконагруженной системе обновить популярный пакет (да даже функцию) на нагруженной системе - целая проблема.
Обновление кода происходит обычно через CI/CD процесс в любое время, если изменения не вызывают долгие блокировки, иначе да, либо тех окно, либо с переключением на реплику. Последнее применяется в случае систем 24 на 7, у которых не может быть простоя по определению.
У тех проектов, где сам участвовал в разработке-в Сбер, Альфа, ВТБ и т д. Правда не во всех там проектах участвовал, потому не могу сказать что прям все проекты, но думаю этих 3-х компаний достаточно. И ещё больше компаний, о которых менее известно-Фортис (Монополия), ЦРТ, GS Group, MCS Group и ещё несколько.
В Ozon тоже релизы выкладывают через налаженный CI/CD - процесс почти в любое время.
То есть, по вашему, одного профессионализма достаточно, чтобы избежать факапов при релизе, которые будут замечены после запуска нагрузки (типичная причина, по которой может понадобиться обновить код не дожидаясь очередного окна обновления)?
Пока получается что в большинстве случаев PG сравним или в 2-3 раза медленнее Oracle, хотя в иерархических запросах и курсорах с функцией random PG отстает в 10-20 раз.
На самом деле, там не все так просто. У Oracle, например, сильно умнее планировщик запросов, но он, соответственно, планирует гораздо медленнее, чем PostgreSQL. И если Вы делаете много разных простых запросов (у которых планы не кэшируются), то бывают ситуации, когда PostgreSQL в итоге работает быстрее.
Но у того же PostgreSQL есть одна большая проблема - он не умеет "перепланировать" запрос в ходе выполнения (что в каком-то виде умеет Oracle). То есть, если PostgreSQL построил план, а в ходе выполнения выяснилось, что записей там не 100000, а 10, то PostgreSQL продолжит выполнение по старому плану, что может привести к катастрофическим затратам на выполнение. Мы это (так как автоматически компилируем запросы) решаем таким образом : когда видим, что запрос выполняется дольше чем должен (порог определяется эвристически), то останавливаем запрос и автоматически разбиваем его на несколько запросов (с временными таблицами). Тогда уже при повторном выполнении PostgreSQL будет знать статистику во временной таблице и построит новый план.
Но стратегически просто надо сразу писать запросы с учетом определенных СУБД. И то, что оптимизировано под PostgreSQL не станет быстрее работать на Oracle (без рефакторинга). Более подробно разницу выполнения запросов на разных СУБД с примерами мы описывали в этой статье.
Вообще, существует достаточно вариантов, когда написанный под PostgreSQL код будет медленнее работать на Oracle, если его просто перенести и подправить синтаксически.
Что касается планировщика: для простых запросов это идёт ораклу в минус, т.к. тупо теряется время на IPC, в итоге, пока Oracle планирует запрос, PostgreSQL его уже выполнил. Один из примеров - execute (immediate) с простым запросом в цикле. Да, так неправильно делать и под PostgreSQL это также будет работать хуже, чем статически написанный запрос. Но при этом потеря производительности из-за динамического запроса по сравнению с обычным в Oracle будет гораздо больше (раз в 10), чем в PostgreSQL.
Приведите полностью скрипт для слона и для оракла и по времени сколько получилось?
Также важно расписать настройки каждой СУБД, настройки ОС под каждую СУБД, ФС, систему ввода-вывода и железо.
Только после этого можно объективно сравнить производительность решения и оценить качество данной проверки (всё ли было настроено верно и в равных ли условиях были обе СУБД).
Не приведу - давно было, сейчас доступа к тем машинам нету. Да и правильный тест делается не совсем так: нужна одна машина (как вариант - полностью идентичные машины), куда накатывается сперва одна субд, затем другая. Могу лишь сказать, что опыта в настройке Oracle у админов, которые эти сервера ставили, было гораздо больше, чем в настройке PostgreSQL.
В том то и проблема, что возможно настройки должны быть разными. Но для Oracle не буду утверждать (т к с ним не работал). Однако, слона лучше на винду не ставить равно как и скуль до 2019 версии лучше не на винду не ставить. Иначе заранее уже получите плохой результат. Если нет достаточного опыта в админстве одной из СУБД, то привлекают 2-3 экспертов, кто может провести ревью настроек и помочь в подготовке среды для тестирования. По крайней мере мы так делали. У нас тогда скуль 2017 был на линухе и был в проигрышном варианте, но всё равно оказался шустрее слона даже при таких настройках. Но там пришлось на линуксе тестить, ибо заказчик отказывался от винды.
Ссылка на результат тестирования приведён вначале публикации.
На таблицах очень среднего размера, несколько десятков тысяч записей. И PG работает в 2-3 раза медленнее Oracle, вот и всё.
А давайте Вы просто возьмете 2 простые виртуальные машины, поставите туда и Oracle и PostgreSQL, и покажете то, что PG работает в 2-3 раза медленнее на запросе SELECT x FROM y WHERE z = 1123421 (первый и второй раз - то есть когда данные в кэше и когда нет). И напишите под это статью на хабре. Вот мы так сделали (см. ссылку на статью выше), и она видимо понравилась сообществу (раз набрала много плюсов).
Теперь делаю то же самое в PG и получаю индейское национальное жилище - sequential read хоть убейся.
Так создайте просто индекс по UPPER. Он прекрасно используется тогда (только что проверил) :
"Index Scan using test on stock_sku (cost=8.45..454.20 rows=1817 width=2128)"
" Index Cond: (upper((stock_name_sku)::text) = 'НАПИТОК ГАЗ.СПРАЙТ 1Л'::text)"Я про это и имел ввиду, когда писал :
"стратегически просто надо сразу писать запросы с учетом... бла-бла-бла"
В принципе косвенная цель моей нынешней задачи - предоставить доказательства что PG - это плохая замена Oracle. Как говорится, PG - это Oracle для бедных.
Никто не отрицает того, что Oracle умеет больше чем PostgreSQL, и поэтому стоит в бесконечное количество раз дороже. Но речь идет о другом. Дело в том, что сейчас для 95% (условно) задач возможностей PostgreSQL достаточно, и нет смысла еще тратить деньги на Oracle.
Например, у нас работают десятки клиентов, у многих из которых свыше тысячи одновременно работающих пользователей, и базы данных больше 3ТБ с некоторыми таблицами свыше миллиарда записей. Все это работает на PostgreSQL практически на стандартных настройках (вот в этой статье я описывал каких именно). При этом там еще есть большой резерв по ресурсам (в статье есть график с Zabbix'а).
Кстати пытаюсь найти какой-нибудь простой фреймворк для написания веб-приложения на базе PG, велели искать бесплатный. Ну, гуглил, получается что по сути только Django или Ruby. Колупаю Django - грустно, девицы. А я еще оракловый APEX ругал...
Вот прямо идеальное подходит открытая и бесплатная платформа lsFusion, на которой и написаны все наши решения для таких клиентов, которые описаны выше.
" Так создайте просто индекс по UPPER." - а давайте вы попробуете сначала прочитать мой текст, а потом комментировать, ведь именно об этом я и пишу - " создаю функциональный индекс в Oracle и вижу как время исполнения функции падает с 3 ms до 0.02 ms. Теперь делаю то же самое в PG и получаю индейское национальное жилище ".
Так я и привел пример. Специально создал индекс test по выражению UPPER. Сделал запрос и получил план с index scan (хотя без индекса был parallel scan). Выполнение соответственно тоже там заняло доли миллисекунд.
пусть "платформа" просуществует 10 лет
Платформа уже существует 10 лет (можете посмотреть историю коммитов на github).
ни малейших проблем, пусть "платформа" просуществует 10 лет, пусть вокруг нее возникнет международное communinty и пусть на ней буде сделано хотя бы сотня серьезных корпоративных приложений в США - с удовольствием рассмотрим переход на эту никому неизвестную русскую поделку.
Ну если бы такая платформа уже существовала (плюс еще и открытая, и бесплатная), то мы бы тоже не разрабатывали бы свою. Но если лучшее из того, что сейчас есть - это Django, то "Хьюстон, у нас проблемы". Все таки сравнивать его с lsFusion - некорректно, так как там совсем разные уровень абстрагирования.
Да, на lsFusion есть серьезные корпоративные приложения только на постсоветском пространстве (и, кстати, парочка и в США небольших проектов). Но это все критически важные для бизнеса решения, падение которых хотя бы на час останавливает весь бизнес. Так что с надежностью проблем никаких. А что касается community, то во многих случая лучше прямая связь с разработчиками через slack, чем огромное community.
"разработчики" вообще не заинтересованы в распространении знания, они трясутся за свои прибыли и разрешают пользователям только то, что они считают нужным. Apple - классический пример.
Давайте не будем сравнивать open-source и corporate. У них абсолютно разные цели и подходы. У нас, например, нет цели зарабатывать на разработчиках. Мы сами зарабатываем на конкретных решениях, на базе платформы, а саму платформу отдаем в открытый доступ, чтобы другие могли тоже зарабатывать. И так работает во многих open-source продуктах (например, Linux - Redhat, PostgreSQL - PostgresPro).
Антипример - Oracle Jdeveloper ADF. Ничтожно маленькое community, бессвязная документация, примитивные tutorials от разработчика, крайне мало информации, разработчики не могут пофиксить критические баги годами.
Закрытые проприетарные системы - это практически всегда тупиковый путь. Вот Oracle этого не понимает, и поэтому тихо увядает. А вот тот же Microsoft это уже давно понял, поэтому и становится все более открытым. Вот и растет.
Смотря, что Вы считаете tutorial. Лично я предпочитаю изучать любые технологии по примерам. В порядке сложности :
Вот здесь куча мелких примеров (для разных use-case) сгруппированных по цели использования.
Вот тут два примера совсем простых приложений (описание 1, демо 1, описание 2, демо 2).
Относительно простое решение для бизнеса MyCompany (github, demo).
Ну и коммерческое решение, на которым мы зарабатываем основные деньги (github, demo).
Как раз опен соурс для очень состоятельных компаний, т к нужно выделить целый отдел, который будет продвигать и делать нужные компании фичи в том числе на уровне ядра системы (кастомизация решения под нужды компании), в том числе исправлять баги и улучшать безопасность и стабильность нужных фрагментов кода для компании.
Многие компании об этом забывают и берут опен соурс как есть, а потом со временем удивляются всё большим тратам на эксплуатацию и потерям при ней для бизнеса в целом.
В нашей компании делается вклад в развитие тех опен соурс решений, которые используются в ней.
кстати, в понедельник всё наладилось. Нич-чего не понимаю. В выходные админы ребутили машину с базой, может это?
Вот поэтому я и писал, что некорректно сравнивать СУБД и делать скоропалительные вывода, когда нет хоть какой-то экспертизы в них. Цитирую документацию по CREATE INDEX :
The system regularly collects statistics on all of a table's columns. Newly-created non-expression indexes can immediately use these statistics to determine an index's usefulness. For new expression indexes, it is necessary to run
ANALYZEor wait for the autovacuum daemon to analyze the table to generate statistics for these indexes.
У Вас просто демон потом отработал по индексу.
Кстати, у PostgreSQL - огромнейшее community. И Вы не смогли найти причину. А вот если бы Вы зашли в slack к разработчикам и спросили у них, то быстро бы получили ответ. Никто не спорит, что community - это хорошо, и классно когда оно есть. Но по своему опыту, если бы у многих библиотек у меня была возможность поообщаться с разработчиками напрямую, то для меня это было бы гораздо лучше, чем искать ответы на SO. Там почитаешь, такой треш иногда рекоммендуют (и плюсуют), что аж волосы дыбом встают.
еперь админы пишут что не могут проапгрейдить с 11.13 до 12. Фэйлится extension ORAFCE :(
ORAFCE - далеко не самый популярный extension. Тут претензии скорее к разработчикам расширения, а не PostgreSQL. Мы обычно стараемся почти сразу тестировать платформу при выходе новой Java или PostgreSQL, и сразу же делать поддержку, если что-то поменялось.
Это текущая дата и время начала транзакции, а не текущая дата и время в глобальном понимании. Источник
Используем SQL CLRs (функции, триггеры, хранимки на C#).
Сталкивались ли с SQL CLR и на каком языке реализовывали альтернативу?
PS: рассматриваем частичный перенос базок на PG.
Подобные решения уходили в сам сервис. Однако, слон поддерживает разные языки программирования, о чем более подробно можно почитать здесь. Т е можно и в процедуру завернуть.
Карманный справочник: сравнение синтаксиса MS SQL Server и PostgreSQL