Рубрика «базы данных» - 13

Бойтесь операций, buffers приносящих…
На примере небольшого запроса рассмотрим некоторые универсальные подходы к оптимизации запросов на PostgreSQL. Пользоваться ими или нет — выбирать вам, но знать о них стоит.
Читать полностью »

Привет! Как водится, три раза в году мы рассказываем о том, над чем работали. Это статья о том, что нового в DataGrip 2019.3, а значит и во всех IDE от JetBrains с поддержкой баз данных.

DataGrip 2019.3: MongoDB, дебаггер, модный прогресс-бар, много новых инспекций - 1
Читать полностью »

image
Фото: www.rbc.ru

Центральный банк РФ будет отслеживать сомнительные операции с помощью анализа мобильных устройств и компьютеров юридических лиц. Для этого ЦБ создал проект межбанковской базы данных с информацией о технике пользователей — «Сервис анализа технических устройств». Мера должна помочь бороться с отмыванием доходов, считает Банк России.
Читать полностью »

Всем привет!

Меня зовут Михаил Мазеин, я — ментор Backend community ManyChat. 5 декабря в нашем офисе пройдёт первый Backend Meetup.

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

Начнём с истории про выбор инструментов для вычисления математических формул. Продолжим фундаментальной темой выбора подходящей базы данных. А закончим встречу большим докладом о тюнинге сервера высоконагруженного проекта с помощью тонкой конфигурации nginx и php-fpm на основе данных о движениях запросов вместо постоянного увеличения количества серверов.

5 декабря, ManyChat Backend MeetUp - 1

Участников ждут доклады от инженеров ManyChat и, конечно, общение. Встречать гостей будем в 18:30, а начнем митап в 19:00. Регистрация доступна по ссылке, а подробная программа мероприятия — под катом.
Читать полностью »

Классический вопрос, с которым разработчик приходит к своему DBA или владелец бизнеса — к консультанту по PostgreSQL, почти всегда звучит одинаково: «Почему запросы выполняются на базе так долго?»

Традиционный набор причин:

  • неэффективный алгоритм
    когда вы решили сделать JOIN нескольких CTE по паре десятков тысяч записей
  • неактуальная статистика
    если фактическое распределение данных в таблице уже сильно отличается от собранной ANALYZE'ом в последний раз
  • «затык» по ресурсам
    и уже не хватает выделенных вычислительных мощностей CPU, постоянно прокачиваются гигабайты памяти или диск не успевает за всеми «хотелками» БД
  • блокировки от конкурирующих процессов

И если блокировки достаточно сложны в поимке и анализе, то для всего остального нам достаточно плана запроса, который можно получить с помощью оператора EXPLAIN (лучше, конечно, сразу EXPLAIN (ANALYZE, BUFFERS) ...) или модуля auto_explain.

Но, как сказано в той же документации,

«Понимание плана — это искусство, и чтобы овладеть им, нужен определённый опыт, …»

Но можно обойтись и без него, если воспользоваться подходящим инструментом!
Читать полностью »

image

Небольшая заметка о встраиваемой key-value БД под названием Coffer, написанной на Golang. Если совсем коротко: в остановленном состоянии БД данные лежат на диске, при запуске данные копируются в память. Чтение происходит из памяти. При записи изменяются данные памяти, а изменения записываются в журнал на диск. Максимальный размер хранимых данных ограничен размером оперативной памяти. API позволяет создавать хидеры для записей БД и применять их в транзакциях, сохраняя при этом консистентность данных.
Читать полностью »

«Покрывающий индекс» не просто еще одна фича, которая может пригодиться. Это вещь сугубо практичная. Без них Index Only Scan может не дать выигрыша. Хотя и покрывающий индекс в разных ситуациях эффективен по-разному.

Речь здесь будет не совсем о покрывающих индексах: строго говоря, в Postgres появились так называемые инклюзивные индексы. Но, по-порядку: покрывающий индекс — это индекс, который содержит все значения столбцов, необходимые запросу; при этом обращение к самой таблице уже не требуется. Почти. О «почти» и других нюансах можно прочитать в статье Егора Рогова, входящей в его индексный сериал из 10 (!) частей. А инклюзивный индекс создается специально для поиска по типичным запросам: к поисковому индексу добавляются значения полей, по которым искать нельзя, они нужны только для того, чтобы не обращаться лишний раз к таблице. Такие индексы формируются с ключевым словом INCLUDE.

Анастасия Лубенникова (Postgres Professional) доработала метод btree так, чтобы в индекс можно было включать дополнительные столбцы. Этот патч вошел в версию PostgreSQL 11. Но патчи для методов доступа GiST/SP-GiST не успели созреть до выхода этой версии. К 12-й GiST дозрел.
Читать полностью »

Описание общей потребности в поиске данных и объектов в базе данных

Поиск данных, а также хранимых процедур, таблиц и других объектов в базе данных является достаточно актуальным вопросом в том числе и для C#-разработчиков, а также и для .NET-разработки в целом.

Достаточно часто может возникнуть ситуация, при которой нужно найти:

  1. объект базы данных (таблицу, представление, хранимую процедуру, функцию и т д)
  2. данные (значение и в какой таблице располагается)
  3. фрагмент кода в определениях объектов базы данных

Существует множество готовых решений как платных, так и бесплатных.
Сначала рассмотрим как можно осуществлять поиск данных и объектов в базе данных с помощью встроенных средств самой СУБД, а затем рассмотрим как это сделать с помощью бесплатной утилиты dbForge Search.
Читать полностью »

TL; DR: JSONB может значительно упростить разработку схемы БД без ущерба производительности в запросах.

Введение

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

Самый простой путь решения этой проблемы – это создание столбца в таблице БД для каждого значение свойства, и просто заполнять те, которые нужны для определенного экземпляра сущности. Отлично! Проблема решена… до того момента, пока ваша таблица не содержит миллионы записей и у вас не возникнет необходимость добавить новую запись.

Рассмотрим паттерн EAV (Entity-Attribute-Value), он встречается достаточно часто. Одна таблица содержит сущности (записи), другая таблица содержит имена свойств (атрибутов), а третья таблица связывает сущности с их атрибутами и содержит значение этих атрибутов для текущей сущности. Это дает вам возможность иметь разные наборы свойств для разных объектов, а также добавлять свойства “на лету”, не изменяя структуры БД.

Читать полностью »

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

Мы решили сделать свой фреймворк, с C++17 и корутинами. Вот так теперь выглядит типичный код микросервиса:

Response View::Handle(Request&& request, const Dependencies& dependencies) {
  auto cluster = dependencies.pg->GetCluster();
  auto trx = cluster->Begin(storages::postgres::ClusterHostType::kMaster);

  const char* statement = "SELECT ok, baz FROM some WHERE id = $1 LIMIT 1";
  auto row = psql::Execute(trx, statement, request.id)[0];
  if (!row['ok'].As<bool>()) {
    LOG_DEBUG() << request.id << " is not OK of " << GetSomeInfoFromDb();
    return Response400();
  }

  psql::Execute(trx, queries::kUpdateRules, request.foo, request.bar);
  trx.Commit();

  return Response200{row['baz'].As<std::string>()};
}

А вот почему это крайне эффективно и быстро — мы расскажем под катом.
Читать полностью »


https://ajax.googleapis.com/ajax/libs/jquery/3.4.1/jquery.min.js