Сабина wrote:Ацка, если поток данных такой большой и интенсивный что без сокетов не обойтись, то я правильно понимаю что хранить такое можно только или в HDFS или в scalable noSQL ?
конечно же неправильно
правильный ответ был самым первым, цитирую:
Как хочешь, так и хранишь, йопта
а если все-таки включить архитектора, то правильный ответ дал стенькин:
Невозможно ответить на незаданную задачу с незаданными параметрами и условиями
т.е. весь вопрос в том, как именно эти данные нужно анализировать; и _нужны_ли_ все данные для этого анализа или можно их налету существенно укомпактить. например, нам нужно знать для каждого автобуса данные по каждому дню: во сколько выехал, во сколько вернулся, сколько стоял на светофорах/пробках, средняя скорость движения, пройденное расстояние. тогда мы храним данные за последние сутки все, потом их спокойно в фоне обрабатываем (ночью, например) и из груды барахла сохраняем совсем немного жемчуга. это один вариант и достаточно тривиальный. но может ведь захотеться и гораздо более сложной аналитики - например, как изменить маршруты автобусов, чтобы минимизировать расход топлива, стояние в пробках и _время_потраченное_средним_пассажиром_ - тут уже жбан нужно чесать не по-детски. т.е. структура хранения данных может диктоваться потребностями анализа, и тут может вполне потребоваться какое-нибудь noSQL решение просто потому что для него есть подходящий проект, который всякими богопротивными мап-редюсами анализирует примерно так, как нам надо. в то же время данные очень хорошо подходят под парадигму RDBMS, поэтому банальный mySQL может оказаться более правильным выбором, а если потом понадобится - в чем проблема, переложим в noSQL
Мораль: архитектить можно зная все детали и цель. просто так можно нафантазировать что угодно
