Миллиард транзакций в сутки

1. Babys (babys) 21.04.17 13:07 Сейчас в теме
Всем привет.
Вот тут вырисовывается Заказчик, но уж очень специфичный.
С бизнес логикой вроде всё в порядке, а вот технические спецификации даёт "звезда в шоке". Но основное требование не меньше 100000000 (СТО МИЛЛИОНОВ) транзакций в сутки с 5 источников и их обработка. Нечто вроде опердня в банке.
По железу пока нет интереса, а вот как программно реализовать?!?!?!?!?!
Пока видится 1 база на консолидацию потоков и очистку данных. На входе 5 справочников без ЛЮБЫХ индексов, с разделением по областям данных.
2 база получает данные порциями из 1 базы и производит связывание данных.
3 база получает данные из 2 базы и уже формирует набор учетных данных.
На что обратить внимание, какие подводные камни ждать?

ЗЫ: Источники oraclе-вые базы, входящий формат один. Равномерность входных потоков пока неизвестна, но судя по логике есть более "жирные" потоки, и да во времени они не должны быть равномерны.
Ответы
2. Алекс Кон (alex-l19041) 9 21.04.17 13:19 Сейчас в теме
(1)
очистку данных
- можно подробнее ?
3. Алекс Кон (alex-l19041) 9 21.04.17 13:21 Сейчас в теме
(1)
транзакций в сутки
- уточните что в данном случае считать за одну транзакцию?
4. Сан Саныч (herfis) 129 21.04.17 13:21 Сейчас в теме
Говоришь, будет очень много неизвестно каких данных, которые надо неизвестно как обрабатывать?
Понимаю твою озабоченность.
5. Babys Babys (babys) 82 21.04.17 19:58 Сейчас в теме
(2) Предварительная очистка данных, когда картридж данных входящей транзакции не соответствует заданным правилам. Всего 5 потоков, 5 картриджей, пока озвучены правила для 1 потока.
В принципе содержимое картриджей похоже для всех входящих потоков, т.к. идет стандартизация на уровне шины обмена. Возможность попадания данных из других источников существенно больше 0.

(3) Транзакция это пакет данных состоящий из 1 или более картриджа, Заказчик уверяет что больше 4 картриджей не будет. По сути можно попробовать упереться и уломать Заказчика на создание отдельной интерфейсной шины oracle - 1C, но это писец как сложно. Но тогда картриджи будут разными, и будут как раз равны одной транзакции.

(4) Какие данные известно, и как их обрабатывать известно. Неизвестно как входной поток сохранить без потери данных. И возможно я не разглашу секретов, т.к. контракт еще не подписан, это данных с автоматических датчиков и исполнительных механизмов. Да есть SCAD, но Заказчику виднее, возможно в существующем решении нет необходимой функциональности.

Да для более полного понимания, Заказчик пока не требует обработки "на лету", т.е. его вполне устраивает отставание отчётности на сутки.
6. Михаил Максимов (МихаилМ) 21.04.17 20:38 Сейчас в теме
для аналитической базы соотношение индексов к данным может достигать 20 к 1.

так что в "чистом виде" 1с8 не подходит. я так понял начальству скд-овые отчеты любы.

заведите olap базу в субд а клиента на 1с напишите.
ipoloskov; +1 Ответить
7. Валерий М (VmvLer) 21.04.17 20:44 Сейчас в теме
да, скорее это задача для платформы 1С: 12.3

два-три года подождать
8. Михаил Максимов (МихаилМ) 21.04.17 20:52 Сейчас в теме
видимо картриджи это кортэжи
9. Babys Babys (babys) 82 21.04.17 23:43 Сейчас в теме
(8) Ну не мной придумано, а учить Заказчика ....
10. Сан Саныч (herfis) 129 24.04.17 11:49 Сейчас в теме
Если первоначально данные с датчиков падают в оракловую базу, то какой смысл тянуть их в 1С один к одному? Моя не понимать. Потоковой обработкой оракл уже занимается. 1С нужна для сводных аналитических отчетов, как я понял.
Достаточно грузить задним числом готовые агрегации для базовой аналитики, а при необходимости "провалиться" до первичных данных - показывать детализацию из оракла.
корум; +1 Ответить 1
11. Babys Babys (babys) 82 24.04.17 15:35 Сейчас в теме
(10) "Моя не понимать." Моя тоже, тем более там есть trace, который может и самое главное делает всё это.
Самое прикольное в этой ситуации что на входе данные не из scada, а прямые данные из входящих буферов. И когда предложили брать данные из scada Заказчик отказался. Мы даже предлагали с trace перейти на другую, ответ отрицательный. Для конторы 1С побочный бизнес.
12. Александр alex_2h2008 (alex_sh2008) 5 24.04.17 15:42 Сейчас в теме
(1)Зачем хранить 100млн транзакций в базе, если можно на лету загружать в базу готовый результат
13. Сан Саныч (herfis) 129 24.04.17 18:01 Сейчас в теме
(11) Я не знаю, что такое "прямые данные из входящих буферов", но если подразумевается он-лайн чреватый потерей данных или отказом оборудования в результате дауна 1С, то они ССЗБ. Денег с таких взять можно, но юристы нужны хорошие :)
14. Babys Babys (babys) 82 24.04.17 19:51 Сейчас в теме
(12) Я выразился на совещании так: "Нах.я козе баян".

(13) Я так что ниже уровня получения данных в 1С не было, а то бы заставили и драйвера для всех датчиков переписывать.

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

Всем спасибо.
Оставьте свое сообщение