Мониторинг PostgreSQL. Необходимость в информативных счётчиках ресурсов и трассировки

В данной статье хочу поднять тему, которая представляет собой одну большую боль для администраторов, разработчиков и тестировщиков высоконагруженных (и не очень) систем под управлением PostgreSQL. Даже не «боль», а «БОЛЬ»!

Удивительно, что за почти 30 лет существования PostgreSQL не появилось нормальных инструментов для получения вменяемых счетчиков и трассировок. Все, кто работают с MS SQL Server используют профайлер. Это обязательный и привычный инструмент, который позволяет вылавливать запросы, интересные нам в рамках исследования. Вылавливать как все запросы без разбора, так и какие-то единичные запросы, которые удовлетворяют правилам отбора. Кроме того, можно настроить не одну трассу, а столько сколько нужно, с разными фильтрами. Эти трассы содержат очень богатый набор измерений для анализа: – Reads физические и логические; Writes; SPID, Процессорное время; план запроса (хэш плана), количество строк и т.д.

Многие компании стали всерьез рассматривать СУБД PostgreSQL как замену MSSQL и сталкиваются с тем, что возможностей для ее мониторинга просто нет – она как черный ящик, в котором наощупь вылавливаешь какую-ту информацию и пытаешься систематизировать ее хоть как-то.


Читать: https://habr.com/ru/companies/softpoint/articles/747322/

Real-Time Energy Monitoring for Smart Buildings with MongoDB and HiveMQ

Read: https://www.mongodb.com/blog/post/real-time-energy-monitoring-smart-buildings-mongodb-hivemq

Breaking News from MongoDB.local NYC

Read: https://www.mongodb.com/blog/post/breaking-news-mongodb-local-nyc

Boosting Developer Productivity with MongoDB Compass Settings

Read: https://www.mongodb.com/blog/post/boosting-developer-productivity-compass-settings

Lleva al siguiente nivel tu estrategia de fijación de precios con MongoDB y Databricks

Read: https://www.mongodb.com/blog/post/fueling-pricing-strategies-mongodb-databricks-esp

July edition of newsletter for Autonomous Database Serverless

We are continually adding new features to Autonomous Database Serverless. Over the LAST 12 MONTHS, over 200 NEW FEATURES have been added, and the latest updates include the following:

Read: https://blogs.oracle.com/datawarehousing/post/july-edition-of-newsletter-for-autonomous-database-serverless

Архитектура аналитической платформы Modus BI: ETL

Начинаем цикл статей об архитектуре аналитических платформ. Поговорим об общем устройстве и подробнее остановимся на анатомии ETL на примере Modus. Вы узнаете, из каких компонентов состоит аналитическая система, откуда она получает и как работает с данными, и что мы в Modus делаем такого, чтобы оптимизировать эти процессы.


Читать: https://habr.com/ru/companies/modusbi/articles/747866/

Переоткрывая хэш-индексы в PostgreSQL

Если вы работает с базами данных, то, скорее всего, знакомы с B-tree индексами. У них множество применений и они являются дефолтными типа индекса в большинстве движков баз данных. Если вы работаете с полнотекстовым поиском или пространственными данными, то скорее всего вы знакомы еще и с GIN и GIST индексами. Если вы работаете с массивными временными рядами, то слышали еще и о BRIN индексах.

Однако, есть еще один менее популярный тип, о котором большинство даже ничего не слышало. Пару версий PostgreSQL назад он был не то что даже непопулярен, но и строго не рекомендован к использованию. Однако в некоторых случаях он может обойти даже B-tree в плане производительности.

Сейчас мы переоткроем хэш-индекс!


Читать: https://habr.com/ru/articles/747910/

Highload-приложения: технологии для обработки больших объемов данных и запросов

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

Читать: «Highload-приложения: технологии для обработки больших объемов данных и запросов»

Переезд c PostgreSQL на YDB. Кейс сервиса Яндекс Игры

Привет! Меня зовут Александр Смолин. Я бэкенд-разработчик в команде Яндекс Игр. Уже два года мы используем YDB для задач сервиса. В статье расскажу, как мы в Яндекс Играх внедряли YDB, зачем это было нужно, с какими сложностями столкнулись и какие результаты у нас сейчас.


Читать: https://habr.com/ru/companies/yandex_cloud_and_infra/articles/747998/

Ping пакеты как временное хранилище данных на python raw socket

Payload (данные) в ping пакете действительно есть, однако до реальной пользы им далеко - это английский алфавит (нет, я не испытываю ненависть к латинице, просто мне хотелось бы уметь редактировать это содержимое).


Читать: https://habr.com/ru/articles/748230/

Lock-free reservation in 23c: how to start with

This blog posting illustrates the basice of lock-free reservations in 23c

Read: https://blogs.oracle.com/coretec/post/lock-free-reservation-in-23c

Tata Digital Harmonizes a Variety of Data, Powered by MongoDB Atlas

Read: https://www.mongodb.com/blog/post/tata-digital-harmonizes-variety-data-powered-mongodb-atlas

Oracle DatabaseWorld at CloudWorld 2023

Announcing Oracle DatabaseWorld at CloudWorld 2023 - the place for DatabaseWorld fans to get up-to-speed with the latest Oracle database technology and try it hands on.

Read: https://blogs.oracle.com/database/post/oracle-databaseworld-at-oracle-cloudworld-2023

A Peek Under the Hood of Distributed SQL Engines

Read: https://mariadb.com/?p=37006

Amplifying Retail Operations with Generative AI and Vector Search: The Unexplored Potential

Read: https://www.mongodb.com/blog/post/amplifying-retail-operations-generative-ai-vector-search

KeyDB и Redis: в поисках серебряной пули — in-memory replicated DB (Replicated IMDB)

На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.

В то же время, если мы хотим использовать отказоустойчивые решениями вроде Sentinel и Cluster, нам понадобится поддержка этих технологий на уровне библиотеки, которую приложение использует для подключения в Redis. Причем лишь немногие библиотеки умеют читать из реплик Redis — в обоих вариантах (Sentinel и Cluster) чтение, как правило, происходит с мастеров. И запись, естественно, тоже происходит в мастеры.

В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.

Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется.

Звучит как фантастика?


Читать: https://habr.com/ru/companies/flant/articles/747760/

Как мы снизили нагрузку на SAP HANA незаметно для пользователей

Объем информации в корпоративном хранилище данных (КХД) со временем неизбежно начинает превышать запланированные изначально мощности. Обычно эта проблема решается тем, что докупаются недостающие мощности (будет дорого). Когда с такой ситуацией столкнулся наш клиент, мы предложили ему другое решение. Оно позволило сэкономить бюджеты и сделать переходный период максимально безболезненным.

Читайте, что именно мы сделали и какой был результат.


Читать: https://habr.com/ru/companies/sapiens_solutions/articles/747142/

Алгоритм быстрого поиска при помощи хэширования

В этой статье я хочу представить мой алгоритм оптимизации суммирования ряда чисел в массиве (на примере контейнера map).

Итак, дано задание
Есть некая электронная книга, которую одновременно читает неограниченное количество читателей. Нужно сделать так, чтобы любой читатель в любой момент мог проверить, сколько еще читателей читают ту же страницу, что и он. Предложена наивное решение хранить в map<int,int в качестве ключа номера страниц, в качестве значения- количество прочитавших их пользователей. Конечно, при таком подходе программа медленно работает с большими тестами потому, что количество итераций по контейнеру map равняется числу прочитанных пользователем страниц. То есть, если пользователь прочел 1000 страниц из 1000 возможных, то в цикле нужно будет сделать 1000 итераций, и это сильно замедляет программу.
Чтобы уменьшить время работы программы, нужно упростить алгоритм подсчета пользователей. В этом алгоритме я отдельно считаю, сколько пользователей прочли столько же полных сотен страниц, как и искомый читатель, и затем уже постранично суммирую всех, кто прочел столько же страниц из той сотни, на которой сейчас находится читатель. Такой алгоритм позволяет вместо 999 итераций (если пользователь читает 999-ю страницу) сделать всего 108 (9 итераций сотням и 99 по единичным страницам).

Это вкратце, теперь перейдем к подробному описанию и для начала приведу код.
больше информации

Читать: https://habr.com/ru/articles/749600/

Amplificando las Operaciones de Retail con IA Generativa y Búsqueda Vectorial: El Potencial Inexplorado

Read: https://www.mongodb.com/blog/post/amplifying-retail-operations-generative-ai-vector-search-esp