C, Go, Angular, MySql, MongoDb, PostgreSql, RabbitMQ, Redis, возникает 1 закономерный вопрос - почему вам не хватило одной реляционной базы?
Сюда же примеры с Kafka + RabbitMQ + NATS или Redis + Memcached. Широкий техстек это чаще минус авторам проекта, и в большинстве случаев вы и так не встретите проблемы, требующие несколько баз сразу (you're not Google at mini scale так сказать).
Признаюсь, у нас у самих было 2 БД одновременно, но все было во время миграции, хотя в итоге остались на старой БД, просто было нерационально переписывать одно и то же. Но вот не все мигрируют, там более годами)
(пока в коменты не набежали с аргументами "да мы монолит 5 лет распиливаем, с пхп+монго на го+пг" скажу сразу, в начале поста упоминается _новый_ проект, сделанный с нуля, и объяснить зачем так, человек не смог)
Почему-то тут же вспомнился 1 СТО, который делал 1 инстанс БД пер сервис. Что конечно делало компоненты независимыми, но так же (имхо) раздувало поддержку этого чуда. И не чуть-чуть счёт.
Под каждую задачу более подходящий инструмент вс унификация стэка?
а потом целый штат опсов чтобы поддерживать всю инфраструктуру ага
это про внедрение куба в организацию?)
или половина штата разработчиков пытается сделать чтобы мускуль не тормозил с сотней миллинов записей в табличке аудит логов
а че с кубом то?
В каком-то 2015ом году действительно могло не хватить, но теперь реляционки умеют в NoSQL.
в 2015 уже был эластик для этих целей
Эластик умеет и в реляционку и nosql одновременно?
тогда "для таких целей" не подходит) Речь же была "почему не юзать одну СУБД"))
ну в целом кейсов когда не подходит реляционка и нужна документ дб очень мало и в любом случае нельзя запихнуть рандом структуру с вложенностью и чтоб магией работали запросы по ним. тебе придется делать точечную индексацию по полю, а это ничем не отличается от того что у тебя будет колонка в реляционке, а поля по которым не нужно искать - json пусть даже обычным text
Согласен. Максимум что мне кажется хоть сколько-то важным уточнеем — key-value в реляционке как будто overengineering — получается множество неиспользуемого + в целом помедленнее. Но вполне юзали, да (не я).
key-value может быть чисто движком. тот же LevelDB в Марье
Хм, действительно. Не подумал
Обсуждают сегодня