Относительно предложенной статьи
В 2000 году нам пришлось реализовать для 1С: Предприятие 7.7 свою систему проводок и отчетов, поскольку производительности стандартных бухгалтерского и даже оперативных регистров нам не хватало. Бухгалтерский регистр вообще не давал адекватных результатов: конечные остатки уже на март не совпадали с начальными остатками на апрель. Модель переделанная на оборотных регистрах справлялась с итогами за 3 года, но формирование отчета занимало до 40 минут.
Мы переделали структуру на прямые запросы к таблицам MS SQL и начали высчитывать, на какое количество оборотных записей есть смысл делать промежуточные итоги.
Выяснилось, что без всяких материальных индексов, до 50 млн. записей, быстрее оказывается получить агрегаты по таблице оборотов, чем усложнить запрос, с вычислением промежуточных итогов и выравнивания до них таблицы оборотов.
Практически, мы вообще отказались от промежуточных итогов, поскольку время построения отчета составляло до двух минут, а запрос ко всей таблицы — менее 30 секунд. Использование же промежуточных итогов ускоряло расчет запроса до 2-3 секунд, но при этом поддержка формирования этих запросов из языка 1С была очень трудоемкой.
К чему это все я рассказал.
Тест на 1 млн записей ни о чем не говорит.
Кроме того, как раз нет проблемы для простого (иерархиченого) агрегирования итогов.
Куда сложнее, когда алгоритм формирования показателей оборотов не тривиален (например, есть признак операции для каждой строки, по которому определяется, как и по каким ресурсам будут изменены итоги). Еще хуже, когда операции между собой взаимосвязаны (например — списание по партиям).
В тривиальном случае, действительно, нет смысла городить огород с промежуточными итогами.
Однако, как только число записей сильно зашкаливает за сотню миллионов, либо алгоритм расчета итогов отличается от тривиального суммирования, расчет промежуточных итогов становится необходим.
К примеру, бывали ситуации, когда проведение некоторого документа по десятку регистров может требовать несколько десятков секунд.
Формирование отчета по миллиону таких документов без формирования регистров практически невозможно. С учетом самой строгой оптимизации, добиться формирования такого отчета быстрее, чем за пару месяцев — просто невозможно.
Практически, система представляет кластер: часть расчетов делается на клиентских компьютерах (которых больше 500), часть расчетов на сервере в режиме онлайн, часть на сервере — по ночам и в выходные. И, к сожалению, полный пересчет итогов в такой системе требует привлечения дополнительных ресурсов. Например — расчетов в облаках. В одной организации, такой пересчет удалось произвести за 4.5 месяца, исключив часть наименее приоритетных показателей, которыми оказалось проще пожертвовать, и задействовав на это время арендованные сервера, в четыре раза превышающие стандартно используемые мощности.
Поймите и Вы, я очень хорошо понимаю, что такое двойная запись, поскольку эксперт в этом вопросе. Только я не про нее, а про реализацию оперативных регистров. Которым неоднократно учил разработчиков корпоративных систем, изобретающих отвратительные модели данных. Именно поэтому, регистр остатков/оборотов в 1С — это замечательный шаблон проектирования. А вот как раз нормальной математической модели в основе платформы 1С — нет.
Что касается CQRS — не знаю, Вам виднее. Буду изучать :)
Спасибо за Ваши комментарии.
Я понимаю о чем Вы. Но регистры в платформе 1С: Предприятие — не об этом. Понимаете? Регистры не имеют отношения к двойной записи, хоть и дают возможность ее реализовать, когда это необходимо. Идея-фикс насчет того, что 1С: Предприятия это чисто бухгалтерский инструмент, увы, соответствует реалиям 1С: Бухгалтерии, вплоть до версии 6.0. То есть — примерно на 1996-1997 год. С тех пор немало воды утекло и бухгалтерские принципы в платформе 1С отражены примерно в 5% системы. Остальные 95% — совершенно не связано с задачами бухгалтерского учета.
Насчет остатков и оборотов, попробую объяснить.
Смотрите, есть у Вас некий отчет. Который может быть сформирован за любой период, хоть за день, хоть за год, хоть за пятилетку.
У Вас есть десяток показателей, которые входят в отчет.
По каждому показателю у Вас за день полмиллиона записей.
Каким образом материализованные индексы помогут Вам считать агрегаты (и не всегда это просто сумма значений в отобранных записях) по миллиардам записей, при этом формируя отчет за секунды? Уже даже десятки секунд — неприемлемо.
Поэтому механизм промежуточных итогов, предрассчитанных в момент совершения записей, или в отложенном режиме (но все равно до того, как данные будут востребованы для анализа) помогает распределить время расчета агрегатов, снять нагрузку с системы в момент формирования расчетов.
Прошу меня простить, но должен Вам возразить: регистры не основаны на двойной записи. Есть специальный регистр — бухгалтерский. Он, и только он, реализует механизм корреспонденции счетов. Регистры оперативного учета реализуют именно шаблон разделения оборотов и остатков, для обеспечения более высокой эффективности формирования отчетов.
Вероятно, я не открою большого секрета, но, модель с хранением событий и хранением состояний не является по сути дела противоречивой.
Могу показать на примере платформы 1С: предприятие.
Есть такая сущность, как регистр. Она, по факту, состоит из двух таблиц. Одна таблица содержит «обороты» — то есть историю событий. Вторая таблица хранит остатки — то есть состояния. Есть возможность сделать пересчет итогов, когда таблица остатков очищается и пересчитывается по событиям.
При этом, таблицы можно свернуть (wrap) на определенный момент времени, подготовив, так называемые, начальные остатки (исходное состояние, до которого нет истории событий)
Кроме того, можно формализовать процесс расчета состояний по историй событий. В 1С для этого используются, в частности, обработки проведения документов.
Я нередко обнаруживал, что разработчики, никогда не сталкивающиеся с зрелыми платформами разработки корпоративных решений (к которой я смело причисляю и 1С: Предприятие начиная с версии 7.0), не знают этих шаблонов проектирования, а потому, нередко, изобретают велосипед.
С другой стороны, я сам не знал названий этих шаблонов проектирования, поскольку мой опыт созревал в сообществе, где шаблоны вшиваются в платформу без разъяснения их сообществу.
Тем интереснее и полезнее подобные статьи, особенно в ключе их обсуждения.
Как говорится, каменты жгут!
Ну, вообще вопрос клиента, заказчика, пользователя — довольно запутан. Есть проект, где подрядчик делает что-то для заказчика, не имея контакта ни с клиентом (тем, кто платит за продукт), ни с пользователем (тем, кто использует продукт в интересах клиента). Я бывал в разных позициях. Как клиент, могу сказать, что далеко не все интересы пользователя я готов удовлетворять за свой счет. Если меня интересует определенный функционал, меня может мало волновать мнение пользователя (моего сотрудника) о том, насколько ему хочется этот функционал использовать (ему может быть вообще не хочется эту работу делать)
Поэтому не проблема, а задача менеджера проекта, понимать, кто клиент и за что он платит деньги, что должен делать пользователь и в каком случае его нужно слушать, а в каком — отправлять к руководителю за взбучкой. Если же я подрядчик, у меня есть заказчик, который заказывает систему, представляя для меня и клиента, и пользователя, то тут, конечно же, от меня требуется, прежде всего, правильное взаимодействие с заказчиком (т.е. полезные советы, хорошая исполнительность и документальная защищенность от произвола)
Бюджет (цена) следует за ценностью. Выходить за рамки — значит видеть (и предлагать) новую и большую ценность, чем та, за которой стоит согласованный бюджет (ожидаемая, принятая цена).
Мне очень понравилась статья, хоть уже и прошло много времени с момента ее публикации и обсуждения.
В своей работе нередко приходилось пренебрегать принципом внимательного наблюдения за пользователями, их действиями, их отношением к интерфейсу продукта. Хотя нередко, время потраченное на споры и отстаивание своего видения было даже избыточным для того, чтобы присмотреться, прислушаться, записать, проанализировать, сделать выводы и поблагодарить за помощь в улучшении дизайна.
В 2000 году нам пришлось реализовать для 1С: Предприятие 7.7 свою систему проводок и отчетов, поскольку производительности стандартных бухгалтерского и даже оперативных регистров нам не хватало. Бухгалтерский регистр вообще не давал адекватных результатов: конечные остатки уже на март не совпадали с начальными остатками на апрель. Модель переделанная на оборотных регистрах справлялась с итогами за 3 года, но формирование отчета занимало до 40 минут.
Мы переделали структуру на прямые запросы к таблицам MS SQL и начали высчитывать, на какое количество оборотных записей есть смысл делать промежуточные итоги.
Выяснилось, что без всяких материальных индексов, до 50 млн. записей, быстрее оказывается получить агрегаты по таблице оборотов, чем усложнить запрос, с вычислением промежуточных итогов и выравнивания до них таблицы оборотов.
Практически, мы вообще отказались от промежуточных итогов, поскольку время построения отчета составляло до двух минут, а запрос ко всей таблицы — менее 30 секунд. Использование же промежуточных итогов ускоряло расчет запроса до 2-3 секунд, но при этом поддержка формирования этих запросов из языка 1С была очень трудоемкой.
К чему это все я рассказал.
Тест на 1 млн записей ни о чем не говорит.
Кроме того, как раз нет проблемы для простого (иерархиченого) агрегирования итогов.
Куда сложнее, когда алгоритм формирования показателей оборотов не тривиален (например, есть признак операции для каждой строки, по которому определяется, как и по каким ресурсам будут изменены итоги). Еще хуже, когда операции между собой взаимосвязаны (например — списание по партиям).
В тривиальном случае, действительно, нет смысла городить огород с промежуточными итогами.
Однако, как только число записей сильно зашкаливает за сотню миллионов, либо алгоритм расчета итогов отличается от тривиального суммирования, расчет промежуточных итогов становится необходим.
К примеру, бывали ситуации, когда проведение некоторого документа по десятку регистров может требовать несколько десятков секунд.
Формирование отчета по миллиону таких документов без формирования регистров практически невозможно. С учетом самой строгой оптимизации, добиться формирования такого отчета быстрее, чем за пару месяцев — просто невозможно.
Практически, система представляет кластер: часть расчетов делается на клиентских компьютерах (которых больше 500), часть расчетов на сервере в режиме онлайн, часть на сервере — по ночам и в выходные. И, к сожалению, полный пересчет итогов в такой системе требует привлечения дополнительных ресурсов. Например — расчетов в облаках. В одной организации, такой пересчет удалось произвести за 4.5 месяца, исключив часть наименее приоритетных показателей, которыми оказалось проще пожертвовать, и задействовав на это время арендованные сервера, в четыре раза превышающие стандартно используемые мощности.
Что касается CQRS — не знаю, Вам виднее. Буду изучать :)
Спасибо за Ваши комментарии.
Насчет остатков и оборотов, попробую объяснить.
Смотрите, есть у Вас некий отчет. Который может быть сформирован за любой период, хоть за день, хоть за год, хоть за пятилетку.
У Вас есть десяток показателей, которые входят в отчет.
По каждому показателю у Вас за день полмиллиона записей.
Каким образом материализованные индексы помогут Вам считать агрегаты (и не всегда это просто сумма значений в отобранных записях) по миллиардам записей, при этом формируя отчет за секунды? Уже даже десятки секунд — неприемлемо.
Поэтому механизм промежуточных итогов, предрассчитанных в момент совершения записей, или в отложенном режиме (но все равно до того, как данные будут востребованы для анализа) помогает распределить время расчета агрегатов, снять нагрузку с системы в момент формирования расчетов.
Могу показать на примере платформы 1С: предприятие.
Есть такая сущность, как регистр. Она, по факту, состоит из двух таблиц. Одна таблица содержит «обороты» — то есть историю событий. Вторая таблица хранит остатки — то есть состояния. Есть возможность сделать пересчет итогов, когда таблица остатков очищается и пересчитывается по событиям.
При этом, таблицы можно свернуть (wrap) на определенный момент времени, подготовив, так называемые, начальные остатки (исходное состояние, до которого нет истории событий)
Кроме того, можно формализовать процесс расчета состояний по историй событий. В 1С для этого используются, в частности, обработки проведения документов.
Я нередко обнаруживал, что разработчики, никогда не сталкивающиеся с зрелыми платформами разработки корпоративных решений (к которой я смело причисляю и 1С: Предприятие начиная с версии 7.0), не знают этих шаблонов проектирования, а потому, нередко, изобретают велосипед.
С другой стороны, я сам не знал названий этих шаблонов проектирования, поскольку мой опыт созревал в сообществе, где шаблоны вшиваются в платформу без разъяснения их сообществу.
Тем интереснее и полезнее подобные статьи, особенно в ключе их обсуждения.
Как говорится, каменты жгут!
Поэтому не проблема, а задача менеджера проекта, понимать, кто клиент и за что он платит деньги, что должен делать пользователь и в каком случае его нужно слушать, а в каком — отправлять к руководителю за взбучкой. Если же я подрядчик, у меня есть заказчик, который заказывает систему, представляя для меня и клиента, и пользователя, то тут, конечно же, от меня требуется, прежде всего, правильное взаимодействие с заказчиком (т.е. полезные советы, хорошая исполнительность и документальная защищенность от произвола)
Мне очень понравилась статья, хоть уже и прошло много времени с момента ее публикации и обсуждения.
В своей работе нередко приходилось пренебрегать принципом внимательного наблюдения за пользователями, их действиями, их отношением к интерфейсу продукта. Хотя нередко, время потраченное на споры и отстаивание своего видения было даже избыточным для того, чтобы присмотреться, прислушаться, записать, проанализировать, сделать выводы и поблагодарить за помощь в улучшении дизайна.