«Супербаза»

    Однажды мне поставили задачу — на офисно-бытовом железе (P4-2GHz, 1Gb RAM) формировать отчеты по данным из десятка филиалов, которые представлены в виде сотен отдельных баз данных по тысяче файлов каждая. Это были базы 1С-Торговля 7.7 (dbf), обрезаные по месяцам, которые приезжали из филиалов на флешках. Суммарный объем измерялся сотнями гигабайт, только на копирование уходило больше часа. Но отчеты за 3 года по всем филиалам выполнялись за несколько минут. Как?



    Очень просто. Была создана супербаза. Нет, это не одна большая общая база, куда слиты данные со всех баз. Я пробовал, фигня получается. Слишком большие объемы, слишком много проблем с синхронизацией данных. Все гораздо проще…



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

    Например, нужен отчет по взаиморасчетом с клиентом ООО «Спартак». Указываем часть названия и ИНН (если есть), задаем период и прочие параметры. Супербаза поочереди стартует известные ей базы данных и через API (через OLE) передает им команду сформировать такой-то отчет с такими-то параметрами. База формирует отчет и отдает его супербазе. Из отдельных отчетов по каждой базе собирается один общий отчет. Собранные для отчетов данные кешируются, при повторном формировании с похожими условиями не требуется заново собирать данные.

    Поскольку обращение к базам идет через API, то совершенно не важна версия и структура конкретной базы. Филиалы автономны, у каждого свои заморочки, каждый их по-своему решает. Общий только формат выдачи отчетов и формат получения первички (накладные, платежки, счета, ордера и прочие стандартные бумажные документы). Кроме того, качество данных на каждом филиале разное. Одни аккуратно ведут справочники и документы, заполняют все основные реквизиты. Другие пишут как зря, с ошибками и дублями, реквизиты либо не заполнены, либо с ошибками. Но это не столь важно, достаточно части названия. В итоговом отчете будет разбивка по разным вариантам названий, убрать лишние проще, чем добрать недостающие.

    Еще одно огромное удобство — базы могут лежать на разных носителях. Это могут быть флешки, USB-HDD, сетевые шары. Базы можно подключать-отключать «на ходу» — они ведь запускаются автономно и атомарно, сбой отдельной базы никак не вредит. Можно одновременно запускать несколько баз с разных носителей без потери производительности на IOPS и блокировках. Такой вот динамический partitioning для бедных.

    Быстродействие достигалось гораздо большее, чем на одной общей базе, даже если использовать MS-SQL на SSD и более мощное железо. Одновременно запускалось несколько баз с разных носителей, при этом не было проблем с блокировками и однопоточностю каждой отдельной базы. На флешках базы порой работали даже быстрее, чем на HDD. Отчеты формировались частями, что позволяло начать их рассмотрение до окончания всего процесса. В случае ошибок в условиях можно тормознуть отчет, не дожидаясь, пока он полностью сформируется.

    Очередной плюс — безопасность. Поскольку базы на филиалах обрезались каждый месяц и хранились на переносных носителях, то:
    — не оставалось лишних данных для посторонних (данные всего за текущий месяц максимум)
    — нет возможности хитрому персоналу портить данные за прошлые периоды. А если вдруг решат испорить — можно легко сравнить с состоянием на конец предыдущего периода
    — потеря данных в случае форс-мажора не больше месяца. Однажды была рейдерская атака. Потеряли данные всего за 3 дня, а злодеям достался огрызок одной базы за неделю.
    — переносные носители (особенно флешки) в случае форс-мажора можно легко уничтожить или спрятать. И никаких следов, паролей, и прочих намеков. И на работу не влияет.

    Немного о деталях реализации. Все это было сделано на 1С-Предприятие 7.7 релиз 25. Два варианта открытия баз — один через OLE, для неспешного выдергивания первички и справочников. Второй — автономный запуск из командной строки, с запуском обработки autorun.ert. Перед открытием базы этот autorun.ert и файл с настройками копировались в каталог базы. После выполнения обработки результат сохранялся в файл (обычно как СписокЗначений или ТаблицаЗначений, сериализованные через ЗначениеВФайл() ).

    Чаще всего супербаза использовалась для переноса первички из оперативных торговых баз по «чистовым» базам юрлиц. Для этого сперва создавался большой список всех накладных без табличных частей. Потом этот список вручную (почти вручную) отфильтровывался бухгалтерами, в нем оставались только «чистые» документы по конкретному юрлицу. И после этого из доступных баз документы из отфильтрованного списка копировались в чистовую базу юр.лица.
    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 11

      +2
      Без диаграмм и схем для потоков данных непонятно почему все стало быстро работать. Звучит вроде бы все понятно, но в голове не укладывается. Или это применить можно только к 1С? Что-то подсказывает, что это можно провернуть и на других базах, данных, но без схемы тяжело.
        0
        Да уж не знаю, как это изобразить. Идея-то проста до безобразия. С другими базами наверняка тоже можно так же поступить.
        0
        Все новое — давно придуманное старое:
        v8.1c.ru/consolid/
          +4
          Ну и магические буквы OLAP автору тоже помогут углубить свои знания
            +2
            А оно быстро работает? Железо какое нужно? Новые базы сами подключаются? Сколько денег стоит? Паралельный запуск делать умеет?
            0
            Это вы сколько там сущностей наплодили, если в каждой базе тысяча файлов? Или вы индексы тоже считаете? 1sqlite не пробовали? Выборки в сотни тысяч строк формируются буквально за секунду-две.
              0
              Насчет тысячи не уверен, может и полтыщи с индексами, точно не помню. Новых сущностей там не так много, в основном отчеты и печатные формы.

              Я много чего пробовал, и прямые запросы, и оптимизация кода с замером производительности в отладчике и профайлере MSSQL. Да, можно очень быстро строить некоторые отчеты, но проблемы с наполнением и обслуживанием это не решает. 1С 7.7 просто не расчитана на работу с такими объемами. Удаление помеченных объектов не работает, много непонятных глюков. А 8.х тормоз еще тот, и железо для него нужно приличное.

              Мне не требовалось формировать супер-отчеты за секунду. Достаточно было запускать отчеты в фоне и просматривать их по мере формирования.
                0
                1sqlite работает как раз с файловым вариантом базы. Как вариант, я бы вам предложил, также в фоне запускать отчет в каждой базе, выбирать все необходимые данные и складывать в одну консолидированную базу sqlite (компонента позволяет уложить любую ТЗ и Список значений в базу sqlite буквально 1й строкой.). Плюсы: Для каждой новой базы запускать выборку потребуется 1 раз. У вас будет большая консолидированная база с довольно шустрым движком. А там уже и мегаотчеты захотите делать.
                  0
                  Повторюсь, проблема не сколько в извлечении, сколько в консолидации, объединении не вполне корректных данных. Например, в марте товар назывался «консервы рыбные», а в апреле он же называется «кукурузные палочки». То есть, каждая база актуальна и относительно корректна в своем периоде (за месяц), но если их сложить за год, получится хрень. Кроме того, заранее не известно, какие данные могут понадобиться в отчетах, а вытаскивать и синхронизировать из баз все подряд — весьма непростая и неблагодарная задача.

                  Кроме того, набор автономных баз отлично решает проблемы с безопасностью. Флешки с базами у директора, и лишний раз доступа к ним нет даже у админа. Нужны данные за прошлый год — взял у директора флешку, поработал, вернул.
              0
              Поздравляю, Вы изобрели BI, ETL и несколько других технологий
                0
                Спасибо. А несколько других — это какие?

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