PostgreSQL и MySQL являются самыми популярными Open Source реляционными базами данных. И часто возникает вопрос - чем отличается PostgreSQL от MySQL? Ответ на этот вопрос позволит понять, какая из баз данных лучше подойдет вашему проекту.
В данной статье мы сравним PostgreSQL и MySQL по различным параметрам и запишем их в сравнительную таблицу.
Часто, в обзорах видов баз данных упоминают реляционные и “другие”, “NoSQL” и т.д., либо приводят самые основные типы СУБД (базы данных), забывая о редких. В данной статье я постараюсь описать максимально полно виды баз данных и привести примеры конкретных реализаций. Разумеется, статья не претендует на всеохватность и классифицировать базы данных можно по разному, в том числе по типам оптимальной нагрузки и т.д., но надеюсь, она даст базовое представление о видах СУБД и принципах их работы.
В статье мы рассмотрим следующие типы баз данных:
В последние годы растет сложность IT-инфраструктуры в компаниях и, соответственно, спрос на сервисы мониторинга ее работоспособности. Их все больше покупают, в них все чаще инвестируют. Но в данной статье мы расскажем о новом смежном тренде - Data Observability. Что это и чем она отличается от Infrastructure Observability?
Классический мониторинг - это наблюдение за работой инфраструктуры и приложений. А Data Observability позволяет осуществлять мониторинг потоков данных (и даже бизнес-процессов) и находить в них сбои.
Рассмотрим несколько примеров.
Создаем красивый отчет или веб приложение на Python при помощи Streamlit и делимся им через облачный сервис с развертыванием через GIT.
В книге «От нуля к единице» Питер Тиль утверждал, что лучшая инвестиция — инвестиция в будущую монополию. Монополию создать не так просто, особенно в мире, где за этим пристально следят. Но иногда удается найти способ, чтобы монополия получилась «естественным путем». И один из таких способов — стандарты. В статье я на примерах покажу, как этот прием использовали известные всем компании, чтобы получить «нерыночное» конкурентное преимущество.
В этой статье мы рассмотрим, как развернуть телеграм бота на python в облаке через push в GIT одной командой
К тому, что описано в статье, мы пришли через череду даунтаймов и багов, которые приходилось править “на горячую”. Происходили сбои во время бета-теста, но все равно тема обеспечения стабильной работы для нас болезненная. За знания пришлось заплатить дорогую цену - неудобства пользователей. Мы сами еще только на полпути к построению той системы обеспечения стабильной работы, какой нам бы хотелось ее видеть. Но надеюсь, наш опыт поможет кому-то не повторять наших ошибок и сразу все сделать правильно.
Статья не имеет цели создать какое-то принципиально новое знание о мониторинге, которого нет у опытного SRE инженера. Но, возможно, будет полезна в качестве отправной точки для изучения технологического стека тем, кто только начинает погружаться в вопрос.
Начнем с того, в каких случаях и какой мониторинг обычно используется.
Node. js - это одна из самых популярных платформ для создания IT-приложений, например, ботов и сайтов. Мы рассмотрим варианты специализированного хостинга с поддержкой проектов Node. js, причем, в основном, бесплатные, или почти бесплатные. Также пробежимся по хостингам, нативно поддерживающим базы данных PostgreSQL, MySQL и MongoDB для Node. js.
В России не так много специализированных провайдеров, поэтому рассмотрим также иностранных игроков. Но для оплаты их услуг потребуется карта иностранного банка. Отмечу, что мы не будем упоминать классические VPS хостинги, поскольку это тема отдельной статьи.
История насчитывает довольно мало компаний, которые совершили настоящую революцию и поменяли взгляд на то, какими должны быть технологии. И одна из таких компаний, безусловно, - Heroku.
Чтобы понять, насколько революционным был их подход, давайте просто вспомним, что Heroku создала в 2007-2011 году. Я могу назвать как минимум 3 вещи - контейнеры, serverless и доставку кода через push в GIT. Во многом современный технологический ландшафт был вдохновлен решениями Heroku, увидевшими свет 15 лет назад.
В этой статье я хочу поговорить об истории компании и причинах утраты “былого величия” в наши дни.
Начало истории Heroku
В 2007 году трое разработчиков Ruby — Джеймс Линденбаум, Адам Виггинс и Орион Генри — основали Heroku. Поначалу это был редактор кода в браузере. Проект вызывал “ВАУ эффект”, но не сильно вовлекал пользователей. С этим проектом основатели даже прошли Y Combinator. В ходе доработки платформы разработчики сделали, как им тогда казалось, второстепенную фичу - возможность разворачивать приложения из мастер ветки привязанного GitHub. Цель была простая - дать возможность разработчикам сразу понять, как работает их код. Почему фича казалась второстепенной? На тот момент GitHub только появился, и делать интеграцию с ним было далеко не очевидной идеей.
Но однажды, анализируя то, как пользователи используют проект, основатели Heroku заметили, что многие клиенты используют только функцию развертывания приложений через push в GIT. И с этого момента началась новая страница развития сервиса.
Рассмотрим варианты сервисов хостинга проектов в docker контейнерах. Сразу оговорюсь — мы не будем приводить в статье список VPS. Да, сделать на них хостинг docker возможно, но это тема отдельной статьи. В этой мы рассмотрим именно специализированные сервисы для хостинга докер контейнеров.
В последнее время я вижу много хайпа вокруг Kubernetes. Кажется, что он везде и всюду, а если кто-то его еще не использует, то он безнадежно отстал. Но странно принимать решение о внедрении технологии только на основе ее популярности в СМИ. Давайте разберемся: а вот лично вам правда нужен K8S?
Для чего используют Kubernetes?
Как правило, внедрение Kubernetes означает использование микросервисной архитектуры. Конечно, чтобы реализовать микросервисы, не обязательно внедрять Кубернетес. Но очень часто обращаются именно к нему.
Тогда сформулируем вопрос иначе: а вам правда нужны микросервисы? И потом вернемся к предыдущему вопросу.
Достоинств у микросервисной архитектуры много. Например:
Когда у вас небольшой проект (например, телеграмм-бот или дискорд-бот), платить лишние деньги за хостинг не хочется. Давайте попробуем разобраться, какие есть варианты бесплатного – или условно бесплатного – хостинга для ботов.
Далеко не все в России знают про компанию Splunk. Splunk разрабатывает IT-сервисы (программы для сбора и обработки логов, SIEM системы и т.д.) и зарабатывает около 3 млрд.$ в год. У нас данная американская компания известна, прежде всего, двумя вещами:
• Ее продукты стоят как “чугунный мост”. Средний чек Splunk - несколько сотен тысяч долларов в год.
• Подключив несколько сотен корпоративных клиентов в России, Splunk ушла с российского рынка одним днем в 2019 году, оповестив клиентов в пресс-релизе. После чего все в горящем режиме переходили на Elastic и другие решения.
Данная статья будет как раз о первом пункте - неадекватной цене, и почему лучше так не делать (хотя уходить одним днем тоже не лучшая идея). Материалы для статьи мы случайно нашли, когда выбирали решение для анализа логов. История показалась нам весьма интересной.
В этой статье мы, расскажем, как сделали первое действительно бесплатное облачное распознавание речи и как им воспользоваться.
Разработчики систем распознавания речи, как правило, используют поминутную тарификацию распознавания. В одной из прошлых статей я уточнял почему считаю это далеко не всегда правильным (если кратко, то при такой тарификации вендоры округляют длительность в большую сторону, а значит, за распознавание коротких записей вы заметно переплачиваете, а при большом трафике это очень дорого).
Давайте теперь разберемся, действительно ли для вендоров экономически оправданно брать деньги с хобби-проектов и небольших компаний, которым нужно распознавать не миллионы, а всего лишь десятки или сотни минут в день.
Эта история началась с того, что к нам пришел клиент, которому нужна была система распознавания речи. Да не простая, а качественно распознающая разговоры с микрофонов на АЗС, то есть речь в сильных шумах. Цель заказчика простая – контролировать, упоминают ли кассиры акции, предлагают ли установить мобильное приложение и выпить кофе. Вы наверняка все это сами слышали на заправках.
Но есть проблема. Хорошо распознать простую чистую речь могут почти все известные решения. Но речь, где на фоне играет радио, слышны звуки с других касс, громкость речи говорящих разная и присутствует много отраслевой лексики (бренды сигарет, марки топлива), качественно распознать не смогло ни одно «коробочное» решение.
Вызов принят! Мы решили за ограниченное время справиться с этим кейсом.
Шаг 1 – транскрибируем несколько файлов и замеряем качество распознавания на своем решении и решении конкурентов.
Для измерения качества распознавания используем метрику WER.
С появлением в 2020 году нейронной сети GPT3 и других архитектур – трансформеров, генерируемые тексты стали невероятно правдоподобными. Такими правдоподобными, что отдельно взятый текст, не несущий большой смысловой нагрузки, стало сложно отличить от написанного человеком. В статье мы разберем подход к определению сгенерированных текстов. И заодно выясним, является ли, по мнению алгоритма, Пушкин (и другие деятели искусства) искусственной нейронной сетью.
Суть подхода
Программисты любят программировать. Но если вы – программист, и результат вашего творения делается не “в стол”, рано или поздно наступит момент, когда нужно показать его миру: заказчику, пользователям, инвесторам, etc. Хорошо, когда вы работаете в компании, где есть целый отдел или хотя бы отдельный специально обученный человек, который может развернуть ваше приложение где вы скажете и как вы скажете. Однако не все компании могут себе такое позволить. А уж если вы фрилансер или это ваш пет-проект, развертывание приложения точно ляжет на вас.
О чем вам нужно позаботиться перед развертыванием? Арендовать сервер, настроить его, зарегистрировать доменное имя, получить SSL-сертификат, подумать о доставке обновлений.
Чтобы предметно рассмотреть процесс развертывания, напишем небольшой API-сервис TODO-заметок на языке программирования Python с использованием микрофреймворка Flask.
Планирование
Каждая заметка будет определяться следующим образом:
Мне нравится концепция, согласно которой речь – это, в первую очередь, не способ коммуникации, а отражение сознания. В таком случае стихи - это отражение красоты сознания. Но сможет ли нейросеть сгенерировать стихотворения, похожие на рукотворные? Давайте попробуем сделать такой алгоритм.
Шаг 1 – выбираем архитектуру
Тренд последних лет в обработке естественных языков (NLP) - использование нейронных сетей. А если смотреть более узко, то - нейронных сетей архитектуры «трансформер», включающих блок внимания «attention». Суть подхода в том, чтобы использовать при кодировке как в энкодере эмбединга (вектор признаков на выходе слоя нейронной сети), так и в декодере, механизм «attention», позволяющий учитывать взаимосвязь между словами и «фокусировать внимание» нейронной сети только на контексте, имеющем значение для слова.
Одной из архитектур на основе трансформеров является ruBERT, его и возьмем. Но для чистоты эксперимента попробуем также использовать и более старый подход, а именно LSTM нейронную сеть.
Возможно, у вас была (или есть) потребность развернуть свой IT-проект, будь то простой бот, сайт, приложение или сложный высоконагруженный сервис. И, возможно, вы пользовались для этого AWS, MS Azure или другими провайдерами публичных облаков.
Тогда вы знаете, что для использования таких облачных решений нужно иметь весьма «глубокие карманы». Так, чтобы развернуть обычный сервис распознавания речи на 20 потоков вы заплатите Яндексу за виртуальные машины и за СУБД 43500 руб. в месяц (расчет на основе нашего ASR). И это еще достаточно простой, пусть и требовательный к CPU сервис. Кажется, облачные услуги должны быть более доступны с финансовой точки зрения.
В этой статье мы расскажем, как делали свое облако, с чем столкнулись, и что в итоге получилось.
Предположим, вы программист и вам нужно где-то разместить сайт или приложение.
Но что если проект не такой большой, чтобы платить серьезные деньги за облако по типу Amazon, вы не хотите тратить человеческий ресурс на администрирование инфраструктуры и хотите большую масштабируемость, чем у железного сервера?
Вот как раз в этом случае и пригодятся контейнеры.
Традиционно у вас есть 3 основных варианта: собственный железный сервер, хостинг виртуальной машины, облачные сервисы наподобие Amazon EC2.