Здравствуйте, мыщъх, Вы писали:

М>с телеметрического оборудования идут данные. есть предельное время, отпущенное на их обработку. как их обрабатывать в кэше? даже на примере того же поиска значений от M до K?

Это не что-то наподобие вот этого:
http://www.microsoft.com/sqlserver/en/us/solutions-technologies/business-intelligence/streaming-data.aspx
?

Здравствуйте, 3dbiz, Вы писали:

3>вывод:
3>треп во всяких статьях о стартапах о том, что идеи и бизнес-план ничего не стоят — это чушь собачья
3>они стоят именно ту сумму, которую я указал выше
Люблю такие темы. Идеи эт конечно хорошо. Скажи, сколько твоих идей дощли до продакшена и дали прибыль? В какой срок? Сколько денег затрачено было от момента составления бизнес плана до получения стабильной прибыли? Надеюсь твои "идеи" это не очередной сервис на похапе?

Здравствуйте, 3dbiz, Вы писали:

3>стоимость генерации бизнес-идей и бизнес-планов

3>вывод:
3>треп во всяких статьях о стартапах о том, что идеи и бизнес-план ничего не стоят — это чушь собачья
3>они стоят именно ту сумму, которую я указал выше

У меня идея ещё проще — поступи в Гарвард или в Колумбийский университет и идей будет сколько хочешь.

Здравствуйте, мыщъх, Вы писали:


>>> она идеально подходит для задач типа логгирования телеметрии
Q>>так никто в здравом уме данные телеметрии не пишет в базу напрямую.
Q>>Нужно кэширование.
Q>>не приемник — база
Q>>а приемник — кэширование — база
М>у вас есть 100500 сенсоров и over 9000 метрик. куда их кэшировать? какую структуру данных использовать? ну не массив же, верно. найдите мне в массиве все значения от M до K. долго же вы их искать будете. а все, что сложнее массива уже в каком-то смысле база данных.

Я не qwertyop, но попытаюсь ответить.
Сейчас вся телеметрия приходит на контроллеры, которые эти данные обрабатывают и реагирую.
На выходе я не встречал данных быстрее 100MS для SCADA или логирования. 90% что я встечал 1000MS на передачу данных.
Все эти 100500 сенсоров находятся не на одном контроллере, но если на одном, то отправляются данные одним пакетом, именно массивом (можно и самому их читать). Каждой метрике соответствует какая то область определенного размера и вот тут qwertyop абсолютно прав, если для SCADA системы нужно сразу отражать изменения сигналов (их довольно мало), то для логов время не критично, и гораздо разумнее их потихоньку разбирать, не нагружая ни сеть, ни комп, беря только разницу, или только измененные значения. А писать сразу в БД, без предварительной обработки, это имхо изврат и то, только на малом количестве сигналов и на отдельно стоящей железяке. И для очень больших данных подходит обыкновенный типиризированный файл, который скачивается на сервак и там парсится.
И даже для 100500 сенсоров не все так сложно. 80% параметров нафиг никому не нужны, берут данные влияющие или на работу оборудования или на технологический процесс и их очень мало, из нескольких сотен метрик, хорошо если десяток наберется тех которые нужны.
Полный анализ (и то не тысячи, а десятки метрик) включается только на проблемные узлы, но никак не на все.
Данные же специалисты должны анализировать, а они не вечны и в сутках у них не 1000 часов.

Здравствуйте, AWSVladimir, Вы писали:

AWS>Здравствуйте, мыщъх, Вы писали:


AWS> Я не qwertyop, но попытаюсь ответить.
...
AWS> А писать сразу в БД, без предварительной обработки, это имхо изврат

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

"писать сразу в БД без предварительной обработки..." -- в данном случае БД и является частью процесса обработки данных.

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