Не совсем понятно почему выбран Hadoop.

По задаче получается что нужно персистентное хранилище выдерживающее массированный прием простых данных.

В мире джава это Apache Cassandra. Hadoop штука несколько не про то. Он нужен когда нам и обработку данных нужно масштабировать.

Но. Работа с COM из Java может принести немало головной боли. Более надежно, найти такую БД которая удовлетворяет предстоящим нагрузкам, но имеет универсальный протокол обмена с внешним миром, обычно нечто поверх http. Чтобы не думать, на чем она написана, хоть на Erlang,е

И. базы типа MariaDB(есть еще скоростные клоны MySQL) - хорошо тюнятся на запись. может, для вашей задачи не понадобится связываться с кластерными технологиями.

darlov, очень мало технических подробностей, чтобы что-то конкретное посоветовать

насчет медлительности - ... MyISAM ... Using multiple key caches was the good solution at that time and we could get over 200K of inserts/sec. High Rate insertion with MySQL and Innodb

darlov3 600 000 значений это же только за час накопится
эти цифра ни о чем не говорят. 3 600 000 значений размером во сколько байт? уже как-то понятней будет.

При "работе с датчиками" обычно не интересует эта цифра. а вот пиковое количество сохранений в секунду - да. которое можно обойти самим сборщиком, который формирует пакеты для bulk операций, а уж потом шлет. но - что в вашем случае лучше - неизвестно.

Про кластерные технологии упомянул, потому что если нет опыта работы с ними - запросто можно получить работу медленнее чем на обычном MySQL. В отличие от реляционных БД - там каждая настраивается по своему, имеет свои фичи и хитрости, и т.д. Если нет цели изучить для карьерного роста, а сугубо прагматичная - реализовать задачу с минимальными усилиями, то

1. Java вам не нужна. С# - сам напросился.
2. смотреть в сторону реляционных БД, методов их разгона и паттернов на массированную запись.

darlov, мир биллионговых систем годами как-то обходился без Hadoop'а.

4 байта это - не объем, при 1000 в сек.

darlovДля меня идеально конечно все хранить в реляционной
вот и попробуйте вначале хранить там :) см выше - поспрашивайте как оптимизируется запись в биллинге.

darlovно боюсь в будущем переписывать все под что то другое.
набросайте DAO слой, чтобы остальная часть и не знала где оно хранится

Задачи нужно решать по мере поступления, с небольшим заделом на будущее. Врядли в обозримом будущем вашей системе придется обрабатывать данных в 100 раз больше чем сейчас.

darlovв реляционной БД тяжело хранить такой объем
если не ошибся с арифметикой:
4000*60*60*24*365 / 1024 / 1024 / 1024 = 117 Гб в год чистых данных. это не объем для современных реляционных БД. Тем более то с этими данными работа будет осуществляться один раз - выбрать в агрегирующую систему. наверняка нужны будут идентификаторы датчиков. и очень может быть, что через месяцок разрешено будет удалять исходные данные, или "сворачивать".

На какой рост объема вы рассчитываете в будущем - в 10, 100, ..., 1 000 000 раз?

и не забывайте о важной вещи - класстерные БД тогда хороши, когда есть более 3ех физических нодов, с большим объемом ОЗУ на каждом.
Если железо слабое, то реляционные то оптимизированы на работу с размерами данных многократно превышающими размер ОЗУ на единичном ноде.
Я к тому, что злую штуку может сыграть и этот фактор, развернете вы Hadoop, а ему то развернуться и мощь показать не будет на чем.

Очень часто забывают учесть эти факторы
освоение любой технологии требует времени, а применение - изменения окружения: технического, а то и бизнесового.