Администрирование баз данных *

Продолжаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

Сегодня поговорим о самых простых, но важных, возможностях команды SELECT, наиболее часто используемой при работе с базами данных - формировании выборок (VALUES), их ограничении (LIMIT/OFFSET/FETCH), фильтрации (WHERE/HAVING), сортировке (ORDER BY), уникализации (DISTINCT) и группировке (GROUP BY).

Как обычно, для предпочитающих смотреть и слушать, а не читать - доступна видеозапись.

«PostgreSQL может заменить Kafka, RabbitMQ, MongoDB, Redis, Elasticsearch, Geospatial Database и даже Сron. Но есть нюансы».

В среду, 13 декабря, в прямом эфире встретились Senior Software Engineer в Avito Tech Виталий Лихачёв и DBA в Altinity Евгений Климов и обсудили PostgreSQL. В компании Виталия любят PostgreSQL, умеют его готовить и используют для множества задач. А вот в компании Евгения предпочитают Clickhouse и считают, что один инструмент для всего — не всегда хорошо. У экспертов получилась интересная и местами остренькая беседа.

Замахнемся сегодня на RLS.

Обсуждать будем проблемы по нашему профилю, связанные с производительностью 1С:Предприятие. Но, в целом, этот материал может быть полезен и не только 1С-никам.

Почему запросы с RLS часто такие долгие?

Какие есть варианты их ускорить?

Этим постом я запускаю публикацию расширенных транскриптов лекционного курса "PostgreSQL для начинающих", подготовленного мной в рамках "Школы backend-разработчика" в "Тензоре".

В программе: рассказ об основах SQL, возможностях простых и сложных SELECT, анализ производительности запросов, разбор [не]эффективного применения индексов и особенностей работы транзакций и блокировок в этой СУБД.

Курс не претендует на лавры "войти в айти", поэтому подразумевает наличие у слушателя опыта программирования или работы с другими СУБД, и, главное, желания самостоятельно изучать тему работы с PostgreSQL глубже.

Для тех, кому комфортнее смотреть и слушать, а не читать - доступна видеозапись.

Выбор подходящей системы управления базами данных (СУБД) для корпоративного использования всегда был непростой задачей, а в условиях необходимости импортозамещения этот выбор приобретает критическую значимость для многих организаций.

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

Бесплатный PostgreSQL тоже звучит заманчиво, но не забывайте, что придется потратить время на его настройку и, возможно, даже на внесение изменений в исходный код, если вам потребуется больше мощностей. И еще один момент – качественная поддержка. Если возникнут проблемы, кто вам поможет их решить? В общем, выбор СУБД – дело серьезное!

Всем доброго дня! Комментарии к моей предыдущей статье о том, как я развиваю свой pet-проект, а также различные законы, подразумевающие локализацию персональных данных на серверах, размещенных на территории РФ (в частности Федеральный закон от 21.07.2014 № 242-ФЗ «О внесении изменений в отдельные законодательные акты Российской Федерации в части уточнения порядка обработки персональных данных в информационно-телекоммуникационных сетях»), озадачили меня идеей постепенного перевода всех данных приложения в РФ. В качестве сервера БД я отдал предпочтение сервису Supabase, который легко разворачивается в Docker на сервере.

В данном туториале я хочу обзорно пройтись по сравнению двух сервисов, представляющих собой не только СУБД, а BaaS (backend as a service), но внимание заострю именно на работе с данными, постараясь сравнить их функционал, производительность и простоту использования. Также приведу примеры обработки получения, обновления и удаления данных в Google Firebase Realtime Database и Supabase Realtime Database на JavaScript.

Стоит сразу сделать оговорку, что Realtime Database от Firebase - это облачная БД для хранения и синхронизации данных в реальном времени, в то время как БД от Supabase хоть и является её аналогом, но позволяет хостить базу данных самостоятельно ("под капотом" у Supabase располагается объектно-реляционная СУБД PostgreSQL).

Мы рассмотрим шаги, необходимые для переноса данных и обсудим примеры кода для реализации этого процесса.

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

Привет, меня зовут Мария Карпенко, я разработчик в команде Yandex Tracker — сервиса для управления процессами и проектами. Внутри Яндекса сервис  используется для постановки задач практически во всех командах, так что общее количество событий по задачам исчисляется уже миллиардами. 

Как внутренний сервис Tracker существует с 2012 года, и старые инстансы исторически использовали базы данных on-premise. Но к 2023 году многие части даже из списка легаси должны были переехать в облако — и нам понадобилось продумать бесшовный переезд для достаточно объёмных БД.

В этой статье расскажу, как мы решили эту задачу, — рассказ будет интересен всем, кто планирует переезд в облачную инфраструктуру.

«640 КБ хватит всем», — предположительно Билл Гейтс, примерно 1981 год.

Мы решили, что в нашей системе управления финансовыми базами данных TigerBeetle для хранения всех финансовых сумм и балансов будут использоваться 128-битные числа, и что мы откажемся 64-битных целых чисел. Хотя кто-то может заявить, что 64-битного integer, способного хранить в себе целые числа от нуля до 2⁶⁴, достаточно для подсчёта всех песчинок на Земле, мы осознали, что для адекватного хранения всех транзакций нам нужно подняться выше того предела. И в статье мы расскажем, почему.

Периодически сталкиваюсь с однотипными задачами вида "показать TOP-N позиций на каждом из вложенных интервалов некоторого периода".

Это может быть "5 лучших по успеваемости студентов в каждом семестре за последний учебный год", или "помесячная динамика позиции 10 наиболее продающихся товаров", или, как у нас в сервисе визуализации PostgreSQL-планов explain.tensor.ru, "3 наиболее активных страны за каждый день":

Добрый день, Хабр! 

Меня зовут Олег, я являюсь Backend-разработчиком в IT-компании «Философт» последние полтора года. Мы занимаемся разработкой платформы для жителей, подключённых к нашей системе, которая призвана помочь взаимодействовать с различными «умными» устройствами, коммуницировать с управляющей компанией, оплачивать счета ЖКХ и т.п.

Изначально разработка велась силами подрядчиков, оставивших после себя крайне посредственного качества монолит, который мы с коллегами приводим в приличный вид, постепенно распиливая на модули, а также занимаемся внедрением новых возможностей и интеграций. Одной из областей взаимодействия с пользователями является отображение показаний приборов учёта (электричество, водоснабжение и т.п.). Не так давно эта область кода была подвергнута достаточно масштабному рефакторингу и переработке, в рамках чего и состоялось наше знакомство с БД Clickhouse. 

В Postgres достаточно подробная документация, и видимо поэтому , при инсталляции Postgres для 1С большинство параметров приходится выставлять самим. Параметров в Postgres много, а составить эффективную комбинацию не так просто. Все упрощается если рассмотреть профиль нагрузки, например, 1С это прежде всего профиль OLTP нагрузки – так устроены его метаданные (объекты).  Если сосредоточится на оптимизации профиля OLTP, понимание Postgres сразу упростится.

Как не грабить память, не пытать диск, не мучать кластер. Или делать все это всего одним запросом на Impala к Hadoop.

Среди задач аналитиков данных, в рамках которых необходимо иметь дело с большими объемами однотипных данных, выделяются задачи построения витрин данных, автоматизации процессов сбора и обработки данных. Многие аналитики используют различные реляционные базы данных, в таблицах которых хранятся огромные объемы информации, агрегация и доступ к которым может занимать долгое время, поэтому правильное составление и оптимизация запросов к этим таблицам становится критически необходимым фактором для работы аналитиков, инженеров данных и data scientist.

Чтобы система долго работала без сбоев и перерывов, нужно поработать над отказоустойчивостью. В статье дадим несколько способов её построить и покажем готовое решение.

В начале ноября так сложились обстоятельства, что мне с коллегой довелось поучаствовать в качестве судей на мероприятии под строгим названием «Отборочный этап чемпионата России по спортивному программированию» в дисциплине «Продуктовое программирование». Или, говоря более простым языком — студенческий трехдневный онлайн-хакатон, победители которого поедут на финал чемпионата страны в Москву.

Вот об этом мероприятии, что на нём было интересного и каких-то выводах из увиденного сегодня и поговорим.

Системы управления базами данных (далее по тексту – СУБД) – набор компонентов, с помощью которого можно создавать, хранить, передавать и управлять базами данных. Они нужны практически на любом предприятии, которому приходится иметь дело с большими массивами информации: это могут быть данные о товарах магазина или производителя, данные о клиентах, данные о сотрудниках, данные о вашем сайте – в общем, всё, что по какой-то причине нужно хранить для решения разных бизнес-задач.

Меня зовут Вадим Ивахин, я техлид в Vi.Tech — это IT-дочка ВсеИнструменты.ру.

Я и мои коллеги трудимся над большим количеством проектов и используем в своей работе различные инструменты, в том числе MongoDB. В этой статье я не стану рассказывать о том, что такое MongoDB. Хочу рассказать о её интересной и удобной особенности — механизме Watch, и о том, как с его помощью спроектировать приложение, способное выдержать десятки тысяч rps.

Параллелизм – это возможность выполнения запросов сервером СУБД в нескольких потоков. По умолчанию в настройках SQL Server параллелизм не ограничен и потенциально для выполнения запроса могут использоваться все ядра всех процессоров (max degree of parallelism= 0). В то же время, в системах 1С вендор настоятельно рекомендует установить max degree of parallelism = 1, и, соответственно, один запрос будет использовать только одно ядро.

Почему так и что же с этим всем делать? Давайте разбираться.