Немного посмотрел сие чудо. В облаке можно даже не за дорого сие поднять.
Но не ясен ключевой вопрос — как быть с базой данных? Тут ребята описали свой опыт https://habr.com/company/eastbanctech/blog/420665/ , но у них база данных была классическая, т.е. никакой распределенности не было.
Как вообще принято решать этот вопрос? Есть ли готовые решения?
Здравствуйте, Shmj, Вы писали:
S>Немного посмотрел сие чудо. В облаке можно даже не за дорого сие поднять.
S>Но не ясен ключевой вопрос — как быть с базой данных?
А как связан сабж и БД? Ну хочешь свою в k8s подними хочешь другую используй.
Здравствуйте, GarryIV, Вы писали:
GIV>А как связан сабж и БД? Ну хочешь свою в k8s подними хочешь другую используй.
Дык... Поднять то много инстансов и добавить типа лоадбалансер — нет проблем. Проблема начинается когда хочешь чтобы везде данные были одинаковые. А это значит нужна единая согласованния база, что не очень то совмещается с распределенностью. Вот и спрашиваю — какие есть стандарные решения этой проблемы?
Здравствуйте, Shmj, Вы писали:
GIV>>А как связан сабж и БД? Ну хочешь свою в k8s подними хочешь другую используй.
S>Дык... Поднять то много инстансов и добавить типа лоадбалансер — нет проблем. Проблема начинается когда хочешь чтобы везде данные были одинаковые. А это значит нужна единая согласованния база, что не очень то совмещается с распределенностью. Вот и спрашиваю — какие есть стандарные решения этой проблемы?
Ты чего балансировать собрался? Какое у тебя узкое место? Вообще кубернейтис не заставляет ничего распределять. Хочешь поднять скажем PostreSQL сделай один под для него и пусть себе крутиться. Хочешь распределенную БД — ставь такую чтоб умела распределенность, подними подов сколько надо.
Здравствуйте, Shmj, Вы писали:
S>Дык... Поднять то много инстансов и добавить типа лоадбалансер — нет проблем. Проблема начинается когда хочешь чтобы везде данные были одинаковые. А это значит нужна единая согласованния база, что не очень то совмещается с распределенностью. Вот и спрашиваю — какие есть стандарные решения этой проблемы?
У каждого миркросервиса должна быть своя бд, соотв. единой согласованной бд быть не должно.
S>Дык... Поднять то много инстансов и добавить типа лоадбалансер — нет проблем. Проблема начинается когда хочешь чтобы везде данные были одинаковые. А это значит нужна единая согласованния база, что не очень то совмещается с распределенностью. Вот и спрашиваю — какие есть стандарные решения этой проблемы?
Мои 5 копеек.
Здесь нужно рассуждать с точки зрения нагрузки и объемов данных.
Задаем вопросы типа:
Сколько запросов в секунду прилетает на наш сервис (по чтению, по записи)?
Сколько запросов в БД делается на один запрос к сервису (по чтению, по записи)?
Какой объем данных пишется (читается) на один запрос? Как быстро будет расти БД с учетом вышесказанного?
Есть ли ограничения по данным (длительность хранения, например), способу доступа (скажем, большинство запросов только к 5% самых актуальных данных) и т.п.
Получив какие-то цифры уже можно прикидывать, вытянем ли мы ожидаемую нагрузку и объемы силами одной БД.
Если да — то проблемы нет, ставим БД на отдельную машину, все сервисы ходят в нее.
Т.е. когда говорят, что у каждого микросервиса должна быть своя БД, это не обязательно означает, что она должна быть у каждого инстанса сервиса. Вполне может хватить одной на всех.
Если нет — данные нужно распределить между несколькими физическими машинами (т.е. размазать по кластеру).
Самый простой путь — отдать это на откуп самой БД. Скажем, MongoDB, Cassandra умеют кластеризоваться из коробки.
Некоторые SQL-базы, насколько я знаю, тоже умеют работать в кластере, но у них это хуже получается (что немудрено, ибо вытянуть полноценный ACID против CAP-та еще задачка)
Более сложный (но и более гибкий) путь — распределять данные руками. Это называется шардирование. (гуглить шардирование, виртуальные шарды, шард-диспетчер, консистентное хэширование).
Здравствуйте, Sharov, Вы писали:
S>>Дык... Поднять то много инстансов и добавить типа лоадбалансер — нет проблем. Проблема начинается когда хочешь чтобы везде данные были одинаковые. А это значит нужна единая согласованния база, что не очень то совмещается с распределенностью. Вот и спрашиваю — какие есть стандарные решения этой проблемы?
S>У каждого миркросервиса должна быть своя бд, соотв. единой согласованной бд быть не должно.
Ты точно понял смысл этой фразы? Карго культ какой-то.
Здравствуйте, RushDevion, Вы писали:
RD>Т.е. когда говорят, что у каждого микросервиса должна быть своя БД, это не обязательно означает, что она должна быть у каждого инстанса сервиса. Вполне может хватить одной на всех.
Если я не ошибась, то микросервисы же "типизированы" по типу выполняемой задачи, т.е. у нас может быть n микросервисов типа А, m типа B. Все мс типа А имеют одну свою базу, типа B одну свою.
Ну это как я себе представляю, имея только незначительные теор. познания.
Здравствуйте, Sharov, Вы писали:
RD>>Т.е. когда говорят, что у каждого микросервиса должна быть своя БД, это не обязательно означает, что она должна быть у каждого инстанса сервиса. Вполне может хватить одной на всех.
S>Если я не ошибась, то микросервисы же "типизированы" по типу выполняемой задачи, т.е. у нас может быть n микросервисов типа А, m типа B. Все мс типа А имеют одну свою базу, типа B одну свою.
Микросервисы A и B должны быть логически независимы и в этом смысле да у каждого сервиса своя БД. Нет ничего такого если эти логические БД тупо схемы (да хотя бы и таблицы) в одном физическом инстансе БД. Понадобиться можно будет и разделить.
Но тут речь о другом, тут скорее только сервис А и автор думает как ему БД деплоить. Сдается он хочет в одном поде и сервис и БД деплоить вот у него и распределенность получается непонятная.
Здравствуйте, Sharov, Вы писали:
S>Если я не ошибась, то микросервисы же "типизированы" по типу выполняемой задачи, т.е. у нас может быть n микросервисов типа А, m типа B. Все мс типа А имеют одну свою базу, типа B одну свою.
Так и есть. Только, правильнее,пожалуй, сказать "одну схему базы". Потому что самих физических баз может быть больше одной даже в рамках одного микросервиса.
Простой пример. Допустим, мы проектируем сервис хранения изображений.
Прикинули нагрузку.
Скажем, 1000 загрузок в день, средний файл 1мб, 500rps на чтение в пике.
Понимаем, что нагрузка небольшая. Ее можно держать вообще одним инстансом сервиса. ОК. Ставим 2 для надёжности.
Теперь БД. Ежедневный прирост нашей базы — 1гб, ~30гб/месяц, 360гб/год, 3.6тб за 10лет. В принципе, 360гб влезут на одну машину. Значит 10 инстансов БД нам в обозримом будущем хватит.Теперь как разложить между ними данные? Ну например так: shard_id = md5(file_name) % 10. Зная shard_id идём к нужному инстансу БД.
Здравствуйте, Shmj, Вы писали:
S>Немного посмотрел сие чудо. В облаке можно даже не за дорого сие поднять.
S>Но не ясен ключевой вопрос — как быть с базой данных? Тут ребята описали свой опыт https://habr.com/company/eastbanctech/blog/420665/ , но у них база данных была классическая, т.е. никакой распределенности не было.
S>Как вообще принято решать этот вопрос? Есть ли готовые решения?
Перевожу вопрос
Базу принято держать на raid из быстрых hdd
некоторые таблицы и индексы дожны быть на raid из быстрых ssd
в к8с как с этим?
для простоты рассмотрим 2 случая
1. бд это mssql server
2. бд это nosql кластер типа монго
update
а пикантность интриги ещё ив том что девелоперы нихрена не знают про к8с. у них и на билд сервере docker-compose с эфемерными дисками и им плевать на ваши райды
