Бизнес работает круглосуточно. Это включает в себя все, от веб-сайта, бэк-офиса, цепочки поставок и так далее. В другой раз все запускалось партиями. Еще несколько лет назад операционные системы были приостановлены, чтобы данные можно было загрузить в хранилище данных и запустить отчеты. Теперь отчеты о том, как обстоят дела в данный момент. Нет времени на ETL.
Большая часть ИТ-архитектуры по-прежнему основана на звездообразной системе. Операционные системы наполняют хранилище данных, которое затем наполняет другие системы. Специализированное программное обеспечение для визуализации создает отчеты и информационные панели на основе «склада». Однако это меняется, и эти изменения в бизнесе требуют адаптации как баз данных, так и системной архитектуры.
Меньше копий, лучше базы данных
Часть большой миграции в облако и усилия по масштабированию за последнее десятилетие привели к использованию множества специально созданных баз данных. Во многих компаниях веб-сайт поддерживается База данных NoSQL, в то время как критически важные системы, связанные с деньгами, находятся на мейнфрейме или в реляционной базе данных. Это только поверхность вопроса. Для многих задач используются еще более специализированные базы данных. Часто эта архитектура требует перемещения большого количества данных с использованием традиционных пакетных процессов. Операционная сложность приводит не только к задержке, но и к сбоям. Эта архитектура не создавалась в масштабе, а была собрана вместе, чтобы остановить кровотечение.
Базы данных меняются. Реляционные базы данных теперь могут обрабатывать неструктурированные, документированные данные и данные JSON. Базы данных NoSQL теперь имеют хотя бы некоторую поддержку транзакций. В то же время распределенные базы данных SQL обеспечивают целостность данных, реляционные данные и исключительную масштабируемость, сохраняя при этом совместимость с существующими базами данных и инструментами SQL.
Однако этого самого по себе недостаточно. Линия между транзакционные или операционные системы и аналитические системы не может быть границей. База данных должна обрабатывать как множество пользователей, так и длительные запросы, по крайней мере, большую часть времени. С этой целью в транзакционные/операционные базы данных добавляются аналитические возможности в виде столбцовых индексов или возможностей MPP (массово-параллельной обработки). Теперь можно выполнять аналитические запросы к некоторым распределенным операционным базам данных, таким как MariaDB Xpand (распределенный SQL) или Couchbase (распределенный NoSQL).
Никогда не извлекать
Это не означает, что технология находится в таком месте, где специализированные базы данных не нужны. Ни одна действующая база данных в настоящее время не способна выполнять петабайтную аналитику. Есть крайние случаи, когда ничего, кроме временных рядов или другой специализированной базы данных, не будет работать. Хитрость в том, чтобы упростить вещи или добиться аналитики в реальном времени, заключается в том, чтобы избегать извлечений.
Во многих случаях ответ заключается в том, как в первую очередь собираются данные. Вместо того, чтобы отправлять данные в одну базу данных, а затем извлекать данные из другой, транзакция может быть применена к обеим. Современные инструменты, такие как Апач Кафка или Амазонка Кинезис включить этот вид потоковая передача данных. Хотя этот подход гарантирует, что данные будут доставлены в оба места без задержек, он требует более сложной разработки для обеспечения целостности данных. Избегая принудительной передачи данных, как транзакционные, так и аналитические базы данных могут обновляться одновременно, что позволяет проводить аналитику в реальном времени, когда требуется специализированная база данных.
Некоторые аналитические базы данных просто не выдерживают этого. В этом случае в качестве временной меры можно использовать более регулярные пакетные загрузки. Однако для эффективного выполнения этого требуется, чтобы исходная операционная база данных выполняла более длительные запросы, возможно, во время пиковой нагрузки. Это требует встроенного столбцового индекса или MPP.
Базы старые и новые
Базы данных клиент-сервер были потрясающими в свое время. Они эволюционировали, чтобы эффективно использовать множество процессоров и контроллеров для обеспечения производительности самых разных приложений. Однако клиент-серверные базы данных были разработаны для сотрудников, рабочих групп и внутренних систем, а не для Интернета. Они стали абсолютно несостоятельными в современную эпоху веб-систем и вездесущности данных.
Многие приложения используют множество различных баз данных дымохода. Преимущество — небольшой радиус взрыва, если один упадет. Минус в том, что постоянно что-то ломается. Объединение меньшего количества баз данных в распределенную структуру данных позволяет ИТ-отделам создавать более надежную инфраструктуру данных, которая обрабатывает различные объемы данных и трафика с меньшим временем простоя. Это также означает, что вам придется меньше перемещать данные, когда придет время их проанализировать.
Поддержка новых бизнес-моделей и операционная аналитика в режиме реального времени — это лишь два преимущества архитектуры распределенной базы данных. Другой заключается в том, что с меньшим количеством копий данных понимание происхождения данных и обеспечение целостности данных становятся проще. Хранение большего количества копий данных в разных системах создает большую вероятность того, что что-то не совпадет. Иногда несоответствие — это просто разные временные индексы, а иногда — настоящая ошибка. Объединяя данные в меньшем количестве и более мощных системах, вы уменьшаете количество копий и меньше проверяете.
Новая архитектура реального времени
Полагаясь в основном на распределенные базы данных общего назначения, которые могут обрабатывать как транзакции, так и аналитику, и используя потоковую передачу для этих более крупных аналитических случаев, вы можете поддерживать оперативную аналитику в реальном времени, которая требуется современному бизнесу. Эти базы данных и инструменты легко доступны в облаке и локально и уже широко развернуты в рабочей среде.
Изменения сложны и требуют времени. Это не просто техническая проблема, а кадровый и логистический вопрос. Многие приложения были развернуты с архитектурой «трубопровод» и живут отдельно от цикла разработки остальной инфраструктуры данных. Однако экономическое давление, растущая конкуренция и новые бизнес-модели подталкивают к этим изменениям даже самые консервативные и стойкие компании.
Тем временем многие организации используют миграцию в облако для обновления своей ИТ-архитектуры. Независимо от того, как и почему, бизнес теперь работает в режиме реального времени. Архитектура данных должна ему соответствовать.
Эндрю С. Оливер — старший директор по маркетингу продуктов в МарияДБ.
—
New Tech Forum представляет собой площадку для изучения и обсуждения новых корпоративных технологий с беспрецедентной глубиной и широтой. Выбор субъективен и основан на выборе технологий, которые мы считаем важными и представляющими наибольший интерес для читателей InfoWorld. InfoWorld не принимает маркетинговые материалы для публикации и оставляет за собой право редактировать весь предоставленный контент. Все запросы направляйте на [email protected].