Ну, отсутствие дисциплины лечиться как раз на уровне коллектора. При том, что логстэш ну очень медленный, проще уж взять Filebit или тот же vector (который может быть и гибче) или еще кого
Вот звёздочка (*) в E*K - это и есть Filebit, и пр.
Вообще, пока в решении легко поддерживать E*K, то можно обойтись и просто .tag.gz файлами и zgrep/zless А когда данных много, то уже проще ставить что-то удобное )
Ну, года три назад если в проекте используется Mongo - то скорее всего там вообще нет архитектора и даже сеньор-дева. Сейчас уже она хотя бы не теряет данные, но мне сложно придумать схему, где ее использование хоть чем-то оправдано.
Ну, года три назад если в проекте используется Mongo - то скорее всего там вообще нет архитектора и даже сеньор-дева. Сейчас уже она хотя бы не теряет данные, но мне сложно придумать схему, где ее использование хоть чем-то оправдано.
Именно. Главный агрумент - Operations. Нужны веские причины, чтобы эксплуатировать "ещё одну" БД.
Ну, года три назад если в проекте используется Mongo - то скорее всего там вообще нет архитектора и даже сеньор-дева. Сейчас уже она хотя бы не теряет данные, но мне сложно придумать схему, где ее использование хоть чем-то оправдано.
Если что - Монга до 2.4 (или 2.6, не помню уже) теряет данные при почти любых настройках.
Нынче она 4.4.х и многое поменялось. очень многое. Она заняло свое место в архитектуре, но как любое решение - не является серебряной пулей.
Про что говорите Вы - это примеры про всякие ReST API за 10 минут как запрос насквозь той же структуры JSON положить в БД. Это очень простые example для определенных целей, например чтобы продемонстрировать deploy-инструмент, где приложение не имеет ценности. Или чтобы показать язык/framework, где код в этом примере тоже не имеет ценности. Но эти примеры научили людей не думать и пробрасывать структуру данных насквозь.
Но это не проблема монги, таких примеров миллион.
Можно прекрасно имея ORM для РСУБД не понимать как она работает и кормить ее напрямую JSON Payload из запроса.