Облачные службы данных
Экономические факторы приводят к появлению инфраструктур, обеспечивающих программные и вычислительные средства в виде служб, обычно называемых облачными (cloud) сервисами, или облачным компьютингом. Облачные сервисы могут обеспечить эффективность провайдерам приложений за счет как ограничения начальных капитальных вложений, так и сокращения со временем стоимости владения. Сегодня имеется набор разнообразных облачных сервисов, включая прикладные сервисы (salesforce.com), сервисы хранения (Amazon S3), вычислительные сервисы (Google App Engine, Amazon EC2) и сервисы данных (Amazon SimpleDB, Microsoft SQL Server Data Services, Google’s Datastore).
Эти сервисы демонстрируют многообразие преобразований архитектур управления данными, а на горизонте видно еще больше новых архитектур. Участники встречи предвидят, что многие будущие приложения, ориентированные на обработку данных, будут опираться на облачные сервисы данных.
Общей проблемой провайдеров облачных сервисов является потребность в компромиссе между функциональными возможностями и эксплуатационными расходами. В сегодняшних начальных сервисах данных обеспечиваются API, намного более ограниченные, чем в традиционных системах баз данных, с минималистским языком запросов и ограниченными гарантиями согласованности. Это затрудняет программирование приложений, но позволяет провайдерам облачных сервисов создавать более предсказуемые службы, в которых обеспечиваются соглашения об уровне обслуживания, трудно достижимые для полнофункциональных сервисов данных на основе языка SQL. Потребуется дополнительная работа и накопление опыта в нескольких направлениях для исследования непрерывного спектра подходов между ранними облачными сервисами данных и более развитыми с функциональной точки зрения, но, возможно, менее предсказуемыми альтернативами.
В облачных средах особенно важным качеством является управляемость. По сравнению с традиционными системами, достижение высокого уровня управляемости в облачных средах осложняется тремя факторами: ограниченным человеческим вмешательством, сильно изменчивыми рабочими нагрузками и разнообразием совместно используемых инфраструктур.
В подавляющем большинстве случаев будут отсутствовать администраторы баз данных или систем, которые могли бы помочь разработчикам при создании приложений, основанных на облачных сервисах; администрирование платформ должно будет в основном производиться в автоматическом режиме. Системы всегда трудно настраивать при наличии смешанных рабочих нагрузок, которые в данном контексте, по-видимому, будут неизбежно возникать. Со временем может значительно изменяться рабочая нагрузка даже у одного и того же потребителя: эластичное обеспечение облачных услуг делает эти сервисы экономически целесообразными для пользователей, которым в короткие промежутки работы может потребоваться значительно больше ресурсов, чем обычно. При этом возможности настройки сервисов сильно зависит от способа «виртуализации» совместно используемой инфраструктуры. Например, в Amazon EC2 для обеспечения программного интерфейса используются виртуальные машины аппаратного уровня. На другом конце спектра в salesforce.com реализуется хостинг с несколькими арендаторами одного ресурса («multi-tenant» hosting), когда с использованием одной СУБД поддерживается много независимых схем баз данных. Возможны и многие другие решения по виртуализации. В каждом из этих решений обеспечивается свой подход к контролю поддерживаемых рабочих нагрузок и используемых платформ. При наличии этих вариантов потребуется пересмотреть традиционные роли и распределение ответственности для многоуровневого управления ресурсами.
Потребность в управляемости делает более срочной разработку технологий самоуправления баз данных, которые исследовались в последнее десятилетие. Для обеспечения жизнеспособности этих систем потребуются адаптивные онлайновые методы, хотя наличие новых архитектур и API (включая гибкость, позволяющую отойти от традиционной семантики SQL и транзакций, когда это разумно) могут приводить к использованию подходов, подрывающих адаптивность.
Отдельной проблемой является абсолютный масштаб облачного компьютинга.
Сегодняшние SQL- ориентированные системы баз данных просто не могут масштабироваться на тысячи узлов при размещении в облачном контексте. В области хранения данных непонятно, следует ли обходить эти ограничения с применением новых методов реализации транзакционности, или с использованием новой семантики хранения данных, или того и другого. В литературе по тематике баз данных изложено много предложений по решению этой проблемы. В существующих облачных сервисах начинают применяться некоторые простые прагматические подходы, но для синтеза идей, описанных в литературе, в современных условиях облачного компьютинга требуется дополнительная работа. При обработке и оптимизации запросов будет нереально производить исчерпывающий поиск в пространстве планов с учетом тысяч обрабатывающих узлов, так что потребуются какие-то ограничения, налагаемые на пространство планов или на поиск. Наконец, неясно, как будут писаться программы для облачной среды (это уже отмечалось в подразделе 2.2). Дополнительные исследования требуются для обеспечения понимания реальной масштабируемости облачного компьютинга (как ограничений по производительности, так и требований приложений). Такое понимание должно помочь разработчикам осуществлять навигацию в возникающем пространстве проектных решений.
При совместном использовании физических ресурсов в облачной инфраструктуре требуется обеспечение безопасности и конфиденциальности данных, которые не могут гарантироваться за счет наличия физического разграничения машин или сетей. Следовательно, облачные сервисы обеспечивают плодородную почву для усилий по объединению и ускорению исследований, выполняемых сообществом баз данных в этих областях. Залогом успеха здесь будет ориентация на конкретные сценарии использования облачных сервисов, основанные на практических экономических стимулах для сервис-провайдеров и потребителей.
Участники встречи ожидают, что, по мере расширения популярности облачных сервисов данных, будет появляться новые сценарии использования со своими собственными проблемами.
Например, можно предвидеть появление специализированных служб с заранее загруженными крупными наборами данных, например, курсами акций, историей метеорологических условий, результатами просмотра Web и т.д. Все более привлекательной будет становиться возможность совместного использования интересных данных из приватных и публичных источников, и это будет стимулировать скорейшее решение проблем, перечисленных в подразделе 2.3. Это также указывает на неизбежность сервисов, охватывающих несколько облачных сред. Этот аспект уже распространен в научных гридах данных, в которых обычно имеются крупные совместно используемые серверы данных в нескольких узлах, даже если весь грид посвящается одной дисциплине. В целом, это также перекликается с разрастанием источников данных на большинстве предприятий. Появление федеративных облачных архитектур будет только усиливать описанные выше проблемы.
Уровень погружения сообщества баз данных в «облачную» среду кажется мне чрезвычайно низким. Весь этот подпункт производит впечатление «застолбления участка», на котором, вполне вероятно, могут находиться золотые жилы. Совершенно очевидно, что в этой области нужно работать.
