Телемедицинский сервис DOC+ связал утечку персональных данных, о которой стало широко известно в минувшие выходные, с ошибкой сотрудника. DOC+ выступает одним из медицинских провайдеров в маркетплейсе Яндекс.Здоровье — данные клиентов этого сервиса в отрытый доступ не попали, подчеркнули в PR-службе, в отличие от собственных:
Появление данных из ClickHouse в открытом доступе произошло из-за ошибки, Читать полностью »
Графики, отчеты и аналитика – все это так или иначе присутствует в back-office любого, даже совсем маленького, предприятия. Когда в обычных таблицах в Excel/Numbers/Libre становится уже тесно, но data все еще не очень big, традиционные решения для внутренних потребностей компании часто строятся с помощью реляционных баз данных, таких как PostgreSQL, MySQL или MariaDB.
Эти базы данных бесплатны, благодаря SQL удобно интегрируются с остальными компонентами в системе, они популярны и с ними умеют работать большинство разработчиков и аналитиков. Нагрузку (трафик и объемы) они могут переварить достаточно объемную, чтобы спокойно продержаться до того момента, когда компания сможет позволить себе более сложные (и дорогие) решения для аналитики и отчетов.
Читать полностью »
Любые процессы, связанные с базой, рано или поздно сталкиваются с проблемами производительности запросов к этой базе.
Хранилище данных Ростелекома построено на Greenplum, большая часть вычислений (transform) производится sql-запросами, которые запускает (либо генерирует и запускает) ETL-механизм. СУБД имеет свои нюансы, существенно влияющие на производительность. Данная статья — попытка выделить наиболее критичные, с точки зрения производительности, аспекты работы с Greenplum и поделиться опытом.
Представляет собой несколько разных экземпляров процесса PostgreSql (инстансы). Один из них является точкой входа для клиента и называется master instance (master), все остальные — Segment instanсe (segment, Независимые инстансы, на каждом из которых хранится своя порция данных). На каждом сервере (segment host) может быть запущено от одного до нескольких сервисов (segment). Делается это для того, чтобы лучше утилизировать ресурсы серверов и в первую очередь процессоры. Мастер хранит метаданные, отвечает за связь клиентов с данными, а также распределяет работу между сегментами.
Подробнее можно почитать в официальной документации.
Далее в статье будет много отсылок к плану запроса. Информацию для Greenplum можно получить тут.
Мы решили подготовить серию дайджестов с обзорами наиболее популярных open source проектов. В список попали самые обсуждаемые на Hacker News решения с открытым исходным кодом. Тема первой подборки — инструменты и сервисы для работы с логами и базами данных.
The Guardian — одна из крупнейших британских газет, она основана в 1821 году. За без малого 200 лет существования архив накопился изрядный. По счастью, далеко не весь он хранится на сайте — всего за какие-то последние пару десятков лет. В базе данных, которую сами англичане назвали «источником истины» для всего онлайн-контента, около 2,3 млн элементов. И в один прекрасный момент они осознали необходимость миграции с Mongo на Postgres SQL — после того, как одним жарким июльским днём в 2015 году процедуры аварийного переключения были подвергнуты суровому испытанию. Миграция заняла без малого 3 года!..
Мы перевели статью, в которой рассказывается, как проходил процесс миграции и с какими сложностями столкнулись администраторы. Процесс долгий, но резюме простое: приступая к большой задаче, смиритесь, что ошибки будут обязательно. Но в конечном итоге, 3 года спустя, британским коллегам удалось отпраздновать окончание миграции. И поспать.
Мы продолжаем экспериментировать с форматами проведения митапов. Недавно на боксерском ринге мы сталкивали централизованную шину данных и Service Mesh. В этот раз решили попробовать нечто более миролюбивое — StandUp, то бишь открытый микрофон. Темой выбрали in-memory базы данных.
В каких случаях стоит переходить на in-memory? Как и зачем масштабировать? И на что стоит обратить внимание? Ответы в выступлениях спикеров, которые мы осветим в этом посте.
Читать полностью »
Недавно мы рассказали об архитектуре Яндекс.Облака. Теперь давайте перейдем от теории к практике. В Облаке есть несколько сервисов для автоматизированного контроля за СУБД: Managed Service for ClickHouse, Managed Service for PostgreSQL и Managed Service for MongoDB. Все они являются платформенными и позволяют сосредоточиться на задаче хранения данных, а не на администрировании инфраструктуры. Но иногда бывает важно контролировать ещё и виртуальные машины кластера. Например, может возникнуть задача масштабирования в ответ на увеличение или снижение нагрузки. Обычно этот сценарий — один из самых трудоёмких с практической точки зрения. Сегодня мы расскажем, как Яндекс.Облако позволяет автоматизировать сложные задачи масштабирования, и убедимся, что база остаётся доступной в процессе изменения размера кластера.
В условиях highload сложность оптимизации реляционных баз данных возрастает на порядок, так как покупка ещё более мощного железа обходится дорого а также уже нет возможности просто выключить приложение ночью для долгого процесса альтера БД и миграции данных.
Недавно мы рассказали, как мы оптимизировали PHP-код нашего приложения. Теперь же пришёл черёд статьи про то, как мы полностью изменили внутреннюю структуру самой нагруженной и важной базы данных в Badoo, не потеряв при этом ни одного запроса.
Читать полностью »
Хотим поделиться историей, которая произошла на одном из наших проектов под Новый год. Суть проекта в том, что он автоматизирует работу врачей в медицинских учреждениях. Во время визита пациента доктор записывает информацию на диктофон, затем аудиозапись транскрибируется. После процесса транскрибирования – т.е. превращения аудиозаписи в текст – формируется медицинский документ по соответствующим стандартам и высылается обратно в клинику, откуда пришла аудиозапись, где ее получает отправивший врач, проверяет и утверждает. После прохождения обязательных проверок документ отсылается конечным пациентам.
Читать полностью »
Одна из малозаметных, но важных функций наших сайтов объявлений — сохранение и отображение количества их просмотров. Наши сайты следят за просмотрами объявлений уже больше 10 лет. Техническая реализация функциональности успела несколько раз измениться за это время, и сейчас представляет из себя (микро)сервис на Go, работающий с Redis в качестве кэша и очереди задач, и с MongoDB в качестве персистентного хранилища. Несколько лет назад он научился работать не только с суммой просмотров объявления, но еще и со статистикой за каждый день. А вот делать все это действительно быстро и надежно он научился совсем недавно.
В сумме по проектам, сервис обрабатывает ~300 тысяч запросов на чтение и ~9 тысяч запросов на запись в минуту, 99% которых выполняются до 5мс. Это, конечно, не астрономические показатели и не запуск ракет на Марс — но и не такая тривиальная задача, какой может показаться простое хранение чисел. Оказалось, что делать все это, обеспечивая сохранение данных без потерь и чтение согласованных, актуальных значений требует определенных усилий, о которых мы расскажем ниже.
Читать полностью »
