При чтении логов из базы данных, а именно, из LDF данных, в большинстве случаев вы наткнётесь на такие функции в запросе sys.fn_dblog(null, null), sys.fn_dblog_xtp(null, null)
Читать из LDF Вы захотите по различным причинам, но так или иначе основная проблема будет «у нас откуда‑то списались деньги остатки, пропал товар, упал прод, разберитесь».
Допустим, Вы захотите воскресить удалённый, дропнутый объект из базы.
Типичный скрипт
Один из наших длительных проектов — это крупное многопользовательское SaaS-решение (CRM-система) основанное на микросервисной архитектуре и развернутое в облаке Azure. Изначально это был MVP, где все части (сервисы, базы данных и т. д.) располагались на одной виртуальной машине. Со временем проект вырос в облачное распределенное решение с множеством веб- и мобильных клиентов.
В этой статье мы расскажем, как решили одну из проблем, с которой столкнулись в процессе разработки.
Бизнес все чаще и чаще предпочитают отдать искусственному интеллекту извлечение данных из документов: при таком подходе меньше ошибок и выше скорость обработки документов. И все чаще звучит вопрос — каким решением пользоваться и к какому подрядчику пойти за оказанием услуги?
Поэтому мы сделали сравнительный обзор двух популярных решений от лидеров рынка по обработке документов — AWS Textract, Microsoft Azure Document Intelligence и собственного решения Ripper Service. Сравнивали решения по нескольким основаниям: по производительности, по результатам извлечения значений из форм, а также по стоимости.
Надеемся, что данная статья будет полезна руководителям компаний, которые уже задумались о применении ИИ для массовой обработки документов.
Существует множество определений термина "Архитектура ПО", от устаревших и неформальных до слишком абстрактных и претендующих на остроумие. К примеру, можно упомянуть сайт Института Программной Инженерии (SEI) Университета Карнеги-Меллона, в электронной библиотеке которого есть соответствующий документ.
Привет, Хабр!
Сегодня мы поговорим о том, какие LLM лучше всего работаю на бизнес-задачах. AI-хайп находится на локальном пике, похоже, что весь мир только и делает, что внедряет AI-фичи в свои продукты, собирает миллионы на разработку еще одной оболочки для ChatGPT, заполняет свои ряды AI-тулами и, кажется, предоставляет работу роботам, пока сами попивают кофе в старбаксе.
Привет, Хабр!
В Kubernetes кластер состоит из множества узлов (nodes), которые представляют собой виртуальные или физические машины, на которых запущены приложения. Node Pools — это группы узлов с одинаковой конфигурацией, управляемые как единое целое.
С Node Pools можно иметь разные пулы для разных задач или приложений, оптимизировать стоимость, используя различные типы виртуальных машин, и применять разные ОС в рамках одного кластера.
Azure Kubernetes Service (AKS) — это управляемый сервис Kubernetes от Microsoft, предназначенный для упрощения развертывания, управления и масштабирования приложений на базе контейнеров. AKS автоматически управляет хостовыми инфраструктурами, снимая бремя настройки и мониторинга, позволяя сосредоточиться на разработке приложений.
VPN обеспечивает доступ удаленных пользователей в корпоративную сеть. Решений много, но выбор оптимального не всегда очевиден. В данной статье хотел бы поделиться опытом внедрения и использования такого продуктового решении как Always On VPN от компании Microsoft. Подчеркну, что это не просто технология постоянно работающего соединения (многие вендоры используют похожие слова), а название продукта или даже целой экосистемы.
Статья будет полезна архитекторам решений и тем, кто планирует внедрять VPN на основе технологии Always On VPN (или еще сомневается). В документации вендора вопросы, затронутые в данной статье совсем не освещены и понять возможные трудности можно только на основе личного опыта.
Привет Хабр!
В мире быстро развивающихся технологий быстродействие и доступность играют ключевую роль в обеспечении удовлетворения потребностей пользователей. В этой эпохе, где каждая миллисекунда имеет значение, использование современных инструментов для оптимизации скорости доставки контента становится неотъемлемой частью стратегии любого онлайн-проекта. Сети доставки контента (CDN) представляют собой одно из ключевых решений для сокращения времени загрузки и улучшения доступности контента для глобальных аудиторий.
В контексте облачных вычислений Microsoft Azure предоставляет мощный инструментарий для эффективной реализации CDN. Путем распределения контента по всему миру с использованием глобальной сети серверов, CDN в Azure позволяет организациям улучшить производительность, снизить задержки и обеспечить надежную доставку контента пользователям в любой точке земного шара.
В данной статье мы рассмотрим основные принципы работы CDN в Microsoft Azure, его особенности, преимущества и способы эффективного использования для оптимизации процесса доставки контента, улучшения пользовательского опыта и повышения конкурентоспособности онлайн-платформ.
В этой статье поговорим о том, как сделать простой процесс загрузки данных с помощью Microsoft Azure Data Factory и Databricks в 2023/2024 году. Во второй части разберем миграцию init scripts из DBFS в Workspace в связи с новым обновлением от Databricks, если ее не сделать, то не удивляйтесь, что в конце 2023 года у вас начнут падать ADF pipelines и кластера в Databricks. 1 декабря 2023 г. Databricks отключит сценарии инициализации (init scripts) с именем кластера для всех рабочих областей. Этот тип сценария инициализации ранее считался устаревшим и не будет больше использоваться.
В этой статье я рассмотрю, как в .NET приложении можно эффективно использовать Application Insights и Serilog, а также как можно воспользоваться специфичным функционалом Azure для логгирования. Вместе эти два прекрасных инструмента дают очень богатые и гибкие возможности по логгированию для любого приложения. В статье будут показаны разнообразные варианты настройки этих инструментов и приведены примеры кода для разных сценариев логгирования.
Application Insights - это мощный инструмент для сбора и анализа метрик и логов приложений, как размещенных в облаке, там и исполняемых локально.
Serilog реализует "структурное логгирование", которое сохраняет сообщения и данные в формате, удобном для поиска и анализа, используя так называемые "sinks" для записи логов в различные хранилища. С помощью Serilog можно одновременно сохранять логи в Application Insights, локальные файлы и любые другие хранилища. Эти sinks можно очень тонко настраивать, а также включать и выключать в ходе работы приложения.
О чем и для кого статья
В какой-то момент в нашей компании возникла необходимость уметь быстро разворачивать множество тестовых сред в Azure. Данная статья расскажет об архитектуре данного решения и о его ключевых деталях.
Я подразумеваю, что читатель статьи уже владеет основами Terraform.
Предполсылки и требования
Для начала хотелось бы рассказать о нашей компании. Мы финтех стартап, занимающийся факторингом. Мы с самого начала развивались как cloud native. Все наши вычислительные мощности и сервера находятся в Azure.
На момент событий, описываемых в статье, большинство наших ресурсов составляли Azure App Service, Azure Sql Servers и Azure Blob storages. У нас было два крупных монолита и около 10 микросервисов вокруг. Честно говоря, это было больше похоже на распределённый монолит, потому что тестировать приходилось всю экосистему, а не отдельные сервисы.
В определенный момент мы начали очень быстро расти с, примерно, 20 человек в Tech отделе до 120 за год. В это время основной нашей болью было количество тестовых сред. У нас были три среды: test, staging и prod. Команды толкались в этих средах, test был постоянно разломан, протестировать что-либо было невозможно. От этого staging тоже забивался неработающим функционалом и выпуски затягивались на недели.
Быстрым решением на тот момент было увеличение числа контуров. Мы хотели дать по тестовому контуру на команду. То есть попросту продублировать все сервисы столько раз сколько есть команд. Понятно, что это не идеальное решение, и в идеале для работы над одним микросервисом команде не нужны все остальные сервисы и инфраструктура вокруг них. Но наличие крупных сервисов, над которыми работали несколько команд, и сильная связность между микросервисами не позволяли нам так сделать. Поэтому мы стали искать решение по автоматизации создания нашей облачной инфраструктуры. Нужна была возможность быстро создавать и уничтожать тестовые контура.
Привет Хабр сегодня мы поработаем с Azure Monitor Activity Logs в три простых шага: логгинг, мониторинг и алертинг.
Давайте поговорим о том, как настроить автомасштабирование для существующего кластера Azure HDInsight с помощью Azure CLI.
Microsoft Azure — это служба облачных вычислений, предлагаемая и управляемая Microsoft.
Azure HDInsight — это управляемая комплексная облачная служба аналитики с открытым кодом, предназначенная для предприятий. С помощью HDInsight в среде Azure можно использовать платформы с открытым кодом, такие как Apache Spark, Apache Hive, LLAP, Apache Kafka, Hadoop и другие.
Hadoop и Spark появились еще до Azure HDInsight. Такие механизмы, как Spark или Hadoop, можно использовать для масштабного анализа данных с высокой производительностью. Вообще говоря, Spark имеет лучшую производительность, потому что он хранит и обрабатывает данные в памяти. Hadoop, с другой стороны, хранит данные на жестких дисках.
Всем привет! В данной статье я расскажу о том, как наша компания смогла сэкономить за счет внедрения Azure SQL Elastic Pool. Дополнительно будут примеры Azure REST API для энумерации SQL Servers, для энумерации SQL databases и для получения метрик.
Самые пытливые в конце статьи узнают сэкономленную величину. Здесь исходники
Для тех кто хочет погрузиться в проектирование .Net микросервисов, Kubernetes, Azure и Azure DevOps процессы.
