MongoDB *

Совсем недавно начал изучать фреймворк 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 системы. Это когда, например, приложение перестаёт справляться с моментальной нагрузкой, а вся инфраструктура работает на пределе возможностей, и запаса для роста у неё нет. Забегая вперед, скажу, что решение есть у каждой из перечисленных проблем. Но, обо всём по порядку.

Как и почему рутинное обновление Руби гемов менее чем за 1 час создало 475 новых подписок на общую сумму $73.271 долларов.

Привет, Хабр. В феврале стартует очередной набор группы курса "MongoDB", в связи с чем подготовили для будущих студентов перевод статьи из официального блога MongoDB про релиз 5.2. Решили, что для читателей Хабра эта информация тоже может оказаться полезной, поэтому делимся с вами.

MongoDB позволяет решать самые разные задачи с данными при помощи единого API. Наш последний быстрый релиз — MongoDB 5.2 — развивает эту концепцию, улучшая эргономику запросов, совершенствуя коллекции временных рядов (представленные в MongoDB 5.0), масштабирование, оперативную устойчивость и новые возможности, позволяющие командам выполнять более сложную аналитику на месте.

Сжатие столбцов для коллекций временных рядов

Появившиеся в MongoDB 5.0 коллекции для данных в форме временных рядов позволяют легко получать и работать с информацией из этих коллекций вместе с вашими операционными или транзакционными данными без необходимости интеграции отдельной одноцелевой базы в вашу среду. В версии 5.2 Rapid Release представлено сжатие столбцов для коллекций временных рядов в MongoDB. 

Случаи использования временных рядов — будь то мониторинг устройств, выявление тенденций или прогнозирование — требуют, чтобы при каждом измерении в базу данных вносились новые данные. В случаях, когда данные поступают постоянно, их объем может быть ошеломляющим, что затрудняет управление постоянно растущим объемом хранилища.

Чтобы помочь командам достичь высокой производительности при сохранении эффективности использования ресурсов, мы добавили несколько возможностей в коллекции временных рядов.

Начинаю публикацию решений машин с площадки HackTheBox. Надеюсь этот туториал станет небольшой подсказкой тем, кто только начинает свой путь в этичном взломе. Начнем....

Одним из трендов при проектировании сервисов в последнее время выступает использование в качестве баз данных NoSQL-систем. Мы также стараемся идти в ногу со временем и, конечно же, имеем в своем IT-ландшафте несколько таких решений. Одно из них — шардированный кластер MongoDB. Эксплуатация этой СУБД сопряжена с проблемами производительности, архитектуры, взаимодействия и т.д. Удивительно, но факт - зачастую, все мы сталкиваемся с тем, что ошибаются разработчики самой СУБД. Кто бы мог подумать.., что после штатной перезагрузки узла конфигурационного сервера MongoDB в процессе обновления может произойти аварийное завершение работы сервиса базы данных и наш стенд превратится в «тыкву»!

Об одном из таких случаев хотим рассказать в этой статье и, возможно, уберечь наших читателей от опрометчивых шагов при работе с MongoDB.

Дисклеймер: нижеописанные события произошли после того, как была опубликована рекомендация производителя не использовать версию 4.4.4.