Как вариант, еще можно использовать специальные операторы для PostgreSQL в Kubernetes. Они как правило позволяют "из коробки" развернуть кластер с бэкапами, репликами, мониторингом и т.д.. Но это если нужно сразу такую базу создать, а не текущую подключать.
Не совсем. Elastic, MongoDB и еще ряд компаний перешли либо на SSPL, либо на AGPLv3 лицензии, а они требуют открывать под этими лицензиями весь код продуктов, в которых они используются. Т.е. если облачный провайдер решит предоставлять без коммерческой лицензии доступ к условному Elastic, ему нужно открыть и свой код. И для многих это неприемлемо. Хотя и выпускать форки под прикрытием лозунгов о свободном ПО в данном случае немного "лицемерно" на мой взгляд.
Как посмотреть. На все языки и фреймворки есть спрос, только как правило ищут как минимум мидлов. Но это не проблема языка. Если у вас крутая экспертиза, всегда реально найти нормальное предложение. А без опыта и начальное знание условного "Scala" или "Lua" мало поможет.
Яндекс стоит конских денег потом, когда промо баланс закончится. Да и докер нужно уметь написать. Но если вы докер напишете, можно практически в любом облаке/хостинге запустить без особых проблем. Тут скорее вопрос как накатывать обновления потом. Без настройки CI/CD это не так просто, вернее требует больше телодвижений, чем пара команд для обновления Git, как описано в статье.
Там совсем другая механика. Надо nginx настраивать и т.д.. Хотя и свободы действий больше. Как вариант, если есть ВМ, можно воспользоваться одним из инструментов для CI/CD для реализации похожей механики доставки кода.
Здравствуйте, поправили. Бета-тест закончился в июле, и мы тогда всем начислили по 1000 руб., но сейчас есть более скромный стартовый баланс и грантовая программа при соблюдении определенных условий
Все то-же самое, только зависимости по другому задаются. Именно 17 java хотим еще улучшить поддержку, сейчас лучше 8 или 11 использовать. И как самый универсальный способ - dockerfile, через него можно проект с произвольным окружением загрузить.
Это список с ресурса db-engines. Там есть вопросы к классификации, но как правило на этом ресурсе сами вендоры указывают к какому классу относить их БД.
Для этого лучше использовать данные с синтетических тестов для производительности. А вот параметры удобства и т.д., наверное, лучше смотреть в сравнениях конкретных СУБД. Но сама идея взять несколько кейсов и сделать сравнение по типам хорошая, хотя скорее всего будут явные лидеры и много исключений, не попадающих в методологию сравнения.
Никто, но причем тут Data Observability. Elastic (он же Opensearch) - это СУБД + поиск, которая заточена на хранение и поиск по текстовым данным. Так можно хоть в PostgreSQL все сохранять и потом обрабатывать. Просто ни то ни то, не специализированные решения для потоковой алгоритмической обработки данных для поиска разных аномалий.
А почему PostgreSQL, а не SQLite? Кажется, с SQLite не нужно создавать отдельного проекта - будет дешевле
Попадало, но уже когда реализовывали функционал. Поэтому глубоко не исследовали. Думаю, в ближайшее время посмотрим подробнее
Эти операторы (кроме Stolone) предназначены для работы в Kubernetes. Для развертывания кластера на виртуалках лучше другие решения рассмотреть.
Тут по разному, но может и на "порядок", особенно в 95-99-ом процентиле запросов. А для некоторрых отраслей и 5% критично
Как вариант, еще можно использовать специальные операторы для PostgreSQL в Kubernetes. Они как правило позволяют "из коробки" развернуть кластер с бэкапами, репликами, мониторингом и т.д.. Но это если нужно сразу такую базу создать, а не текущую подключать.
Спасибо, поправил, не заметил опечатку)
Не совсем. Elastic, MongoDB и еще ряд компаний перешли либо на SSPL, либо на AGPLv3 лицензии, а они требуют открывать под этими лицензиями весь код продуктов, в которых они используются. Т.е. если облачный провайдер решит предоставлять без коммерческой лицензии доступ к условному Elastic, ему нужно открыть и свой код. И для многих это неприемлемо. Хотя и выпускать форки под прикрытием лозунгов о свободном ПО в данном случае немного "лицемерно" на мой взгляд.
Пока нет, но планируем сделать в начале 2024
Нет, можно привязать ваш. Там при создании проекта есть инструкция, как сделать
Пока они на нашей стороне, но планируем вывести управление пользовательскими в интерфейс, по сроку не подскажу правда
Как посмотреть. На все языки и фреймворки есть спрос, только как правило ищут как минимум мидлов. Но это не проблема языка. Если у вас крутая экспертиза, всегда реально найти нормальное предложение. А без опыта и начальное знание условного "Scala" или "Lua" мало поможет.
Яндекс стоит конских денег потом, когда промо баланс закончится. Да и докер нужно уметь написать. Но если вы докер напишете, можно практически в любом облаке/хостинге запустить без особых проблем. Тут скорее вопрос как накатывать обновления потом. Без настройки CI/CD это не так просто, вернее требует больше телодвижений, чем пара команд для обновления Git, как описано в статье.
Там совсем другая механика. Надо nginx настраивать и т.д.. Хотя и свободы действий больше. Как вариант, если есть ВМ, можно воспользоваться одним из инструментов для CI/CD для реализации похожей механики доставки кода.
Да, внизу экрана ЛК есть почта и чат поддержки
Здравствуйте, поправили. Бета-тест закончился в июле, и мы тогда всем начислили по 1000 руб., но сейчас есть более скромный стартовый баланс и грантовая программа при соблюдении определенных условий
Все то-же самое, только зависимости по другому задаются. Именно 17 java хотим еще улучшить поддержку, сейчас лучше 8 или 11 использовать. И как самый универсальный способ - dockerfile, через него можно проект с произвольным окружением загрузить.
Там кнопку нужно нажать снизу справа для подгрузки. Обычно они приходят примерно через минуту после отображения статуса результата сборки.
Нет, там ограничение в 25 мб. Если нужно большие файлы отправлять (к примеру ml-модели, то лучше пушить в Git).
Олег, спасибо за уточнение, дополнил.
Это список с ресурса db-engines. Там есть вопросы к классификации, но как правило на этом ресурсе сами вендоры указывают к какому классу относить их БД.
Для этого лучше использовать данные с синтетических тестов для производительности. А вот параметры удобства и т.д., наверное, лучше смотреть в сравнениях конкретных СУБД. Но сама идея взять несколько кейсов и сделать сравнение по типам хорошая, хотя скорее всего будут явные лидеры и много исключений, не попадающих в методологию сравнения.
Никто, но причем тут Data Observability. Elastic (он же Opensearch) - это СУБД + поиск, которая заточена на хранение и поиск по текстовым данным. Так можно хоть в PostgreSQL все сохранять и потом обрабатывать. Просто ни то ни то, не специализированные решения для потоковой алгоритмической обработки данных для поиска разных аномалий.