Автор его использует для авто рестарта при изменении файлов. Но этим функционал process manager не ограничивается. Если хотите перезапускать приложение при фейле, или запускать разные приложения на одном сервере (в одном контейнере) на разных портах и потом шарить их под разными доменами, или запустить несколько инстансов приложения через встроенный LB, или хотите перенаправить логирование кудабы-то ни было. С базовыми настройками проще (типа сертификат поменять не пересобирая и не перезапуская контейнер). Не уверен, что uvicorn лучший выбор тут... Я бы выбрал pm2, он хоть и на nodejs, но python будет крутить не хуже. Или supervisord
Вы эти проблемы можете и по-другому решать. Так что можно и без него.
nginx из коробки ничего кроме статических файлов раздавать не умеет. Поэтому вам в любом случае нужен какой-то сервер который будет крутить ваше приложение, a nginx обычно будет стоять как reverse proxy.
Тут точно не переживайте. Абсолютно любой фреймворк на абсолютно любом языке достаточно быстрый для 99.9999% приложений. Не встречал приложений у которых проблемой производительности хоть на 0.001% был бы API фреймворк. Всегда раньше упрутся в базу, ивентбас, кукую бы то ни было интеграцию...
Если даже, вдруг, случится - серверный слой легко и дешево масштабируется горизонтально.
Но статья, как обзор на FastAPI, хорошая. Хоть и название у фреймворка "кричащее"
Я не заметил тут какого-то большого количества полезных фраз. Так что без знания английского они не помогут. Но тут есть структура типового вопроса и ответа, что поможет структурировать ответы на вопросы в формате в котором вас будет легко понять.
Отчасти согласен. И понимаю что опытному админу такие туториалы не нужны. Ставил целью сократить настройку до минимума, чтобы настроил даже человек, который не понимает что делает и как это работает. Или просто потрогать: не понравится - снесу контейнер.
Если бы у меня проходило несколько платежей в секунду через таблицу X. Я бы сделал все чтобы процесс обновления этой таблицы проходил 7кругов ада перед любым обновлением. rebuild таблицы(который кстати пройдет в фоне и без блокировки, если я правильно понял доку) там будет меньшей из проблем. Но да, очевидно, MySQL будет плохим выбором именно для такой таблицы транзакций.
> Тут простой прямых денег стоит. Тоже не всегда это правда. Нужно понимать еще что вы продаете и как. Небольшой простой такого ресурса просто спровоцирует небольшой всплеск нагрузки после старта. Придут те у кого не получилось до этого. А вот вернутся ли они - это зависит от их мотивации и того что вы продаете, в некоторых случаях у них и выбора не будет. В других, таких как retail, вернется 80-99% (конечно если это не простой в неделю)
Все так, но это же проблема не SQL. В SQL очень легко добавить новое поле. В Большую БД (и в MongoDB тоже) добавить поле сложно из-за процесса обновления БД между разными окружениями: миграция, code review и пр (если там есть такой процесс). Если же любой разработчик просто лепит поля в документы как ему нравится никого не предупреждая - это быстро и плохо закончится.
Сейчас обидно было... Но я всегда готов поискать противоречия в том что написал.
SQL позволяет отфильтровать и преобразовать данные из БД?
SQL позволяет менять схему БД?
Как вы сами написали, чтобы поддерживать код в согласованном состоянии с БД "миграции никто не отменял" что с MongoDB что с SQL. ИМХО, противоречий нет.
Реляционная БД с поддержкой SQL - очень мощная штука, которая позволяет отобрать, отфильтровать и преобразовать данные из БД. Очень удобно для быстроизменяющихся требований ПО, когда структура БД, выбранная на старте сильно меняется уже в процессе развития.
Sharding - НЕ позволяет масштабироваться горизонтально если вы активно используете Aggregation! Потому что там однозначно много $unwind и $lookup, а эти операции сведут на нет все горизонтальное масштабирование. А с репликами у вас не будет проблем и с реляционной БД.
Change Streams - Может быть очень полезен. Полностью согласен. Но это узкая область задач.
"Про монгу очень много написано" - По стратегии продвижения монги можно сейлзов учить и многие так и делают. Другое дело что большая часть написанного про монгу имеет мало общего имеет с ценностью для технарей ввиду того что это просто маркетинг.
К сожалению, я так и не протестировал это самостоятельно. Находил много тестов других организаций занимающихся OLAP хранилищами которые отмечают ее отсталость от PostgreSQL (раз, два) даже в выборках по JSON. Легко верю что и MySQL при грамотной настройке будет работать не хуже MongoDB. Хотя в блоге MongoDB они всегда самые быстрые.
Хотя стоит признать что по удобству работы с JSON объектами MongoDB в разы лучше любой другой СУБД.
На основе чего был сделан вывод? Если инструмент неудобен и провоцирует делать глупые ошибки - люди будут их делать, потому что они люди. Поэтому я лучше выберу удобный и предсказуемый инструмент для хранения любых данных которые я не хотел бы потерять. А про "надежность" и "предсказуемость" монги я писал выше.
Либо это не правда, либо вы не знаете, либо не вы занимались апгрейдом. 6 лет назад монга была версии 2.6! Пройдитесь по всем версиям - раздел Compatibility Changes и known issues. Каждую версию присутствуют изменения обратно несовместимые! Мы довольно активно использовали aggregation framework - почти каждый апгрейд мы что-то ловили.
Пример со StackOverflow: предложенное решение работало в сентябре 2015 (версия 2.6 или 3.0), в 2018 уже нет (и вы даже не найдете этого в release notes, но это так) - т.е. после апгрейда у вас "некоторые" апдейты начинают работать не так как работали раньше без предупреждений... без ошибок... просто часть данных не обновляется... узнаете об этом в проде.
Еще изменения в драйвере для nodejs который претерпевает серьезные и абсолютно ненужные синтаксические изменения и его необходимо обновлять с версиями монги.
Казалось бы "не обновляйте" и живите себе спокойно и мы так и делали для одного из приложений которое просто работало себе спокойно на mongodb2.6... Но никакое облачное решение не вечно(MongoDb cloud) и заставляет мигрировать на новые версии, а мигрировав нам еще и драйвер надо обновить который несовместим с проектом... поддерживать стабильную работу mongodb2.6 на своих серверах дело еще менее благодарное.
MongoDB также значительно сокращает цикл разработки приложения по нетехнической причине — устраняется необходимость координации миграции изменений схемы базы данных с DBA.
Если на проекте есть DBA он и до MongoDB доберется. Если нет, то и в SQL проблемы с DBA нет.
Примеры применения написаны в статье хорошо, с оговоркой: никогда не посоветую использовать MongoDB как основное хранилище первичных данных - это в 99% случаев будет выстрел в ногу. Как уже выше писал @yar3333, "надёжность не на высоте", да и сами разработчики постоянно будут ломать схему, риск поломать данные безвозвратно всегда присутствует. Наиболее распространенное заблуждение - "у нас простая БД что тут можно сломать".
Хинт: У Google так же есть PageSpeed Module под Nginx и Apache призванный улучшать сайт по рекомендациям выставленным PageSpeed Insights. Почти на каждую рекомендацию есть настройка. Но будьте аккуратны, некоторые комбинации могут поломать сайт.
Автор его использует для авто рестарта при изменении файлов. Но этим функционал process manager не ограничивается. Если хотите перезапускать приложение при фейле, или запускать разные приложения на одном сервере (в одном контейнере) на разных портах и потом шарить их под разными доменами, или запустить несколько инстансов приложения через встроенный LB, или хотите перенаправить логирование кудабы-то ни было. С базовыми настройками проще (типа сертификат поменять не пересобирая и не перезапуская контейнер).
Не уверен, что uvicorn лучший выбор тут... Я бы выбрал pm2, он хоть и на nodejs, но python будет крутить не хуже. Или supervisord
Вы эти проблемы можете и по-другому решать. Так что можно и без него.
nginx из коробки ничего кроме статических файлов раздавать не умеет. Поэтому вам в любом случае нужен какой-то сервер который будет крутить ваше приложение, a nginx обычно будет стоять как reverse proxy.
Тут точно не переживайте. Абсолютно любой фреймворк на абсолютно любом языке достаточно быстрый для 99.9999% приложений. Не встречал приложений у которых проблемой производительности хоть на 0.001% был бы API фреймворк. Всегда раньше упрутся в базу, ивентбас, кукую бы то ни было интеграцию...
Если даже, вдруг, случится - серверный слой легко и дешево масштабируется горизонтально.
Но статья, как обзор на FastAPI, хорошая. Хоть и название у фреймворка "кричащее"
Спасибо, звучит разумно. Не знал что он доступен для установки через паетный менеджер под freebsd. Добавил как хинт в туториал.
Я не заметил тут какого-то большого количества полезных фраз. Так что без знания английского они не помогут. Но тут есть структура типового вопроса и ответа, что поможет структурировать ответы на вопросы в формате в котором вас будет легко понять.
Отчасти согласен. И понимаю что опытному админу такие туториалы не нужны. Ставил целью сократить настройку до минимума, чтобы настроил даже человек, который не понимает что делает и как это работает. Или просто потрогать: не понравится - снесу контейнер.
Если бы у меня проходило несколько платежей в секунду через таблицу X. Я бы сделал все чтобы процесс обновления этой таблицы проходил 7кругов ада перед любым обновлением. rebuild таблицы(который кстати пройдет в фоне и без блокировки, если я правильно понял доку) там будет меньшей из проблем. Но да, очевидно, MySQL будет плохим выбором именно для такой таблицы транзакций.
> Тут простой прямых денег стоит.
Тоже не всегда это правда. Нужно понимать еще что вы продаете и как. Небольшой простой такого ресурса просто спровоцирует небольшой всплеск нагрузки после старта. Придут те у кого не получилось до этого. А вот вернутся ли они - это зависит от их мотивации и того что вы продаете, в некоторых случаях у них и выбора не будет. В других, таких как retail, вернется 80-99% (конечно если это не простой в неделю)
Совсем не обязательно это что-то значит для прода, часто даже downtime допустим. Но да, я не знал, жестковато - может создать приличную нагрузку.
Почему же. MySQL с версии 5.6 тоже может. Но да.. они поздновато сделали (2013)
Во многих случаях - да. При добавлении колонки - нет (года с 2010+- все популярные SQL решения так могут)
Все так, но это же проблема не SQL. В SQL очень легко добавить новое поле. В Большую БД (и в MongoDB тоже) добавить поле сложно из-за процесса обновления БД между разными окружениями: миграция, code review и пр (если там есть такой процесс). Если же любой разработчик просто лепит поля в документы как ему нравится никого не предупреждая - это быстро и плохо закончится.
Сейчас обидно было...
Но я всегда готов поискать противоречия в том что написал.
SQL позволяет отфильтровать и преобразовать данные из БД?
SQL позволяет менять схему БД?
Как вы сами написали, чтобы поддерживать код в согласованном состоянии с БД "миграции никто не отменял" что с MongoDB что с SQL. ИМХО, противоречий нет.
Реляционная БД с поддержкой SQL - очень мощная штука, которая позволяет отобрать, отфильтровать и преобразовать данные из БД. Очень удобно для быстроизменяющихся требований ПО, когда структура БД, выбранная на старте сильно меняется уже в процессе развития.
Sharding - НЕ позволяет масштабироваться горизонтально если вы активно используете Aggregation! Потому что там однозначно много $unwind и $lookup, а эти операции сведут на нет все горизонтальное масштабирование. А с репликами у вас не будет проблем и с реляционной БД.
Change Streams - Может быть очень полезен. Полностью согласен. Но это узкая область задач.
"Про монгу очень много написано" - По стратегии продвижения монги можно сейлзов учить и многие так и делают. Другое дело что большая часть написанного про монгу имеет мало общего имеет с ценностью для технарей ввиду того что это просто маркетинг.
Опыта с MongoDB у меня куда больше чем с Postgres. С MongoDB я с версии 2.0
К сожалению, я так и не протестировал это самостоятельно. Находил много тестов других организаций занимающихся OLAP хранилищами которые отмечают ее отсталость от PostgreSQL (раз, два) даже в выборках по JSON. Легко верю что и MySQL при грамотной настройке будет работать не хуже MongoDB. Хотя в блоге MongoDB они всегда самые быстрые.
Хотя стоит признать что по удобству работы с JSON объектами MongoDB в разы лучше любой другой СУБД.
Полностью согласен. Выбор не мой!
На основе чего был сделан вывод? Если инструмент неудобен и провоцирует делать глупые ошибки - люди будут их делать, потому что они люди. Поэтому я лучше выберу удобный и предсказуемый инструмент для хранения любых данных которые я не хотел бы потерять. А про "надежность" и "предсказуемость" монги я писал выше.
> За 6 лет не было ни одной проблемы ?
Либо это не правда, либо вы не знаете, либо не вы занимались апгрейдом. 6 лет назад монга была версии 2.6! Пройдитесь по всем версиям - раздел Compatibility Changes и known issues. Каждую версию присутствуют изменения обратно несовместимые! Мы довольно активно использовали aggregation framework - почти каждый апгрейд мы что-то ловили.
Пример со StackOverflow: предложенное решение работало в сентябре 2015 (версия 2.6 или 3.0), в 2018 уже нет (и вы даже не найдете этого в release notes, но это так) - т.е. после апгрейда у вас "некоторые" апдейты начинают работать не так как работали раньше без предупреждений... без ошибок... просто часть данных не обновляется... узнаете об этом в проде.
Еще изменения в драйвере для nodejs который претерпевает серьезные и абсолютно ненужные синтаксические изменения и его необходимо обновлять с версиями монги.
Казалось бы "не обновляйте" и живите себе спокойно и мы так и делали для одного из приложений которое просто работало себе спокойно на mongodb2.6... Но никакое облачное решение не вечно(MongoDb cloud) и заставляет мигрировать на новые версии, а мигрировав нам еще и драйвер надо обновить который несовместим с проектом... поддерживать стабильную работу mongodb2.6 на своих серверах дело еще менее благодарное.
Если на проекте есть DBA он и до MongoDB доберется. Если нет, то и в SQL проблемы с DBA нет.
Примеры применения написаны в статье хорошо, с оговоркой: никогда не посоветую использовать MongoDB как основное хранилище первичных данных - это в 99% случаев будет выстрел в ногу. Как уже выше писал @yar3333, "надёжность не на высоте", да и сами разработчики постоянно будут ломать схему, риск поломать данные безвозвратно всегда присутствует. Наиболее распространенное заблуждение - "у нас простая БД что тут можно сломать".
Хинт: У Google так же есть PageSpeed Module под Nginx и Apache призванный улучшать сайт по рекомендациям выставленным PageSpeed Insights. Почти на каждую рекомендацию есть настройка. Но будьте аккуратны, некоторые комбинации могут поломать сайт.