Базы данных *

Что такое электронная таблица, объяснять не надо. Все знают Excel, и многие хоть раз им пользовались. История создания электронных таблиц тоже, на первый взгляд, незамысловатая и сравнительно недолгая: как только появились первые ПК, сразу началась разработка ПО для выведения на экран их монитора интерактивной таблицы, которая сильно облегчила бы работу бухгалтеров и менеджеров. IT-инженеры уложились в 15 лет, с конца 60-х до середины 80-х, чтобы создать электронную таблицу от начала и до конца – от разработки самого принципа ее программирования до появления первых электронных таблиц (от VisiCalc до Excel) на экране ПК, сильно порадовав тем самым белых воротничков (и не только их). Дальше шло лишь усовершенствование электронных таблиц.

С чего вдруг IT-инженеры и изобретатели озаботились бухгалтерскими проблемами, тоже понятно. Люди старшего поколения помнят, что можно было делать на первых ПК 70-х и 80-х годов, еще до эпохи интернета. Если оставить в стороне возможность самостоятельно заняться программированием и обмениваться файлами с такими же энтузиастами, что сейчас часто ставят в заслугу первым ПК (для этого все-таки надо было в душе быть айтишником), то на этих ПК можно было играть в интерактивные игры (правда, на игровых приставках к телевизору это обходилось дешевле) и можно было использовать ПК как пишущую машинку, при пользовании которой не надо было замазывать белилами ошибки и ждать, когда те высохнут, чтобы напечатать поверх правильную букву. Сказать, что это сильно порадовало писателей и редакторов бумажных СМИ значит ничего не сказать, это была настоящая революция в писательском и издательском деле, сравнимая разве что с изобретением печатного станка Гутенбергом в XV веке. А когда к этому добавились еще электронные таблицы для сведения дебета с кредетом в интерактивном режиме, это была еще одна революция в бухгалтерии того же масштаба, если не большего.

Привет, Хабр! Меня зовут Роман Ананьев из команды DBA в Авито. В этой статье я расскажу о поиске альтернативы для многошардовых инсталляций MongoDB. Основная цель исследования — найти базу данных с поддержкой автошардирования, которая упростит эксплуатацию и лучше утилизирует ресурсы.

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

Это текст не про то, что MongoDB плохая, она — прекрасный стандарт рынка, в топ-5 движков БД. Я расскажу про то, что происходит, когда у стандартной технологии заканчивается запас прочности на нужном масштабе, и про то, как мы в Авито перебрали множество NoSQL и NewSQL кандидатов, чтобы найти одного подходящего.

В статье я разберу результаты технического исследования, проведённого командой DBA. Мы сравнили производительность, утилизацию ресурсов и архитектурные грабли Cassandra 5, FoundationDB и других БД. Также объясню, почему погоня за низкой latency в случае с FDB обернулась трёхкратным перерасходом дискового пространства.

Когда речь заходит про Lakehouse и федеративный доступ, многие вспоминают про Trino и… часто на этом все. Но федеративные запросы поддерживаются в том или ином виде довольно большим количеством СУБД, SQL-движков и систем для виртуализации данных.

В этой статье постараемся немного расширить кругозор читателей, которым интересна данная тема: рассмотрим федеративные запросы на примере набирающего популярность и активно развивающегося StarRocks. Из статьи вы узнаете: что такое федеративные запросы, как обстоят дела с реализацией гетерогенного федеративного доступа в этой СУБД и какие изменения команда решения Data Ocean Nova реализовала для оптимизации в StarRocks и Impala с целью улучшения функционала доступа к внешним данным.

Утечка данных почти никогда не выглядит как взлом — чаще это тихий SELECT без LIMIT от роли, у которой и так есть доступ. Заметить такое штатными средствами PostgreSQL почти невозможно: аудита как отдельной подсистемы там нет, а есть лишь разрозненные логи, из которых расследование превращается в quest с grep. В этой статье — как с помощью pg_proaudit и pgpro-otel-collector превратить эту головную боль в один запрос на LogsQL.

Ряд аналитиков середины 2010-х отмечали, что язык SQL — один из самых важных и нужных для программистов. Ведь он распространен максимально широко: им пользуется бизнес, государственные учреждения, вузы, финансовые структуры и так далее. В нашей статье — о том, как этот язык появился и какие патенты на него были получены.

Полгода назад я начал писать in-memory базу с векторным поиском на Go: RESP-протокол, HNSW-индекс, WAL, многопоточность. Рассказываю, что из этого вышло: как я мерил производительность и на каких граблях стоял, что реально ускоряет векторный поиск, а что нет. Все цифры воспроизводимы, код открыт.

Redis долго был понятным выбором: BSD-лицензия, можно использовать почти где угодно. После смены лицензии в 2024 году всё стало сложнее: RSAL, SSPL, AGPLv3, Valkey, форки и вопросы к юристам.

В статье рассматриваю этот вопрос со стороны обычных продуктовых команд, а не облачных провайдеров. Если Redis у вас внутри как кеш, очередь или для сессий, что реально меняется, где начинаются риски и что сегодня разумнее выбрать - Redis 8, Valkey или другой Redis-compatible вариант.

Тест на List.AsQueryable() зелёный, а на проде всплывают LINQ-трансляция, null, collation, unique index и два воркера, забравшие один платёж. Разбираю, где in-memory тесты помогают, а где начинают врать.

Краткая история внешней памяти и пять функций листа бумаги

Не претендуя на гениальность задался простым, на первый взгляд, вопросом: "На моем столе в 2026г всегда лежит лист черновика и пара карандашей?" Ответ оказался не таким коротким, как ожидал. Приглашаю к прочтению!

8 июля у PostgreSQL юбилей — ей исполняется 30 лет. В 1996 году Марк Фурнье из компании Networking Services предоставил первый внешний сервер для разработки опенсорсного проекта Postgres. До этого СУБД разрабатывали на мощностях Калифорнийского университета в Беркли .

В день рожденья PostgreSQL мы публикуем перевод статьи, которая послужила основой СУБД. Кстати, у неё тоже юбилей — 40 лет с момента выхода.

«Отдельные базы больше не нужны», «конец пайплайнов» - каждую неделю кто-то крупный со сцены хоронит то, что ты вчера поставил в прод. ClickHouse поступил ровно наоборот, и поэтому его анонсы стоит прочитать внимательно. Что реально показали на Open House 2026 и что из этого доедет до прода - разбор практика без вендорского глянца.

Всем добрый день. В этой статье мы расскажем вам об июньских изменениях в Pro-функциональности GigaIDE, который можно найти на нашем маркетплейсе. Соответствующий обзор за май доступен по этой ссылке.

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

Сначала задача звучала просто: складывать PDF, CVE и статьи по кибербезопасности в одну базу, затем давать LLM-агенту подходящие фрагменты через HTTP API. На доске это помещалось в одну цепочку: загрузка, извлечение текста, разбиение на части, построение векторов, поиск.

Рабочий прототип появился быстро. Настоящая работа началась потом.

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

Рассмотрим пример с одной таблицей, имеющей один столбец с уникальным ограничением (и индексом):

Задача широко знакома в узких кругах: наш каталог товаров встречается с каталогом контрагента — по сути одни и те же позиции, но названы по-разному. Надо найти совпадения и предоставить коллегам список подходящих наших артикулов для каждой их позиции.

В разобранном ниже случае это картриджи: 22 тысячи записей у контрагента против сотен тысяч наших номенклатур. Для такой задачи матерый программист берёт Elasticsearch, алгоритмы нечёткого поиска и тратит много времени, иногда в меру матерясь. Здесь подбор ведется с помощью токенизации, запросами в стиле no-code и без ИИ.

На старте поисковая система часто устроена просто: одна таблица на одном сервере. Это работает, пока не случится одно из двух. Либо отдельный запрос перестаёт задействовать весь CPU, за который вы заплатили, либо одного сервера перестаёт хватать — по объёму, по пропускной способности или просто потому, что сервер может выйти из строя, и данные на нём будут потеряны.

Автоматический шардинг, встроенный в Manticore Search и доступный начиная с релиза 27.1.5 , решает обе проблемы, разбивая таблицу на несколько физических фрагментов меньшего размера (шардов), по которым можно выполнять поиск параллельно и которые можно размещать на разных узлах:

Раньше построение KNN-индекса было самым медленным этапом при сохранении и слиянии чанков в таблицах с векторными атрибутами. Начиная с v27.1.5 , Manticore может задействовать несколько ядер CPU при сохранении чанков, слияниях через OPTIMIZE, авто-оптимизации и ALTER TABLE ... REBUILD KNN. На 16-ядерном Ryzen 9 5950X построение KNN-индекса для 1 миллиона 1536-мерных векторов сократилось с 8 минут до 39 секунд.

Фонд Национальной технологической инициативы реализует проект технологических конкурсов Up Great — открытых соревнований для инженерных команд. Здесь преодолевают технологические барьеры России и мира, чтобы решать задачи, с которыми ещё никто не справлялся.

Один из текущих конкурсов — «Экспедиция. Data Science» с технологическим партнёром Phystech.Genesis, который предоставляет платформу и маркетинг события. В конкурсе участники работают над системами ИИ по распознаванию археологических объектов на поверхности земли и глубине до 5 метров. Пока такую работу археологи делают вручную, что требует много времени и специалистов. Конкурс призван ускорить процесс и исключить человеческие ошибки, чтобы дать исторической науке новые возможности, а учёным — время на экспедиции и раскопки.

В рамках «Экспедиция. Data Science» — 3 конкурса отдельных заданий (КОЗ), а также финальный конкурс. С каждым следующим этапом команды берутся за более сложные задачи и пробуют новые подходы. Недавно организаторы объявили победителей второго из них — «Сканирование». На этом этапе команды создавали нейросети, чтобы искать археологические объекты в рельефе и под поверхностью земли.

В этой статье мы собрали заключения технических экспертов, комментарии профессионального археолога, а также поговорили с тройкой лидеров и одним из ведущих российских учёных по Data Science. Мы хотим рассказать вам, как технология и наука вместе развивают знание людей о мире в нашей стране.

Компания Postgres Professional представляет новое издание книги Егора Рогова «PostgreSQL 18 изнутри», которое будет выпущено в издательстве «ДМК Пресс» в 2026 году. Электронная версия доступна уже сейчас. Эта книга — подробный путеводитель по внутреннему устройству СУБД PostgreSQL, призванный помочь разработчикам и администраторам детально разобраться в механизмах её работы.