Почему SQL "тормозит"?

Почему SQL "тормозит"?

В последнее время в коференции fido.ru.1csoft стали появляться вопросы по клиент-серверным версиям (SQL) программ фирмы "1С". Аналогичные вопросы поступают к нам и по электронной почте и по телефону от клиентов нашей компании (Альтер Лого). Судя по содержанию этих вопросов (а также по содержанию ответов на них в фидошной конференции) могу с прискорбием констатировать, что люди, занимающиеся внедрением и эксплуатацией программных продуктов "1С" имеют весьма смутное представление о том, что такое клиент-серверная система, для чего она вообще нужна, как она работает и чего от нее можно и нужно ожидать, а чего нельзя.

Мимо такого непонимания я пройти спокойно не могу, поэтому беру на себя труд по сочинению этого текста, который, как я надеюсь, поможет многим из разработчиков и пользователей понять, нужен ли им SQL-продукт или нет.

Итак, первое, что необходимо понять и запомнить: SQL-системы не предназначены для ускорения выполнения выборок и печати отчетов. Если Вы ожидаете, что установив "1C-Торговлю для SQL" Вы ускорите работу своей системы, то Вы глубоко заблуждаетесь. Не будет она работать быстрее. Поэтому всякие разговоры о том, что "…SQL-Торговля - это тормоз…" абсолютно не имеют смысла. Несколько лет назад журнал PC Magazine проводил сравнительный анализ (в том числе и по быстродействию) систем управления базами данных, построенных на основе обычных файл серверов и с использованием клиент-серверных (SQL) систем. Естественно, условия испытаний по возможности были нивелированы, т.е. применялись одинаковые объемы баз данных, одинаковые их структуры, один и тот же компьютер в качестве сервера, одинаковое количество рабочих станций и т.д. Если мне не изменяет память, из клиент-серверных систем были испытаны Oracle, Interbase, Informix, Gupta и самый дешевый в то время Watcom SQL Server. Во всех случаях, средняя скорость выполнения запросов в SQL-системах была ниже, чем у файл-серверной системы (сейчас об этом эффекте можно прочесть в любой серьезной книге по SQL ). Испытатели не были удивлены полученным эффектом, поскольку были людьми грамотными и понимали причину такого поведения SQL-систем при заданных условиях эксперимента. Ведь задачей эксперимента было сравнение быстродействия двух видов систем и поэтому были выбраны условия, позволяющие произвести это сравнение. В частности для тестов использовались базы данных объемом 1.5-2Гб. Ведь если бы исследователи взялись проводить испытания, используя базы данных на порядок большего размера, то им просто не с чем было бы сравнивать SQL-варианты, поскольку обычная файл-серверная система на таких объемах информации просто заткнулась бы. Вот в этом то и состоит основное отличие и достоинство клиент-серверных систем: они будут работать со вполне приемлемой скоростью с базами данных такого объема, с которыми файл-серверная система работать просто не сможет ("не сможет" в том смысле, что ее функциональность, в том числе и быстродействие, станут неприемлемы для коммерческих приложений).

Посмотрите на обычный сетевой вариант 1С-Торговли. Она реализована на файл-серверном принципе, т.е. обработка данных ведется рабочей станцией, а сервер служит просто как дополнительное, доступное всем пользователям дисковое устройство. Это означает, что при выполнении задачи (например при сборке отчета) ВСЯ база данных (или значительная ее часть) прокачивается по сети на рабочую станцию и там обрабатывается процессором рабочей станции. Быстродействие такой системы зависит от быстродействия диска сервера, скорости передачи данных по сети, мощности процессора рабочей станции, объема ее ОЗУ и некоторых других факторов. Центральный процессор сервера играет второстепенную роль и должен просто обеспечивать передачу потока данных с сетевого канала на диск и обратно, по возможности не внося замедления в этот процесс. Главным в таком подходе является то, что практически вся база данных перегоняется по сети на рабочую станцию для последующей обработки. Если несколько станций одновременно выполняют сборку отчетов, то всем им закачивается база данных и естественно система "тормозит". Когда выполняются менее накладные операции, типа ввода нового документа, то объем перекачки данных значительно меньше, правда в реальности ввод документа как правило сопровождается поиском клиента в справочнике, вычислением задолженности клиента и т.п., что в свою очередь порождает перекачку большого количества информации с диска сервера на рабочую станцию. Не следует также забывать о необходимости синхронизации доступа рабочих станций к данным. Поскольку вся обработка ведется на уровне рабочих станций, а файл-сервер просто играет роль разделяемого дискового устройства, задачи синхронизации решаются в таких системах с помощью организации различных файлов блокировок (на диске файл-сервера) в которые каждая рабочая станция записывает информацию о данных, которые она модифицирует в данный момент, а при попытке считать данные проверяет не заняты ли эти данные другой рабочей станцией. Несмотря на ряд недостатков ("висячие" блокировки при аварийном выключении рабочих станций, "торможение" всей системы при модификации большого числа записей), способ вполне работоспособен.

Скорость работы такой системы прямо связана с объемом обрабатываемой базы данных. Они начинают ощутимо "тормозить", когда база данных достигает объема свыше 200-300Мб и