После того, как мы объявили, что VideoAmp завершила переход с MongoDB на Postgres, многие люди обратились к нам. Для нас это была целостность данных. Мы заложили в бюджет 6–8 недель на миграцию моделей и укрепление тестов; мы сделали это за 3,5 недели от начала до конца!

SELECT * FROM database_history
Чтобы понять контекст принятия решений, я кратко объясню свою позицию. Исторически я был мыслителем и мастером в области реляционных баз данных. Мой наставник по SQL, Стив Янг, также был дипломированным бухгалтером и научил меня 1000-строчным хранимым процедурам и удобным для бухгалтерского учета дампам данных, от которых у вас кружилась голова. Когда на сцену вышли хранилища документов, такие как MongoDB, я не сразу отреагировал…

The Baby and the Bathwater за последние 4–5 лет я создал несколько десятков приложений MEAN меньшего масштаба («М» — монго), предназначенных для небольшого числа пользователей и развернутых для оборудование для микроэкземпляров и Heroku. Это были инструменты с высоким ROI, но для небольшого круга корпоративных пользователей. В хранилище документов есть много полезного для многомерных данных и быстрого ввода/вывода со структурами JSON; это сочетание, созданное на небесах производительности в сочетании с Javascript. Это мило и легко!

После прочтения этой несколько устаревшей тирады: http://pastebin.com/FD3xe6Jt
я стал равнодушен к этим недостаткам, пока приложению не понадобился масштаб. Вот почему мы выбрали его на раннем этапе с VideoAmp; чтобы работать быстрее с node.js.

Перенесемся в сегодняшний день: у нас есть около 30 талантливых инженеров по API, платформам данных и науке о данных, а также несколько экспертов по postgres. Они вздрагивали, хмурились и критиковали слабые стороны монго и неспособность (без уровня модели в языке программирования) обеспечить строгую целостность данных. Как насчет таких магазинов, как наш, которые активно используют Node и scala? Как приложение обеспечивает целостность модели без двойного обслуживания моделей на нескольких языках?
Это создает больше проблем, чем решает….

Слабая связь, SOA, микросервисы в стороне, мы уже выиграли, поместив строгие правила в схему БД и позволив любым языкам (python, node.js, scala) общаться с ней.

Создание миграции
 Итак, в качестве хакерского проекта мы решили создать приложение для миграции, которое перешло с mongo на postgres, используя Bookshelf в качестве уровня модели для node.js. Все началось со строгой схемы, которая сопоставляла типы массивов из монго с перечисляемыми типами в postgres. Дочерние документы в монго стали дополнительными таблицами с сопутствующими таблицами связей и внешними ключами. Примерно через 3–4 дня миграция была завершена, и оттуда ее взяла на себя команда API.

Удивительно, сколько мусора накопилось в нашей базе данных mongo за 18 месяцев разработки. Конечно, часть хлама была вызвана отсутствием дисциплины у наших инженеров, но можно утверждать, что это была такая небрежная среда, которая способствовала тому, что данные со временем стали несогласованными.

Например, когда вы меняете перечисления в mongodb, вам нужно будет создать приложение для миграции, чтобы исправить данные… если вы хотите…. или нет…. но сама БД не будет жаловаться. Строгая типизация и проверка схемы защищают нас от этой проблемы. Таким образом, вместо «CPM», «CPM», «CPM» в качестве данных это просто «CPM». Вместо полей, которые могут присутствовать или отсутствовать, мы теперь явно о них. Точно так же внешние ключи защищают нас от сиротских отношений.

Утро после
 Теперь мы движемся вперед полным ходом, запуская новые функции. Каждый инженер обладает чувством понимания и уверенности в том, что наши данные являются цельными. Мы используем хранимые процедуры и ловушки, которые составляют основу нашего контрольного журнала; независимо от того, какое приложение вносит изменения; мы не полагаемся на прикладной уровень, чтобы спасти наши задницы, и мы не задаемся вопросом, возится ли инженер вручную с записью. Мы безнаказанно добавили несколько новых функций, и, что наиболее важно; мы подняли боевой дух наших инженерных команд, поскольку postgres гораздо больше соответствует их прошлому опыту.

Я не ненавижу MongoDB, потому что она помогла нам на этапах прототипирования, и было полезно делать дерьмо в небольших «одноразовых» проектах. Теперь, когда VideoAmp расширяет нашу инженерную команду и количество наших клиентов, было жизненно важно отказаться от него, потому что он продвигал методы «Loosey Goosey».

Первоначально опубликовано на https://www.linkedin.com 19 ноября 2015 г.