будет около 1000 организаций, по каждой около 100 тысяч счетов и чуть меньше платежей из банка ежедневно по рабочим дням. вопрос имеет ли смысл проектировать такую конфигурацию на 1с или стоит использовать другие платформы.
задача реальная просто нужно экспертное мнение сообщества

(16) вот кстати почти как дикси https://habr.com/company/X5RetailGroup/blog/432412/

(19) Скажу так - когда в ритейле котором я работал? внедряли SAP PI, то приехал целый отдел разработки SAP, сидели круглосуточно, дорабатывали на лету, ибо никто не ожидал такой нагрузки и ПО не справлялось.
Возможна ли в принципе такая ситуация у нашего вендора?)

(20) приехал целый отдел разработки SAP - имелось ввимду немцы из головного отдела, а не локальные внедренцы

Я уже молчу сколько стоит годовая стоимость владения 1 рабочим местом, ибо низя разглашать, но могу сказать что дохрена.
Но это работает.

(0) без сценариев работы пользователей это тупой вопрос

(22) да, лучше молчи

(0) А по факту - один только сбор ТЗ тут на месяцы растянется)

(19) Ух, сколько там золотых слов то.

Вы серьезно, миллиарды счетов в 1с? Бред.

(27) почему? если делать по технологии фреш или аналог, то там будет 1000 паралельных баз в скуле или оракле и один кластер 1с который будет паралелить все это...

тут ответы простые

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

(27) В одной базе на чем бы она ни была, хоть на одной эс, хоть на другой эс - ничто не потянет.

(29) Это совершенно не так, есть базы которые потянут это из коробки, например https://ru.wikipedia.org/wiki/Riak
И кста это выйдет сделать в сотни и тысячи раз дешевле чем на 1С, хороший пример того где 1С практически не конкурентоспособна.

Клиент хочет одну базу. Без фрэша. Скорее всего самописка. Но модет надстройка на типовую. Не знаю почему так. Но пока 50/50

Просто хочу понять расходы на железо.  База будет централизованной. Нужно примерно понять ширину Канала связи на 3000 пользователей

вопрос о сап закрыт отрицательно

документы скорее всего будут "однострочные". Если правильно спроектировать систему, то 1с справится. конечно если основное условие - чтобы работало на том севрере что стоит вон там в углу - то ясен пень не взлетит.

в одной базе 100 документов в секунду и 24/7 - крайне сомнительно, значит надо распараллелить. а раз так нужно чуть больше информации (на самом деле сильно больше) о бизнес процессах - что должно учитываться, какие отчеты собираться, какие зависимости данных, какие есть операции критичные по времени выполнения и т.п.
тогда уже можно и пофантазировать по архитектуре. но вообще согласен - вопрос надо в голову 1С задавать.

ИМХО, вполне возможно. Исходя из описания задачи, ничего в ней сверхестественного нет. Но тут стоит понимать, что требования к проектированию очень-очень вырастают. Придется каждый реквизит и каждую строчку кода продумать. Главное чтобы к задаче не подпустили эхфективных менеджеров, типа автора вот этой статьи:
Идеальный программист (статья с Хабра)

А вообще, структуру данных - в студию!

(4),(35) ноль потеряли один)
1000 документов в секунду

Ни в коем случае не обращаться в 1С по данному вопросу.

Ведь им совсем не интересен данный проект.

(0) главное чтобы банк не лопнул

(0) серьезная нагрузка ; требуется выверенный и быстрый код, компактная передача данных- вплоть до битов;)

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

100000 счетов в день. 5 минут на счет - примерно 100 счетов в день на человека. 100000 счетов - 1000 сотрудников в каждой конторе. 1000 контор - 1000000 сотрудников. Это нужно задействовать весь офисный планктон России.

+(43) https://moremost.livejournal.com/293588.html

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

(45) +1

А вроде даже факторинговая компания

(45) Ну тогда, видимо, Aliexpress переходит на 1С

(45) А, ну если сотрудников нету, то и 1с не нужна. Даже странно, что про 1с вспомнили при таком раскладе.

(48) это да. Некому в формы данные вводить и кнопку провести нажимать.

(48) Да сотрудники-то наверно есть, но их не много и через 1с просто хотят смотреть на данные и скорей всего не на первичку, а на какие-то консолидированные результаты. Возможно будут на основании первички генерить какие-то сводные доки. Без знания подробностей можно только гадать о замыслах ТС-а...

(0) >около 1000 организаций, по каждой около 100 тысяч счетов и чуть меньше платежей из банка ежедневно по рабочим дням.

Работал в конце 90-х в банке... банк был в топ 30 по оборотам, хотя не мск. Платёжек было значительно меньше чем вы тут нарисовали.

Если всё так в реале как вы тут нарисовали - добро пожаловать в мир Enterprise. В этом мире и объёмы данных другие и железо и зарплаты, но и требования к качеству...

И да... стоковый клиент-банк/интернет-банк для 1000 организаций не подойдёт...  тут и с банком следует как-то вопрос решать к взаимному удовольствию.

(31) // Клиент хочет одну базу. Без фрэша. Скорее всего самописка.

не взлетит

одной базой такое не решается

(53) Так может там база из двух таблиц. Мы же не знаем о чем вообще речь.

1С это конечно звучит гордо, но есть и у нее предел.

(52) какие проблемы со взлётами?

(50) "через 1с просто хотят смотреть на данные" ну как бы можно, но зачем 1с. Для этого есть, например, Power BI.

(56)
Владимир Маяковский ПОСЛУШАЙТЕ!

Послушайте!
Ведь, если звезды зажигают —
значит — это кому-нибудь нужно?
Значит — кто-то хочет, чтобы они были?
Значит — кто-то называет эти плево́чки жемчужиной?

И, надрываясь
в метелях полу́денной пыли,
врывается к богу,
боится, что опоздал,
плачет,
целует ему жилистую руку,
просит —
чтоб обязательно была звезда! —
клянется —
не перенесет эту беззвездную му́ку!
А после
ходит тревожный,
но спокойный наружно.
Говорит кому-то:
«Ведь теперь тебе ничего?
Не страшно?
Да?!»

Послушайте!
Ведь, если звезды
зажигают —
значит — это кому-нибудь нужно?
Значит — это необходимо,
чтобы каждый вечер
над крышами
загоралась хоть одна звезда?!

[1914]

(0)На 1с не взлетит. Это не та платформа, на которой стоит решать высоконагрузочные задачи. Имхо.

(59) В мире 1с, тормоза - это не проблема, а предмет гордости.

(58) это сейчас к чему?

(31) > Но может надстройка на типовую.

Ни одна типовая с такими объемами не справится.
Даже если брать 1С:Платежные документы, где на первый взгляд нет ничего лишнего.

Автор если ты задаешь такие вопросы,  тебе наверное не стоит браться за задачу.
Второй вопрос, откуда уверенность про 1000 организаций и 100к платежей.
Это из разряда, а давай спланирую ка я с самого начала true-архитектуру?

(38) точно )

Присоединяюсь к (37), (54) и т.п.

+  (64)

Думаю да. Только проектировать нужно будет исходя из такой нагрузки.

Ну и статью рекомендую прочитать:
http://catalog.mista.ru/public/835719/

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

Подобное делали для одной сети магазинов, загрузка шла круглосуточно, параллельными пакетами, в несколько потоков, потом временные слои по часам собирали аналитику для базы на которой делали отчёты. Было две базы, одна для аналитики, другая только для загрузки. Работает до сих пор. Приглашали 1с, они помогали делать загрузку. Стоимость проекта была под 1млрд.

Да и забыл проголосовать

(68) Повезло вам. Найти лоха с миллиардом - это как в спортлото выиграть.

(0) Вы лицензии-то считали? Проще что-то стороннее посмотреть, по деньгам еще дешевле выйдет.

(68) Ну и что в этом решении от 1С осталось? Морда лица?

(4) странная у вас арифметика. 100000000/86400=1157 в секунду

На фреше поднять можно. Сервер мощный нужен будет, пара кластеров, куча еще доп серверов, сайты, прокси. 1с если соблюдать правила разработки, как в принципе и с любой системой,кроме SQL еще не чего особо не придумали,  если будешь гонять запрос без отборов с 1м записей будет значительное замедление. или блокировать всю таблицу на час. так что все в руках разработчиков, есть инструменты мониторинга производительности системы в целом. ЦУП вроде.

Всё не читал - удалось понять, что это за данные такие у ТС?

(74) сейчас дичайшие скорости у серверов, можно и 1000 000 000 доков в день )))

да бред какой-то

причем, абсолютно не ясно, каким боком все эти данные могут быть притулены к 1С?!

что вообще можно называть 1С-кой в части размытых по времени и по пространству больших чисел астрономического масштаба?!

1.7 м и у тебя супер комп, для sql, покупаешь хранилище ibm зависит от харизмы, для 1с придется ставить несколько серверов на тех процах которые она быстро кушает ... 3 млн, может больше только железо.

ну скромный ск с 1тб памяти всего..

(78) если денег мало, то всё будет прекрасно работать на трёх серваках за 200 ты. Если денег много, то всё будет точно также работать та 30 серваках за 1 миллиард. :)

интересно сколько по стоимости будет стоить железо, которое потянет примерно такую нагрузку. Знакомая контора платит за аренду серверов 700к в мес, при этом нагрузка даже близко не такая. Мне кажется их знатно разводят

Типичный сценарий загрузки от типичного 1сника:
- данные считываются из файла, расположенного на диске, а то и на сетевом ресурсе
- считанные данные загружаются в типовой документ со ста реквизитами
- при загрузке делается миллион запросов в цикле, типа НайтиПоКоду, НайтиПоНаименованию и получения значений через точку
- после загрузки документ тут же проводится по тридцати регистрам
- всё это дело тянет вниз сложные RLS

Если с такими подходами, то да, 1С не вытянет. А если всё грамотно спроектировать и организовать, то проблем быть не должно. При грамотном подходе упрешься в производительность оборудования/канала/СУБД, но не 1С. 1С "глючная и тормозная" только когда её заставят быть такой.

(0) 1000 организация в рамках одной конфигурации?
Очень странная постановка задачи.  

Зачем?

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

(84)как-то она странно вылезла. 8.3.12 и 13 жутко тормозные даже на простейших операциях

(52) смотря как спроектировать и какой бюджет на всё это... если есть 2 компа на целеронах вместо серверов и ТС как единственный разраб и это вообще всё.... конечно не взлетит

(85) были неудачные релизы, не спорю. но в остальном достаточно приемлемо.

(85) например? Что за операции?

Если ПрямыеРуки и ЕстьОпытЗнания и ЕстьФинансы Тогда
    СтоитИспользовать1С = Истина;
Иначе
    СтоитИспользовать1С = Ложь;
КонецЕсли;

(89) а я думал что 1С - это когда финансов нет ;-)

(90) 1С - это доступно и всерьёз )

(91) Штаны слезут на крупных проектах такого рода из-за лицензий перед open source... Счета на оплату - самый тупой документ без движений.

3000 пользователей * 3.5 тыс лицензия 1С на рабочее место = 10.5 лямов, плюс кластер серверов, лицензия MSSQL (мы же тупые 1Сники, слона не ставим) ~ 20млн.
Это только лицензии без работ.

Берем open source = 20 000 000 / 70 (курс) / 40$ (ставка хороших спецов) / 8 (рабочий день) = 892 дня спеца.

(87) ctrl + break работает, горячие клавиши/контекстное меню в терминале не отваливаются после отправки на печать, ага...

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

Такое можно сделать, если есть настоящие эксперты по 1С

в виде документов счетов 115 проведений в секунду? в 1с это не возможно в следствии механизма блокировок и бесконечной генерации временных таблиц.
Подобную скорость возможно реализовать на регистрах сведений, файловой базе на nvme ssd, но файловая база не сможет работать с таким количество сеансов.
В общем не решаемо

(97) а нахрена это ПРОВОДИТЬ? пишем документ и все. судя (по крупному) - то что ТС написал это сугубо тупо регистрирующая система. записали - равнозначно "провели". а дальше все записанное можно сливать или делить по базам с проведением и прочим хоть в один поток хоть в 100.

и вообще неизвестно из условий задачи будут ли там сеансы как таковые.

В принципе, это некорректная задача, на которой вообще не имеет смысла говорить, что для ее решения используется 1С

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

(97) если документ, то обязательно надо его сразу же проводить? Даже по части проведения есть множество вариаций, позволяющих повысить производительность. Но тут нужен будет впринципе не 1сный подход. Как вариант:
- сначала данные тупо загружаются из внешней системы в документ, у которого три реквизита: номер (без автонумерации и контроля уникальности), дата и строка с данными в формате JSON. Этот документ является чисто буфером для загрузки
- затем документ из предыдущего пункта разворачивается в нормальные документы. Но делается это оптимально - на каждую порцию документов по одному однотипному запросу. А не как обычно принято, запросы в цикле
- если требуется проведение, то это делается третьим этапом. И это снова делается оптимально. Никаких тебе контролей при проведении, соединений в запросах со сторонними регистрами. Тупо выхватили данные из документа запросом и тут же закинули их в регистры. Движения только по оборотным регистрам накопления компактной структуры
- следующим этапом уже ищем "грязь" в проведенных документах. Обычно косячных документов немного, поэтому правильнее их выцепить после, чем каждый контролировать при проведении
Всё это добро разруливают грамотно настроенные регламентные задания. С распараллеливанием и прочими фишками, повышающими производительность

(101) Ой да нафиг эти всякие регламентные задания, документы, проведение-непроведение, если можно это сделать без 1с и гораздо дешевле. Если данные вводить руками в 1с никто не будет, то 1с не нужна и кроме тормозов ничего проекту не даст. Судя по описанию, там всё просто, но много данных. Главное - это пропускная способность. Нужно обращаться к специалистам. Хотя, если там всё так просто как написано, то и пару студентов хватит.

я тут подумал, потребителем такой системы может быть фнс, которая хочет собирать документооборот

(102) "и гораздо дешевле"

Далеко не факт

+(104) задача описана далеко не полностью. Данные эти ведь для чего-то загружаются, потом будут как-то обрабатываться. Уже эта дальнейшая обработка и выводы всяких отчетов на других системах могут оказаться дороже.
На моём предприятии все операции сначала проводятся в системе на Oracle, а потом данные переливаются в 1С. Уже в 1С данные обрастают дополнительной аналитикой и формируются всякие отчетики. Допиливание отчетиков и бантиков в 1С обходится гораздо дешевле по части разработки. И это только стоимость разработки. Стоимость ПО отдельная тема. Заморские СКД на заморских системах продаются отдельно, и стоят дороже славянской платформы 1С со всеми потрохами.

А что это вообще такое "1С"?
Какой смысл, какое содержание следует подразумевать, когда задается вопрос "Смогу ли я решить задачу если буду использовать "1С"?

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

Предложенный объем критичен только по отношению к серверу БД, если он с ним справляется, то любой софт закидывающий и выбирающий данные будет работать, в том числе и 1с, а дальше - всё зависит от того, какой программисты напишут код.

(108) Узким местом на запись объектных данных является сервер 1С. Без автонумерации, контроля уникальности номером.
Просто запись простого справочника из кода и наименования.

для таких ежедневных объемов использование 1С это постоянный подвиг
думаю здесь надо напрямую писать в SQL
а 1С для аналитики

(109) так было ещё в 8.2, в 8.3 многое в этом плане поменялось

+ в 8.3 многое перепахали в части производительности и параллельности

(112) То что нумератор работает единовременно в один поток - осталось.

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

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

(113) это понятно. Поэтому выше я и писал, что не использовать автонумерацию и контроль уникальности.

(0) 100 млн документов в день - это немного. Узкое место - SQL.
У меня ( в другой системе) получалось 1 млн документов в 5 сек.То есть 500 с на все 100 млн если многопоточность работает.

(117) Ну это пакетно если.