Эта статья была первоначально опубликована на mongoDB . Спасибо за поддержку партнеров, которые делают возможным использование SitePoint.
Черные дыры — это области в пространстве с таким сильным гравитационным воздействием, что ничто не может избежать. Не совсем разрушительно, как вы могли бы поверить, их гравитационные эффекты помогают управлять формированием и развитием галактик. Фактически, наша собственная галактика Млечный Путь вращается вокруг сверхмассивной черной дыры с массой Солнца в 4,1 миллиона раз больше. Некоторые предполагают, что никого из нас не было бы здесь, если бы не черная дыра.
С другой стороны, черные дыры также могут проноситься сквозь космос — часто со скоростью миллионы миль в час — разрывая все на своем пути. Говорят, что все, что делает их горизонтами событий, «точкой невозврата», никогда больше не увидят и не услышат, что делает черные дыры одними из самых интересных и страшных объектов в космосе.
Почему мы говорим о черных дырах, гравитационных эффектах и точках невозврата? Потому что нечто подобное происходит прямо сейчас в вычислительной технике.
Впервые разработанная Дейвом МакКрори в 2010 году , концепция «гравитации данных» обрабатывает данные так, как если бы это была планета или небесный объект с массой. По мере накопления данных в среде приложения и службы, которые полагаются на эти данные, будут естественным образом перемещаться в одну среду. Чем больше «масса» данных, тем сильнее «гравитационное притяжение» и тем быстрее это происходит. Приложения и сервисы имеют свою собственную гравитацию, но гравитация данных является самой сильной, особенно в том, что:
- Чем дальше находятся данные, тем сильнее влияние на производительность приложений и пользовательский опыт. Наличие приложений и сервисов рядом друг с другом снижает задержку, максимизирует пропускную способность и облегчает группам создание эффективных приложений.
- Перемещение данных имеет свою стоимость. В большинстве случаев имеет смысл централизовать данные, чтобы снизить эти затраты, поэтому данные обычно накапливаются в одном месте или среде. Да, распределенные системы позволяют организациям разделять данные различными способами для конкретных целей — например, для ограждения наборов данных по географическим границам в соответствии с правилами — но в этих разделах все еще желательно минимальное перемещение данных.
- И, наконец, усилия по оцифровке деловых и организационных действий, процессов и моделей (которые многие называют инициативами «цифрового преобразования») увенчаются успехом или провалом в зависимости от того, насколько эффективно используются данные. Если программное обеспечение является двигателем, с помощью которого происходит цифровое преобразование, то данные являются его топливом.
Как и в реальном мире, чем больше масса объекта, тем труднее его перемещать, поэтому гравитация данных также означает, что, как только ваша масса данных становится достаточно большой, также становится труднее (а в некоторых случаях почти невозможно) переехать. Что сейчас актуально, так это переход на облачные вычисления. Когда компании переходят в облако, им необходимо принять решение, которое будет иметь серьезные последствия в будущем — где и как они собираются хранить свои данные? И как они не позволяют гравитации данных в облаке превращаться в черную дыру данных ?
Для организаций существует несколько вариантов перехода от создания собственной ИТ-инфраструктуры к использованию ее в качестве службы в облаке.
Собственные табличные (реляционные) базы данных
Компании, стоящие за закрытыми табличными базами данных, часто наказывают своих клиентов за использование этих технологий на любой облачной платформе, кроме их собственной. Это не должно удивлять никого из нас. Это те же поставщики, которые в течение десятилетий полагались на продажу тяжелого проприетарного программного обеспечения с многолетними контрактами и годовой платой за обслуживание. Блокировка поставщика не является для них чем-то новым.
Организации, решившие использовать проприетарные табличные базы данных в облаке, также несут весь багаж этих технологий и получают мало облачных преимуществ. Эти базы данных масштабируются по вертикали и часто не могут использовать облачные архитектуры для масштабирования и эластичности без значительных компромиссов. Если доступно горизонтальное масштабирование данных между несколькими экземплярами, оно не является встроенным в базу данных и требует сложных конфигураций, изменений на стороне приложения и дополнительного программного обеспечения.
Подъем и перенос этих баз данных в облако не меняет того факта, что они не предназначены для использования облачных архитектур.
Табличные базы данных с открытым исходным кодом
Немного лучше обстоят дела с табличными базами данных с открытым исходным кодом, поскольку нет поставщика, который бы вводил штрафные цены, чтобы держать вас в облаке. Однако, подобно частным табличным базам данных, большинство этих технологий предназначены для вертикального масштабирования; масштабирование для полной реализации эластичности облака часто управляется с помощью хрупких конфигураций или дополнительного программного обеспечения.
Многие компании, работающие с этими базами данных в облаке, полагаются на управляемую службу, чтобы уменьшить свои операционные издержки. Однако четности функций на облачных платформах не существует, что делает миграцию сложной и дорогой. Например, базы данных, работающие в Amazon Aurora, используют специфичные для Aurora функции, которых нет в других облаках.
Собственные облачные базы данных
С проприетарными облачными базами данных очень легко попасть в ситуацию, когда данные поступают и ничего не выходит. Эти службы баз данных работают только в своем родительском облаке и часто предоставляют очень ограниченные функциональные возможности базы данных, что требует от клиентов интеграции дополнительных облачных служб для чего-либо, кроме очень простых случаев использования.
Например, многие проприетарные облачные сервисы NoSQL предлагают чуть больше, чем функциональность ключ-значение; пользователям часто нужно передавать данные в облачное хранилище данных для более сложных запросов и аналитики. Они также имеют тенденцию быть незрелыми в плане эксплуатации, что требует дополнительных интеграций и сервисов для защиты данных и обеспечения адекватной видимости производительности. И это не останавливается там. Новые функции часто вводятся в виде новых сервисов, и, прежде чем пользователи узнают об этом, вместо того, чтобы полагаться на одну облачную базу данных, они зависят от постоянно растущей сети облачных сервисов. Это усложняет получение данных.
Крупные поставщики облачных услуг знают, что, если они смогут получить ваши данные в одной из своих проприетарных служб баз данных, они доставят вас туда, где они вам нужны. И хотя некоторые могут возразить, что организациям на самом деле следует использовать эту новую, окончательную форму привязки к поставщикам, чтобы получить максимальную отдачу от облака, это не оставляет клиентам много вариантов, если их требования или правила данных изменяются. Что если облачный провайдер, которым вы не пользуетесь, выпускает услугу, изменяющую игру, которая вам нужна, чтобы обойти конкурентов? Что если они откроют центр обработки данных в новом географическом регионе, который вы выбрали по приоритетам, а у вас его нет в их дорожной карте? Что если ваш основной клиент потребует разорвать связь с вашим облачным провайдером? Это случилось раньше .
Это все сценарии, в которых вы могли бы извлечь выгоду из использования базы данных, которая работает везде одинаково.
База данных, которая работает одинаково … везде
По мере того, как вы переходите в облако, вы предотвращаете изменение силы тяжести данных и ограничивает свою гибкость — используйте базу данных, которая работает одинаково в любой среде.
Одним из вариантов для рассмотрения является MongoDB. Как база данных, она сочетает в себе гибкость модели данных документа со сложными запросами и индексированием, необходимыми для широкого диапазона вариантов использования, от простого значения ключа до агрегации в реальном времени, которая обеспечивает аналитику.
MongoDB — это распределенная база данных, разработанная для облака по своей сути. Избыточность для устойчивости, горизонтального масштабирования и географического распределения встроена в базу данных и проста в использовании.
И, наконец, MongoDB обеспечивает согласованное взаимодействие независимо от того, где оно развернуто:
- Для организаций, которые не совсем готовы к переходу в облако, они могут развернуть MongoDB в своих помещениях за своими собственными брандмауэрами и управлять своими базами данных с помощью расширенных операционных инструментов .
- Для тех, кто готов к переходу в облако, MongoDB Atlas предоставляет базу данных как полностью управляемую услугу более чем в 50 регионах на AWS, Azure и Google Cloud Platform. Встроенная автоматизация проверенных методов помогает сократить количество трудоемких задач администрирования баз данных, за которые отвечают группы, и не позволяет организациям перенести свои эксплуатационные накладные расходы в облако. Конечно, если вы хотите самостоятельно управлять MongoDB в облаке, вы можете это сделать.
- И, наконец, для команд, которые хорошо разбираются в облачных сервисах, MongoDB Atlas обеспечивает единообразный опыт работы в AWS, Azure и Google, позволяя разрабатывать многооблачные стратегии на единой унифицированной платформе данных.
Гравитация данных, без сомнения, окажет огромное влияние на то, как ваши ИТ-ресурсы объединяются и развиваются в облаке. Но это не значит, что вы должны попасть в ловушку. Выберите базу данных, которая обеспечивает единообразный опыт работы в разных средах и избегайте перехода через точку невозврата.