Базы данных *

ScyllaDB — это высокопроизводительная распределённая NoSQL-база данных, совместимая с Apache Cassandra, но в разы более быстрая за счет того, что написана на C++. Однако, несмотря на сверхбыструю скорость работы, можно ли сделать ее еще быстрее?

В современных компаниях корпоративные хранилища данных (Data Warehouse) играют критически важную роль, обеспечивая централизованное хранение и обработку больших объёмов информации. Данные поступают из разнообразных источников: операционных систем, CRM, ERP, IoT-устройств, веб-аналитики, мобильных приложений и других платформ, отражая все аспекты деятельности организации. На основе этой информации компании формируют разного рода отчётность, отслеживают ключевые показатели эффективности (KPI), оптимизируют бизнес-процессы, прогнозируют рыночные тенденции и принимают стратегические решения.

Эффективная работа с хранилищем невозможна без участия бизнес- и системных аналитиков, которые проектируют структуры данных, очищают и объединяют информацию, адаптируя решения под меняющиеся задачи. С ростом объёмов данных и требований к скорости анализа даже опытные команды сталкиваются с вызовами. Рутинные операции — проектирование схем, поиск таблиц, проверка качества данных — требуют не только технических навыков, но и глубокого понимания бизнес-контекста. Большую часть времени занимает написание и оптимизация SQL-запросов, что становится «узким местом» в условиях динамично меняющихся требований.

Ошибки в SQL-запросах или недостаточное знание структуры данных приводит к потерям времени и снижению точности аналитики. Для решения этих проблем на помощь приходят технологии на основе больших языковых моделей (LLM), таких как GigaChat, GPT, BERT или DeepSeek. Обученные на исторических данных и журналах запросов, они способны автоматизировать подбор таблиц, JOIN-условий и шаблонов SQL. 

Привет, Хабр!

Один параметр PostgreSQL может похоронить вашу производительность, если вы о нём забудете — это fillfactor. Почему однократная настройка числа приводит к неожиданным page split, bloat и мучительному откату запросов? Давайте разбираться.

Для анализа и обработки больших объёмов данных применяются специальные системы — OLAP (Online Analytical Processing). Мы разберём основные принципы их работы, преимущества и примеры использования.

Определение OLAP-систем

OLAP-системы — это инструменты для анализа данных, которые позволяют быстро и эффективно находить ответы на сложные вопросы. 

Они находят применение в разных сферах, таких как финансы, производство, розничная торговля и другие.

Пример использования OLAP-технологии

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

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

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

В российских источниках не так много полезной информации по ArangoDB, и наша задача — исправить это недоразумение. Разберем главные нюансы работы с этой системой БД в разработке и тестировании, вспомним ее плюсы, минусы и потенциальные баги. Текст будет полезен как инженерам любых грейдов, которые связаны с работой над базами данных (сил вам...), так и классическим разработчикам продуктов.

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

А началось всё просто: пока все вокруг спорят как настраивать железо и тюнить операционные системы дабы выжать лишних TPS, мы решили проверить как отреагирует движок PostgreSQL если загрузить в него действительно большой объём данных. Например, давайте сделаем базу размером один петабайт и посмотрим как он это переживёт.

На дворе было 10 декабря, руководство поставило задачу сдать отчёт 20 января, до нового года оставалось меньше месяца, а в руках появился знакомый всем инженерам зуд.

Как я поднял базу знаний за 15 минут — без бюджета и опыта

Почему я выбрал именно BookStack

Мы в команде давно искали удобный инструмент для хранения технической документации и инструкций. Пробовали всё подряд — от Wiki.js до Confluence. Но то санкции, то интерфейс перегружен, то кастомизация страдает. В какой-то момент я наткнулся на BookStack — лёгкую, симпатичную open-source платформу на Laravel. Решил попробовать. В итоге — развернул, настроил, и теперь она у нас в проде.

Шардирование, двухфазный коммит и распределенные транзакции окружены определенными мифами и заблуждениями. Например, может быть достаточно неочевидно, что двухфазный коммит обеспечивает только атомарность транзакций, но не их изоляцию. Поэтому мы решили написать пост, который бы помог разобраться в этих сложных вещах и сделать правильный выбор, когда Postgres'а Вам станет мало и Вы столкнётесь с шардированием.

Привет, меня зовут Костя Осипов, и я занимаюсь разработкой СУБД. На Хабре есть несколько моих статей про MySQL, Tarantool и про всякое-разное. Кроме того, я веду Telegram-канал, где делюсь инсайтами в области управления базами данных. Сегодня я выступаю в роли основателя компании Picodata, создающей одноимённую открытую СУБД, и управляющего директора ПАО Arenadata по исследованиям и разработке. Ниже — вольный пересказ моего недавнего доклада на HighLoad. Он про то, что нас ждёт в мире СУБД завтра, и, в частности, про место резидентных СУБД в архитектурах будущего.

На Reddit я наткнулся на статью про обработку создания 100 тысяч коротких URL в секунду¹. [Прим. пер.: автор статьи по ссылке создал три варианта системы; третий, наилучший, по его мнению, вариант при помощи кластера-координатора делит нагрузку на несколько ECS-воркеров, использует DynamoDB TransactWrite для пакетных условных вставок, а для устойчивости применяет кэш Redis.]

Какой же это запутанный оверинжиниренный бардак!

Не поймите меня неправильно: я люблю оверинжиниринг, но только в обучающих хобби-проектах. Как сказали многие комментаторы на Reddit, в образовательных учреждениях редко преподают распределённые системы и архитектуру ПО. Когда новички попадают в нашу отрасль, из-за подобных постов, написанных авторитетными на вид техлидами, они могут подумать, что оверинжиниринг — это единственный способ работы. Однако часто решение может быть гораздо проще.

Вопрос "какая репликация MySQL лучшая?" звучит часто. Ответ, как водится в сложных системах, – "зависит от ситуации". Нет универсального решения. Выбор оптимального метода репликации всегда компромисс. Приходится искать золотую середину между тем, насколько данные должны быть одинаковыми везде, скоростью работы, бесперебойностью и тем, насколько сложно все это настроить. Посмотрим внимательнее на главные способы. Это поможет сделать осознанный выбор.

Всем привет! Меня зовут Диана Бутько, я студентка 3 курса, изучаю информационные системы и программирование. В InfoWatch я пришла на практику, и одной из моих задач стал сравнительный анализ различных методов поиска похожих векторов. Это один из ключевых аспектов машинного обучения и анализа данных, используемых в рекомендательных системах, кластеризации, семантическом поиске и других областях. Но чем больше объем данных, тем важнее становится выбор инструментов: полный перебор векторов требует больших вычислительных ресурсов, а в других алгоритмах порой необходимо балансировать между точностью и скоростью поиска.

В этой статье я сравниваю пять методов поиска похожих векторов:
— полный перебор по евклидову расстоянию с реализацией в Python;
— FAISS с индексами IndexFlatL2 (полный перебор, евклидово расстояние) и IndexIVFFlat (сегментирование по ячейкам, евклидово расстояние);
— векторный поиск в ClickHouse с индексом HNSW и метриками расстояния L2Distance (евклидово расстояние) и cosineDistance (косинусное сходство).

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

Далее представлен перевод статьи “5 things to look for in a database monitoring tool”, который подготовил специалист «Автомакон» специально для русскоязычной аудитории. Исходная публикация посвящена ключевым критериям подбора оптимального инструмента для мониторинга баз данных крупными организациями, столкнувшимися с необходимостью обработки больших объёмов данных и увеличения сложности информационных систем.

Современная разработка ПО – это почти всегда про распределенные системы. Микросервисы, облака, глобальный охват – все это стало нормой. Но за красивыми диаграммами и модными словами скрывается фундаментальная сложность. Как заставить кучу разрозненных компонентов работать вместе надежно? Как гарантировать, что данные, размазанные по сети, останутся корректными и доступными? Эта головная боль знакома любому, кто проектировал системы сложнее калькулятора, будь то в требовательном финтехе, динамичном e-commerce или где-либо еще.

И вот тут на помощь (или, скорее, для обозначения поля боя) приходят три понятия: ACID, BASE и теорема CAP. Может показаться, что это сухая теория, но игнорировать их – все равно что выходить в море без компаса и карты. Эти концепции описывают фундаментальные компромиссы, с которыми приходится иметь дело каждому архитектору. Понимание их – не гарантия успеха, но его необходимое условие. Давайте погрузимся в их суть и посмотрим, как они влияют на реальные архитектурные решения.

Меня зовут Олег, и в Яндексе мы с командой занимаемся Python-обвязкой вокруг нашей базы данных YDB. Python знаменит «батарейками в комплекте», широким ассортиментом библиотек на все случаи жизни, включая богатую экосистему для работы с базами данных. Есть свой интерфейс DBAPI (PEP-249), несколько конкурирующих ORM и многочисленные уровни абстракции между софтом и базами. В этой статье — о том, как мы делали полноценную интеграцию нашей базы данных с Apache Superset: чтобы достаточно было выбрать YDB из выпадающего меню и начать визуализировать аналитические данные.

Tarantool Proxy — «умный посредник», который делает работу с кластером Tarantool надежнее, быстрее и проще, беря на себя рутинные задачи вроде балансировки и безопасности. Но изначально Tarantool Proxy был написан на Lua, из-за чего для получения всех профитов от работы с ним нужна была специфическая экспертиза и готовность мириться с некоторыми сопутствующими издержками, что подходило не всем. Поэтому мы решили оптимизировать работу с Tarantool и использовали для этого толстый клиент на Go.

Меня зовут Максим Коновалов, я архитектор Tarantool в VK Tech. В этой статье я расскажу, зачем и как мы уходили от Lua и что получили в итоге.

Каждый, кто работает с PostgreSQL, знает его символ — синего слона. Но задумывались ли вы, откуда он взялся? Его история — это не результат работы дорогого брендингового агентства, а захватывающее повествование о зарождении IT-сообщества, питерских энтузиастах, случайных файлах и том, как «маленький презент» стал мировым символом.

Привет, Хабр! Последние несколько лет я занимаюсь разработкой баз данных ВКонтакте. Аудитория такой крупной соцсети ежедневно генерирует огромные массивы информации. 

В этой статье я расскажу про хранилище ВКонтакте: как оно менялось, что мы делаем для оптимизации занятого места и как гарантируем сохранность данных.

Supabase с оценкой в $2 млрд стремительно становится технологическим фундаментом современного вайб-кодинга. Почему разработчики массово переходят на этот бэкенд с открытым исходным кодом, и как PostgreSQL-решение превратилось в незаменимый инструмент для AI-приложений, используемый в 29% стартапов последнего набора Y Combinator? История компании, чья ценность оказалась настолько высокой, что инвестор пролетел 17 часов до отдалённого уголка Новой Зеландии для встречи с её основателем.