|
|
Статья про то, как 1с в СДЭК работает.
maxar, Garykom, Кирпич, renegade, tomvlad, vis, Fish, Timon1405, АНДР, ansh15, H A D G E H O G s, Хряк, 1cVandal, Лодырь, DeeK, Чинандалар Бонг, San787, aka MIK, RVN, Dirk Diggler, smartu, SleepyHead, Lama12, Seriy_Volk, Ботаник Гарден Меран, Bad_Aleks, mikecool, okmail, paramedic, Мультук, andy_minsk, Доминошник, obs191, Chameleon1980, toypaul, Климов Сергей, zuza, PLUT, eddy_n, alexxx961503, akronim, Eugene555, Kigo_Kigo, Elf_80_lvl, Krendel, Web00001, RomanYS, evgeniy_n, arsik, oleg_km, ivanov-i-i, Fragster, troyka, Федя Тяпкин, Xapac, Адинэснег, slad, Михаил_, 2S, Dmitrii, Толич, Pers0naGrata, shuhard, Builder, Caesar, asady, d4rkmesa, bwi3, Галахад, Черников, ЭТРН, Hmster, bolder, Amra, A_G, Prog_man, BublikNM, d18, Anton9843, fbear, ads55, John D, vova1122, Sserj, rozer76, integer, mgreat, scanduta, Karamzin, Волшебник, lucbak, AlekseiYunniPodavvan, sikuda, Gucci76, Garikk, calmius, Ychenik1c, mmg, YFedor, LoneMan, MAG, ADirks, Alex33, Crusher, Vstur, Greeen, alexela, PuhUfa
| ☑ |
|
0
Fragster
гуру
28.10.26
✎
11:01
|
Всего мнений: 5
https://habr.com/ru/companies/cdek_blog/articles/1074562/
Пока читаю, но вот что удивило:
"Финансовые события и расценки — это первичные данные биллинга. Их очень много. Их нельзя терять. Мы являемся мастер‑системой этих данных. Поэтому хранить их должны максимально надёжно и экономно.
Храним в независимых регистрах сведений. Реквизитный состав этих регистров сведений имеет максимально примитивные типы, а сами регистры имеют минимальную индексную нагрузку.
Первичные данные партиционируем. Причём не средствами СУБД, а на уровне метаданных 1С.
Для каждого месяца у нас есть отдельный регистр для финансовых событий и для расценок. Итого — 24 регистра на год."
Как вам такой подход?
|
|
|
1
toypaul
гуру
28.10.26
✎
11:11
|
(0) В правильных системах можно было бы делать средствами СУБД. Но тут же 1С. Плюс ковыряние в СУБД всегда на свой страх и риск.
Так что подход понятен.
|
|
|
2
Lama12
28.10.26
✎
11:12
|
Не очень верится что у них первичка биллинга именно в 1С, но если б делал, то делал как-то в подобном варианте. Чем больше нагрузка на регистр на запись, тем логичнее разнести эту нагрузку на разные регистры. Задача легко распараллеливается. Для меня странно что всего 24 регистра.
Всегда так делаю |
|
|
3
toypaul
гуру
28.10.26
✎
11:12
|
Одно я не понял. Почему в СДЭК 1С сделали мастер системой для биллинга. Это какой-то кривой подход. Видимо там 1Сники в свое время захватили власть.
|
|
|
4
Lama12
28.10.26
✎
11:13
|
(3) Предполагаю что это после того, как их самаписку, несколько раз взломали.
|
|
|
5
shuhard
28.10.26
✎
11:21
|
(0) клоуны, поржал
о_О |
|
|
6
Garykom
гуру
28.10.26
✎
11:47
|
Приняли решение разработать новый модуль с нуля. Изначально были мысли построить его на Java. Но это дорого и долго. Помимо ресурсов разработки нужны ещё и методологи финансового учёта. Так сложилось, что концентрация компетенций была в департаменте разработки учётных систем, а в СДЭК — это 1С.
Тупо сэкономили.
На 1С оказалось дешевле и спецы есть...
|
|
|
7
Lama12
28.10.26
✎
11:48
|
(5) У них там компромисс между имеющимися ресурсами и корректным (с технической точки зрения) выбором инструментов для решения задачи. Как система, смотрится не так уж и плохо.
|
|
|
8
Krendel
28.10.26
✎
12:08
|
(0) а они восстановились после того как месяц восстанавливали инфраструктуру?
По реализации:
Биллинг складских операций-1 регистр, 1 заполнялка табличной части реализации
Биллинг инжинириговой компании по заготовке леса(прокладка дорог, заготовка леса, транспортировка до зоны приемки, включая сплотирование)
1 регистр, +генератор пбз, для себеса
Ап регистр накопления ессно
(5) поддержу
|
|
|
9
Garykom
гуру
28.10.26
✎
11:51
|
Для каждого месяца у нас есть отдельный регистр для финансовых событий и для расценок. Итого — 24 регистра на год.
Кривое архитектурное решение
Я бы сделал 366 * N регистров на каждый день в году и вид операции
Затем данные из этих регистров переносил в более полные сводные
|
|
|
10
Lama12
28.10.26
✎
11:55
|
(9) 👍 аналогично.
|
|
|
11
bolder
28.10.26
✎
12:01
|
(0) Много разумных решений.И самое главное,есть что посмотреть на гитхабе.А критикам и выложить нечего.
Другое |
|
|
12
aka MIK
28.10.26
✎
12:15
|
(3) потому что 1С отлично подходит роль мусорки. не под фронт же ее использовать в самом деле
|
|
|
13
bolder
28.10.26
✎
12:37
|
(12) Конечно,конечно.Java там не "шмогла" ибо нерусь, дорогая.
|
|
|
14
bolder
28.10.26
✎
12:44
|
(9) Я бы сделал 366 * N регистров на каждый день в году и вид операции
Еще более кривое решение.В СДЭК стояли на земле, и видели реальные объемы данных.Так что они пошли на компромисс между сложностью и скоростью.Вы же предлагаете систему космического масштаба...
|
|
|
15
Лодырь
28.10.26
✎
12:52
|
Не самая стандартная задача. Не самое тривиальное решение. Доклад слушал вживую, докладчик вполне компетентен в том что он делал и зачем. На вопросы отвечал, логику решений объяснял. Ну и самое главное - это все работает.
Другое |
|
|
16
H A D G E H O G s
28.10.26
✎
13:24
|
(0) Не вижу ничего криминального. Самолюбы, которые тащат всё во внешние базы - просто не умеют готовить РС.
p.s. Скорее всего, под СДЭК 1С запилило механизм расширенной модификации РС, а потом и РН до кучи. Плохо чтоли, хорошо!
|
|
|
17
H A D G E H O G s
28.10.26
✎
13:25
|
«Владислав был очень могущественным, он мог превратиться в любое животное. Вот только у него не всегда получались лица».
|
|
|
18
Garykom
гуру
28.10.26
✎
13:29
|
(16) 1С уже умеет программно в регзадании CREATE TABLE?
|
|
|
19
d4rkmesa
28.10.26
✎
13:42
|
Думаю, имеет право на жизнь. Но сложно получилось, по меркам 1С.
Другое |
|
|
20
d4rkmesa
28.10.26
✎
13:43
|
(18) Докладчик написал, что раз в год создают.
|
|
|
21
АНДР
28.10.26
✎
13:46
|
(18) С момента появления Внешних источников данных.
Или вопрос про создание регистра в метаданных конфигурации?
|
|
|
22
Garykom
гуру
28.10.26
✎
13:51
|
(21) Про создание новых регистров и прочих объектов метаданных в СУБД
При необходимости, хотя и редкой
|
|
|
23
Ботаник Гарден Меран
28.10.26
✎
14:28
|
Заходишь в типовой 1С УХ, смотришь на синтетический регистр показателей, затем на пронумерованные аналитические регистры показателей.
Консолидация, конечно, древний продукт уже, но в 90-х такие решения для dbf часто встречались.
P.S.
И да, я помню, как в Зик-1 итоги в справочник складывались.
|
|
|
24
АНДР
28.10.26
✎
14:04
|
(22) Если есть pipeline, то запихнуть новые "типовые" объекты метаданных в GIT не большая проблема
|
|
|
25
vis
28.10.26
✎
14:23
|
(14) Для программы какая разница 24 или 366 ?
|
|
|
26
Garykom
гуру
28.10.26
✎
15:59
|
(25) 366 даже удобней
По идее можно на каждый новый день новую табличку создавать
А затем удалять когда данные в архив переходят
|
|
|
27
Garykom
гуру
28.10.26
✎
16:01
|
Решение с 24 табличками (по 2 на каждый месяц) выглядит странным
Каждые новые текущие месяцы/кварталы будут явно самыми напряжными, больше всего движений/обращений
Затем постепенно все меньше движений, затем всплеск перед концом года
И когда год закрыт совсем нет почти
|
|