Как сегодня хранят POJO в NoSQL?

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

Добавлю к словам предыдущего комментатора, что в кассандре есть коллекции, и что-то можно хранить прямо в таких коллекциях, хотя у них есть свои ограничения

А разбирать объекты и выносить коллекции в отдельное место? В этом случае выборки не станут сильно уж медленнее, Article найденная по индексу не потребует нового поиска, т.к. ссылку на коллекцию тегов хранит внутри себя. А сама коллекция хранит прямые ссылки на теги.

Это и места будет меньше занимать... Чем делать +100500 дублирований одних и тех же данных на каждый новый вид выборки. Например, вывести все статьи по определенному тегу.

Разве нет таких решений? Какой у них минус?

PostgreSQL? я серьезно. man jsonb

я серьезно. man jsonb

объекты в NoSQL, но не тупо в виде графа документа, а с какой-то нормализацией что-то похожее на 3нф в реляционках

Самое близкое, что удалось найти http://orientdb.com/docs/last/index.html Но там так же всё через задницу не для людей. Так что оставил в TODO на будущее запилить свою БД на джаве для хранения и выборки POJO без всяких ORM и прочих костылей...

а с какой-то нормализацией

jsonb умеет в constraints