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

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

ЗЫ: Источники oraclе-вые базы, входящий формат один. Равномерность входных потоков пока неизвестна, но судя по логике есть более "жирные" потоки, и да во времени они не должны быть равномерны.
По теме из базы знаний
Ответы
Подписаться на ответы Сортировка: Древо развёрнутое
Свернуть все
2. alex-l19041 8 21.04.17 13:19 Сейчас в теме
(1)
очистку данных
- можно подробнее ?
5. babys 90 21.04.17 19:58 Сейчас в теме
(2) Предварительная очистка данных, когда картридж данных входящей транзакции не соответствует заданным правилам. Всего 5 потоков, 5 картриджей, пока озвучены правила для 1 потока.
В принципе содержимое картриджей похоже для всех входящих потоков, т.к. идет стандартизация на уровне шины обмена. Возможность попадания данных из других источников существенно больше 0.

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

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

Да для более полного понимания, Заказчик пока не требует обработки "на лету", т.е. его вполне устраивает отставание отчётности на сутки.
3. alex-l19041 8 21.04.17 13:21 Сейчас в теме
(1)
транзакций в сутки
- уточните что в данном случае считать за одну транзакцию?
12. alex_sh2008 4 24.04.17 15:42 Сейчас в теме
(1)Зачем хранить 100млн транзакций в базе, если можно на лету загружать в базу готовый результат
14. babys 90 24.04.17 19:51 Сейчас в теме
(12) Я выразился на совещании так: "Нах.я козе баян".

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

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

Всем спасибо.
4. herfis 498 21.04.17 13:21 Сейчас в теме
Говоришь, будет очень много неизвестно каких данных, которые надо неизвестно как обрабатывать?
Понимаю твою озабоченность.
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 90 21.04.17 23:43 Сейчас в теме
(8) Ну не мной придумано, а учить Заказчика ....
10. herfis 498 24.04.17 11:49 Сейчас в теме
Если первоначально данные с датчиков падают в оракловую базу, то какой смысл тянуть их в 1С один к одному? Моя не понимать. Потоковой обработкой оракл уже занимается. 1С нужна для сводных аналитических отчетов, как я понял.
Достаточно грузить задним числом готовые агрегации для базовой аналитики, а при необходимости "провалиться" до первичных данных - показывать детализацию из оракла.
корум; +1 Ответить
11. babys 90 24.04.17 15:35 Сейчас в теме
(10) "Моя не понимать." Моя тоже, тем более там есть trace, который может и самое главное делает всё это.
Самое прикольное в этой ситуации что на входе данные не из scada, а прямые данные из входящих буферов. И когда предложили брать данные из scada Заказчик отказался. Мы даже предлагали с trace перейти на другую, ответ отрицательный. Для конторы 1С побочный бизнес.
13. herfis 498 24.04.17 18:01 Сейчас в теме
(11) Я не знаю, что такое "прямые данные из входящих буферов", но если подразумевается он-лайн чреватый потерей данных или отказом оборудования в результате дауна 1С, то они ССЗБ. Денег с таких взять можно, но юристы нужны хорошие :)
Оставьте свое сообщение

Для получения уведомлений об ответах подключите телеграм бот:
Инфостарт бот