Комментарии 124
Но ведь так и есть.
Они мало что знали о PostgreSQL
весело…
это точно убер? (сарказм)…
выглядит так: перестроили под то, о чем мало знали, походили по граблях, узнали больше о том как нужно было, решили «проще вернуться на то о чем знают хорошо, чем повторно перестроить на postgresql учитывая набитые шишки».
При такой организации в InnoDB требуется больше логических чтений при извлечении через не праймари индекс. К слову непосредственный индекс и в Oracle используется, вроде. Т.е. здесь явно компромисная ситуация.
Вообще на мой взгляд оба варианта довольно странные в комплексе. Вот почему:
- Postgres версионный, а значит на каждый чих обновляет все индексы. Им бы как раз использовать косвенную адресацию, чтоб экономить на обновлении хоть как-то. (Разве там нет скрытой косвенной адресации через версии?)
- InnoDB не версионный, а с сегментами отката. Вот им бы прямая адресация не пила столько крови, поскольку положение строчки в куче не меняется при обновлении.
Получается идеальная комбинаци у Oracle: прямая адресация и сегменты отката.
Это вроде давнишнее событие, и эксперты по PostgreSQL давно тщательно проанализировали данный доклад и сделали вывод: Uber мечется из стороны в сторону, толком не разобравшись в том, что им нужно, и как это настроить, прыгают с базы на базу, рассчитывая, что оно само магическим образом заработает так, как им хочется.
Легко найти комментарии экспертов к данному докладу, где объясняется, как Uber неправ в каждом пункте.
Ээээ. Вы статью читали? Там собственно разбор мнений этих самых экспертов. И что-то один из главных разработчиков не так категоричен, как вы.
Победа NoSQL это из разряда слышали акустические волны, но источник не нашли. Да, есть сферы деятельности, где NoSQL хорош. Например хранение не согласованной информации: фоточки, посты, профайлы пользователей. Все они довольно независимы друг от друга логически и могут обновляться не согласовано.
А вот например бухгалтерия, платежные или другие транзакции, и вообще все сферы, где необходимо одновременно и согласованно изменять много значений по-прежнему висят на SQL. Более того, в Big Data сейчас серьёзный откат именно в эту область, правда уже по причине тезиса, что Big Data не должны быть Bad Data.
Сейчас зачастую призодится слышать что без NoSQL это вообще невозможно сделать.Невозможно сделать… что? Google Adsense уехал с MySQL на свою собственную систему несколько лет назад, но на NoSQL не перешёл.
Да и есть подозрение, что 4-5 лет назад, когда они ещё на MySQL жили там нагрузка была такая, что Uber и рядом не лежал.
— и как это поможет исправить переход на MySQL?
Если эту фразу интерпретировать, как «Ну Uber сами дураки», то можно тушить свечи. А так… Общее ощущение что молодые ребята вкалывают, принимают волевые решения. Удачи.
Что до смены версий, разворачивать репликацию для перехода на новую версию это конечно один из подходов, но сказать чтобы это было интересно я не могу. Развертка триггеров дело вполне по плечу среднему разработчику, и сделать скрипт для перехода на обновленную версию дело не сложное. Видимо были какие — то другие приоритеты. Может им кто — то за перехода на MySQL обещал грант подкинуть на разработку робота — водителя, или помочь замять дело с недавней гибелью человека.
Постгрес как база лучше чем MySQL. Это однозначно. И кластеред индекс у неё есть. Автор лукавит. Это создаваемая по умолчанию секвенция строк. Выход на неё по бинарному древу поиска там по — моему с 7-й версии. В общем улучшение репликации пожалуй существенная вещь, но сказать, чтобы она была решающей трудно.
в mysql вроде бы с этим так себе.
Так, pg_logical прекрасно вошел в 10 версию: www.postgresql.org/docs/10/static/logical-replication.html
C MVCC vs UNDO тоже ситуация на месте не стоит: 1, 2, 3. Опять-таки, с учетом темпов развития, глядишь уже в 12 версии появится.
А то разговоры о том, что «всё уже очень крута у нас, только возьмите версию, которая вышла меньше полугода назад» — это нормально для хайповой библиотечки, которая только год назад появилась.
От продукта, которому двадцать с лишним лет ожидаешь, что уж такие-то базовые вещи в нём реализованы давным-давно.
Взять эталон индустрии разработки ПО. Microsoft SQL Server — физическая репликация ( mirroring ) появилась только с Service Pack 1 SQL Server 2008, то есть в 2010-м, мульти — узловая физическая репликация с доступом для чтения резервной копии в версии 2012, ошибки, которые лишали её возможности нормально работать поправили только в SP2, выпущенного 12-го Июля 2016-го года.
Сравнивая поддержкой репликации СУБД Postgres, мне кажется критика «хайповой библиотечки, которая только » не только не обоснована, но совершенно не отражает реальность.
А PostgreSQL до недавнего времени мучал людей всяким Slony и прочими trigger-based убожествами.
После того как MySQL отдали InnoDB, коммерческий продут, а Оракл купила MySQL, примерно год — два назад MySQL выпустила новые фитчи для репликации, которые сделали её доступной. Они до сих пор глючат. Я это говорю не для того, чтобы сказать, что MySQL плох или хорош. Ваши утверждения носят характер маркетинговой рекламной кампании. Вам здесь не место. Занимайтесь этими глупостями в статьях, за которые Ваша фирма платит.
MySQL выпустила новые фитчи для репликации, которые сделали её доступной. Они до сих пор глючат
Это какие? Semi-Sync репликация? И что значит «доступной»?
Ваши утверждения носят характер маркетинговой рекламной кампании. Вам здесь не место. Занимайтесь этими глупостями в статьях, за которые Ваша фирма платит.
Ого, ничего себе, маркетологом меня еще никто не обзывал. И что же я рекламирую? 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 это позволяет…
Рискую отхватить минусов, но самый нормальный и самый стабильный во всех отношениях SQL Server — это Microsoft SQL Server. И в нем реализовано гораздо больше возможностей, чем во всех этих open source. Хочешь Row Versioning — включи одну настройку и работай. Не хочешь — работай с блокирующими апдейтами. Компрессия, репликация, отслеживание изменений таблиц, column store индексы, индексы с включенными полями, collation на каждую колонку, партиционирование, репликации, фэйловер кластер, always-on группы — возможностей хватит лет на 20 вперед. И все это доступно уже с версии 2012 как минимум (после этого уже вышли версии 2014 и 2016 и готовится очередная новая версия). MS уже не знает, что еще придумать, потому что их продукт превзошел всех конкурентов еще лет 10 назад. Ну разве что Oracle может поконкурировать.
По поводу стоимости лицензий да, все печально. Но продукт стоит того. Плюс есть Express версия, бесплатная.
Поддержка Linux уже появилась (RHEL, Ubuntu, SUSE)
Поддерживает кластер пользуясь инфраструктурой PKI, не требуя Windows Active Directory.
А уведомления о событиях аналогичные постгресовским NOTIFY/LISTEN в SQL Server уже появились?
И должен сказать что как-раз та часть которая OLAP целиком и полностью сделана на коленке.
А та часть которая MSSQL жрет ресурсы как-будто они бесплатны.
MS не знает что делать? Пусть займутся качеством, устойчивостью и прожорливостью. Там работы в их темпе на 10 лет хватит.
Остальные доводы — спекулятивные. Я миллион раз защищал оптимизатор MSSQL от нападок людей, которые просто не умели готовить годные ему запросы. Так что надо разбирать конкретные ситуации. Хотя, в плане чистого быстродействия я отдаю предпочтение MSSQL, но у Postgresql больше вариантов решений, в том числе и дающих существенный выигрыш.
Получилось либо удаление всех записей в одной большой транзакции с чтением удаляемых при этом данных, либо квадратичный алгоритм (оптимизатор упрямо сует в план запроса на удаление полный проход по таблице). Итог в любом случае один и тот же: если позволить данным скопиться, то их уже никогда не удастся оттуда вычитать.
Сложно сказать, я попробовал топорный DELETE FROM… WHERE id = ANY(ARRAY(SELECT id… LIMIT 1000) или… WHERE id < (SELECT MIN(id) + 1000 ...)
Пробовал вариант похожий на первый, он почему-то давал полное сканирование таблицы и Hash Join. Но подробностей не помню уже, год назад это было...
Если задача возникнет снова — попробую ваш второй вариант, он выглядит так как будто там негде накосячить.
1. Фильтровать при запросе каждой страницы — медленно
2. Между запросами выборка может измениться — привет, пропадающие записи и дубликаты
Правильное решение: выдать список идентификаторов (снепшот списка на конкретный момент времени), а потом отдельным пакетным запросом получить данные по интересующей части списка.
Но почему-то этот антипаттерн чуть более, чем везде.
А вот указать, от какой позиции листать дальше — я видел на FB (мобильной версии), reddit и blogspot… ой, и всё. Ну ладно, ещё кого-то я не знаю. Ну будет десяток имён на весь мир. И как это понимать?
Я бы понял, если бы вы сказали что-то вроде «ну ведь работает же и даже не выжирает всё, по крайней мере в 99% случаев». Но просто сослаться на AaP — «миллион мух/леммингов/etc. ничего не доказывают» это не более чем неконструктивно отмахнуться.
А меня исходно интересовало вообще, откуда берётся эта традиция листания по «страницам» вывода с непостоянной базой, что заставляет людей массово приходить к такому решению. Только традиция и примеры перед глазами, или есть ещё какой-то фактор?
Есть, кстати, ещё одно, идущее непонятно откуда, но тиражируемое чуть менее, чем всеми — это неуказание временно́го фактора в направлении листания. Опять же, хабр: «туда» это в прошлое. А почему собственно? На некоторых сайтах, кстати, наоборот. Явно «в прошлое» писал сам по себе разве что 3dnews.ru (и позже opennet.ru стал писать «раньше»/«позже», но это уже, извините, я попросил админа).
Люди не любят думать, поэтому просто делают как все, пока очередной трендсеттер не повернёт хайп в другую сторону. И тогда все срочно ринутся переделывать. При этом не важно на что. Ты либо в тренде и считаешься остальными такими же профессионалом на острие технологий, либо не в тренде и делаешь странные вещи, а то и вообще назовут твой подход bad practive, так как хайп на него уже прошёл.
Обычно эволюция разработчика идёт такая:
- Херачим из базы всё, что запросили.
- Понимаем, что данных много, а нужны не все. Ага есть стандартный паттерн, который прикручивается малой кровью — паджинация.
- Огребаем багрепортов на тему странного дублирования записей. Много думаем, придумываем один из вариантов выдачи снепшота всего списка и догрузки подробной информации по части элементов.
- Огребаем багрепортов на тему экспоненциального потребления ресурсов для моделей с перекрёстными ссылками. Наконец нормализуем выдачу.
- Огребаем багрепортов на тему долгой загрузки. Ага, модели жирные, а показываются из них 1-2 поля. Прикручиваем укзазание интересующих в выдаче полей.
Сразу сделать хорошо ведь совсем не дорого (один раз реализовать универсальный мееханизм фетчинга любых коллекций, или всять уже готовое решение). Но нет, всем нужно пройти через все эти болезненные рефакторинги, потратив куда больше ресурсов.
Вот именно это решается через CLR на раз и насколько помню последний раз делал это 3 года тому назад, даже не надо помечать как unsafe
Постгрес на фоне — просто лапочка для программиста. А что он медленнее — да пофиг же. Замена одной SQL-базы на другую ради 2-3x ускорения — это только очень большим и богатым может отбиться, остальным проще сервер в 2 раза дороже купить.
Хорошо, где у MS SQL транзакционный DDL?
Мне сильно нравится возможность Postgres в отдельной транзакции, никому не мешая (почти), накатить непростой апдейт на схему БД и откатиться, если что-то пойдёт не так.
если верить этому, то изменения видны ещё до коммита
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_Description, не является полноценной заменой простого comment on column. Это невероятно, но при попытке добавления MS_Description к столбцу таблица эксклюзивно блокируется, ее на некоторое время ни читать, ни писать нельзя. У тех, кто привык с другими базами работать, такие сюрпризы вызывают шок.
Или, например, такая нехитрая вещь, как %rowtype, когда в MSSQL появится?
В статье так и не нашел ответа на вопрос, какая реляционная СУБД лучше?
Всё зависит от задач. Скажем, если нужна интенсивная и небанальная работа с геоинформационными данными, PostgreSQL впереди планеты всей из-за упомянутого в статье расширения PostGIS.
Под «небанальной» работой с геоданными я подразумевал всё то, что выходит за рамки отслеживания координат пользователя в реальном времени и различных алгоритмов поиска в дорожном графе, что, по идее, и является основными задачами компаний типа Uber. И что, в принципе, не требует каких-либо специализированных средств в БД и просто моделируется стандартными типами данных и стандартными операциями. PostGIS же обеспечивает более богатый функционал: работа с 2D и 3D геометриями (точками, линиями, полигонами и коллекциями геометрий), операции создания, манипулирования, сравнения, выборки и прочее, относящееся к геометрическим (и географическим) представлениям данных. Можете сами оценить мощность набора операций в справочнике PostGIS Reference. Всё это заточено и оптимизировано под свои специализированные типы данных. Не скажу насчёт современного состояния MySQL в этом вопросе (что-то там сейчас появилось из этой области), но во времена миграции Uber на PostgreSQL ничего подобного в MySQL точно не было. Собственно, и претензии Uber к PostgreSQL лежат не в области работы с геоданными, а в неоптимальной низкоуровневой обработке данных под high load. О чём и статья. ;)
Так я пошутил)
На мой вопрос нет правильного ответа)
Хотя мне интересно, почему многие рассматривают постгрес исключительно вместе с постгис? Без гео составляющей в ней совсем совсем смысла нет?
Мне лично очень нравится поддержка JSONB и довольно могучий и гибкий полнотекстовый поиск. Опять же, возможно в свежих версиях MySQL всё это появилось, но из-за отсутствия NoSQL средств работать с версией 5.5 после PostgreSQL было откровенно грустно. Вот ниже коллеги подтверждают ту же мысль. ;) Вообще, если выбирать СУБД для новых проектов, однозначно нужно брать Postgres, а не MySQL.
Совместное с SQL использование эластики тоже проблематично т.к. не будет целостности данных.
Все мосты которые поддерживают связь эластики с другими базами — при рахрыве соединения не обспечивают согласованности данных в sql и эластике.
В этом смысле мне пока известны два решения — это orientdb в которуб встроена lucene и neo4j. При этим первая еще не очень стабильная а вторая платная.
И еще в h2 модно встроить lucene но там больше придется производить работы при индексации.
В orientdb все просто — объявляешь на поле индекс типа lucene и просто ищешь что нужно.
В области геокодирования и поиска адресной информации средств Postgres'овского FTS вполне достаточно, использование elasticsearch и аналогов тут будет очевидным overhead. Но всё зависит от задачи, конечно. ;)
Ну или же встроенного индекса типа lucene как в orientdb или h2
В PostgreSQL для этого есть расширение fuzzystrmatch.
Да и цитата с документации не внушает оптимизма
At present, the soundex, metaphone, dmetaphone, and dmetaphone_alt functions do not work well with multibyte encodings (such as UTF-8).
И уж простите, что я не верю в тот факт, будто они действительно упираются в столь низкие уровни. Как правило глянув в любую базу есть проблемы уже на стадии архитектуры, а в запросах порой такой ад творится, что не передать.
Их метания добавляют еще больше веса моим сомнениям. Имхо разработчик, который не просто попробовал перенести текущий функционал, а вкусивший pg или oracle, на Mysql не вернется уже никогда.
У каждой БД есть свои слабые и сильние стороны. И я считаю что 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 и выглядело все довольно здорово.
Да 100% писать код на C# или JAVA намного удобнее чем на PL/SQL за счет GUI синтаксиса и тд. Но когда задача работать с транзакциями и даними Pl/sql действительно хорош.
Имхо, мне кажется тут самый главный затык именно в репликации. В реляционках оно исторически сложнее по многим причинам, и если в MySQL репликация действительно лучше, стабильнее и "правильнее" чем в Postgre, то еще очень большой вопрос что лучше -30% на ноду из-за странного оптимизатора (проценты), или невозможность распределять корректно чтения в кластер (разы).
Возможностей море. Не так давно знакомые делились что перенесли обработку данных внутрь базы на v8 и получили существенный прирост скорости обработки данных. Обрадовались и засунули туда еще больше данных через FDW. Когда много возможностей это всего хорошо.
На pg базовое время выполнения оптимального для mysql запроса
А оптимального для mysql?
Я ни в коем случае не пытаюсь похвалить mysql, я просто хочу сказать, что есть случаи, когда возможность корректного scale out (и внезапно здесь в этой роли mysql) важнее возможности scale up и перфоманса одной конкретной ноды.
А оптимального для mysql?
Таки да, я специально уточнил.
Я ни в коем случае не пытаюсь похвалить mysql, я просто хочу сказать, что есть случаи, когда возможность корректного scale out (и внезапно здесь в этой роли mysql) важнее возможности scale up и перфоманса одной конкретной ноды.
Возможно. Если действительно грамотная архитектура, вылизанные запросы и оптимальная конфигурация. В противном случае это попытка отложить проблемы костылями.
К тому же мне не нравицо убер. А комфорт при работе для меня главное.
В эру вап сайтов у меня в сервисах был 1 млн пользователей, более 600 млн личных сообщений (активно удаляемых) и все бегало очень шустро на IBM x346, при том тчо параллельно там был форум с десятками тысяч сообщений в темах и счетчики посещаемости, обрабатывающие сотни млн хитов в сутки. А сейчас из каждого утюга с 10 млн строк в базе раздаются рассуждения об оптимизации и неоптимальности работы пг с кортежами.
Интересно, как Яндекс.Почта поживает на Postgres?
Я не понимаю почему переход MySql -> Postgres и обратно возможен, а переход на более новую версию Postgres нет.
Я не понимаю почему в том что компания выбрала продукт не проверив его виноват продукт?
Я не понимаю почему они, как пологается взрослым людям, не работали с обоими решениями паралельно, убеждаясь в надежности и правильности выбора хотя-бы пол года — год.
Не надо делать поспешных решений, продиктованых модой или давлением сверху, тогда и не будет переходов на разные базы данных раз в три года.
И не будет необходимости искать виноватых.
Я не понимаю почему переход MySql -> Postgres и обратно возможен, а переход на более новую версию Postgres нет.
Ну это им нужно было один раз сделать, а потом mysql обновлять почти без даунтайма.
Компания такого уровня должна иметь в архитектуре запланированные простои одного или нескольких серверов баз данных. И уметь это решать на уровне общей архитектуры проекта.
Конечно, если такие вещи не запланированы вначале, их не просто сделать потом.
Но можно. И нужно.
А все остальное — отговорки. Я работал над продуктом который использовал в отдельные моменты времени 3 разных сервиса хранения информации. И имел ( да и сейчас имеет) решения для случая когда не то что сервер, когда датацентр умирает.
Весь этот плач о «прохой базе данных» — это стыдно и не профессионально. Убер никто не просил использовать решение не проверив его.
И сводить разговор к «MySql vs Postgres» это не этично.
Если я буду резать хлеб бензопилой и потеряю руку, виновата ли в этом бензопила?
А конкретику можно. Как вы видите такую архитектуру?
Общая схема в таких случаях — любые данные аппликативно или через прокси пишутся в больше чем один мастер. В больше чем один вид баз данных. Тогда можно и проверить все перед тем как переключаться.
А чтение должно быть реализовано через серию «запасных аэродромов» типа если данных нет тут, поищем там.
То есть в начале всегда читаем из старой базы, и на фоне проверяем что в новой данные тоже есть ( а если нет — дотягиваем). Потом, после перехода, долгое время все еще пишем в обе, но читаем сначала из новой. И если чего-то нет — читаем из старой и дотягиваем отсутствующее.
Это не что-то новое. Это способ иметь работаюший продукт и не шарахаться по непровереным технологиям.
Но это все — тот этап когда база данных проверена и выбрана.
А до того надо протестировать кандидата на простых кейсах и убедиться что он подходит.
Простые кейсы разнятся от базы к базе, но если для NoSQL это проверка устойчивости кластера, скорость работы под нагрузкой и ростом данных, то для RDBM необходимо проверить скорость и способ репликации — в общем проверить теряет ли система данные в критичных ситуациях.
Пример — Mongo не выдерживает проверок, тестовый кластер из 4х машин под нагрузкой при уходе одного их серверов падает в осадок. Не всегда. Но падает. И если этого можно добиться на стенде — то в бою такой кластер сам загнется. Без вашей помощи.
Как достигается гарантированность консистентности при чтении с нескольких потенциально не полных реплик?
А если они есть везде, но разные?
Не нашёл на странице упоминания schemaless.
ДевКонф решил хайпануть на холиваре. Не похвально.
И я уже написал, что мне больше понравились подробности внутреннего строения СУБД, чем холиварные.
Угу, мопед не мой.
Ну дак и писали бы про устройство субд в общем виде. Есть мол вот так, а есть вот так.
Убер — это гигантская корпорация, она живет в первую очередь своими корпоративными законами. Они переделали систему, сделали там schemaless, таким образом они избавились и от mysql и от postgres.
Далее была крайне кривая статья от убер, без как бы то нибыло цифр. Потом человек сильно аффилированный с mysql что то начал хайпить. И вы туда же.
Сама тема очень интересная. Просто перечитывать предложения надо по нескольку раз чтоб понять смысл.
DevConf: переход Uber с PostgreSQL на MySQL