Разработчик баз данных
От редакции: Майкл Стоунбрейкер - один из самых известных в IT мире ученых и отец-основатель Postgres. В соавторстве с Энрю Павло, недавно опубликовал большой обзор всех актуальных технологий систем управления базами данных. В этом материале — подробно обо всем, что произошло в мире баз данных за последнее время, а также прогнозы. Мы посчитали что нельзя лишать нашу аудиторию возможности ознакомиться с этим обзором, поэтому подготовили данный перевод.
Смотрим, как вездесущий PostgreSQL справляется с нестандартными для реляционной системы управления базами данных (СУБД) ролями: хранением и поиском временных рядов, пар «ключ — значение», эмбеддингов для больших языковых моделей и многомерных кубов. Отвечаем на вопрос: действительно ли так нужно строить сложные архитектуры со множеством разнородных систем хранения данных — MongoDB, Redis, InfluxDB, Pinecone, ClickHouse, Apache Cassandra — или можно обойтись одним PostgreSQL?
Привет, Хабр! Меня зовут Александр Брейман, я доцент департамента программной инженерии факультета компьютерных наук НИУ ВШЭ и по совместительству эксперт Учебного центра IBS по управлению данными и архитектуре ПО. В прошлой статье я рассказывал о миграции с Oracle на PostgreSQL, а сегодня разберу, как последний работает с нетипичными видами данных.
В минувшем году все только и говорили об ИИ и о том, как он может всё за вас сделать.
Мне нравится, когда кто-то или что-то работает за меня. Поэтому решил: попрошу-ка ChatGPT написать за меня новогодний пост:
«Эй, ChatGPT. А ты можешь реализовать большую языковую модель на SQL?»
«Нет, SQL не подходит для реализации больших языковых моделей. Язык SQL предназначен для выполнения запросов к данным, хранящимся в РСУБД и для управления этими запросами. Для реализации большой языковой модели требуются сложные алгоритмы, обширные датасеты, а зачастую — и фреймворки для глубокого обучения. SQL всеми этими возможностями не обладает.»
Что ж, лишний раз убеждаешься, что, если хочешь что‑то сделать хорошо – сделай это сам.
Давайте же воодушевимся этим оптимистическим планом и реализуем большую языковую модель на языке SQL.
Привет, Хабр!
PostgreSQL, одна из самых мощных и гибких реляционных СУБД, предлагает нам свой модуль pg_trgm, чтобы решить сложную задачу полнотекстового поиска.
Когда речь идет о поиске, просто LIKE запросы больше не всегда могут удовлетворить технические требования. Полнотекстовый поиск подразумевает не только поиск точных соответствий, но и учет схожести слов, учет морфологии, а также поддержку более сложных запросов. PostgreSQL, конечно, предоставляет средства для выполнения таких задач, и модуль pg_trgm - один из инструментов, с помощью которого это можно сделать.
Итак, что такое pg_trgm? Этот модуль PostgreSQL предоставляет набор функций и операторов, которые позволяют работать с трехграммами (триграммами) - это последовательности из трех символов. Для понимания, давайте взглянем на пример...
1 сентября 2021 года ФНС перестала обновлять свой адресный справочник в формате ФИАС. Относительно новый ГАР внезапно стал единственным государственным адресный реестром, доступным общественности. Рассказываем, что из себя представляет новый справочник и чем он отличается от ФИАС.
В этой статье подробно разбирается алгоритм обучения архитектуры CBOW (Continuous Bag of Words), которая появилась в 2013 году и дала сильный толчок в решении задачи векторного представления слов, т.к. в первый раз на практике использовался подход на основе нейронных сетей. Архитектура CBOW не столь требовательна к наличию GPU и вполне может обучаться на ЦП (хотя и более медленно). Большие готовые модели, обученные на википедии или новостных сводках, вполне могут работать на 4-х ядерном процессоре, показывая приемлемое время отклика.
При разработке чат-ботов и голосовых ассистентов часто возникает задача нахождения семантического сходства слов. Причина тому – наличие в языке большого количества схожих по смыслу слов и выражений.
Маленький совет из будущего: «В данной статье будут затронуты некоторые понятия, о которых я писал раньше, так что для полного понимания темы, советую прочитать и предыдущую статью»На самом деле, на хабре было множество публикаций по этой теме, но все они говорят о разных вещах. Давайте разберёмся и соберём всё в одну кучку, для полноценного понимания картины мира.
Что появилось первым: курица или яйцо?
Статистики давно уже нашли ответ на этот вопрос.
Причем несколько раз.
И каждый раз ответ был разным.
А если серьезно, то для машинного обучения становятся все более актуальными вопросы причинно-следственного анализа (causal inference) - когда главной целью моделирования является не прогноз и его качество, а то, как мы можем принимать решения на основе нашего алгоритма. И как это повлияет на мир, в котором эта модель будет действовать. Сделает ли модель его лучше, чем он был? Или наоборот.
Под катом я расскажу о причинно-следственном анализе, его ключевых методах и применении в машинном обучении. В следующей статье побеседуем о ключевых трендах в развитии методов причинно-следственного анализа в машинном обучении в 2020-2021 гг.
"Хочешь ускорить запросы, построй индекс" – классический первый шаг по увеличению производительности в PostgreSQL. Вот только на практике можно встретить ситуацию, когда индексы в PostgreSQL есть, но тормоза никуда не делись. Не все индексы являются эффективными. Одна из возможных причин тормозов индексов – это отсутствие корреляции данных. Давайте поговорим о пенальти на производительность, которое дает расположение данных: почему это происходит и как это можно предотвратить.
Статья о том, как реляционная СУБД может выполнить JOIN. Для лучшего понимания мы попробуем своими руками написать такую же реализацию на языке C#. Что позволит нам лучше вникнуть в детали.
А чтобы было не совсем скучно - мы зададимся вопросом производительности. Что работает быстрее C# или SQL? И хоть сам по себе вопрос не корректен, к этому пониманию мы как раз и придем.
postgres=# select amname from pg_am;
amname
--------
btree
hash
gist
gin
spgist
brin
(6 rows)
Привет, Хабр! Приглашаем на бесплатный Demo-урок «Параллельный кластер CockroachDB», который пройдёт в рамках курса «PostgreSQL». Также публикуем перевод статьи Тома Брауна — Principal Systems Engineer at EnterpriseDB.
В этой статье рассмотрим несколько полезных советов по работе с PostgreSQL: ссылка на всю строку целиком, сравнение нескольких столбцов, общие табличные выражения, пользовательские параметры конфигурации, сравнение логических значений без "равно", изменение типа столбца без лишних затрат, информация о секции, в которой находится строка, таблицы — это типы.