Alex XYZ

Все ключи уникальны между собой

Это лишнее уточнение, т.к. в object все ключи уникальны по определению. Одинаковых ключей не бывает в принципе.
Что касается простоты, то сам json является простым форматом, но не сценарии, в которых он может быть применён. То что вы написали не является стандартным способом работы с Json, который входит в набор его базовых функций - типа получить ключи или значение по ключу или длину массива элемента. Поэтому даже сценарий получения такого списка «ключ-значение», как у вас должен писаться. Увы.

Немного полистал инфу, там написано
1. "That ibdata1 isn't shrinking is a particularly ann..."
2. Движок InnoDB не поддерживает уменьшение размеров ...
3. Есть ещё бинарные логи (забиваются очень сильно), они чистятся командой "RESET MASTER" (только осторожно - они используются для репликации, если серверов несколько).

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

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

Можно, конечно, только тут есть одна проблема - проверка валидности данных перед записью в MySQL. Из коробки в MySQL нет встроенных средств проверки схемы. Я такую проверку писал на Java/JavaScript/Nashorn (чтобы одна и та же функция валидировала JSON на выходе со страницы и на входе в сервлет) перед сохранением.

Похоже, что вам просто нужна транзакция. В таком случае количество запросов по разным таблицам на вставку/обновление/удаление не имеет значения.

>> Реляционная база подходит или стоит посмотреть в сторону NoSQL?
Хранить первичные данные в реляционной базе правильно, а изменения, которые делают сотрудники (версионность) записывать в отдельную JSON-сущность и складывать в отдельную таблицу. Дело в том, что бизнеслогика может требовать возможности работы с транзакциями, а в NoSQL они поддерживаются только на уровне документа (ElasticSearch, Mongo). Если во время работы вам потребуется откатить изменения в нескольких сущностях, то NoSQL вам этого не обеспечат.
Есть вариант скрестить NoSQL и реляционные базы - использовать JSON в MySQL. Но тут будет другая проблема - проверка схемы записываемых данных. Нетривиальная задача для MySQL. В общем, NoSQL на сегодняшний день ещё сыроват и для применения в проектах над ним надо попотеть. В Mongo схема вроде как есть, в ElasticSearch вообще жесткач по схеме (раз вы задаёте вопрос, то точно с ним не сталкивались и уверяю, что на изучение схемы в Elastic вы потратите время не меньше, чем на сам проект)

Вчера как раз отвечал на похожий вопрос с версионностью в MySQL: Как сделать версионность как на вики?

Что касается версионности, то тут есть ещё один момент - как защитить сущности от перезаписи другим пользователем? Основываясь исключительно на своём субъективном мнении я делаю инкрементируемое поле (скажем, version) для каждой сущности (группе значений, которых я принимаю за сущность), значение которого я отдаю при select-е из базы. При сохранении сущности клиент обязан предоставить этот индекс. Если индекс не менялся, то запись разрешена. Как только происходит запись сущности, то я инкрементирую это поле и если другой человек тоже попытается перезаписать данные со старым значением поля version, то программа ему не позволит это сделать (это очень примитивный способ блокировки, очень отдаленно напоминающий git. Там используются хеши, ну а я все упростил до безобразия) Проверка значения поля version делается в триггере, он же и отменяет процесс записи, если версии не совпадают (чего как раз нельзя сделать в чистой NoSQL). Можно было бы сделать как в 1С блокировку чтения, но для программ не уровня 1с имеем кучу геморроя при реализации.

Что касается Excel и Word, то читайте описание формата OOXML и смотрите библиотеки по работе с офисными форматами. Для Node не знаю, но для Java и C# есть очень мощные, если не хотите разбираться с OOXML.

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

Судя по документации MySQL для вашего случая - никак:

dev.mysql.com/doc/refman/5.5/en/create-table.html

default value must be a constant

Было как-то дело, я работал с тестовым набором в миллионы строк на одной таблице. Попробовал ElasticSearch. По скорости работы агрегации примерно на уровне коммерческой версии MSSQL (не знал, что бесплатная версия и коммерческая MSSQL сильно отличаются по производительности, а ElasticSearch делал выборки не медленнее коммерческого MSSQL). Но в агрегацию ElasticSearch въехать не просто.

Это достаточно высокий и хороший уровень конфигурирования приложения. Из реальной жизни посмотрите на maven или grunt, у них то же самое. Особенно maven - максимум, что они можно выжать - более удобный способ отображения XML, например, в Eclipse или IDEA, чтобы было легче воспринимать структуру файла. К тому же само наличие файла конфигурации уже повышает уровень восприятия вашего приложения. Я бы не стал задумываться о "программировании" конфигурации и раскладывания его параметров по базе, т.к. такие суть именно в том, что такие конфиги и должны храниться в одном месте, а не раскидывать значения по таблицам, чтобы отдельным процессом собираться в этот файл да ещё и с ошибками, возможно.

Смотря что за редактор у новости. Я на CKEditor-е как-то сделал без предзагрузки изображения в базу. см. ckeditor.com/addon/image. Может удастся сделать нечто подобное?

У меня опыт хранимых процедур для MySQL не большой (в MSSQL побольше, но как пользователь серверов большой принципиальной разницы не вижу), поэтому просто хочу поделиться мыслями. Не важно на чём вы пишете процедуры — на C++, JavaScript или SQL, но если у вас несколько технологий в проекте, то:

1. Каждую процедуру нужно писать в своей технологии.
2. Максимально изолировать технологии друг от друга (в идеале только передача параметров и результатов), чтобы держать проектирование под контролем.
3. Искать методы численной оценки производительности различных этапов программирования. Это отдельная задача.

Может у вас всё нормально идёт, и вы просто боитесь, что что-то пойдёт не так?

Про rrdtools мне очень понравилось. Достаточно быстро нашёл ссылку: Использование rrdtool для мониторинга сети. Мега вещь!!! Не знал. Спасибо за наводку.

select * from tbl where id%10=0 and datetime>=addtime(now(), '-0:1:00');

Выбрать данные за последнюю минуту, в которых id кретен 10. За сутки что-то похожее будет.