Коллеги, есть такой любопытный вопрос: имеется допиленная типовая бухия, платформа 8.2, средней паршивости сервер. Объемы исчисляются в сотнях (150-200) обычных бух. документов ежемесячно (строк по 10-20) + 90 доков по 9-10 тысяч строк. Разумеется, это все вполне себе работает и не жужжит.

Но тут озвучили одну занятную задачку, при реализации которой количество записей в упомянутых тридцати документах возрастает до трехсот тысяч. 300 тыс. х 90 = 27 млн. записей в месяц (и столько же бухгалтерских проводок, ага).

А теперь сам вопрос - достаточно ли будет аппаратного масштабирования (ессно, после расчетов), или у платформы есть какой-то предел по возможностям обработки и объемам базы? Сама база на данный момент - 150 гигабайт (рост с 20 до 150 произошел за 2014-2015 годы, когда появились вышеупомянутые многострочные документы).

Альтернативные варианты имеются в запасе, но хотелось бы услышать мнение касательно 1С - предпочтительнее будет не плодить зоопарк в инфраструктуре.

(0) блокировки

почитай внимательно Посоветуйте интегратора с опытом внедрения ERP от 1С.

+(0) Разумеется, возможность разнести эти триста тысяч строк по разным докам есть, но практического смысла это не имеет, по большому счету. Разве что проводить удобнее.

(2) Да читал я, там акулы ща переколбасят друг друга желтыми книжками и 22-сантиметровыми :)

Мне бы мнение тех, кто практически с такими объемами сталкивался уже.

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

(1) Разумеется. Теоретически вариант решаемый, возможно даже вынести проводки этих документов в отдельный регистр.

(3) документы дробить обязательно иначе будите их по очереди проводить.

(5) Да, это не проблема. Увеличится кол-во доков, уменьшится кол-во записей. Объемы данных только не изменятся почти.

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

а в целом вопрос производительности и отказоустойчивости решается только итерациями. Нашли бутылочное горлышко расшили смолтрим где еще есть проблемы.

(5) отложенное проведение ...
(4) 1с не зря сделало ограничение на размер табличных частей, в практическом смысле не стоит делать документы которые делают такие большие транзакции...

кроме того на транзакцию памяти много надо, скорее всего словишь исключение по памяти....

(10) Меня как раз и интересует вопрос - являются ли возможности технологической платформы 1С 8.2 этим самым бутылочным горлышком, которое расширять уже нечем и надо использовать альтернативные варианты?

У меня в практике был случай на большом заводе, когда документ КЗР записывал около млн. записей.Запись в базу на серваке происходила примерно 1-1.5 часа на серваке средней паршивости.Но дело даже не в этом, а в том что сервер приложений забивал всю память и падал от этого.

Зарание вам серебряную пулю не кто не даст. 1с дает лиш общие рекомендации бывает так, что в конкретном случае их можно нарушить.

(10) ты не прав, тут 90% зависит от выбора архитектуры

(11) Во, уже ближе к теме. ОК, разобьем доки по 10 тысяч записей, получаем 2700 документов.

(14) В общих рекомендациях 1С все радужно и масштабируемо до уровня неба и Аллаха. На практике веселуха заканчивается, начинаются суровые будни.

(13) Но таки проводился и выбивало в редких случаях?

(15) да ладно даже стив маконел рекомендует учетные решения разрабатывать итерационно т.к. время на создание хорошей архитектуры может перекрыть время жизни решения.

(17) все зависит от уровня нормализации/денормализации таблиц, именно на этом этапе ты ДОЛЖЕН избавится од 99% проблемм с маштабируемостью...

почитай когда нужно нормализовывать а когда денормализовывать.  Читать лучше например курсы по SQL, а потом это применять к 1с.

(18) В основном проводился.

(21) Тогда, думаю, это исчерпывающий ответ на мой вопрос. Если миллион проводок пишутся 1-1.5 часа, то и 3 документа по 300 тыс. строк (или 27 по 10 тыс.) дольше двух часов проводиться не будут. Делается это в ночное время, так что вопрос блокировок не сильно актуален, да и решить его можно на уровне разработки.

ЛУчше дробить большие документы по непересекающимся частям
И включать управляемые блокировки

а может нужно начать с "Организации документооборота"?
Слабо верится в такое количество хоз.операций в короткое время.

Принцип "Консерватории" еще не отменён :)

(24) Там много мелких платежей, собсно.

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

(22) не делай так, расскажу, что будет на себе

когда делали факторинг на ночной регламент повесили расчет комиссий по договорам (каждый день примерно 500 000 проводок), расчет занимал примерно 2 час... Хорошо, что я его сделал не одним документом а многими.

Теперь что было дальше...

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

Проводки сводно, детализацию в регистр накопления.
Можно сказать, типовое решение.

(26) Не, это совсем адЪ чота :)

(27) >не делай так

В смысле, большими документами? Да это уже понятно, разбивать будем.

(29) Не всегда, у нас так сложился БП, что даже на каждый продукт, даже в рамках одной отгрузки будет своё приложение и т. д. Иногда удобства от такого больше, чем геморроя с количеством документов.

да и в целом регистры бухгалтерии не очень в плане высоко загруженности.

(32) Было бы удобно с точки зрения отчетности, но какбе и не обязательно. Рассмотрим вариант с детализацией в РН (или вообще все в РН вынести, по большому счету двойная запись в моем случае не нужна).

(33) Я так в рознице ещё на клюшках делал. По номенклатуре учет в регистре, бухучёт на проводках.

(33) А что ты будешь делать с этими данными?Может создать буферную таблицу в скуле и напрямую туда писать/читать?

(9) >данные подгружаются из другой инф. системы.

Я бы крепко подумал, а стоит ли использовать именно документы. Может РС лучше или еще что.

А проводки нужно агрегировать.

(25) Терминальшики что ли?

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

+(38) Вообще, я к этому варианту изначально очень склоняюсь, ибо вообще все траблы отпадают. Но тут вмешиваются хотелки больших юзеров.

(39) Как это идет вразрез с хотелками?

(38) ну тогда вариант собирать все рн, а потом в конце месяца делать общую проводку по бух учету без разбивки.

(9) Если "данные подгружаются из другой инф. системы", то разумнее поменять концепцию: вводить проводки агрегированные суммы авизовками.

(36) А может вообще внешний источник данных чисто для отчетов. И не надо тащить их в 1С?

(38) Для целей БУ детальные данные нафиг не нужны. Их нужно сливать в отдельную базу. Если недалекий босс хочет непременно 1С - пусть будет 1С. Только проектировать нужно тщательно.

Ваша задача агрегировать в 1С крупнее, и обеспечить сходимость и возможность валидации любой 1Совской проводки с OLTP-базой

и в принципе можно даже нарисовать при помощи Внешних Источников данных интерфейс в эту OLTP-базу, так чтобы на пользовательском уровне решение выглядело seemless

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

P.S. безумно не хватает в 1с возможности писать наборы регистров накопления без отбора по регистратору (чтобы можно было формировать наборы сразу по нескольким регистраторам)

(47) писать с привзякой с кзр

ТС, что мешает произвести нагрузочное тестирование?

(49) Вопрос пока академического характера, мощностей свободных на ближайший месяц не дают - заняты. Не на десктопе же тестить.

(50) Ну на самом деле тебе ответ даст только скажем Тест центр, а все остальное это балобольство и предположения =)

на всяк оставлю тут) http://v8.1c.ru/expert/tc/tc_overview.htm

(50) Ага, спасибо :)

Ну как балабольство - Ranger_83 реальный пример привел, от которого уже плясать можно. Я же не точные цифры спрашиваю - сугубо "мона или низя/нинуна/лучше не надо?".

(53) Твое оборудование может сильно отличаться от Ranger_83, как и ваши представления о "средней паршивости сервере". ))

(54) Задача не совсем чтобы "какие мощности требуются", а "возможно ли принципиально это сделать на данной программной платформе, если предположить, что аппаратно масштабироваться можно до усёру?" :)

(55) ну я тогда поставлю на "что да, возможно" =)

(55) кстати такое большое количество документов как в (16) можно проводить в несколько фоновых заданий: http://test-out.kursypo1c.ru/articles/%d0%ba%d0%b0%d0%ba-%d1%83%d1%81%d0%ba%d0%be%d1%80%d0%b8%d1%82%d1%8c-1%d1%81-%d0%bc%d0%bd%d0%be%d0%b3%d0%be%d0%bf%d0%be%d1%82%d0%be%d1%87%d0%bd%d0%be%d1%81%d1%82%d1%8c/

(57) при условии что данные не пересекаются.

(58) Это написано в статье

(57) Благодарствую, может пригодиться =)