Как стать автором
Обновить

Комментарии 124

Отформатируйте стену текста, пожалуйста — очень тяжело читать.
Спасибо за статью.
Тоже постоянно сталкиваемся с затыками постгреса на большом количестве апдейтов.
> Изначально ставил перед собой задачу выставить Uber дураками, а PostgreSQL белым и пушистым

Но ведь так и есть.
Они мало что знали о PostgreSQL


весело…

это точно убер? (сарказм)…

выглядит так: перестроили под то, о чем мало знали, походили по граблях, узнали больше о том как нужно было, решили «проще вернуться на то о чем знают хорошо, чем повторно перестроить на postgresql учитывая набитые шишки».
В масштабах убера дважды за 3 года менять СУБД действительно выглядит странно :)
BTW, я это преобразовал в статью, поскольку тут подробно описаны многие низкоуровневые детали, которые интересны вне зависимости кейса с убером.

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


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


  1. Postgres версионный, а значит на каждый чих обновляет все индексы. Им бы как раз использовать косвенную адресацию, чтоб экономить на обновлении хоть как-то. (Разве там нет скрытой косвенной адресации через версии?)
  2. InnoDB не версионный, а с сегментами отката. Вот им бы прямая адресация не пила столько крови, поскольку положение строчки в куче не меняется при обновлении.

Получается идеальная комбинаци у Oracle: прямая адресация и сегменты отката.

Вот мне показалось аналогично. Может, имеет смысл рассматривать проблемы производительности с учётом соотношения чтение/запись? У Убера, возможно, транзакций на запись значительно больше в таком соотношении?

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


Легко найти комментарии экспертов к данному докладу, где объясняется, как Uber неправ в каждом пункте.

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

Да, посыпаю голову пеплом, прочитал первое предложение, и подумал, что это тот самый первый доклад.


Но кстати, с того момента, как Uber перешел обратно на MySQL, PostgreSQL выпустил несколько версий, в которых исправлены некоторые из проблем, о которых говорилось в изначальном докладе Uber.

где-то на хабре была ссылка на выступление сотрудника из танчиков (world of tanks), они аналогично мигрировали MySQL > Postgress > MySQL.
В статье (первой) Uber мне было скорее интересно не то что они ушли или не ушли с MySQL/PostgreSQL а то что такая нагруженая система работала и на том и другом продукте. Сейчас зачастую призодится слышать что без NoSQL это вообще невозможно сделать. (Напр. где-то была статья от vk где в частности упоминалось что осталась ровно одна таблица на реляционной базе с названием schestnoe_slovo_posledniayja_tablitsa (или что-то вроде этого)

Победа NoSQL это из разряда слышали акустические волны, но источник не нашли. Да, есть сферы деятельности, где NoSQL хорош. Например хранение не согласованной информации: фоточки, посты, профайлы пользователей. Все они довольно независимы друг от друга логически и могут обновляться не согласовано.
А вот например бухгалтерия, платежные или другие транзакции, и вообще все сферы, где необходимо одновременно и согласованно изменять много значений по-прежнему висят на SQL. Более того, в Big Data сейчас серьёзный откат именно в эту область, правда уже по причине тезиса, что Big Data не должны быть Bad Data.

Сейчас зачастую призодится слышать что без NoSQL это вообще невозможно сделать.
Невозможно сделать… что? Google Adsense уехал с MySQL на свою собственную систему несколько лет назад, но на NoSQL не перешёл.

Да и есть подозрение, что 4-5 лет назад, когда они ещё на MySQL жили там нагрузка была такая, что Uber и рядом не лежал.
Ну это простая защитная реакция назвать дураками тех, кто тебя критикует. Хотя репутационный ущерб для PostgreSQL конечно есть. Но это должно их сподвигнуть усилить свои слабые места.
«Uber еще замечает, что вообще у них были длинные транзакции в основном по вине разработчика.»
— и как это поможет исправить переход на MySQL?
Если эту фразу интерпретировать, как «Ну Uber сами дураки», то можно тушить свечи. А так… Общее ощущение что молодые ребята вкалывают, принимают волевые решения. Удачи.

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

Постгрес как база лучше чем MySQL. Это однозначно. И кластеред индекс у неё есть. Автор лукавит. Это создаваемая по умолчанию секвенция строк. Выход на неё по бинарному древу поиска там по — моему с 7-й версии. В общем улучшение репликации пожалуй существенная вещь, но сказать, чтобы она была решающей трудно.
хм. как я понимаю у них активная работа с геоданными.
в mysql вроде бы с этим так себе.
Одна проблема с этой статьей: постгрес развивается очень хорошими темпами и статья в апреле 2018 устарела (и основана на еще большем старье).

Так, pg_logical прекрасно вошел в 10 версию: www.postgresql.org/docs/10/static/logical-replication.html

C MVCC vs UNDO тоже ситуация на месте не стоит: 1, 2, 3. Опять-таки, с учетом темпов развития, глядишь уже в 12 версии появится.
А мы точно говорим о продукте, которому больше 20 лет?

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

От продукта, которому двадцать с лишним лет ожидаешь, что уж такие-то базовые вещи в нём реализованы давным-давно.
Репликация это не базовая вещь. У некоторых СУБД с мировым именем репликацию обеспечивают только пакеты от третьих производителей ПО.
Да? Это какие-такие СУБД «с мировым именем» не имеют репликации из коробки?
Разговор идет не о «сейчас/сегодня» а о «хайповой библиотечки, которая только », и как Postgres выглядит на фоне лучших производителей СУБД.

Взять эталон индустрии разработки ПО. Microsoft SQL Server — физическая репликация ( mirroring ) появилась только с Service Pack 1 SQL Server 2008, то есть в 2010-м, мульти — узловая физическая репликация с доступом для чтения резервной копии в версии 2012, ошибки, которые лишали её возможности нормально работать поправили только в SP2, выпущенного 12-го Июля 2016-го года.

Сравнивая поддержкой репликации СУБД Postgres, мне кажется критика «хайповой библиотечки, которая только » не только не обоснована, но совершенно не отражает реальность.
Ну, знаете ли, в том же MySQL row-based репликация появилась в версии 5.1, это 10 лет назад, а statement-based по-моему была чуть ли не с 3 версии.

А PostgreSQL до недавнего времени мучал людей всяким Slony и прочими trigger-based убожествами.
10 лет или даже 20 лет назад.
После того как MySQL отдали InnoDB, коммерческий продут, а Оракл купила MySQL, примерно год — два назад MySQL выпустила новые фитчи для репликации, которые сделали её доступной. Они до сих пор глючат. Я это говорю не для того, чтобы сказать, что MySQL плох или хорош. Ваши утверждения носят характер маркетинговой рекламной кампании. Вам здесь не место. Занимайтесь этими глупостями в статьях, за которые Ваша фирма платит.
MySQL выпустила новые фитчи для репликации, которые сделали её доступной. Они до сих пор глючат

Это какие? Semi-Sync репликация? И что значит «доступной»?

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

Ого, ничего себе, маркетологом меня еще никто не обзывал. И что же я рекламирую? MySQL? Мне наверное Oracle платит? :)

Ого, ничего себе, маркетологом меня еще никто не обзывал. И что же я рекламирую? MySQL? Мне наверное Oracle платит? :)

Почему «обзывал». Это прибыльное дело. Вы пишете не профессиональные комментарии, не несущие никакой информации, кроме личных выпадов и цитат из рекламных пособий фирмы производителя ПО.

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

Вообще после глубокого анализа статьи я пришел в выводу, что Uber видимо вернется к Postgress. После глубокого анализа я пришел к выводу, что выбор Postgress не был случайным или результатом hipe. Расчет был холодный, оправданный и похоже худо ли бедно ли, но бизнес был доволен пакетом ПО. Для этого есть объективные причины инженерного характера, которые без Postgress не решить. Моя оценка за 3 года фирма вернуться к Posgress не сможет, из-за возможной потери лица, но больше 5 лет без него прожить не сможет.

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

Да? :) Мне как раз казалось, что это универсальный ответ Mysql: возьмите 5.7, там у нас ого-го, а уж в 8… (почитайте хотя бы нашего местного евангелиста разрушителя). Видимо, это общий тренд

Ну а вообще — смотря с чем сравнивать и что считать базовой вещью, можно же и с Ораклом (которому 40 лет). Кому суп жидкий, кому жемчуг мелкий…
Ну а вообще — смотря с чем сравнивать и что считать базовой вещью, можно же и с Ораклом (которому 40 лет).
А вот тут вы, как бы, сами указали на основную разницу: довольно естественно ожидать от продукта, которому 40 лет, большей «вылизанности», чем от продукта, которому 20. Было бы странно если бы разницы не было.

Но MySQL всего на год старше PostgreSQL, обоим проектам уже за 20, так что странно видеть, что какие-то достаточно базовые вещи, которые в MySQL были реализованы 10 лет назад в PostgreSQL появились вот-буквально-только-что.

И да, репликация-для-того-чтобы-можно-было-много-много-читать — это одна из базовых вещей для web-приложений. Потому что, блин, это нужно всем. Это в 80-90е базы данных использовались так, что клерки вбивали туда данные из всяких формочек с утра до вечера, а аналитики иногда запрашивали отчёты. С приходом интернета и, особенно, web'а тренд развернулся и количество запросов на чтение стало на порядок (а часто и на два) больше количества запросов на запись.

Если у вас нет репликации, которая это позволяет оптимизировать, то как вас вообще можно рассматривать всерьёз в этом мире? Если у вас нет возможности производить апргейд начиная с read-only реплик (с последующим переключением за минуты), то как вас можно рассаматривать как бакэнд для терабайтных баз?

То, что PostgreSQL 10 наконец-то получил эту возможность — это замечательно, но то, что её не было 20 лет — настораживает…
так что странно видеть

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

Базовая вещ? Ну дак сделать то не проблема, правда?)
Базовая вещ? Ну дак сделать то не проблема, правда?)
Но зачем, если есть альтернатива, которая решает проблему?

Компании, вообще-то, используют open-source именно для того, чтобы «не вкладывать ни копейки».

Если потребуется вкладывать — они скорее эксклюзивно для себя фишечку сделают, благо лицензия PG это позволяет…
Компании, вообще-то, используют open-source именно для того, чтобы «не вкладывать ни копейки».

ну вот точно не для этого, это не free beer
Это вы можете так считать. А 90% (если не 99%) процентов компаний рассчитывают именно на «free beer», а свобода их мало интересует…
Дело не только в свободе. Использую СПО каждый должен отдавать себе отчет, что вам его создатели, в общем то, ничего не должны.
Интересно, а кто-нибудь помнит, чтобы разработчики MySQL как-нибудь реагировали на критику их продукта?
А им оно надо? Я в том числе не видел от них статей вроде «все БД говно, кроме MySql». У MySql есть куча своих проблем и куча форков, где эти проблемы просто решаются тем или иным образом.
Кстати, а Амазон многое переделал в системе хранения когда свой Redshift точили?

Рискую отхватить минусов, но самый нормальный и самый стабильный во всех отношениях SQL Server — это Microsoft SQL Server. И в нем реализовано гораздо больше возможностей, чем во всех этих open source. Хочешь Row Versioning — включи одну настройку и работай. Не хочешь — работай с блокирующими апдейтами. Компрессия, репликация, отслеживание изменений таблиц, column store индексы, индексы с включенными полями, collation на каждую колонку, партиционирование, репликации, фэйловер кластер, always-on группы — возможностей хватит лет на 20 вперед. И все это доступно уже с версии 2012 как минимум (после этого уже вышли версии 2014 и 2016 и готовится очередная новая версия). MS уже не знает, что еще придумать, потому что их продукт превзошел всех конкурентов еще лет 10 назад. Ну разве что Oracle может поконкурировать.
По поводу стоимости лицензий да, все печально. Но продукт стоит того. Плюс есть Express версия, бесплатная.

В принципе вы правы, но… отсутствие поддержки Linux'а и цена ставят на нём крест в огромном проценте случаев. Тем не менее тот факт, что даже при таком гандикапе он идёт сразу после MySQL — говорит о многом…

Поддержка Linux уже появилась (RHEL, Ubuntu, SUSE)

А уведомления о событиях аналогичные постгресовским NOTIFY/LISTEN в SQL Server уже появились?

Да, давно уже, фича называется Service Broker. Но она очень тормозная.

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

Какой ещё пушки, по каким воробьям. Дилетанты на выход. Пока не вынесли вперёд ногами.
Тут проблема немного в другом. Изначально у стартапов есть сомнения, что они взлетят, поэтому использовать дорогой продукт — это весьма сомнительный вариант. А когда они взлетают, то есть уже огромная база, вендор лок и прочее. В итоге, только безумный будет базу менять. А так да, весь стек майкрософта все лучше и лучше.
Мне пришлось, реально заставили ставить MSSQL для OLAP.
И должен сказать что как-раз та часть которая OLAP целиком и полностью сделана на коленке.
А та часть которая MSSQL жрет ресурсы как-будто они бесплатны.

MS не знает что делать? Пусть займутся качеством, устойчивостью и прожорливостью. Там работы в их темпе на 10 лет хватит.
Работаю с MS SQL уже лет 20, последние несколько лет экспериментирую с PostgreSQL. Небо и земля в пользу последнего. Для галочки в MSSQL огромное количество фич, но их использование — это иногда ад. В качестве примера — поддержка JSON вроде есть, но функции по работе с ним — рудиментарное уродство. CTE вроде есть, но ограничений — миллион, попробуйте использовать INSERT/UPDATE. Люди до сих пор мучаются с банальной конкатенацией строк, реализуя её через FOR XML — запросы. Да мы даже UTF-8 получить не можем, для пары спецсимволов я должен раздувать IO для всех строчных типов в два раза. Я UDF на родном для MS C# цепляю к пострелу проще, чем это делает их SQL Server. От приятных мелочей вроде DROP...CASCADE, DROP IF EXISTS до кастомных типов, индексов, языков UDF. Примеров могу привести миллион. Если их просуммировать — ну очень комфортно себя чувствую, пишу и оно работает так как надо.
В PostgreSQL ограничений не меньше. Те же CTE вроде как мощные — но при этом являются барьером оптимизатора, так что использовать их для чего-то сложного один фиг нельзя. Опять же, оптимизатор запросов в PostgreSQL порой творит какую-то дичь. А уж невозможность сделать delete top 1000 и вовсе кошмар…
DELETE TOP — кошмар? Вы либо лукавите, либо работаете с очень специфичным проектом. Кошмар — это когда десятилетиями ждешь реализации OFFSET+LIMiT и пейджинг на MSSQL стал просто притчей во языцах. Уродливый полнотекстовый поиск, отсутствие deferred constraint, массивов. Регулярных выражений нет. Этож вдуматься только, в 2018 году я не могу сделать банальный creditcard/e-mail/phonenumber constrains. Вот это реально кошмар.

Остальные доводы — спекулятивные. Я миллион раз защищал оптимизатор MSSQL от нападок людей, которые просто не умели готовить годные ему запросы. Так что надо разбирать конкретные ситуации. Хотя, в плане чистого быстродействия я отдаю предпочтение MSSQL, но у Postgresql больше вариантов решений, в том числе и дающих существенный выигрыш.
Там была не очень специфическая задача: раз в день переносить изменения из PostgreSQL в OLAP, для чего в PostgreSQL завели заполняемую триггером таблицу change_log. Нужно было всего-то вычитать из нее данные и почистить ее. Так вот: мне не удалось найти решение, которое бы работало за линейное время и при этом умело вычитывать эту таблицу по частям.

Получилось либо удаление всех записей в одной большой транзакции с чтением удаляемых при этом данных, либо квадратичный алгоритм (оптимизатор упрямо сует в план запроса на удаление полный проход по таблице). Итог в любом случае один и тот же: если позволить данным скопиться, то их уже никогда не удастся оттуда вычитать.
Сложно сказать, я попробовал топорный DELETE FROM… WHERE id = ANY(ARRAY(SELECT id… LIMIT 1000) или… WHERE id < (SELECT MIN(id) + 1000 ...), получилось Index only + Bitmap. Приблизительно то, что я в уме себе и представлял. Ради смеха попробовал вариант с отдельным VIEW на OFFSET 1000 и INSTEAD OF DELETE rule для него. Чтобы удаление выглядело просто как DELETE FROM log_batch_view. Примерно та же картина по быстродействию. В голове роилась ещё куча идей касательно использования BRIN, партиций и т.п., но из меня пока плохой укротитель слонов :) DELETE TOP, конечно, в данной задаче лучше, но я все равно склоняюсь к её специфичности. Это не то, что делаешь каждый божий день или по много раз в проекте. Даже когда набросал пример — началось с CREATE TABLE temp AS SELECT id,… FROM generate_series(1, 1000000) AS id. Попробуйте развернуть для MSSQL.
Сложно сказать, я попробовал топорный DELETE FROM… WHERE id = ANY(ARRAY(SELECT id… LIMIT 1000) или… WHERE id < (SELECT MIN(id) + 1000 ...)

Пробовал вариант похожий на первый, он почему-то давал полное сканирование таблицы и Hash Join. Но подробностей не помню уже, год назад это было...


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

Справедливости ради, offset+limit — антипаттерн. Ибо:
1. Фильтровать при запросе каждой страницы — медленно
2. Между запросами выборка может измениться — привет, пропадающие записи и дубликаты

Правильное решение: выдать список идентификаторов (снепшот списка на конкретный момент времени), а потом отдельным пакетным запросом получить данные по интересующей части списка.
> offset+limit — антипаттерн

Но почему-то этот антипаттерн чуть более, чем везде.
А вот указать, от какой позиции листать дальше — я видел на FB (мобильной версии), reddit и blogspot… ой, и всё. Ну ладно, ещё кого-то я не знаю. Ну будет десяток имён на весь мир. И как это понимать?
Даже() на хабре что-то вроде habrahabr.ru/all/page100 (заметьте, что page101 уже нет — то есть, задано искусственное ограничение), а не какая-нибудь /all/after1524296593/ (я взял текущий unixtime для примера, можно вместо этого по номеру статьи или как-то ещё).

Я бы понял, если бы вы сказали что-то вроде «ну ведь работает же и даже не выжирает всё, по крайней мере в 99% случаев». Но просто сослаться на AaP — «миллион мух/леммингов/etc. ничего не доказывают» это не более чем неконструктивно отмахнуться.

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

Есть, кстати, ещё одно, идущее непонятно откуда, но тиражируемое чуть менее, чем всеми — это неуказание временно́го фактора в направлении листания. Опять же, хабр: «туда» это в прошлое. А почему собственно? На некоторых сайтах, кстати, наоборот. Явно «в прошлое» писал сам по себе разве что 3dnews.ru (и позже opennet.ru стал писать «раньше»/«позже», но это уже, извините, я попросил админа).

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


Обычно эволюция разработчика идёт такая:


  1. Херачим из базы всё, что запросили.
  2. Понимаем, что данных много, а нужны не все. Ага есть стандартный паттерн, который прикручивается малой кровью — паджинация.
  3. Огребаем багрепортов на тему странного дублирования записей. Много думаем, придумываем один из вариантов выдачи снепшота всего списка и догрузки подробной информации по части элементов.
  4. Огребаем багрепортов на тему экспоненциального потребления ресурсов для моделей с перекрёстными ссылками. Наконец нормализуем выдачу.
  5. Огребаем багрепортов на тему долгой загрузки. Ага, модели жирные, а показываются из них 1-2 поля. Прикручиваем укзазание интересующих в выдаче полей.

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

Расписал про это по подробней: habr.com/post/413133
>> Регулярных выражений нет.
Вот именно это решается через CLR на раз и насколько помню последний раз делал это 3 года тому назад, даже не надо помечать как unsafe
Вот плюс один. TSQL этот — как будто специально придумывали чтобы пытать людей. Типа где-то в MS: «я придумал! А давайте этим тварям оставим один цикл while! А чтобы по массиву строк пробежаться — чтобы строк десять надо было написать! Бугагагага!»

Постгрес на фоне — просто лапочка для программиста. А что он медленнее — да пофиг же. Замена одной SQL-базы на другую ради 2-3x ускорения — это только очень большим и богатым может отбиться, остальным проще сервер в 2 раза дороже купить.
Думаю им надо изменить лицензионную политику. Все самые крупные проекты на планете используют опенсорс ДБ на продакшн под невероятными нагрузками с миллионами а может миллиардами пользователей. Для MS просто затруднительно вообще правильно рассчитать количество лицензий необходимых для подобных решений. И даже приблизительная оценка стоимости выходит такой что отбивает желание даже у серьезных компаний даже «пробовать», как описано в данной статье. Я не слышал, может это и моя вина, ни об одном проекте, испоьзующем MS SQL Server для большого Веб Проекта из ТОП-100 сайтов. Поправьте меня если я не прав. Да MS SQL Server весьма востребован для различных бизнес решений, но когда мы говорим об экстремально высоких нагрузках, почему-то MS SQL редко всплывает в обзорах и докладах. Вполне возможно, что архитектурно в нем есть все и реализовано более менее правильно и логично. Но отсутствие реальных примеров может говорить о том, что при реальном прогоне под высокой нагрузкой повылазит большое количество не архитектурных проблем. Как кто-то уже написал тут в комментариях, например Postgres стараются быстро латать все возможные баги, которые им помогает обнаруживать огромное количество реальных и очень серьезных клиентов. Не думаю что MS реагтоуют также оперативно. В бизнес приложениях не принято так часто переходить с версии не версию. Плюс опенсорс модель позволяет общаться с клиентом на более низком уровне, в некоторых случаях изменения в коде могут быть сделаны моментально, и клиент должен просто пересобрать проект и получить изменения или даже сделать изменения самостоятельно. В случае с MS, неважно какого уровня разработчик готов вам помочь — изменения придут только с очередным пакетом обновлений. Я не противник MS. Я просто пытаюсь для себя найти объяснение, почему, если вы правы, реальность как бы это не подтверждает практикой использования.
Ну у mssql тоже есть минусы, я с ней работал в чистом виде и в виде сервиса azure sql в рамках проекта mapit.me Не помню деталей, давно это было, но были вещи которые бесили в mssql. На нее мы перешли как раз с postgresql. Другое дело azure sql, представим что вам дали его бесплатно (как это было в нашей компании), то можно смело ставит 10 из 10, более быстрой базы, плюс с мощным языком как t-sql сложно представить. Пропадает зависимость от операционной системы, используете его как облачный сервис. А чего стоит система рекомендаций: сама советует составные индексы, если запросы начинают просидать по из причине, или их удаление, если перестройка индекса слишком дорогая из-за частоты вставок. Плюс скорость и возможности pivot и partition by, индексы, кластеринг. partition by в postgresql работает ощутимо медленее, а про отвратительный pivot и вообще молчу, который уступает и oracle и mssql

Хорошо, где у MS SQL транзакционный DDL?
Мне сильно нравится возможность Postgres в отдельной транзакции, никому не мешая (почти), накатить непростой апдейт на схему БД и откатиться, если что-то пойдёт не так.

В MS SQL так тоже можно, за редкими исключениями (но лично мне они еще не попадались). С поправкой на то что это блокировщик, а не версионник.

если верить этому, то изменения видны ещё до коммита
https://stackoverflow.com/a/3364466/1049821


but SQL Server does not version metadata, and so changes would be visible to others before the transaction commits.

или это поведение уже изменено в более свежих версиях?

А, вот вы о чем. Да, так чтобы совсем никому не мешать — не получится.
MS SQL Server — вполне годная база для больших проектов.
Но на мой взгляд, чтобы стать популярным, он должен сначала полечить свои детские болезни. Например, это единственная база данных, в которой нет комментариев к объектам. Тот костыль, который Микрософт придумал в виде расширенного свойства MS_Description, не является полноценной заменой простого comment on column. Это невероятно, но при попытке добавления MS_Description к столбцу таблица эксклюзивно блокируется, ее на некоторое время ни читать, ни писать нельзя. У тех, кто привык с другими базами работать, такие сюрпризы вызывают шок.

Или, например, такая нехитрая вещь, как %rowtype, когда в MSSQL появится?

В статье так и не нашел ответа на вопрос, какая реляционная СУБД лучше?

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

Объясните пожалуйста более развернуто про небанальную работу с гео-данными.

Под «небанальной» работой с геоданными я подразумевал всё то, что выходит за рамки отслеживания координат пользователя в реальном времени и различных алгоритмов поиска в дорожном графе, что, по идее, и является основными задачами компаний типа Uber. И что, в принципе, не требует каких-либо специализированных средств в БД и просто моделируется стандартными типами данных и стандартными операциями. PostGIS же обеспечивает более богатый функционал: работа с 2D и 3D геометриями (точками, линиями, полигонами и коллекциями геометрий), операции создания, манипулирования, сравнения, выборки и прочее, относящееся к геометрическим (и географическим) представлениям данных. Можете сами оценить мощность набора операций в справочнике PostGIS Reference. Всё это заточено и оптимизировано под свои специализированные типы данных. Не скажу насчёт современного состояния MySQL в этом вопросе (что-то там сейчас появилось из этой области), но во времена миграции Uber на PostgreSQL ничего подобного в MySQL точно не было. Собственно, и претензии Uber к PostgreSQL лежат не в области работы с геоданными, а в неоптимальной низкоуровневой обработке данных под high load. О чём и статья. ;)

Ну в MySQL пока прикрутили SPATIAL, то есть чистая классическая 2D геометрия.
Единственное что нам было нужно — гео-дистанцию мы прикрутили через UDF. Для регионов (ну там вхождения точек и вот это все) можно ES пользовать, в 6+ совсем неплохо работает

Так я пошутил)
На мой вопрос нет правильного ответа)
Хотя мне интересно, почему многие рассматривают постгрес исключительно вместе с постгис? Без гео составляющей в ней совсем совсем смысла нет?

Мне лично очень нравится поддержка JSONB и довольно могучий и гибкий полнотекстовый поиск. Опять же, возможно в свежих версиях MySQL всё это появилось, но из-за отсутствия NoSQL средств работать с версией 5.5 после PostgreSQL было откровенно грустно. Вот ниже коллеги подтверждают ту же мысль. ;) Вообще, если выбирать СУБД для новых проектов, однозначно нужно брать Postgres, а не MySQL.

Вот, кстати, приятные новости по теме полнотекстового поиска.

Увы, все что касается полнотекстового поиска, если нет реализации fuzzy search — не имеет практической ценности (в подавляющем большинстве случаев).
Совместное с SQL использование эластики тоже проблематично т.к. не будет целостности данных.
Все мосты которые поддерживают связь эластики с другими базами — при рахрыве соединения не обспечивают согласованности данных в sql и эластике.

В этом смысле мне пока известны два решения — это orientdb в которуб встроена lucene и neo4j. При этим первая еще не очень стабильная а вторая платная.

И еще в h2 модно встроить lucene но там больше придется производить работы при индексации.

В orientdb все просто — объявляешь на поле индекс типа lucene и просто ищешь что нужно.

В области геокодирования и поиска адресной информации средств Postgres'овского FTS вполне достаточно, использование elasticsearch и аналогов тут будет очевидным overhead. Но всё зависит от задачи, конечно. ;)

Я имею в виду конкретно fuzzy search то есть поиск в таком виде «хбрахрб»~0.6 который выдаст строки похожие но не полностью соответствующие. Эта функциональность нужна практически всюду чтобы позволить находить текст при опечатках, грамматических ошибках. Есть конечно еще и жесткие мосты которые аттачатся триггерами к mysql или postgres. Но это и минус в потере производительности и откат транзакции в случае той же самой недоступности эластики. Проблема с моей точки зрения очень неприятная и нерешенная. Хоnеось бы иметь такой мост который делал типа репликации на эластику но он пока что у всех в road map.

Ну или же встроенного индекса типа lucene как в orientdb или h2

В PostgreSQL для этого есть расширение fuzzystrmatch.

Ну soundex много где есть. Еластику (точнее люцину) используют не потому что она вычисляет дистанцию между словами или фразами. А потому что строит индексы в которых можно найти похожее слово очень быстро. Даже если это слово не отдельное поле а текст. Не перебирая весь массив данных и каждое слово в тексте.

Да и цитата с документации не внушает оптимизма
At present, the soundex, metaphone, dmetaphone, and dmetaphone_alt functions do not work well with multibyte encodings (such as UTF-8).
Не только Postgis. Ещё JSONB получился неплохо. На себе с JS фронтом очень даже хорошо заходит.
Вы уж извините меня, но выглядит все это очень странно. PG Это нормальная база данных, а MySQL это доска с гвоздями. Конечно, первый не без проблем. Но поменять кучу возможностей от CTE до функциональный индексов на ээ, что? Тот же оптимизатор MySQL это таная странная штука, по которой я знаю 100500 рецептов, но даже зная их, к ним возвращаться никакого желания нет.

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

Их метания добавляют еще больше веса моим сомнениям. Имхо разработчик, который не просто попробовал перенести текущий функционал, а вкусивший pg или oracle, на Mysql не вернется уже никогда.
Чуть поправлю вкусивший oracle, работает на всем остальном с легким отвращением :). Но что поделаеш жизнь не мед.
Я не так много работал конечно, но встретил не так много вещей изза которых мне бы хотелось испытывать отвращение к пг) Хотя БД классная, спору нет)
Если поработать на Oracle несколько лет то все его богатство (SQL, PL\SQL, Администрирование ) становится нормой. И когда возвращаешся на что то другое, ето как пересесть с мерседеса на ладу калину :)
У каждой БД есть свои слабые и сильние стороны. И я считаю что PG лутшая из безплатных. Оракл — просто лутшая.
Если по сравнению pl/sql реально на порядок круче pgsql по возможностям, лаконичности, ориентации на быстодействие, и тд.
Из возможности БД — партиции явно еще не продакшин да и базових возможностей партиций на порядок меньше, такие фичи как кеш резалт — просто волшебная палочка.
Да и отсуствие merge. Оптимизатор намного круче и тд. Ето то что что пришло на ум за несколько минут. Да и скаждой новой версией Оракл не перестает удивлять.
Тут писали что t-sql крутой, для меня он реально топорний. Я с трудом представляю что кто то решится писать всю бизнес логику на t-sql или на pgsql. C ораклом на такое решится без проблем. Там управляемость и скорость, которою очень сложно достичь на высокоуровневых языках.
P.S. Неохота разводить холивар БЛ БД VS С\С+\C#\JAVA\…
Если по сравнению pl/sql реально на порядок круче pgsql по возможностям, лаконичности, ориентации на быстодействие, и тд.

не довелось так глубоко изучить, но там от версии к версии все очень таки разное даже в самом pl/pgsql
А есть еще:
PL/Java
PL/Lua
PL/Perl
PL/PHP
PL/Python
PL/R
PL/Ruby
PL/Scheme
PL/Sh
PL/Tcl
PL/V8

И глядя на этот список есть подозрение что там можно найти искомое)

По партициям в принципе согласен, хотя в 10ке уже очень все приличненько.

Я с трудом представляю что кто то решится писать всю бизнес логику на t-sql или на pgsql.

Я видел примеры реализации логики на v8 и выглядело все довольно здорово.
Да я знаю про весь етот зоопарк. Но ведь чтоб PL/… вызвать SQL или же наоборот в запросе обратится к процедуре на PL/… теряется очеть много ресурсов. И все ето очень не нативно(как то сбоку к БД). В оракле етому (скорости переключение контекста) уделяется огромное внимание. В плоть до того что сделали хинт процедурам указивающий что процедура специально создана для SQL. Кроме того возможможность компелировать в нативний код. + Разбор SQL делается на момент компиляции и тд. Ведь основноя задача встоеного язика работать з базой. А здесь все намного полутше в оракла.
Да 100% писать код на C# или JAVA намного удобнее чем на PL/SQL за счет GUI синтаксиса и тд. Но когда задача работать с транзакциями и даними Pl/sql действительно хорош.

Имхо, мне кажется тут самый главный затык именно в репликации. В реляционках оно исторически сложнее по многим причинам, и если в MySQL репликация действительно лучше, стабильнее и "правильнее" чем в Postgre, то еще очень большой вопрос что лучше -30% на ноду из-за странного оптимизатора (проценты), или невозможность распределять корректно чтения в кластер (разы).

Кривая оптимизация запроса — это не какие-то 30%, а миллион раз.
Ну только лишь оптимизация я бы конечно не сказал что миллион. Но в совокупности очень может быть. Те же, например, функциональные индексы могут давать огромный прирост, если фунцию можно объявить immutable.

Возможностей море. Не так давно знакомые делились что перенесли обработку данных внутрь базы на v8 и получили существенный прирост скорости обработки данных. Обрадовались и засунули туда еще больше данных через FDW. Когда много возможностей это всего хорошо.
Да нет, когда идет полный обход таблицы вместо обращения через индекс — то на больших базах может и чего похуже миллиона раз получиться.
30%? Простите, вы шутите? Я могу руками, на относительно небольшом запросе, mysql прибавить работы раза в 3 как минимум вообще не раздумывая. Я в свое время когда только переходил на PG взял большой запрос: 12 джоинов, вложенные выборки, группировки, и начал его всячески изощренно гнуть. На pg базовое время выполнения оптимального для mysql запроса сразу же было лучше и изменить мне его удалось в рамках 10%, а вот на mysql время выполнения разнилось в разы.
На pg базовое время выполнения оптимального для mysql запроса

А оптимального для mysql?
Я ни в коем случае не пытаюсь похвалить mysql, я просто хочу сказать, что есть случаи, когда возможность корректного scale out (и внезапно здесь в этой роли mysql) важнее возможности scale up и перфоманса одной конкретной ноды.

А оптимального для mysql?

Таки да, я специально уточнил.

Я ни в коем случае не пытаюсь похвалить mysql, я просто хочу сказать, что есть случаи, когда возможность корректного scale out (и внезапно здесь в этой роли mysql) важнее возможности scale up и перфоманса одной конкретной ноды.

Возможно. Если действительно грамотная архитектура, вылизанные запросы и оптимальная конфигурация. В противном случае это попытка отложить проблемы костылями.
Вам, пожалуй, стоит устроиться в Убер и сделать всё красиво :)
Чтобы меня там начали спрашивать о том как устроен системный кеш линуха до того как я взгляну на базу? Нет, спасибо, я это проходил раз 5 уже.
К тому же мне не нравицо убер. А комфорт при работе для меня главное.
Дык вы не водителем напрашивайтесь, а db engineer'ом :)
А что, все по умолчанию должны хотеть в большие компании?
Кстати, знаете, мой скептицизм не на ровном месте. Заглянешь в какой нить сайтик на битриксе со смешным количеством данных, который нормальный сервак насилует, а там таблица по принципу «все сюда» и без каких либо индексов, вешаешь индекс и сразу нагрузка падает на 95%.

В эру вап сайтов у меня в сервисах был 1 млн пользователей, более 600 млн личных сообщений (активно удаляемых) и все бегало очень шустро на IBM x346, при том тчо параллельно там был форум с десятками тысяч сообщений в темах и счетчики посещаемости, обрабатывающие сотни млн хитов в сутки. А сейчас из каждого утюга с 10 млн строк в базе раздаются рассуждения об оптимизации и неоптимальности работы пг с кортежами.

Интересно, как Яндекс.Почта поживает на Postgres?

Я наверное странную вещь спрошу, но ситуация кажется мне несуразной.
Я не понимаю почему переход MySql -> Postgres и обратно возможен, а переход на более новую версию Postgres нет.
Я не понимаю почему в том что компания выбрала продукт не проверив его виноват продукт?
Я не понимаю почему они, как пологается взрослым людям, не работали с обоими решениями паралельно, убеждаясь в надежности и правильности выбора хотя-бы пол года — год.

Не надо делать поспешных решений, продиктованых модой или давлением сверху, тогда и не будет переходов на разные базы данных раз в три года.
И не будет необходимости искать виноватых.
Я не понимаю почему переход MySql -> Postgres и обратно возможен, а переход на более новую версию Postgres нет.

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

«почти без даунтайма»? — позволю себе не согласиться.
Компания такого уровня должна иметь в архитектуре запланированные простои одного или нескольких серверов баз данных. И уметь это решать на уровне общей архитектуры проекта.
Конечно, если такие вещи не запланированы вначале, их не просто сделать потом.
Но можно. И нужно.
А все остальное — отговорки. Я работал над продуктом который использовал в отдельные моменты времени 3 разных сервиса хранения информации. И имел ( да и сейчас имеет) решения для случая когда не то что сервер, когда датацентр умирает.
Весь этот плач о «прохой базе данных» — это стыдно и не профессионально. Убер никто не просил использовать решение не проверив его.

И сводить разговор к «MySql vs Postgres» это не этично.
Если я буду резать хлеб бензопилой и потеряю руку, виновата ли в этом бензопила?

А конкретику можно. Как вы видите такую архитектуру?

Для конкретики нехватает информации о внутреннем устройстве балалайки.

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

Это не что-то новое. Это способ иметь работаюший продукт и не шарахаться по непровереным технологиям.

Но это все — тот этап когда база данных проверена и выбрана.

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

Пример — Mongo не выдерживает проверок, тестовый кластер из 4х машин под нагрузкой при уходе одного их серверов падает в осадок. Не всегда. Но падает. И если этого можно добиться на стенде — то в бою такой кластер сам загнется. Без вашей помощи.

Как достигается гарантированность консистентности при чтении с нескольких потенциально не полных реплик?

Правильным моделированием модели данных
>> То есть в начале всегда читаем из старой базы, и на фоне проверяем что в новой данные тоже есть ( а если нет — дотягиваем).
А если они есть везде, но разные?
Они могут быть везде. Для этого используются версии записей и прочие стандартные схемы.
И как сделать версионность данных без единой блокировки в ДБ? Блокировать сущность на уровне приложения? Но это ведь опять единая точка отказа.
Зачем блокировать?
Мы опять приходим к тому с чего на самом деле начинался «NoSql» — к версиям данных, Lamport timestamps например.
Но если мы уже решили «заморочиться» и устроить NoSql — то зачем нам MySql и PostgreSql в принципе?
что-бы апликативно принимать решения + иметь в каждой базе целые и консистентные данные.
В реальных сценарях, когда данных очень много, NoSql решает больше проблем чем создает.
Почему Booking пишут под mysql нужные им фичи, а Uber не смогла/не стала?

Не нашёл на странице упоминания schemaless.


ДевКонф решил хайпануть на холиваре. Не похвально.

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

Угу, мопед не мой.
Ну дак и писали бы про устройство субд в общем виде. Есть мол вот так, а есть вот так.


Убер — это гигантская корпорация, она живет в первую очередь своими корпоративными законами. Они переделали систему, сделали там schemaless, таким образом они избавились и от mysql и от postgres.


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

А разве были ещё?

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

Блин, ну данный пост на доклад по статье. Он же по этой статье! :)

Автор, перечитайте, пожалуйста, свой доклад, очень много ошибок, которые явно возникли при редактировании. Например «То есть, у PostgreSQL есть некий ореол серьезный, солидная СУБД, совершенный, без недостатков.» или «но большинство проблем, которые описывает Uber уже на основе реальной эксплуатации, я в смог определить правильно.»

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