DATABASE DESIGN – Telegram
DATABASE DESIGN
1.41K subscribers
2.09K photos
3 videos
5.35K links
Лучшие материалы по работе с хранилищами данных на русском и английском языке

Разместить рекламу: @tproger_sales_bot

Правила общения: https://tprg.ru/rules

Другие каналы: @tproger_channels

Другие наши проекты: https://tprg.ru/media
Download Telegram
Прогрессивный JSON

Вы знаете, что такое прогрессивный JPEG? Можете почитать хорошее объяснение. Идея заключается в том, что вместо загрузки изображения сверху вниз оно сначала грузится размытым, а потом постепенно становится чётче.

Что, если мы применим тот же принцип к передаче JSON?


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

#ru

@database_design | Другие наши каналы
Адаптация в эпоху ИИ: всего 11% компаний внедрили ИИ в производство, главная задача — гибкая ИТ-инфраструктура. Опыт проверки MongoDB с TLA+ выявил сложности многопоточности, а тестирование Mobile SDK улучшило качество кода. Стартуп Luna AI масштабируется с помощью MongoDB Atlas.

Читать подробнее

#en

@database_design | Другие наши каналы
MariaDB Community Server 11.8 вышел в стабильной версии. Это новая долгосрочная поддержка с обновлёнными функциями, поступившими после версии 11.4. Подробности о возможностях и улучшениях доступны в официальном анонсе.

Читать подробнее

#en

@database_design | Другие наши каналы
Это личное! Как femtech-приложения защищают наши данные

Привет! Я Ангелина Сулерова, работаю аналитиком и с недавнего времени пишу тексты для первое русскоязычное медиа о технологиях в сфере женского здоровья

" data-abbr="FemTech Force ">FemTech Force . Это моя первая статья на Хабре, которая затронет одну из важных тем в сфере фемтех — безопасность данных.

Правда ли, что женские данные нужно хранить надёжнее, чем мужские? Что будет, если этого не делать? Какие фемтех-приложения уделяют особое внимание вопросам обеспечения безопасности? Обо всём этом расскажу в своем личном исследовании.

Неважно, новичок вы в этой области, просто интересующийся или активная пользовательница фемтех-продуктов — добро пожаловать под кат!

Кстати, рассказывать буду не только я. Специально для статьи взяла комментарий у Кати Меркуловой — основательницы крупнейшего российского трекера цикла Clatch. Так что забегайте за инсайдерской информацией.


Читать: https://habr.com/ru/companies/femtech_force/articles/915666/

#ru

@database_design | Другие наши каналы
Топ-7 самых тупых хакерских атак в истории

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

Читать: «Топ-7 самых тупых хакерских атак в истории»

#ru

@database_design | Другие наши каналы
Данные на продажу: что происходит с информацией после утечек

Новости о крупных утечках данных больше никого не удивляют. Компании вкладывают миллионы в безопасность, проводят аудиты, но число таких инцидентов продолжает расти. Только в 2024 году Роскомнадзор зафиксировал 135 утечек — это более 710 миллионов записей о россиянах в базах данных. Но что происходит с данными после взлома? Куда они утекают? Кто и как их покупает?

Большинство новостей на тему утечек ограничиваются банальным «взломали, утекло, делайте выводы». Но утечка данных — это не конец истории, а только ее начало. После взлома данные начинают жить своей жизнью: их разбивают на части, объединяют с другими базами, разыгрывают на аукционах. Теневой рынок, построенный вокруг сбыта таких данных, напоминает отдельную экосистему, которая до сих пор слабо изучена даже среди ИБ-специалистов.

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


Читать: https://habr.com/ru/companies/bastion/articles/915892/

#ru

@database_design | Другие наши каналы
🕊1
Пятый, юбилейный выпуск исследования «BI-круг Громова»

Пятый, юбилейный выпуск нашего исследования «Круги Громова» выходит в момент, когда рынок отечественных BI-платформ переживает волну бурного роста и трансформации. За два года, прошедшие с публикации предыдущего отчёта, импортозамещение перестало быть формальностью и стало стратегической необходимостью: доля внедрений российских BI-систем выросла почти в восемь раз, а зарубежных — упала до 23 %[1]. На этом фоне особенно важны объективные ориентиры, позволяющие ИТ-директорам и бизнес-пользователям выбрать платформу, которая останется актуальной на ближайшие несколько лет. Именно такую навигационную карту мы и предлагаем.


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

#ru

@database_design | Другие наши каналы
Что стоит знать перед тем, как стать архитектором решений? В статье на MongoDB Blog опытный специалист делится важными уроками: влияние строится на понимании клиентов, успех зависит от командной работы и умения слушать. Роль постоянно развивается, главное – быть готовым учиться и адаптироваться. Luna AI трансформировалась в продвинутую платформу для стратегического управления продуктами с глубокой интеграцией Jira и мощными AI-модулями. Основу системы составляет MongoDB Atlas, обеспечивающий гибкость, масштабируемость и безопасность данных.

Читать подробнее

#en

@database_design | Другие наши каналы
Как с помощью RuBackup сделать резервное копирование систем виртуализации oVirt, ROSA, zVirt, РЕД Виртуализация, HOSTVM

Привет всем, кто заботится о сохранности данных виртуальных машин (ВМ) и не хочет их потерять. Сегодня мы рассмотрим тему бэкапа ВМ на платформе виртуализации oVirt и oVirt-подобных: ROSA; zVirt, РЕД Виртуализация и HOSTVM. Далее в статье, когда будет идти речь о oVirt, подразумевается, что речь будет идти обо всех этих платформах.

Для этого будем использовать систему резервного копирования (СРК) RuBackup.


Читать: https://habr.com/ru/companies/astralinux/articles/916004/

#ru

@database_design | Другие наши каналы
1
Приоткрываем завесу: о принципах работы дисковых хранилищ VK Cloud

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

Привет, Хабр. Меня зовут Василий Степанов. Я руководитель команды разработки Storage в VK Cloud. В этой статье я расскажу о том, как устроено наше дисковое хранилище: какие диски используются в VK Cloud и как мы с ними работаем.


Читать: https://habr.com/ru/companies/vktech/articles/916036/

#ru

@database_design | Другие наши каналы
Нашел, проверил, убедил: как мы организовали генерацию SQL-запросов, проверку сложных данных и при чем здесь Allure

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

Я, Михаил Герасимов, инженер РСХБ-Интех. Уже два года занимаюсь автоматизацией тестирования, и за это время успел написать (и переписать) немало SQL-запросов. Вместе с моим коллегой Михаилом Палыгой мы развиваем инструменты для автоматизированного тестирования, и сегодня расскажем вам о том как мы справляемся с построением сложных SQL-запросов и проверкой объектов в базе данных, на примере нашей библиотеки CheckMateDB для автоматизации тестирования банковской системы ЦФТ-Банк.

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

Мы создали иерархию классов CriteriaBasic и Table для удобного описания критериев поиска данных в базе, используя паттерн fluent interface. Также мы разработали кастомные классы проверок на базе AssertJ с поддержкой Allure-шагов, которые позволяют проверять сложные многоуровневые объекты с возможностью погружения во вложенные структуры. Для облегчения рутинной работы создали плагин, автоматически генерирующий классы DTO и Table на основе структуры базы данных. Библиотека интегрирована с Hibernate через DaoCommon, что обеспечивает удобное выполнение SQL-запросов и управление сессиями. Результатом стало существенное улучшение читаемости тестов, повышение переиспользуемости кода, стандартизация подхода к тестированию и создание информативных Allure-отчетов.


Читать: https://habr.com/ru/companies/rshb/articles/916148/

#ru

@database_design | Другие наши каналы
Как разработать простое приложение и тратить на него 2000$ в месяц

Разработчик показывает, как из простого приложения сделать дорогостоящее — за счет трат на сервера, инфраструктуру и многое другое.

Читать: «Как разработать простое приложение и тратить на него 2000$ в месяц»

#ru

@database_design | Другие наши каналы
Внутристраничная очистка в индексах PostgreSQL

Внутристраничная очистка (HOT cleanup) – это оптимизация, благодаря которой старые версии строк могут эффективно удаляться из блоков таблиц. Освобождённое место используется под размещение новой версии строки. Освобождается только место, занимаемое версиями строк, вышедшими за горизонт базы данных (xmin horizon). В статье рассматривается алгоритм работы аналогичной оптимизации для индексов. Если горизонт удерживается, то ни внутристраничная очистка, ни вакуум не могут освободить место, и тогда новая версия строки вставляется в другой блок. Увидим на примере стандартного теста pgbench, как сильно может снижаться производительность при удержании горизонта базы данных (в случае когда есть сессия с долгим запросом или транзакцией) и разберемся в причинах снижения производительности.


Читать: https://habr.com/ru/companies/tantor/articles/916318/

#ru

@database_design | Другие наши каналы
Шардирование баз данных: проблемы, альтернативы, практические рекомендации

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


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

#ru

@database_design | Другие наши каналы
MySQL репликация: проблемы, решения, практические рекомендации

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


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

#ru

@database_design | Другие наши каналы
«Попал в Яндекс через опенсорс»: как коммиты в опенсорсные СУБД помогают развивать продукт и команду

Привет, Хабр! На связи Андрей Бородин, в Yandex Cloud я руковожу направлением разработки СУБД с открытым исходным кодом — и я попал в Яндекс через опенсорс. Я уже немного рассказывал, что и зачем мы делаем в опенсорсных БД с точки зрения облачных сервисов, где мы развиваем PostgreSQL, Greenplum, Cloudberry, Valkey и другие решения.

Но из этих историй часто ускользает человеческая сторона: мы занимаемся опенсорсом не только для того, чтобы сделать решения с открытым кодом более облачными, не только потому, что это модно, но и потому, что это приносит пользу не только продукту, но и самим разработчикам‑контрибьюторам.

На масштабах Яндекса возникают нетривиальные задачи, которые интересно решать. А когда мы делимся решениями с сообществом, то можем получить от них новый взгляд на проблему, и продолжить совместную разработку новой фичи в удобном формате: с кем‑то на условиях независимого сотрудничества, а кого‑то можем позвать в команду (как это было и со мной).

В общем, если придерживаться опенсорс‑философии, может возникнуть ситуация win‑win. Сегодня с коллегами Леонидом Борчуком @leborchuk и Дмитрием Сарафанниковым расскажу пару историй про то, как это бывает с опенсорсными СУБД.


Читать: https://habr.com/ru/companies/yandex/articles/916800/

#ru

@database_design | Другие наши каналы
Книга: «Масштабируемые данные. Высоконагруженные архитектуры, Data Mesh и Data Fabric. 2-е изд.»

Привет, Хаброжители!

Издательство Sprint book представляет второе издание книги Питхейна Стренгхольта «Масштабируемые данные» — фундаментальное руководство по построению современных архитектур данных в эпоху цифровой трансформации.

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


Читать: https://habr.com/ru/companies/piter/articles/905540/

#ru

@database_design | Другие наши каналы
Резервуарное сэмплирование и собачки

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

• Когда может потребоваться резервуарное сэмплирование.

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

• Простой способ реализации резервуарного сэмплирования на случай, если вам оно понадобится.


Читать: https://habr.com/ru/companies/ruvds/articles/916250/

#ru

@database_design | Другие наши каналы
Рекомендации Oracle по выбору между ArrayList и LinkedList

В Java существует две реализации интерфейса List: ArrayList и LinkedList. Какая из них лучше? Как выбрать подходящую для вашего приложения? В данной статье мы сравним их различия, производительность и потребление памяти, чтобы помочь вам определиться с выбором.


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

#ru

@database_design | Другие наши каналы
Новые возможности наблюдаемости ИИ с MongoDB и Langtrace
Langtrace AI совместно с MongoDB улучшает мониторинг и оптимизацию приложений на базе ИИ. Их интеграция обеспечивает глубокий анализ производительности моделей и эффективное управление данными, что повышает точность и масштабируемость решений. Путь архитектора решений в MongoDB: важнее технических знаний — понимание бизнес-задач и умение слушать клиента. Успех строится на эмпатии, командной работе и способности адаптироваться в быстро меняющемся мире технологий. Архитектура — это не просто схемы, а реальные решения для людей.

Читать подробнее

#en

@database_design | Другие наши каналы
Как мы снизили время создания бэкапов Git с 48 часов до 41 минут

В этой статье мы расскажем о том, как GitLab выявил и устранил «бутылочное горлышко» производительности в 15-летней функции Git, что повысило эффективность, обеспечив возможность применения более надёжных стратегий резервного копирования и снижения рисков.

Резервные копии репозиториев — важнейший компонент надёжной любой стратегии восстановления после сбоев. Однако с увеличением размеров репозиториев процесс создания надёжных бэкапов становится всё сложнее. Для резервного копирования нашего собственного репозитория Rails нам требовалось 48 часов. Это заставило нас искать невозможные компромиссы между частотой резервного копирования и производительностью системы. Мы хотели найти собственное внутреннее решение для наших клиентов и пользователей.

В конечном итоге, мы нашли источник проблемы в 15-летней функции Git со сложностью O(N²) и устранили его, внеся изменения в алгоритм, что экспоненциально уменьшило время резервного копирования. В результате мы обеспечили снижение затрат, уменьшение рисков и возможность создания стратегий резервного копирования, которые хорошо масштабируются месте с нашей кодовой базой.

Оказалось, что это проблема масштабируемости Git, влияла на всех его пользователей с крупными репозиториями. Ниже мы расскажем историю о том, как выявили и устранили проблему.


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

#ru

@database_design | Другие наши каналы