Антишаблоны запуска

Так что этот пост может показаться натяжкой, но у меня есть две или три точки данных, так что пора провести линию. Я присоединился к двум стартапам, в которых были засеяны инженеры, нанятые из крупных финансовых компаний (я также унаследовал команду с такими же характеристиками внутри более крупной фирмы). Оправдание для таких наймов обычно примерно такое: «Ну, ‹ вставьте здесь название крупной финансовой компании › нанимают только лучших, а затем они создают потрясающие технологии, так что инженер оттуда будет знать все, что они нужно создать технологию для моего стартапа ». На диаграмме ниже показано, что происходит дальше.

Проблема с этим рассуждением заключается в том, что большая часть инженерных работ в этих компаниях полагается на инфраструктуру и плечи тех, кто ушел раньше. В стартапе нет плеч! Многие из этих инженеров скажут вам, что они могут создать то, что ‹вставить здесь название крупной компании по оказанию финансовых услуг› было быстрее, с их лидирующими позициями и с использованием выбранной ими технологии. К сожалению, в большинстве случаев это неправда.

Вот пример результатов подбора персонала / создания стартапа с использованием этого подхода:

Что вы имеете в виду, что у таблицы нет первичного ключа?

Что бы вы сделали, если бы присоединились к компании в 2017 году, у которой не было первичных ключей в своих базах данных? Что ж, вот что я сделал. Я уже некоторое время работаю техническим директором стартапа, и когда вы присоединяетесь к стартапу, находящемуся на стадии роста, все всегда хуже, чем вы можете видеть со стороны. Но я никогда раньше не видел ничего подобного.

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

Представьте, если хотите, небольшую стартап-компанию без инженеров. Они нанимают умного инженера из крупной финансовой компании.

Этот инженер знает Java как свои пять пальцев. Они любят Java. Тяжеловесная Java. Они происходят из мира фреймворков, абстракций и слоев библиотек, которые поддерживаются другими командами.

Этого инженера просят быстро построить базу данных. Поэтому они выбирают технологию, которую знают, и изо всех сил создают свою собственную архитектуру приложений на основе Java.

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

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

Теперь protobuf позволяет выражать схему в простой для управления форме. Вот отрывок:

А вот MySQL DDL для базовой базы данных:

Любые вопросы? Кажется достаточно простым. Теперь вам просто нужно сериализовать ваш protobuf в блог и сохранить его в таблице!

Плюсы

  • У вас есть управление версиями (в протобуфе!)
  • У вас сильная типизация (Java-naughts любят строгую типизацию)
  • Вы можете написать свой собственный слой DAO!
  • Использование магической горячности генерации кода и строгой типизации!
  • Да, и мы должны использовать активную загрузку, поэтому ваши графы объектов требуют сканирования таблиц почти каждой таблицы!
  • Безопасность! Ваши данные запутываются, поэтому никто без protobuf не может их «расшифровать».

Минусы

  • Нет первичных ключей
  • Нет вторичных ключей
  • Каждый запрос превращается в сканирование таблицы, потому что индексов нет
  • Для просмотра данных вам необходимо десериализовать каждую строку и проверить каждую из них, чтобы найти строку, которую вы ищете.
  • Производительность за пределами нескольких тысяч строк ОТСТУПАЕТ
  • Невозможно использовать SQL для запроса или исправления ошибок
  • Нет возможности использовать готовые инструменты отчетности
  • Невозможно нанять членов команды, разбирающихся в этой технологии

Итак, что же нам делать? Что бы вы сделали? С чего вообще начать?

JSON спешит на помощь! Но сначала ключи

Поскольку структуры данных поддаются модели на основе документов, мы исследовали Mongo, Cassandra и Postgres. Учитывая наши долгосрочные цели, сочетание реляционных хранилищ и хранилищ документов имело больше смысла. Мы выбрали Postgres и JSON в качестве нашей будущей архитектуры.

Итак, мы создали план - план, который состоял из нескольких шагов:

  • Переход с MySQL на Postgres (доступ к данным Java в этих двух базах данных должен быть идентичным)
  • Десериализуйте protobuf в JSON и создайте параллельный уровень данных (копии объектов protobuf в формате JSON)
  • Протестируйте живых bejeepers вне нашего уровня данных
  • Переключитесь на JSON в качестве основного
  • Денормализовать JSON в представления

Но прежде чем мы перейдем к Postgres, все инструменты, которые позволяют это сделать, предполагают, что у вас есть первичные ключи! Поэтому мы добавили шаг 0, чтобы обеспечить соблюдение ограничений первичного ключа, и шаг 0.5, чтобы удалить повторяющиеся строки ( Я не буду ни подтверждать, ни отрицать, что у нас могли быть повторяющиеся первичные ключи в этой базе данных). И множество шагов 0,5 для тестирования, тестирования, тестирования, тестирования, тестирования и тестирования.

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

На то, чтобы сделать это безопасным, надежным и малотравматичным способом, потребовалось восемь месяцев. Команда инженеров CommonBond раскрутила этот проект и реализовала его с минимальным влиянием на производство.

Что бы вы сделали?