Антишаблоны запуска
Так что этот пост может показаться натяжкой, но у меня есть две или три точки данных, так что пора провести линию. Я присоединился к двум стартапам, в которых были засеяны инженеры, нанятые из крупных финансовых компаний (я также унаследовал команду с такими же характеристиками внутри более крупной фирмы). Оправдание для таких наймов обычно примерно такое: «Ну, ‹ вставьте здесь название крупной финансовой компании › нанимают только лучших, а затем они создают потрясающие технологии, так что инженер оттуда будет знать все, что они нужно создать технологию для моего стартапа ». На диаграмме ниже показано, что происходит дальше.
Проблема с этим рассуждением заключается в том, что большая часть инженерных работ в этих компаниях полагается на инфраструктуру и плечи тех, кто ушел раньше. В стартапе нет плеч! Многие из этих инженеров скажут вам, что они могут создать то, что ‹вставить здесь название крупной компании по оказанию финансовых услуг› было быстрее, с их лидирующими позициями и с использованием выбранной ими технологии. К сожалению, в большинстве случаев это неправда.
Вот пример результатов подбора персонала / создания стартапа с использованием этого подхода:
Что вы имеете в виду, что у таблицы нет первичного ключа?
Что бы вы сделали, если бы присоединились к компании в 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 раскрутила этот проект и реализовала его с минимальным влиянием на производство.
Что бы вы сделали?