Параллельное выполнение индивидуальных запросов
В чисто реляционных базах данных для успешной работы с данными
объемом более 250 Гбт требуется наивысшая степень параллельности
при выполнении каждого индивидуального запроса. Первейшим ключом
к распараллеливанию является структура самого языка запросов SQL.
Этот язык предназначен для работы со множествами и накладывает
немного ограничений на порядок выполнения запроса; поэтому
оптимизаторы запросов реляционных СУБД обладают такой гибкостью
при выборе планов выполнения запроса. По этой же причине SQL
исключительно подходит для параллельного выполнения.
Для использования этой возможности необходимо придумать стратегии
выполнения, обеспечивающие оптимизированное параллельное
выполнение индивидуального запроса, а не только обеспечить
параллельное выполнение последовательных индивидуальных
стратегий. Заметим, что и индивидуальные операции определения и
манипулирования данными (а также утилиты архивирования и
восстановления) должны выполняться параллельным образом.
Поставщики реляционных СУБД выполнили большую часть работы для
обеспечения такого распараллеливания. Более того, оказалось
возможным поддерживать высокую степень прозрачности для
приложений и администраторов баз данных. Этому значительно
способствовали не только структура SQL, но также и то, что ядро
языка и типы данных были в основном зафиксированы в 80-х и начале
90-х гг. И тем не менее, от производителей требуется 2-3 года,
чтобы внедрить внутреннее распараллеливание запросов в зрелую
реляционную СУБД.
Многие отмечают, что сложность внедрения параллелизма в VLDB
связана с двумя аспектами. Первый аспект состоит в замене
последовательных алгоритмов на параллельные. Второй аспект более
тонкий. Для проектирования и разработки конкурентоспособного
программного обеспечения требуется качественная перестройка
образа мышления. Например, первым поползновением разработчика
программы загрузки базы данных было бы использование функции
INSERT. Этот метод работает для малых и средних баз данных, но не
годится для больших: слишком медленно. Необходимо разработать
метод, при котором происходит параллельная загрузка нескольких
потоков данных, опираясь на возможность использования нескольких
процессоров в архитектурах MPP или кластеры SMP. Если данные
поступают из одного последовательного источника (например,
устройства с магнитной лентой), первичная задача загрузки состоит
в как можно более быстром помещении данных в память. После этого
вся процессорная мощь должна быть использована в параллельном
режиме для помещения каждого элемента данных в нужное место,
поддержки индексов и т.д.
С расширением использования ОР-баз данных проблема становится
более сложной. Требуется учитывать наличие новых и потенциально
экзотических типов данных. Должны быть написаны и оптимизированы
для параллельного выполнения новые методы. Между экземплярами
новых типов данных и даже между экземплярами стандартных типов
SQL могут и будут существовать сложные связи. Для поддержки новых
операций и типов данных требуются новые методы доступа к данным,
и их тоже нужно оптимизировать для параллельного использования.
Наконец, необходимо принимать во внимание то, что количество
различающихся значений в одном столбце таблицы может в тысячу и
более раз превосходить число разных значений в другом столбце.
Для учета этого требуется применять новые подходы к хранению и
буферизации данных как на стороне сервера, так и на стороне
клиентов.
