Как выбрать хранилище данных для следующей новой блестящей штуки

Примечание. Это технический пост в блоге, написанный главным инженером Сильвией Ботрос и впервые опубликованный в блоге Sysadvent 25 декабря 2017 г.

Базы данных могут быть сложными. Знаете, что сложнее? Выбор одного в первую очередь. Это сложно, работаете ли вы в новой компании, которая все еще ищет свой продукт/рынок, или в компании, которая нашла свою аудиторию и просто расширяет предложение продукта.

При создании новой вещи одной из самых первых частей этого процесса проектирования является то, какие хранилища данных мы должны использовать, и должны ли они быть одинарными или множественными? Должны ли мы использовать реляционные хранилища или нам нужно выбрать хранилище значений ключа? Как насчет параметров времени? Должны ли мы также добавить некоторые распределенные повторы журналов?

Так. Много. Опции…

В этой статье я попытаюсь описать процесс, который, как я надеюсь, будет определять это решение, и, где это применимо, объяснить, как размер и зрелость вашей организации могут повлиять на это решение.

Базовые требования

Данные — это кровь любого продукта. Даже если мы планируем использовать более передовые технологии для хранения состояния приложения (поскольку MySQL или Postgres больше не «крутые»), все, что мы выбираем, по-прежнему остается хранилищем данных и, следовательно, требует строгости при выборе. делаем наш выбор.

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

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

• Скорость роста: как сами данные или доступ к ним должны измениться со временем?
• Как команда по выставлению счетов будет использовать эти новые данные?
• Как команда ETL будет использовать эти данные?
• Какие требования к точности/непротиворечивости ожидаются для этой новой функции?
• Какой промежуток времени для такой согласованности является приемлемым? Приемлема ли коррекция постобработки?

Найдите контекст, о котором не сказано

Выбор хранилища данных не является выбором, зарезервированным для DBA или группы эксплуатации или даже просто для инженера, пишущего код.

Зрелые организации с известным адресным рынком должны прийти к решению от заинтересованных сторон со всей организации.

Если требования от команды продукта соответствуют дюжине хранилищ данных, как вы определяете требования, которые не были явно заявлены?

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

Многие подразумеваемые вещи могут заставить вас потерпеть неудачу в этой ловушке «слишком много вариантов». Это включает, но не ограничивается:

• Неполные списки функций
• Требования к производительности, которые не указаны явно
• Потребности в согласованности, которые предполагаются
• Скорость роста не указана
• Потребности в выставлении счетов или запросе ETL, которые еще не доступны/известны

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

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

Составьте свой список

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

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

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

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

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

Выбери свой яд

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

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

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

• Хорошо ли это хранилище данных работает при запросах сканирования?
• Полагается ли это хранилище данных на протокол сплетен для репликации данных? если да, то как он обрабатывает сетевые разделы? Сколько данных связано с этими сплетнями?
• Есть ли у этого хранилища данных единая точка отказа?
• Насколько зрелыми являются водители в сообществе, чтобы говорить об этом, или вам нужно перекатывать свои собственные?
• Этот список может быть огромным

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

Таблицу и выпекать!

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

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

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

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

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

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

Документируйте свой выбор

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

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

Выводы

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