« Rev
@mongodb_ru   946
Fwd »


yopp
Ну, кто такой DBA вам известно? В Оракле, Постгресе типичная роль. В Монге совсем нет такого?
DBA это абстрактная роль. Вопрос какие вы хотите задачи ставить перед человеком
yopp
Кто-то считает что DBA должен поддерживать инфраструктуру вокруг хранилищ, кто-то считает что он должен писать код для приложений
yopp
Исходить из абстрактной роли, это взять абстрактного человека и потом удивлятся почему ваши задачи не решются
critskiy
@dmitry_lukyanov обратитесь за этим в dba_ru, там может подскажут, но со словами @dd_bb спешу согласиться
Дмитрий
DBA это абстрактная роль. Вопрос какие вы хотите задачи ставить перед человеком
Да, обычные для ДБА. Резервное копирование, восстановление, добавление нод при необходимости. Миграции какие-то возможно между разными БД. Ну. и поддержка пользователей. Где-то какие-то запросики гонять на MQL
yopp
Резервное копирование это архитектура системы резервирования или реализация системы резирвирования?
Дмитрий
Кто-то считает что DBA должен поддерживать инфраструктуру вокруг хранилищ, кто-то считает что он должен писать код для приложений
Инфра в части железа - это другие люди. ОС поддерживаем в рамках администрирования конкретной СУБД. У них же всех свои особенности. Но вглубь не лезем. Обновление ОС - задача линукс-инженеров.
Дмитрий
Резервное копирование это архитектура системы резервирования или реализация системы резирвирования?
Ну, у каждой СУБД есть свои механизмы. Надо знать. СРК есть. Надо научиться с ней работать нативными средствами СУБД.
yopp
Очень хороший способ понять кто вам нужен, это прямо в вакансии написать конкретные задачи которые надо будет решить в ближайшие три месяца, год и три года. Тогда у вас будет отличное понимание что корктено нужно сделать
Дмитрий
Ну, я описал примерно все задачи.
yopp
Ну, у каждой СУБД есть свои механизмы. Надо знать. СРК есть. Надо научиться с ней работать нативными средствами СУБД.
Резервное копирование 200 гигабайт и 20 Тб это две разные задачи, требующие совершенно разного уровня экспертизы и взаимодействия между командами
yopp
Ну, я описал примерно все задачи.
Это не задачи, так как у них нет описанного конечного результата. Это должностные обязанности
Дмитрий
Это не задачи, так как у них нет описанного конечного результата. Это должностные обязанности
Конечный результат - система работает без сбоев. У нас служба эксплуатации. Тут не так много проектных активностей, которые можно описать отдельно из серии "смигрировать монгу на другой сервер".
yopp
Storage size, latency, availability, rto, rpo, бюджет
yopp
«Нам нужно хранить 1 тб событий в одном ДЦ, запись которых должна занимать 50 мс, а агрегация за последние сутки не более 2 секунд. Мы можем себе позволить около 1 часа простоя в год, мы можем потерять не больше 1 минуты данных. В худшем случае восстановление данных должно занимать не большее 8 часов. На это у нас есть 150 тысяч долларов в год»
yopp
Это и будет KPI и это будут чёткие критерии оценки решена ли задача или нет
yopp
:) всего 1 тб :)
Проблемы начнутся уже с RPO
yopp
потому что 1 минута RPO это _очень дорого_
yopp
С такими требованиями ходят в нереляционные базы?
с такими требованиями ходят в любые хранилища
yopp
база данных существует не ради самой базы данных, она существует ради решения конкретных бизнес задач
yopp
у этих бизнес задач есть требования, которые должны проецироваться на хранилище
Сергей
у этих бизнес задач есть требования, которые должны проецироваться на хранилище
Скажите бизнес задачу, с которой mongo эффективней справится, чем postgres?
yopp
Скажите бизнес задачу, с которой mongo эффективней справится, чем postgres?
С абстрактной задачей эффективнее всего справляется абстрактное хранилище :)
Сергей
Началоооосяяяяя %)
Так я с нод чата пришел, что хотели?
Andrey
Началоооосяяяяя %)
вот прям..."кабуто на Хабр попал" :)
critskiy
вот прям..."кабуто на Хабр попал" :)
Да не, в каждый второй чатик %)
Дмитрий
Скажите бизнес задачу, с которой mongo эффективней справится, чем postgres?
Присоединяюсь к вопросу, кстати... Тоже интересно стало, т.к. Монгу слабо знаю, и то, что знаю, в целом, решается в ПГ без проблем.. =)
Дмитрий
:) Ну так и спросите тех, кто принимал решение использовать у вас монгу.
Ну. обычно такие решения принимаются по принципу "мы знаем <вставить название технологии>", будем делать на ней. Это не показатель вообще же.
Дмитрий
Я б лично всё на Оракле делал, т.к. знаю его лучше всего.
Andrey
Ну. обычно такие решения принимаются по принципу "мы знаем <вставить название технологии>", будем делать на ней. Это не показатель вообще же.
Не знаю. Обычно абстрактный архитектор - совсем по другим причинам выбирает ту или иную технологию. Или я с такими инженерами сталкивался.
Andrey
Я б лично всё на Оракле делал, т.к. знаю его лучше всего.
Я б на оракле в с 2017 года ничего не делал
Andrey
Почему? Санкции?
Затраты, санкции, стоимость на перспективу
Andrey
Куча всего
Дмитрий
Затраты, санкции, стоимость на перспективу
Ну, тут же всё зависит от решаемых задач. Оракл по прежнему предлагает ряд иструментов, которые позволяют решать задачи дешевле, чем даже у с виду бесплатных конкурентов.
Andrey
Вам же вы админ написал...там где про 1тб
Дмитрий
Вам же вы админ написал...там где про 1тб
А что про 1 ТБ? Причём тут Оракл? 1 ТБ для Оракла ни о чём вообще.
yopp
1тб это пример
yopp
вопрос в уровен постановки задачи
Andrey
Да точнее так
Дмитрий
А, ну, это можно сделать на Оракле тоже. Там не сложная задача.
Дмитрий
Не особо специфичная точнее.
Andrey
Вас сложно понять.
yopp
Документные хранилища в среднем хороши там, где требуется гибкая схема
yopp
И где может потребоваться частичная денормализация
yopp
Тот-же entity-attribute-value паттерн в документном хранилище проще реализовать
yopp
Тебарайты маленьких событий в монге хранить в среднем не очень выгодно, как и в любом другом строковом хранилище
yopp
Ждать что монга сможет на петабайте в реалтайме делать агрегации тоже не стоит (как и от любого другого хранилища, если у вас бюджет на хранилище не измеряется десятками и сотнями миллионов долларов в год)
yopp
В монге достаточно мощное и относительно простое в реализации шардирование. Достаточно легко делать multi-tier кластеры
Дмитрий
Документные хранилища в среднем хороши там, где требуется гибкая схема
Так пример про PG был в тему, т.к. он же умеет хранить JSON также. Да и Оракл тоже умеет. Хотя у него это и хуже получается, чем XML.
yopp
Тот факт что что-то умеет хранить json не значит что оно умеет с ним эффективно работать
Anonymous
Всем привет, а существует ли универсальная регулярка для паркинга ObjectID?
Дмитрий
Тот факт что что-то умеет хранить json не значит что оно умеет с ним эффективно работать
Ну, потому и задан этот вопрос, что, вроде, с виду они все умеют. Хотелось бы конкретики...
Сергей
Тот факт что что-то умеет хранить json не значит что оно умеет с ним эффективно работать
Бенчмарки говорят, что уже очень даже неплохо работает, не так гибко конечно
Сергей
Спасибо https://t.me/mongodb_ru/87948
Yaroslav
А мультимастер там есть?
Это когда через арбитр решается на какую бд отсылать запросы?
Yaroslav
Тогда да, есть
yopp
Сайфай
yopp
Они к реальности никакого отношения не имеют
yopp
Даже имея на руках реальную проблему на реальных данных, её бывает очень сложно воспроизвести на тестовом столе
Дмитрий
Это когда через арбитр решается на какую бд отсылать запросы?
Если запросы на чтение, то нет. Речь про возможность записи на любую ноду, а не только чтение.
yopp
Что уже говорить про абстрактные пузомерки
yopp
Но то что обычно решается через multi-primary можно решить шардированием
yopp
Опять-же, зависит от задачи
Дмитрий
Да, это понятно. Вопрос про техническую возможность в целом.
« Rev
@mongodb_ru   946
Fwd »