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С проектировать метаданные.

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