Зачастую возникает необходимость начать новый микросервис.
Вот и у меня совсем недавно возникла такая потребность. А ведь еще хочется и чего-то новенького попробовать.
Сперва был определен стек и хотя процесс для меня не новый, но я столкнулся с множеством подводных камней. В результате решил сделать этот туториал!
Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В прошлой части мы разобрали, как создать аутентификацию с помощью библиотеки Passport, а сегодня мы рассмотрим такие манипуляции, как добавление, редактирование, удаление и получение задач. Для начала давайте разберём HTTP и некоторые типы запросов.
В этой статье я хочу рассказать о своих ошибках, которые я допустил, когда писал сервис, у которого MongoDB была основной БД для хранения пользовательских данных (да и не только, но об этом ниже).
Я ни в коем случае не считаю, что MongoDB это плохая БД и ее не нужно использовать. Более того, я считаю, что только мои кривые руки завели меня в ситуацию, из которой пришлось выходить переписыванием сервиса под другую БД (ушел на Postgres и кайфую).
Тем не менее, нельзя знать всего и чтение документации не спасает от катастроф во время самой реализации проекта. Особенно, если ваши ожидания от инструмента разошлись с реальностью.
На мой взгляд, маркетологи MongoDB приукрасили области применениях БД на своем сайте. MongoDB не универсальная. Далеко не универсальная и даже не пытайтесь на нее смотреть как на решение всех ваших проблем.
Сегодня у нас — экшен, основанный на реальных событиях. Будем переобуваться в воздухе и на лету менять архитектуру высоконагруженной системы.
Действие разворачивается на базе очень большой track & trace системы класса big data. В ней давно откладывали переход на шардированную архитектуру хранилища. Поэтому главному герою предстоит справиться справиться со злом, пробудившимся в системе под нагрузкой: деградацией производительности, полкой по блокировкам и алертами о перегрузке.
В конце — как обычно, хэппи-энд. Наш герой бесстрашно меняет архитектуру решения на лету без downtime (DT) и обеспечивает штатную работу системы. Зло повержено, а отважный инженер купается в овациях!
Статья написана по мотивам доклада на конференции Saint Highload++ 2022. Если не хотите читать — можно посмотреть видео-версию выступления.
В этой статье сравним MongoDB и Cassandra — две самые популярные NoSQL базы данных.
На выбор подходящей СУБД для проекта может уйти довольно много времени. Требования к базе данных могут включать упрощенную модель данных, гарантию транзакций, производительность чтения/записи, горизонтальное масштабирование и отказоустойчивость.
Для начала нужно определиться с типом СУБД: SQL или NoSQL. Если вы выберите NoSQL, то дальше появляется вопрос: MongoDB или Cassandra. Да, на рынке существует множество NoSQL-баз данных, но среди них лидируют MongoDB и Apache Cassandra. Оба продукта похожи, но все-таки разные. Давайте сравним эти две СУБД, чтобы сделать правильный выбор.
Совсем недавно начал изучать фреймворк Fastify, который почему-то не особо популярен в русскоязычном сегменте интернета. Для хранения переменных конфигурации я всегда использовал файл .env. Для чтения файла .env на Express я привык использовать всем известную библиотеку dotenv, то врем как в экосистеме Fastify есть своя библиотека - @fastify-env.
Я в обратился к документации... и ничего не понял. Я попробовал реализовать то, что там указано, но у меня ничего не вышло. Туториал на youtube от какого-то индуса так же не помог (хотя у индийского программиста всё получилось)...
Сославшись на позднее время суток и усталость мозга, я сдался и начал искать какое-нибудь готовое решение в интернете, и оно быстро нашлось, которое нашлось достаточно быстро. Выяснилось, что я не один сталкиваюсь с такой проблемой и это частая сложность у программистов пришедших в Fastify после Express.
Итак, ниже пойдёт перевод этой статьи от 27.07.2021 г. (обновлено 18.02.2022 г.). Перед прочтением статьи рекомендую потратить 5-10 минут времени на чтение ооочень короткой официальной документации библиотеки @fastify-env.
Привет! Меня зовут Максим Чижов, я уже третий год работаю бэкенд-инженером в Авито. Когда только пришёл в компанию, я столкнулся с проблемой хранения больших объёмов информации. О том, как её решить, расскажу в статье.
Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В прошлой части мы разобрались, как настроить и запустить проект, а сегодня продолжим создавать наш планировщик и поэтапно разберём создание аутентификации с помощью библиотеки Passport.
В нынешней ситуации многие сервисы блокируют доступ из РФ, я покажу как можно обойти этот запрет с помощью ProxyChains и Tor на примере MongoDB.
Друзья, всем привет! Меня зовут Игорь Карелин, я frontend-разработчик в компании Домклик. В серии статей мы поэтапно разработаем продвинутое приложение-планировщик. Сначала создадим и настроим монорепозиторий c помощью NX, разработаем интерфейс с помощью React, добавим backend на основе NestJS, и, наконец, подключим базу данных MongoDB.
Привет! Это пост-отчёт с митапа «Быстрый бэкенд», который прошёл в офисе Joom. С коллегами из Джум Лабс и Авито обсудили, как живётся с большим кластером MongoDB, как битмап-индексы помогают быстро искать по каталогам и как анализировать большие объемы Jaeger-трейсов. В этом посте — видеозаписи докладов, презентации спикеров и несколько фотографий со встречи.
Стремясь к повышению производительности базы данных, вы можете столкнуться с ситуацией, когда оптимизации и настройки уже недостаточно. Если вы не можете заменить движок БД, а для настройки параметры рабочей нагрузки больше нет возможностей — базу данных придется масштабировать. Делать это руками долго и нецелесообразно, но и у автоматизации процессов масштабирования есть свои подводные камни.
Это перевод статьи Дмитрия Костика и Миколы Моржан из Percona. С их помощью посмотрим, в какой степени можно автоматизировать горизонтальное масштабирование баз данных MongoDB, MySQL и PostgreSQL в Kubernetes и как это сделать?
Любое приложение, работающее с большими объемами данных, нуждается в такой базе данных, которая будет способна предоставить наиболее высокопроизводительные решения, связанные с хранением этих данных. Есть два распространенных выбора, которые могут удовлетворить такую потребность — реляционные системы управления базами данных (RDBMS или рСУБД) или NoSQL решения. В настоящее время все чаще выбор происходит в пользу баз данных NoSQL из-за их простой структуры и возможности как горизонтального, так и вертикального масштабирования, чего нельзя достичь с помощью традиционных рСУБД. Одна из самых известных баз данных NoSQL — MongoDB, которая включает в себя целый набор MongoDB-инструментов.
В MongoDB мы стремимся предоставить разработчикам возможность внедрять инновации в работу с данными. Временные ряды — самая быстрорастущая рабочая нагрузка с интенсивным использованием данных. Наши нативные возможности при работе с временными рядами позволяют быстрее создавать приложения и получать больше инсайтов из данных этих рядов с меньшей когнитивной нагрузкой.
Точно скажу, что костыли и велосипеды не лучшее решение, особенно если мы говорим о кэшировании, а конкретнее, если нам надо оптимизировать метод доступа к данным, чтобы он имел производительность выше, чем на источнике. Я докажу это на нескольких примерах, приведённых в статье, всего за 5 минут.
Внимание: "Данная статья является ознакомительной и несет лишь основную информацию о стеке технологий MERN."
"Все кратко и просто".
• Что же такое стек технологий MERN?
• Из чего состоит?
• Создание базы данных (MongoDB)
• Серверная часть (NodeJS + Express)
• Клиентская часть (ReactJS)
Для каждой организации необходимы данные, которым можно доверять и получать к ним доступ, независимо от их формата, размера или местонахождения. Быстрые темпы изменений в технологиях и переход к облачным вычислениям революционизируют методы обработки, управления и регулирования данных в компаниях, освобождая их от тяжелой операционной нагрузки, связанной с развертыванием локальных систем. Предприятия ищут централизованное, экономически эффективное решение, способное обеспечить масштабирование системы хранения и аналитики, чтобы они могли получать данные и выполнять операции искусственного интеллекта (AI) и машинного обучения (ML), в конечном итоге расширяя свои маркетинговые горизонты.
В последние годы мы наблюдаем масштабные изменения в области цифровой трансформации. Как люди, мы все "подключены" к сети — наши умные устройства, умные дома, умные автомобили, умные города и так далее. Мы используем умные устройства из-за удобства, которое они нам предлагают — автоматизируя ежедневные задачи и давая представление о текущих событиях, от давления в шинах автомобиля до того, оставили ли мы плиту включенной перед выходом из дома.
Весной 2021 года во французском Страсбурге случилось яркое событие: полностью сгорел дата-центр одного из крупнейших европейских хостинг-провайдеров (OVH). Всего за несколько часов пожар отрубил доступ к миллиону популярных сайтов и онлайн-сервисов во всём мире. Одна из вероятных причин — человеческий фактор. В результате под угрозой существования оказался не только сам ЦОД, но и весь бизнес провайдера. К слову, и в России ЦОДы тоже горят. К сожалению, пожар — не единственная проблема больших данных. Не менее опасно — highload системы. Это когда, например, приложение перестаёт справляться с моментальной нагрузкой, а вся инфраструктура работает на пределе возможностей, и запаса для роста у неё нет. Забегая вперед, скажу, что решение есть у каждой из перечисленных проблем. Но, обо всём по порядку.
