Мы у себя в WIT-e, конечно, иноходцы. Своя ERP-система (писал о ней тут — Как нам обойтись без 1С?), своя CRM-система, своя M2M для связи с дистрибуторами («какие еще умные слова и аббревиатуры вы знаете?»). Ну и, конечно же, свой подход к WWW, чтобы оставаться в рамках этой 3-буквенной парадигмы.

Все началось с любви к Микрософт, и какая-то из ранних версий сайта еще в конце 90-х была сделана на технологии ASP, а в качестве базы данных под ней лежал обычный файл MS Access. Кстати, провайдеры до сих пор предлагают хостинг на старой доброй ASP, спустя 18 лет после ее обновления до ASP.NET – вот вам и legacy systems во всей красе.

В целом это достаточно удобно – поскольку внутренняя база также написана на MS Access, то процедура подготовки данных для сайта была очень проста, никаких перетрансляций из одного формата данных в другой (MySQL к примеру). Access поддерживает расширение языка SQL вида «IN <имя внешней базы>», которое может быть добавлено после любых DML-инструкций: INSERT, UPDATE, DELETE (вот вам еще одна 3-буквенная аббревиатура).

По мере роста эта связка, понятное дело, начала безбожно тормозить (плюс случающиеся непонятно когда блокировки mdb-файла с базой, вырубающие намертво весь сайт). Перевод сайта на ASP.NET кардинально проблему не решил, и нужно было также переходить на MS SQL Server в качестве базы, но тут процесс пошел по иному руслу. Давайте посмотрим на проблему повышения быстродействия сайта с несколько другой стороны.

(Кстати, мой провайдер 1Gb.ru пишет, что ASP.NET в среднем шустрее, чем стандартная связка LAMP (Linux/ Apache/ MySQL/ PHP), что для меня стало откровением. Но кому тут верить, как не эксплуатанту всего этого дела?)

Disclaimer – последующие идеи представляют собой, с одной стороны, некоторую теоретическую конструкцию, возведенную в абсолют, что часто означает – доведенную до абсурда, с другой стороны – конкретную реализацию, так что нельзя сказать, что автор витает в своих фантазиях и совсем оторвался от действительности.

Вопрос 1. Зачем под сайтом вообще должна быть база данных?

Ну действительно, вы же все восхищаетесь быстродействием In-Memory Databases, правда? Так зачем далеко ходить, заведите себе такую прямо под своим сайтом. И даже больше. При начальной инициализации загрузите все данные в массивы, доступные на уровне сайта в целом (объект Application в ASP.NET, Global Variables в PHP, далее везде), и вместо написания запросов к базе делайте просто цикл по этим массивам. Для начальной загрузки данных подойдет что угодно – та же база MS Access, да хоть текстовые CSV-файлы! – операция производится нечасто и время ее выполнения не играет никакой роли.

Возникают вопросы, но на них у нас уже есть готовые ответы

1. Как быть, если веб-страница выбирает данные из запроса, а не из таблицы? Очень просто – преобразуйте результат запроса в таблицу (у себя на внутреннем сервере, при подготовке данных для веб-сайта), и дальше — по предложенной схеме,
2. Эта идея не сработает (или приведет к перерасходу памяти) в следующем типичном случае. У нас есть каталог интернет магазина с кучей товаров в каждом подразделе. Что же нам – заводить отдельную таблицу (массив в памяти) на каждый подраздел каталога, который выбирается простым запросом? Честно говоря, даже в таком экстремальном варианте я не вижу больших проблем – просто заведите массив большего размера/ большей размерности, куда поместите результат связки обеих таблиц – и каталога, и товарных позиций. Но в случае нашего сайта это решено простейшей индексацией такого вида. К таблице Catalog (массиву в памяти веб-сервера!) добавляются 2 столбца – начальный и конечный индекс элемента товара во второй таблице:
   
   
   
   и цикл при выводе товарных позиций этого раздела каталога ведется от MinIndex до MaxIndex. Замечу, что при подготовке таблиц-массивов для сайта вы уже можете задать необходимую сортировку (но только один вариант) – в приведенном выше случае для работоспособности схемы таблица Parts должна быть отсортирована по ID таблицы Catalog, а затем – в нужном нам порядке уже в пределах конкретного раздела каталога.
   

Заметим, что эту идею можно продолжать и далее. Точно так же, как данные выносятся из базы под сайтом в структуру данных самого сайта, можно при генерации веб-страницы нужные ей данные размещать в самой ее структуре – то есть в массивах JavaScript. И никаких AJAX-ов, асинхронности, обработки ошибок связи и прочего. Так и сделано у нас на сайте на страницах, содержащих всякие конфигураторы.

Кстати, в отличие от файлов баз данных, массивы в памяти веб-сервера (и веб-браузера тоже, хотя с оговорками) занимают размер, примерно равный их двоичному представлению, тогда как пустая база данных с одной-единственной таблицей в ней уже тянет на многие сотни килобайт.

Вопрос 2. А зачем вообще нужно использовать скрипты на веб-сервере?

Привожу фрагмент кода в несколько строчек, нарочито упрощенный и на самом безумном из языков программирования — VBA (если не считать 1С)

        Set IE = CreateObject("InternetExplorer.Application")

        IE.Navigate "wit.ru"
        While IE.ReadyState < READYSTATE_COMPLETE
        Wend

        Set str = IE.Document.DocumentElement
        HTML = str.innerhtml

Код делает следующее – прогоняет страницу через некогда очень популярный браузер одной известной фирмы, и сохраняет в виде чистого HTML результат отработки серверного скрипта. Вы уже догадались, наверное, что будет предложено дальше? Совершенно верно – вполне можно сделать сайт как в старые 90-е чисто HTML-ным.

(Снова с сайта 1GB.ru: «IIS очень быстро и эффективно обрабатывает запросы к статическим файлам»)

При этом, может быть, придется озаботиться перекодированием адресов вида
wit.ru/card.aspx?id=23&prodid=1022985
в статические адреса веб-страничек – это тоже вполне известная технология настойки веб-сервера, изначально придуманная для одурачивания поисковых систем и веб-оптимизации.

Тут нужно, наверно, сформулировать основной принцип, из которого выводятся все остальные. Чем больше времени и ресурсов мы потратим на подготовку данных для веб-сайта, тем проще ему будет их вывести и тем быстрее он сможет это сделать. Наш бэк-енд в этом случае может работать вообще в непрерывном режиме, выплевывая на сайт готовые данные с нужной нам периодичностью. И этот подход сработает во всех случаях, кроме, конечно, биржевых сводок или витрины какого-нибудь Amazon или Alibaba, где данные меняются ежесекундно.

Заключение

Я отдаю себе отчет, что проблемы в статье чересчур заострены и предложено слишком нестандартное решение. Рискну предположить (это совсем не моя тема), что такой подход мог бы сработать для всяких embedded-систем, где в противном случае на слабом с вычислительной точки зрения устройстве приходится размещать мини-движок базы данных и обработчик скриптов вместо наипростейшего веб-сервера (ценой большего потребления памяти – оперативной и постоянной).