Классика баз данных - статьи
в области баз данных, вы
Если вы выполняете исследование в области баз данных, вы всегда что-нибудь оптимизируете. При исследовании здорово определить свое собственное "что-нибудь", т.е. ввести ограничения и метрику своей оптимизационной проблемы. Однако, честно говоря, в сообществе баз данных, как правило, обеспечивается ответ на один и тот же вопрос: "Как сделать СУБД быстрее?", и на это же направлена вся оптимизация. Допускаются только те "сценарии" исследований, которые направлены на то, чтобы сделать СУБД быстрее. Возможные сценарии включали новые виды запросов (например, аналитику), новые типы данных (например, изображения, многоугольники, XML) и новые архитектуры (например, потоковые данные). Тем не менее, оси y на графиках в статьях с конференций SIGMOD и VLDB одни и те же, показывающие время ответа в секундах или пропускную способность в числе транзакций в секунду. Кроме того, фиксируются такие ограничения, как строгая согласованность (т.е. ACID-транзакции) и доступные аппаратные ресурсы.
Целью статьи является переосмысление понятия лучше в контексте систем баз данных, т.е. в ней делается попытка определить, как должны выглядеть оси y на графиках в статьях будущих конференций SIGMOD и VLDB. Утверждается, что в будущем единицы измерения оси y должны измениться. Вместо времени ответа или пропускной способности оси y должны показывать расходы в денежных единицах. Кроме того, согласованность должна быть параметром, изменяемым при проведении экспериментов с системой. Другими словами, цель статьи состоит в переопределении проблемы оптимизации баз данных: определении новых ограничений и других показателей оптимизации.
Эта статья мотивируется несколькими тенденциями. Очевидно, что наиболее важной тенденцией является изменение требований многих приложений. Для многих приложений в Web строгая согласованность в соответствии с парадигмой ACID просто не требуется. Вместо этого таким приложениям требуется масштабируемость до миллионов пользователей, и ни один пользователь не должен когда-либо блокироваться каким-либо другим пользователем.
