Losted

Со стандартной сериализацией этого не избежать никак. Предлагаю использовать сторонние библиотеки:
- json формат - куча библиотек для работы с ним, например https://github.com/google/gson
- kryo - отличный и очень быстрый сериализатор (!) - https://github.com/EsotericSoftware/kryo
- protobuf - тоже очень неплох - https://developers.google.com/protocol-buffers/doc...
- xml формат - куча библиотек, даже встроенные в поставку JVM

Из этого всего разнообразия я бы остановился или на xml/json или на kryo. Но если нужна кроссплатформенность, то protobuf.

По стандарту delete-запросы не могут иметь тела - RFC 7231.

Изучайте Spring. Boot - это всего лишь один компонент, причём мелкий.

Простой ресурсов сам по себе - не проблема, а счастье. Проблемой является простой ресурсов при заметной деградации сервиса.

Но в тестовом режиме, загружая систему примерно на 100 000 запросов с 2000 потоков (через tomact: ab -n 1000000 -c 3000 ") проц всё ещё остаётся загружен всего на 36%.

Ответ приходит за какое время? Сколько времени выполняется 1 запрос при нулевой загрузке? При каком количестве запросов происходит деградация сервиса?
увеличить использование процессора и ускорить выполнение не обязательно ходят вместе. Процессор может простаивать по причине ожидания ввода-вывода, но так же и потому, что он легко справляется с текущей нагрузкой.
В любом случае, спрашивать надо не на тостере, а у профилировщика: куда уходит время цпу, в каких ситуациях появляется простой цпу, какое соотношение простоя к полезной работе. Если сервис долго ждет ввод-вывод - нужно ускорять именно ввод-вывод, а не стараться нагрузить процессор.

Настоящий программист создаёт всё сам с помощью библиотек.

Нет, не стоит.
Увеличение скорости работы будет, но довольно небольшим и на большинстве задач невооруженным глазом вы его не заметите.

вообщем ПК нагружается хорошо

Откройте монитор ресурсов, посмотрите загрузку процессора, памяти, очередь к диску и станет понятно чего надо добавить для улучшения быстродействия.

не стоит: значительного прироста не будет.
говорю как обладатель нескольких pci-ssd (и в страйпе, и без) на своей рабочей машинке.

такие диски - штука хорошая.
но профит дают только на определенных задачах и в обычной работе являются напрасной тратой денег.

1) только вот C/C++ софт придётся компилировать самому под все целевые платформы;
2) платформо-зависимые части кода в большинстве случаев уже собраны в библиотеки;
3) JavaFX или собственная реализация Swing UI. Даже голый Swing причесать так, чтобы он выглядел практически одинаково на всех платформах, особого труда не составит;
4) то же с .net (то, что Microsoft пихает его рантайм в Windows — не заслуга дотнета как такового. А заодно поинтересуйтесь, как у дотнета обстоят дела со стабильностью API);
5) с джарами и не бывает возни, достаточно установить JRE.

В общем, вы просто не умеете готовить кошек^W кофе o)

Неважно архитектор вы или нет, но если вы предлагаете техническое решение, то вопрос резонный со стороны тех кто будет открывать кошелек, сколько все это обойдется. В принципе-то хороший индикатор что вашим решением заинтересовались, если думают о деньгах. Значит оно решает насущные проблемы, а не пространные теории неизвестно о чем.
Отказаться предоставить приблизительную смету будет со стороны смотреться как будто вы этим вопросом никогда не интересовались а это в свою очередь значит что вы не учитываете интересы потенциальных заказчиков или фирмы. Ваша смета не должна быть особенно точной, людям нужно представление сколько нулей у итоговой суммы :) Укажите что цены на текущий момент. Если спросят а можно ли дешевле, то будете думать дальше а так среднего арифметического на салфетке вполне хватит.

Это аннотация пишется над методами, которые переопределяются из супер класса.

Это что-то вроде страховки, гарантирующая что 100% переопределен метод.

class A {
public void superMethod() {}
}

class B extends A {
@Override
public void superMethod() {}
}

Компилятор, когда встретит данную аннотацию, проверит, чтоб сигнатуры методов в супер классе и в под классе совпадали, т.е. вы переопределили метод, и в полиморфизме будит вызываться переопределенный метод.

Если вдруг вы ошиблись в сигнатуре метода (например пропустили букву в название), то компилятор выдаст ошибку

Redis, с включением Persistence redis.io/topics/persistence

В MongoDB вы можете использовать https://docs.mongodb.org/manual/reference/configur... для старого хранилища.
Для WiredTiger по умолчанию идет компрессор snappy. Но вы можете использовать zlib или bzip
source.wiredtiger.com/2.4.1/compression.html Правда нагрузка на CPU вырастет. Будьте осторожны.
Кроме этого я могу сказать, что у вас неправильный подход к бекапам для MongoDB. Использовать режим полного бекапа не очень удобно. Правильно использовать отложенную репликацию.
Могу сказать, что у меня текущая база содержит примерно 100 GB данных (на диске 253G, Mongo 2.6). Все отлично реплицируется (у меня replica set из 2х машин) и бэкапится (delayed). Это требует отдельный сервер, но он может быть не таким мощным как основной или иметь другой диск, например обычный HDD.
10 GB это очень маленький объем данных. Пересмотрите свою архитектуру.

Точность будет одинаковая, это зависит не от языка, а от типа данных

смотрите типы данных float и double

Да.
Они отдали ее в open-source.
Есть версия от Gluon
Не сказать что кардинально изменили, но кое-какие плюшки появились. Единственное, у меня на одной машине утечка памяти идет.

1 BlockingQueue музыкальный плеер, есть очередь откуда проигрываются треки, плеер снизу забирает трек, сверху пользователь накидывает в очередь новые треки. работа с очередью идет из разных потоков.
2 качалка файлов, очередь файлов для закачки, настройками могу регулировать кол-во одновременно качающих потоков
3 CountDownLatch отличный инструмент для отсчета оставшегося времени
4 CyclicBarrier чумовой механизм ожидания завершения работы нескольких потоков, парсинг сайта,
закачка файлов, обработка текстов, подсчет данных или игр
5 Executors и ExecutorService быстрая организация пула потоков использую для работы с sqlite,
а также ScheduledExecutorService для организации таймера для проверки изменения чего либо у пользователя на девайсе
6 полезная штука Exchanger, моментальная реализация задачи producer - consumer
7 ConcurrentHashMap вообще классика для организации хешей, это сейчас есть LRU, а раньше не было. А было WeakReference и эксперементы с очередями и хешами WeakHashMap
8 Atomic, легко позволяют создавать потоко-безопасные переменные, использовал AtomicBoolean, как межпотоковый стейт
Я знаю, что есть конторы, как крупные так и мелкие не используют Retrofitы robospicы DI фреймвори и так далее.
Учитывая проблемы с 65к dex, из-за тучи либ сторонних и особенно play services, собрать уже сложно.
И для мелкой задачи стоит ли с собой тащить либу, вопрос холиваный
И стоит знать java.util.concurrent потому что, это используется в либах. Тот же volley, там три чистых потока Thread для выполнения http, а в ui пробрасывается через хендлер и Executor