NS
да тут придеться найти какойто компромис между latency внутри сервисов и с latency для конечных юзеров и пока не понятно на что в этом опираться
Size: a a a
2020 May 06
MZ
я бы сам потратил пару недель и перевел сразу все в кубик или композ, но можно это делать только по частям и пока нет понимания как перетащить туда 100гб mysql, который должен иметь мастер-мастер репликацию в ДЦ на разных континентах и возможно сменить её на что то другое по пути
Сменить mysql по пути - наводит на мысли переписывания приложения на другую БД. Или речь о сменить mysql на mariadb или облачный mysql? Так это не не сменить, это просто мигрировать.
NS
именно сменить бд
VP
всем привет
использую S3 с aws-sdk и мне прилетает ошибка.
при том что мой конфиг
и переменные корректно заполнены
использую S3 с aws-sdk и мне прилетает ошибка.
EC2 Metadata roleName request returned errorпри том что мой конфиг
AWS.config.update({
accessKeyId: process.env.AWS_ACCESS_KEY_ID,
secretAccessKey: process.env.AWS_SECRET_ACCESS_KEY,
region: process.env.AWS_REGION,
});и переменные корректно заполнены
ЕА
если есть какие-то проблемы с mysql на 100гб данных, то проблемы вероятно будут и с любой другой бд
NS
разные базы - разные плюсы и минусы, и надо подобрать под будущиею нагрузку то что лучше подходит а пока есть только предположения, в моей случаи сменить бд относительно легко
NS
основная проблема с базой что увеличить её объем легко и даже нужно, сейчас мы удалем старые записи, но они нам нужны на самом деле, и основной объем данных в одной табличке
MZ
разные базы - разные плюсы и минусы, и надо подобрать под будущиею нагрузку то что лучше подходит а пока есть только предположения, в моей случаи сменить бд относительно легко
SQL - он и есть SQL, правильно отмасштабировать и затюнить БД под нужды сервиса можно любую БД, но придется погрузиться в тонкости и детальный анализ метрик.
NS
тут скорее нужно выбрать тут бд которою можно будет уже не менять, и опыта немного в этом деле, может кто то готов стать ментором ? =)
MZ
основная проблема с базой что увеличить её объем легко и даже нужно, сейчас мы удалем старые записи, но они нам нужны на самом деле, и основной объем данных в одной табличке
Это процесс архивирования БД. Сделайте еще один простекий инстанс mysql и скидывайте данные туда. Будет и хранение привычный доступ к ним.
NS
наверное лучше сказать не так, сейчас мы храним данные за день а хотелось бы за неделю/месяц
ЕА
если данные не надо менять и стоит вопрос в объеме данных, то clickhouse хорошо жмет, примерно в 5-7 раз меньше чем в mysql будет
MZ
тут скорее нужно выбрать тут бд которою можно будет уже не менять, и опыта немного в этом деле, может кто то готов стать ментором ? =)
Ни одна БД из коробки не даст результат который вырабатывается архитектурными и логическими решениями по работе с данными в БД.
NS
да я думал о нем но у нас данные обновлявлюьбся переодически
NS
я clickhouse хочу прикрутить для метрик(для чего он собственно и создавался)
ЕА
Ни одна БД из коробки не даст результат который вырабатывается архитектурными и логическими решениями по работе с данными в БД.
есть оттюненные решения которые покрывают 99% нужд
MZ
Чем больше разнородных продуктов тем больше с них задачек на обслуживание - тут ошибка, там тормозит, тут непонятно и т.д.
Если команды достаточно большая чтобы распределить такие задачи то ОК.
Если команды достаточно большая чтобы распределить такие задачи то ОК.
MZ
я clickhouse хочу прикрутить для метрик(для чего он собственно и создавался)
ClickHouse создавался для bigdata, а не метрик. Это колоночная СУБД ориентирования на работу с большим объемом данным.
NS
да каждая новая технология увеличивает комплексити системы и это минус, с этим придеться как то жить =)
MZ
Для метрик создавались timeserias-бд - tsdb(prometheus), influx и т.д.