https://habr.com/ru/companies/cdek_blog/articles/1074562/
Пока читаю, но вот что удивило:
"Финансовые события и расценки — это первичные данные биллинга. Их очень много. Их нельзя терять. Мы являемся мастер‑системой этих данных. Поэтому хранить их должны максимально надёжно и экономно.

Храним в независимых регистрах сведений. Реквизитный состав этих регистров сведений имеет максимально примитивные типы, а сами регистры имеют минимальную индексную нагрузку.

Первичные данные партиционируем. Причём не средствами СУБД, а на уровне метаданных 1С.

Для каждого месяца у нас есть отдельный регистр для финансовых событий и для расценок. Итого — 24 регистра на год."

Как вам такой подход?

(0) В правильных системах можно было бы делать средствами СУБД. Но тут же 1С. Плюс ковыряние в СУБД всегда на свой страх и риск.

Так что подход понятен.

Не очень верится что у них первичка биллинга именно в 1С, но если б делал, то делал как-то в подобном варианте. Чем больше  нагрузка на регистр на запись, тем логичнее разнести эту нагрузку на разные регистры. Задача легко распараллеливается.  Для меня странно что всего 24 регистра.

Одно я не понял. Почему в СДЭК 1С сделали мастер системой для биллинга. Это какой-то кривой подход. Видимо там 1Сники в свое время захватили власть.

(3) Предполагаю что это после того, как их самаписку, несколько раз взломали.

(0) клоуны, поржал

Тупо сэкономили.
На 1С оказалось дешевле и спецы есть...

(5) У них там компромисс между имеющимися ресурсами и корректным (с технической точки зрения) выбором инструментов для решения задачи. Как система, смотрится не так уж и плохо.

(0) а они восстановились после того как месяц восстанавливали инфраструктуру?

По реализации:
Биллинг складских операций-1 регистр, 1 заполнялка табличной части реализации

Биллинг инжинириговой компании по заготовке леса(прокладка дорог, заготовка леса, транспортировка до зоны приемки, включая сплотирование)

1 регистр, +генератор пбз, для себеса


Ап регистр накопления ессно
(5) поддержу

Кривое архитектурное решение
Я бы сделал 366 * N регистров на каждый день в году и вид операции
Затем данные из этих регистров переносил в более полные сводные

(9) 👍 аналогично.

(0) Много разумных решений.И самое главное,есть что посмотреть на гитхабе.А критикам и выложить нечего.

(3) потому что 1С отлично подходит роль мусорки. не под фронт же ее использовать в самом деле

(12) Конечно,конечно.Java там не "шмогла" ибо нерусь, дорогая.

(9)
Еще более кривое решение.В СДЭК стояли на земле, и видели реальные объемы данных.Так что они пошли на компромисс между сложностью и скоростью.Вы же предлагаете систему космического масштаба...

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

(0) Не вижу ничего криминального. Самолюбы, которые тащат всё во внешние базы - просто не умеют готовить РС.

p.s. Скорее всего, под СДЭК 1С запилило механизм расширенной модификации РС, а потом и РН до кучи. Плохо чтоли, хорошо!

«Владислав был очень могущественным, он мог превратиться в любое животное. Вот только у него не всегда получались лица».

(16) 1С уже умеет программно в регзадании CREATE TABLE?

Думаю, имеет право на жизнь. Но сложно получилось, по меркам 1С.

(18) Докладчик написал, что раз в год создают.

(18) С момента появления Внешних источников данных.
Или вопрос про создание регистра в метаданных конфигурации?

(21) Про создание новых регистров и прочих объектов метаданных в СУБД
При необходимости, хотя и редкой

Заходишь в типовой 1С УХ, смотришь на синтетический регистр показателей, затем на пронумерованные аналитические регистры показателей.
Консолидация, конечно, древний продукт уже, но в 90-х такие решения для dbf часто встречались.
P.S.
И да, я помню, как в Зик-1 итоги в справочник складывались.

(22) Если есть pipeline, то запихнуть новые "типовые" объекты метаданных в GIT не большая проблема

(14) Для программы какая разница 24 или 366 ?

(25) 366 даже удобней
По идее можно на каждый новый день новую табличку создавать
А затем удалять когда данные в архив переходят

Решение с 24 табличками (по 2 на каждый месяц) выглядит странным
Каждые новые текущие месяцы/кварталы будут явно самыми напряжными, больше всего движений/обращений
Затем постепенно все меньше движений, затем всплеск перед концом года
И когда год закрыт совсем нет почти

(27) Это же СДЭК, а не бухня с кварталами/закрытиями периода. Навряд ли там наблюдается сезонность. Каждый месяц примерно одно и то же.

(28) Это Б2Б с клиентами - контрагентами юриками
И вот когда они год закрывают/подбивают и начинается вся движуха
А в течении года на расслабоне

(28) >Каждый месяц примерно одно и то же.

Так может вынести в отдельные таблички текущий день, прошлый день, текущий и прошлый месяц и "все остальное"?
Этого достаточно?

(30)+ Иначе получается что в первых числах месяца все летает
А под конец месяца у всех тормоза ))

(29) Только движуха эта - не добавление/изменение данных, а чтение. А обрабатывать переходящие данные легче в 12 таблицах, нежели в 366.

(32) Они выставляют счета раз в месяц?
Тогда хватит одного незакрытого/закрытого месяца и целиком года, куда все переходит
Зачем 12 таблиц по числу месяцев в году?

(0) фигассе

(32) Если самое напряжное чтение - логичней как раз по дням хранить а не по месяцам
Ибо отчет может быть не за целый месяца и лезем в две большие таблицы
Вместо кучи мелких по числу дней

А еще можно не по периодам а по контрагентам делить ))
Тогда не надо заморачиваться некими календарными табличками
Тупо у каждого клиента-контрагента свой набор таблиц полный

(33)
Компромисс между объемом одной таблицы и накладными расходами на партионирование.

(36) ПРикольно вернуться в тему и обнаружить спор на том же самом месте.Я в (14) заметил, что СДЭК пошел на компромисс.При 366*N таблицах много будет накладных расходов по перемещению с дня на день даже.И это тоже снизит производительность.

(37) Что еще за перемещение со дня на день?
Какие еще в жопу накладные расходы???

Что SQL запрос на удаление из одной таблицы и на добавление в нее же.
Сильно быстрей чем SQL запрос на удаление в одной таблице но на добавление в другую таблицу?

Пипец
Люди.
Автоматизаторы
Многопользовательских ля приложений.
А про блокировки (на одну большую таблицу) не в теме.
До чего 1С довела...

ЗЫ
Надо признать что с РС и блокировками все чуть попроще.
Чем со справочниками и документами или РН.

Самое интересное.
Как СДЕК выкрутился с лицензиями 1С?
Как с серверными так и с клиентскими на каждый сеанс даже, не пользователя.
Очень, очень, очень интересный вопрос...

(40)Купили, может?

(41) Там суммы выходят больше чем наваять не на 1С

Пусть и не все всё время в онлайне но как?

в 201х искали эксперта с параметром 5000 человек в базе одновременно

(42) статью не читал. Но на первой картинке в ней фронт отдельно и не на 1С. Так что 700К клиентов это контрагенты, а не пользователи 1С.
P.S. Нечего контрагентам в базе биллинга сидеть.
P.P.S. А вот почему отдельные базы для расчетов и биллинга - интересно...

(44) Там из фронта открывается во фрейме веб-клиент 1С с прямой авторизацией по токену
Причем гиперссылки во все стороны увязаны, так то отличная штука

(43) КамАЗ? Там вроде в проблемы клиент серверного взаимодействия при масштабировании в прод упёрлись, расследовали, но ограничились переписыванием 1Совского кода.

(46) Тут как понял все проще ибо самописка
Но минимум некие куски типовых должны быть, для формирования документов правильных

(45) (47) долистал, они на упрощенке!?

(48) Ну дык налоговая оптимизация же
Не они первые

(39) А про управляемые блокировки и пространство блокировки 1С может напомнить?А то большая таблица,большая таблица...Тьфу.

(50) Дык берем форму, просто форму
Данные не привязаны
Получаем их запросами из РС
Пишем туды же
Какие блокировки?
Только нужные на нужные измерения РС как надо ставим

(51) Из статьи,комментарии автора отвечают за меня:

Чем больше партиций тем больше запросов...

(52) Не догадались до связки?
Писать по каждому заказу в какие дни (какие партиции) по нему есть движения например
Затем динамически генерим запрос используя только нужные таблицы

Но имхо это кривая архитектура
Правильно это полный набор отдельных таблиц по каждому клиенту
Без разделения по месяцам

Мелких клиентов с мало данных/юзеров можно группировать
Пусть сидят в одной области

(15) В Яндексе тоже "все работало" пока нес лучился перегруз

(54) Миллионы регистров делать?

(56) Нет. 700к клиентов - сгруппировать по объему в нужное кол-во разных СУБД PostgreSQL.
При общих базах (для группы клиентов ибо конфа одна) на серверах 1С в режиме разделения данных.

Шардинг данных через секционирование PostgreSQL

Вариант. Шардинг данных через секционирование PostgreSQL (Архитектурный хак)

Если цель — сделать так, чтобы для сервера 1С это была одна-единственная база данных (что даст максимально возможную экономию ОЗУ на сервере 1С, так как кэш будет строго один), но таблицы физически лежали на разных серверах Postgres, вам нужно использовать горизонтальный шардинг на уровне СУБД.
Этот вариант реализуется с помощью стандартного механизма PostgreSQL FDW (Foreign Data Wrappers) и декларативного секционирования (Partitioning).

Как это устроено:

1. На основном сервере СУБД (Postgres-Main) создается "пустая" база данных 1С. Сервер 1С подключается только к ней.
2. В конфигурации 1С включается штатный механизм разделения данных (добавляется разделитель, например, ОбластьДанных).
3. На уровне PostgreSQL таблицы этой базы делаются секционированными (партиционированными) по полю разделителя (spFldXXXX).
4. Сами секции (партиции) через механизм postgres_fdw физически размещаются на разных удаленных серверах СУБД (Postgres-Server-B, Postgres-Server-C и т.д.).

Как это работает на практике:

• Сервер 1С отправляет запрос в Postgres-Main: SELECT * FROM _InfoReg123 WHERE _Fld456 = 'Организация_1'.
• Postgres-Main анализирует запрос, понимает, что данные для 'Организация_1' лежат на удаленном сервере Postgres-Server-B, и прозрачно перенаправляет запрос туда.
• Результат для 1С: Сервер 1С думает, что работает с одной базой. Память rphost экономится максимально (один кэш, одни фоновые процессы).
• Результат для СУБД: Нагрузка по дискам, процессору и памяти СУБД распределяется по разным физическим серверам.
Плюсы: Максимальная экономия ОЗУ на сервере 1С. Физическое разделение тяжелых данных по разным серверам СУБД.
Минусы: Экстремально сложная настройка СУБД. При обновлении конфигурации 1С (когда меняется структура таблиц) придется вручную или скриптами пересоздавать партиции на удаленных серверах Postgres. Высокие требования к скорости сети между серверами СУБД.

(57)+ И не придется ничего изобретать с некими 24 таблицами на 12 месяцев.
И даже пофиг на хранение данных только в РС, можно нормально в 1С проектировать метаданные.

Нельзя обьять необъятное...

У меня база 3 Тб, с количеством строк документов и записей регистров накоплений - 1.5 млрд штук. Эта база крутится на дешевеньком сервере. И поэтому я могу с учетом этого опыта оценить "титанический" труд разработчиков 1С СИДЕК.
  Берем исходные данные:
  Количество Контрагентов: 700 тыс.
  Количество Документов в день: 100 000 ( 1 документ в секунду, можно здесь даже не надо делать фоновое проведение) если документы легкие, то 1С потянет 50 док. в сек
  Количество Документов в год:  3 000 000
  Количество Строк в табличной части в год. менее 30 000 000
  Количество Событий (количество Записей регистров накоплений их там штук 10) - 3 млрд. в год
  Количество работающих OnLine - 1500 человек
  Ничего такого выдающегося здесь нет. Типовые конфигурации здесь не пойдут. А простейшая самописка будет работать легко.
   Единственная проблема при использовании 1С в такой задаче - это не эффективное хранение информации самой 1С. И соотоветственно размер самой базы
    Возьмем 3 млрд строк регистров накопления. Я думаю, что здесь должны быть регистры оборотные. Размер будет в районе 3 Тб с учетом индексов.
    Контрагенты 700 тыс - 1 Гб
    Документы Шапка 3 млн - 3 Гб
    Документы ТаблЧасти - 30 Гб
За счет индексов получение информации о любом документе, событии, контрагнте << 1 сек
    Мелкая проблема - это получение сводной информации из оборотного регистра, с количеством записей 1.5 млрд, с анализом построчно занимает, на слабом сервере  минут 30.
   Это можно спроектировать КУБ, заполнять его раз в месяц. Тогда даже отчеты будут летать.
   ВЫВОД. Зря они изобретали ВЕЛОСИПЕД. Проблема в том, что они сначала изобрели ВЕЛОСИПЕД на JAVA, а потом переделали его на !С

И опять же, разработчики прикрутили к базе RLS, значит особых проблем с быстродействием 1С у них там нет

Такая копеечная база легко будет работать через WEB броузер

(62) Ты не забыл про хз сколько юзеров в онлайне из 700к клиентов?
Это не просто контрагенты СДЭК, это его клиенты каждый со своим ЛК где веб-клиенты 1С во фреймах

(60) >Количество работающих OnLine - 1500 человек
А надо чтобы в онлайне было > 700 000 человек!
Точнее цифры хз, у одного клиента могут зайти сразу несколько пользователей, а могут у 70% клиентов никогда не заходить и тогда всего 200к в онлайне будет максимум

(64) > А надо чтобы в онлайне было > 700 000 человек!


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

(65) Есть такое
Но там хз сколько стоек с лезвиями

Там же сказано 1500 клиентов OnLine
У них же 1с это тянет. Тянет даже с RLS

(67) Один сервер 1С тянет максимум 200-300 клиентов 1С на самописке
На типовых еще меньше кстати, там до 100 вменяемо, дальше жуткие тормоза при активной работе

Если хочется чтоб все летало даже для 1500 сеансов пользователей в онлайне - надо нечто придумывать и один хрен кластер из серверов 1С
И начнет упираться в данные, в СУБД - они же не просто зашли а хотят отчет получить или документы?

А по совести изобретать ВЕЛОСИПЕД имеет смысл если:
Количество Контрагентов более 7 млн
Количество документов более 300 млн. в год ( 10 док/сек)
Количество строк документов более 3 млрд в год
Количество записей регистров накопления более 30 млрд. в год
Количество пользователей OnLine более 15 тыс.

Я думаю это придел  1с, из за плохой работы с памятью. Да и SQL не потянет уже

(68) Хотят отчет получить или документы ...
   Там же все индекировано. И количество документов, строк отчета не более сотни.
   А вот если ты захочешь получить отчет или документы по 10 000 клиентам. То там придется ждать. Но как нас учат ГУРУ Мисты "На зачем получать отчеты на сотни тысяч строк"

(68)  200-300 клиентов 1С на самописке ....
  Это у тебя тяжелая самописка. И на легкой самописке 1000 клиентов  должно тянуть легко. Я не пробовал.

(71) >Я не пробовал
А ты попробуй
Тупо даже зайти все 1000 не смогут на один сервер
Точнее там в размер кэша и оперативки упрется
Даже если конфа совсем пустая и ничего делать не будут

(72) Тупо даже зайти все 1000 ...
Что тут пробовать. У меня сейчас тяжелая самописка. Время проведения документа 2-3 сек, плюс ЧестныйЗнак, ЭДО, ЭТРН, Остатки, Взаиморасчеты, Затраты и прочая фигня.
  68 активно работающих пользователей OnLine. Работают без тормозов. При этом я никак не оптимизировал базу для работы пользователей.
   Бывают тормоза когда запускают групповое проведение документов в рабочей базе. В рабочее время.

Если у тебя время проведения будет 0.1 сек на документ (как на 1с77 было), то вообще никаких проблем с тормозами

(73) Ты посмотри/посчитай занятые ресурсы на сервере когда все 68 онлайн зашли и ничего не делают
А потом подумай что будет при 680 юзерах в онлайне?

(72) Точнее там в размер кэша и оперативки упрется
    Я смотрю у меня клиенты много жрут памяти. Надо бы разобраться.

(76) Это нормально
Тяжелый запрос в 1С может сожрать несколько гигов оперативки на сервере 1С

(77)+ Один запрос, одного пользователя

Мы же выяснили в легкой самописке не может быть тяжелых запросов. Запрос максимум на 100 строк

Тем более в тонком клиенте.

(79) Ты путаешь легкую самописку в смысле нет тяжелой конфы с кучей метаданных
И тяжесть запросов которые зависят от количества данных в СУБД

Если взять (0) то у него 1500 клиентов OnLine по 10 строк в сек в запросе.   15 000 строк в секунду. Копеечные запросы.

Все кроется в деталях. На моей поистине лекгой самописке, где 1.5 млрд. записей. Там каждый документ по 1 млн. строк. Вот ей тяжело. И по отчетам и по проведению. Отчеты строятся по сотням тысяч строк. Там десяток пользователей вряд ли сможет работать одновременно.
  Они просто SQL сажают

(79) напишу запрос в 20 строк, который заставит покурить любой сервер СУБД MS SQL.

(83) На нашей нелегкой самописки жили 1400 пользователей онлайн в 20 филиалах по всей Восточной Сибири. Писалось пряяям вот самописка + маркировка ЕГАИС, но потом в нее легко втиснули БСП не нарушая сна. Сначала там был кластер 1С из 2-х 24 ядерных XEON-нов и 192 Гб ОЗУ, а потом один проц выбросили нафиг за ненужностью и тормозам синхронизации ВХ.

(84) Мы не говорим о таких запросах. Речь идет о простых запросах к простым таблицам. С отборами по индексированным полям.

Пессимизм ваш исходит из того, что отлаженные типовые решения обрастают дописками долбоебов, которые ты ну вот никогда не заподозришь в проблеме. Вот эти всякие обмены в регзаданиях, которые запускаются раз в 5 минут и перезаписывают кучу справочников и РС, формируют ексель файлы через Лист.Ячейка(x,Y).Формат и прочая херня.

(76) Не надо путать пользователей РДП и пользователей 1С.
Держать один сервер с РДП и 1С для большого количества пользователей - такое себе извращение.

(85) Отсюда вывод. Что 1500 пользователей OnLine ничего страшного. Если нет грубых ошибок в структуре конфигурации

(89) Зато 1500 пользователей отлично тебе отсигналят о факте циклического падения rphost-а.

(85) Поистине легкая самописка, там нет ЕГАИС, ЧестногоЗнака, регистров остатков, сложных алгоритмов проведения. В идеале ее вообще включить без блокировок и таблицы индексов на быстрые диски.

"Как мы довели Postgres Pro до APDEX 0,986 на 30 000 пользователей 1С:ERP." в трёх частях
https://habr.com/ru/companies/postgrespro/articles/1093472/
https://habr.com/ru/companies/postgrespro/articles/1093484/
https://habr.com/ru/companies/postgrespro/articles/1093494/

Циклического падения rphost-а для 1500 пользователей
  У меня нет столько пользователей, поэтому я не знаю.

(73) 300 в ерп, 100+к документов выпуска в месяц

(60) мы когда грузили реализации в ерп, у нас на пустом сервере была производительность дисков/10.

(95) Мораль. Зря (0) изобретали ВЕЛОСИПЕД

(92) Влом читать.
Там кластера из скоки узлов серверов 1С и узлов СУБД?