У нас биллинг реализован на связке TMeter + ASA, где TMeter фигачит в себе логи на винт и параллейным потоком грузит их в ASA. Если даже сервак остановить или он просядет, то как только он появится, поток продолжит работу и данные все равно в СУБД окажутся. Кажется мне как раз Вам так сделать и нужно, как у TMeter реализовано - в секунду конечно у нас тысячи пакетов не набираются (в день где то по 60-100 тысяч записей по всем таблицам TMeter), но принцип такой же - нереально это дело напрямую спустить к любой РСУБД.

авторесли еще и аналитику по базе в пару сотен М записей пускать, то тогда да, сурово.
Вот и я про тоже говорю. Плюс еще мало ли что с сервером может случиться, по любому придется механизм отложенной записи в СУБД делать.

авторвместо фала более правильно будет сервис очередей использовать.
Так как тогда связку "взять данные -> вставить в базу" можно будет в рамках транзакции делать - гарантировано
А файловые операции по XA протоколу в транзакцию не включишь.
То есть распредененные системы лучше строить на асинхронном обмене сообщениями, используя сервис очередей и XA транзакции для заливки в базу. Многопоточным приложением, которое будет брать из очередей и заливать в базу, можно окучить офигительный трафик.
Ну остальное уже детали реализации.
Плюс асинхронность на распределенных системах - самый идеологически правильный вид работы, где синхронность всего лишь частный случай асинхронности.
TMeter так и работает - асинхронно, очередями пуляя в БД данные. Однако при протоколировании данных с датчиков особо транзакционность не нужна - датчик дал показания, программа записала показания, откатит то датчик все равно возможности нет. А вот сохранять куда то очереди на диск нужно - в текстовые файлы или другим форматом без разницы. Иначе вполне возможно потерять часть данных, когда СУБД не успела вставить, а программа приема показаний датчиков взяла, да навернулась. Кстати вполне возможно использовать связку MySQL 4 -> Мощная РСУБД, где в MySQL все шустро пишется по таблицам, а потом асинхронный поток все это переносит уже в мощную РСУБД для аналитики.

Я же обьяснил - в логи он свои на винт пишет, а уж по ним параллейный процесс все это переносит в СУБД. Даже если СУБД отвалится или еще чего случится, не страшно - как коннект поток сможет восстановить, он дальше продолжить писать с того места, где остановился на момент потери коннекта с СУБД.

ggvASCRUS - так вот вот это "в логи он свои на вин пишет" и не внушает оптимизма.
Ну и способ работы с фацлом, и заливка потом в базу онлайново из файла...
Не весело как-то в плане надежности.
Тогда я не понимаю - что - веселее в память что ли писать или сразу пакеты по сети пускать до СУБД ?