Задача совершенно не понятна.
Любой класс можно сериализовать. Ну и я так понимаю, проблема то не с Queue, а с "буферизации бизнес сущностей"
т.е. нужно или нормальное хранилище (база данных?) или какая нибудь система кэша с возможностью non-heap и хренанения на диске


AFAIK
кроме размера, Amazon еще и за IOPS деньги хочет
т.ч. не факт, что Amazon SSD на 30 Гиг это будет ровно то, что Вы думаете )))
по стандартной опции, IOPS должно быть кот наплакал

ext4 не по размеру файла а по inodes.

AFAIK
кол-во inodes в момент форматирование задается
на Amazon'е плодил несколько миллионов файлов по 500-800 байт, все нормально работало

потом перешел на SQLLite
Не рассматривал базы данных т.к. это оверхед и сортировки по дате всегда тормознутые.

IMHO и зря
Что такое база данных? Это B-tree + максимум лог (redo log). Если целостность не нужна, отключите синхронизацию при записи, оверхеда вообще будет не видно.

Использовал SQLLite. Оверхид вообще не заметен.

Что такое "сортировки по дате всегда тормознутые" мне вообще не понятно. Постройте индекс, будут "мгновенные"

Использовал SQLLite для миллионов строк, все летало. С миллиардами не пробывал )))

Достоинство по сравнению с файловой системой, все же добавить файл в файловую системая значительно больший оверхид, чем строчку в таблицу.
И Амазон слишком дорого берет за поднятие базячных иснтасов а мне их надо будет поднять
для девов штук 4 и для нужд тестинга еще штук 16.

Зачем вообще базячные инстансы от Амазона? Только если своих рук нет, базу поставить. А в случае с SQLite и ставить ничего не нужно. JAR в проект воткнул и все.

С S3 работал только как пользователь, т.ч. не специалист

Все же S3 это не файловая система. Даже по логике, ожидать от нее быстрой работы я бы не стал. Да и доступ по сети (между нодами-машинками) вещь не быстрая. Плюс, подозреваю, если трафик пойдет между дата-центрами, то еще и на оплату трафика можно нарваться.

---

Не очень понятен требуемый функционал. Если бизнес-сущности поддерживают сериализацию. то написать свой Queue с буфферизацией - в общем-то несколько сотен строк кода.

Проблема производительности, как мне видится:

1) Скорость сериализации бизнес-сущности. Сам по себе стандартный механизм сериализации в Java тормозной до чертиков, как Java так умудряется, мне не понятно. Я переписывал на Externalizable.

2) Скорость сохранения на диске. Если бизнес-сущности можно сохранить в fixed size записи, то самое быстрое был бы просто Circle Ring Buffer на диске (сервер то выделеннй, сразу и нарезать буффер на все 30 Gb). Если нет (что скорее всего), то SQL Lite, что бы не изобретать буфферизацию записи/чтения на диск.

3) Входные объемы данных. Как я понимаю, если данные помещаются в ОП, то Вы можете работать в ОП (персистентность и защита от сбоев не требуется). Если не помещаются, то на диск. Но тут проблема, что тогда может быть сильный разнобой по скорости в зависимости от нагрузки, допустимо ли это или нужно всегда медленно, но зато стабильная скорость.

4) Требование от сбоев. Если требуется атомарность и гарантированное хранение информации, то быстрее IOPS'ов Amazon'а не прыгнуть. А их, насколько я помню, десятки, максимум сотни (или платите деньги). А 100-200 записей в секунду - как-то не много. Если при сбое все 30 Гб накрываются "медным тазом" и это нормально, то наверное на пару десятков мегабайт в секунду от локальных дисков расчитывать вполне можно.

Можно конечно в своем формате хранить или смотреть на какие нибудь продукты кэширования, но если что-то сложнее Circle Ring Buffer'а, то SQL Lite будет и проще и, скорее всего, быстрее.

p.s.
с точки зрения "велосипедостроения". Но без полноценной постановки, что же требуется, скорее всего разговариваем о разном.

По опыту, SQLite минимум на порядок ( 7-8 раз и больше ) быстрее postgresql на точечных select'ах / insert'ах. Как минимум, отстутвует проблема меж-процессорного взаимодействия (задержки на localhost + переключение потоков/процессов).

Для проектов, где не требуется полноценная, отдельно стоящая база, а бы первым делом сейчас смотрел на SQL Lite.

А с учетом родовой травмы PostgreSQL (vacuum), для задачь типа subj, на PostgreSQL смотрел бы вообще в последнию очередь. IMHO & AFAIK

Если "не рассматривал базы данных т.к. это оверхед" ориентируясь на PostgreSQL, я бы порекомендовал пересмотреть свое мнение и попытаться сделать тесты производительности, что нужно, что получилось/не получилось с SQL Lite. Какие характеристики не достигнуты.

IMHO & AFAIK

Она же вроде денег стоит?

The our open source license permits you to use Berkeley DB, Berkeley DB Java Edition or Berkeley DB XML at no charge under the condition that if you use the software in an application you redistribute, the complete source code for your application must be available and freely redistributable under reasonable conditions. If you do not want to release the source code for your application, you may purchase a license from Oracle.

BerkeleyDbSince the Queue access method always uses fixed-length records , the user must always set the record length prior to creating the database.

сущности могут быть мелкими.меньше от нескольких байт до 4К

не решается
но при форматировании диска можно задать любое кол-во inodes
AFAIK