Нестандартные мысли об архитектуре веб-сайта

    Мы у себя в 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-систем, где в противном случае на слабом с вычислительной точки зрения устройстве приходится размещать мини-движок базы данных и обработчик скриптов вместо наипростейшего веб-сервера (ценой большего потребления памяти – оперативной и постоянной).
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 9

      0

      "Нестандартные", ага. Я в то ли 98, то ли в 99 году ровно из MS Access генерил полный статический сайт для некоего клиента. Зато никаких требований к хостингу, кроме SSI.

        0
        а потом ты делал это с помощью XSLT :) четырёхбуквенные круче трёхбуквенных.
          0

          Вот так пришел и спалил.

            0
            никто не заметит, основной срач главные обсуждения в нижних комментариях
        0
        Вот!)
          +5
          поздравляю с подключением к Интернету
            0
            Интересно, на чём крутится сайт 1gb.ru, если они не поддерживают TLS 1.2?
              0
              Какого объёма ваши данные если входят в оперативу? при чём вы там храните не только исходные данные но и все варианты запросов к ним.
              Теперь посмотрим на стоимость оперативы и стоимость постоянной памяти. Теперь посмотрим на скорость выдачи страницы при использовании хранилища в оперативе и при использовании хранилища в СУБД.
              И пусть каждый сделает свой вывод о том что ему важней ускорение выдачи на N миллисекунд или стоимость инфраструктуры на M рублей в месяц или всего сервера на X рублей на Z лет.
                +1

                Если данных не много, они не критичные для бизнеса и нагрузка на сервер позволяет ему одному обработать все запросы, то можно и так сделать.
                Если нет, то надо продумать как синхронизировать данные в памяти между несколькими серверами, как потом с них снять бэкап. Как отменить операцию изменения данных, совместный доступ. Права на данные. Отказоустойчивость. Экспорт/импорт из других систем. Вот это вот всё.


                Т.е. все что стоит за абстракцией хранилища БД, придётся навелосипедить программистам. Чтобы сделать аналитику по данным, тоже надо будет загружать в одну из СУБД, через парсинг текстовых файлов.

                Only users with full accounts can post comments. Log in, please.