Ромзес Панагиотис

На всякий случай, если кому-то интересно, отмечу, что пока удовлетворился решением с заменой на контейнер debian:stable-slim - за неимением времени в расследовании причин.

По сути, выход равен входу. За исключением того, что на входе
массив объектов {id:, userId:, title: body:}
а на выходе:
массив объектов {ID:, userId:, title: body:}
То есть id -> ID. Ну так из одной структуры скопировать значения в другую структуру с другими полями. При json.Marshal получится новый массив.

как сделать вывод таким же красивым как и то что изначально?

Это излишне: для компьютера это приводит лишь к дополнительным накладным расходам.
Если "красоту" человек не будет смотреть где-то, то нет никакого смысла. Кроме того, в браузере в DevTools обычно встроено автоматическое выравнивание отступов, так что это не должно являться проблемой.

Итого, текущая постановка задачи звучит как переливание из пустого в порожнее.

На этот момент пока есть мысль выполнить разовую миграцию в одну целую таблицу при помощи хранимой процедуры, где будет алгоритм с 2-мя циклами (годам и месяцам), выполняющий INSERT INTO SELECT в новую таблицу.
Причем, новая таблица должна быть построена с партициями по годам и месяцам, чтобы решить предполагаемую проблему с количеством данных, из-за чего и возникла идея разбить на множество таблиц.
Альтернативно, можно выполнить дамп всех таблиц и "склеить" их при импорте.

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

А, вообще, если у вас в логах хранятся метрики (история цифр), то подумайте о переходе на другие СУБД (аналитические, временных серий и пр.).

Зачем плодить доморощенные форматы данных, когда есть SQLite?
И в коде сразу будет понятно что происходит, достаточно будет посмотреть на SQL запрос.

Добавлено
А если MySQL уже подключена, то вопрос вообще теряет смысл. Нужно просто использовать SQL где можно.

Кроме того, что у вас за проблема с запросом на MySQL, что вы решились на сравнение?

В форме нужно указать multipart/form-data

Можно ли любое GUI положение сперва реализовать в консольном варианте, а потом уже привязывать к нему GUI?

Едва ли. Для простых еще можно, а для сложных, как Excel?
Начинать нужно с проектирования:
- расписать какие есть сценарии работы
- начать собирать макеты интерфейса
- определить что требуется на входе и на выходе каждого действия
- декомпозировать на мелкие задачи
- спроектировать интерфейсы вызовов API
- разделить их на логические модули - DLL и их аналоги
- написать заглушку для каждого вызова
- написать некоторые тесты
- реализовать интерфейсы поэтапно
- пробовать на тестовом стенде: можно консольное, а можно и графическое приложение.
- и из кубиков собирать приложение.
Ну как-то так.

Прямо таки, узкое место именно в Memcached? У вас точно не из-за блокировок в коде задержка?
Сколько процессов или потоков может обновить значение счетчика?

Вообще, для увеличения счетчика используют incr.

Добавлено
Так вы используете еще и MySQL (только прочел в тегах). Ну да, можно использовать Memcached как счетчик. Но минус в том, что при рестарте данные пропадут. Так что можете взять Redis и делать то же самое.

Добавлено
Если вас интересует техника сохранения данных в Redis с минимизацией потерь, то есть статья
https://softwareengineering.stackexchange.com/ques...
Если же есть больше предпочтение работы с MySQL, то можно настроить репликацию так, что для записи счетчиков будет использоваться записью в мастер, а чтение счетчиков с реплики.
Плюс еще статья https://www.percona.com/blog/2007/07/01/implementi...