Postgres Pro TDE — безопасность и производительность
TDE бывает разным: от шифрования на уровне TAM до полного кодирования всего кластера и меток tablespace. Мы сравниваем Percona, Cybertec/EDB, Pangolin/Fujitsu и показываем, где теряется производительность и надёжность, а где появляется гибкость. Дополнительно замдиректора департамента разработки продуктов Василий Бернштейн и старший инженер по ИБ Владимир Абрамов расскажут о том, как в Postgres Pro Enterprise реализована ротация ключей без полного переписывания таблиц и почему выбран AES‑GCM.
Читать: https://habr.com/ru/companies/postgrespro/articles/937246/
#ru
@database_design | Другие наши каналы
TDE бывает разным: от шифрования на уровне TAM до полного кодирования всего кластера и меток tablespace. Мы сравниваем Percona, Cybertec/EDB, Pangolin/Fujitsu и показываем, где теряется производительность и надёжность, а где появляется гибкость. Дополнительно замдиректора департамента разработки продуктов Василий Бернштейн и старший инженер по ИБ Владимир Абрамов расскажут о том, как в Postgres Pro Enterprise реализована ротация ключей без полного переписывания таблиц и почему выбран AES‑GCM.
Читать: https://habr.com/ru/companies/postgrespro/articles/937246/
#ru
@database_design | Другие наши каналы
Jakarta Data. Что это означает для Java-сообщества
Большинство enterprise-приложений работают с БД в том или ином виде. Чаще всего в качестве БД выступает реляционная DBMS, например, PostgreSQL или Oracle. Относительно часто для доступа к данным используют Hibernate. Ранее он предлагал только одну спецификацию — JPA (Java Persistence API), она же Jakarta. Но теперь Hibernate реализует ещё и Jakarta Data.
Jakarta Data — это новая спецификация под зонтиком проекта Jakarta EE (как и JPA), которая упрощает интеграцию данных в корпоративных Java-приложениях. Обе эти спецификации разрабатывает Eclipse Foundation, и в частности Gavin King, создатель Hibernate.
Большинство разработчиков привыкли работать с Hibernate именно через Spring Data JPA. Изначально, когда только обсуждали спецификацию Jakarta Data, Spring Data (не обязательно JPA) была одним из тех проектов, который, в перспективе, мог бы реализовать спецификацию Jakarta Data. Но этого не произошло, и, несмотря на то, что изначально команда Spring Data была вовлечена в процесс создания спецификации, они отказались от идеи реализовывать Jakarta Data, и та стала развиваться самостоятельно. Сегодня Jakarta Data применяют в Hibernate, Open Liberty и ряде более мелких решений. Как же так вышло?
Меня зовут Михаил Поливаха, я практикующий инженер и активный коммитер Spring Data. В этой статье я расскажу об особенностях Jakarta Data, как она появилась и чем отличается от конкурентных решений. Я также расскажу, что помешало команде Spring Data реализовать Jakarta Data, и что же нас ждёт дальше.
Читать: https://habr.com/ru/companies/sberbank/articles/936912/
#ru
@database_design | Другие наши каналы
Большинство enterprise-приложений работают с БД в том или ином виде. Чаще всего в качестве БД выступает реляционная DBMS, например, PostgreSQL или Oracle. Относительно часто для доступа к данным используют Hibernate. Ранее он предлагал только одну спецификацию — JPA (Java Persistence API), она же Jakarta. Но теперь Hibernate реализует ещё и Jakarta Data.
Jakarta Data — это новая спецификация под зонтиком проекта Jakarta EE (как и JPA), которая упрощает интеграцию данных в корпоративных Java-приложениях. Обе эти спецификации разрабатывает Eclipse Foundation, и в частности Gavin King, создатель Hibernate.
Большинство разработчиков привыкли работать с Hibernate именно через Spring Data JPA. Изначально, когда только обсуждали спецификацию Jakarta Data, Spring Data (не обязательно JPA) была одним из тех проектов, который, в перспективе, мог бы реализовать спецификацию Jakarta Data. Но этого не произошло, и, несмотря на то, что изначально команда Spring Data была вовлечена в процесс создания спецификации, они отказались от идеи реализовывать Jakarta Data, и та стала развиваться самостоятельно. Сегодня Jakarta Data применяют в Hibernate, Open Liberty и ряде более мелких решений. Как же так вышло?
Меня зовут Михаил Поливаха, я практикующий инженер и активный коммитер Spring Data. В этой статье я расскажу об особенностях Jakarta Data, как она появилась и чем отличается от конкурентных решений. Я также расскажу, что помешало команде Spring Data реализовать Jakarta Data, и что же нас ждёт дальше.
Читать: https://habr.com/ru/companies/sberbank/articles/936912/
#ru
@database_design | Другие наши каналы
Oracle выпустил новую версию 25.1 Spatial Studio — веб-инструмента без кода для визуализации и анализа геопространственных данных. Приложение доступно в OCI Marketplace и для локальной установки, упрощая работу с геоданными в компании.
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
Новый взгляд на обработку событий в Oracle Database 19c. TxEventQ объединяет возможности очередей сообщений и подписки с поддержкой Kafka, позволяя строить эффективные платформы для event streaming прямо в базе данных. Подробнее — в статье.
Читать подробнее
#en
@database_design | Другие наши каналы
Читать подробнее
#en
@database_design | Другие наши каналы
MariaDB укрепляет поддержку Galera Cluster
MariaDB приобрела компанию Codership, разработчиков Galera Cluster, чтобы гарантировать высокую доступность и дальнейшее развитие технологии. Пользователи могут рассчитывать на стабильность и поддержку от объединённой команды экспертов. Подробнее по ссылке.
Читать подробнее
#en
@database_design | Другие наши каналы
MariaDB приобрела компанию Codership, разработчиков Galera Cluster, чтобы гарантировать высокую доступность и дальнейшее развитие технологии. Пользователи могут рассчитывать на стабильность и поддержку от объединённой команды экспертов. Подробнее по ссылке.
Читать подробнее
#en
@database_design | Другие наши каналы
MariaDB
A Message for MySQL Galera Cluster Users | MariaDB
This blog provides clarity and a migration path for MySQL Galera Cluster users to MariaDB Galera Cluster.
Выбираем архитектуру данных для компании: руководство от дата-инженера
Сегодня данные превратились в один из главных активов бизнеса. От того, как компания их использует, зависит и качество принимаемых решений, и эффективность процессов, и шансы обойти конкурентов.
Эпоха, когда бизнесу достаточно было просто владеть данными, осталась в прошлом. Теперь их нужно интерпретировать, делать легкодоступными, встраивать системы, поддерживающие принятие решений. При этом объемы данных растут, их форматы множатся, а сценарии использования — усложняются.
Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.
Читать: https://habr.com/ru/companies/magnus-tech/articles/937470/
#ru
@database_design | Другие наши каналы
Сегодня данные превратились в один из главных активов бизнеса. От того, как компания их использует, зависит и качество принимаемых решений, и эффективность процессов, и шансы обойти конкурентов.
Эпоха, когда бизнесу достаточно было просто владеть данными, осталась в прошлом. Теперь их нужно интерпретировать, делать легкодоступными, встраивать системы, поддерживающие принятие решений. При этом объемы данных растут, их форматы множатся, а сценарии использования — усложняются.
Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.
Читать: https://habr.com/ru/companies/magnus-tech/articles/937470/
#ru
@database_design | Другие наши каналы
Выбираем архитектуру данных для компании: руководство от дата-инженера
Сегодня данные превратились в один из главных активов бизнеса. От того, как компания их использует, зависит и качество принимаемых решений, и эффективность процессов, и шансы обойти конкурентов.
Эпоха, когда бизнесу достаточно было просто владеть данными, осталась в прошлом. Теперь их нужно интерпретировать, делать легкодоступными, встраивать системы, поддерживающие принятие решений. При этом объемы данных растут, их форматы множатся, а сценарии использования — усложняются.
Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.
Читать: https://habr.com/ru/companies/magnus-tech/articles/937470/
#ru
@database_design | Другие наши каналы
Сегодня данные превратились в один из главных активов бизнеса. От того, как компания их использует, зависит и качество принимаемых решений, и эффективность процессов, и шансы обойти конкурентов.
Эпоха, когда бизнесу достаточно было просто владеть данными, осталась в прошлом. Теперь их нужно интерпретировать, делать легкодоступными, встраивать системы, поддерживающие принятие решений. При этом объемы данных растут, их форматы множатся, а сценарии использования — усложняются.
Чтобы справиться с этим, компании переходят на более гибкие подходы к управлению данными. В этой статье разберем четыре наиболее популярные архитектуры: Data Warehouse, Data Lake, Data Lakehouse и Data Mesh. Обсудим, чем они отличаются и какую выбрать под конкретные задачи.
Читать: https://habr.com/ru/companies/magnus-tech/articles/937470/
#ru
@database_design | Другие наши каналы
Домашний NAS Buffalo LinkStation LS220D в 2025 году: медленный, но надежный
Сетевые хранилища (NAS) давно перестали быть экзотикой, превратившись в удобный инструмент для дома и офиса. Они помогают централизовать хранение данных, обеспечивают доступ к файлам с разных устройств, автоматизируют создание бэкапов. Но выбор NAS — это всегда баланс между ценой, функциональностью и надежностью.
Сегодня я расскажу про Buffalo LinkStation LS220D — недорогой NAS на два HDD, который я купил с серьезной поломкой, починил и теперь активно использую. Разберем возможности системы, скорость работы, интерфейсы, совместимость, шум и, конечно, поговорим о недостатках. Ну а в комментариях рассказывайте о своих NAS — офисных или домашних. Думаю, многим читателям Хабра будет интересно.
Читать: https://habr.com/ru/companies/ru_mts/articles/937436/
#ru
@database_design | Другие наши каналы
Сетевые хранилища (NAS) давно перестали быть экзотикой, превратившись в удобный инструмент для дома и офиса. Они помогают централизовать хранение данных, обеспечивают доступ к файлам с разных устройств, автоматизируют создание бэкапов. Но выбор NAS — это всегда баланс между ценой, функциональностью и надежностью.
Сегодня я расскажу про Buffalo LinkStation LS220D — недорогой NAS на два HDD, который я купил с серьезной поломкой, починил и теперь активно использую. Разберем возможности системы, скорость работы, интерфейсы, совместимость, шум и, конечно, поговорим о недостатках. Ну а в комментариях рассказывайте о своих NAS — офисных или домашних. Думаю, многим читателям Хабра будет интересно.
Читать: https://habr.com/ru/companies/ru_mts/articles/937436/
#ru
@database_design | Другие наши каналы
Новые ИИ-ускорители и SSD на 245 ТБ: дайджест железа за июль
Привет, Хабр! Меня зовут Сергей Ковалёв, я менеджер выделенных серверов в Selectel. Сегодня мы наблюдаем очевидную тенденцию. Серверные комплектующие становятся все более ориентированными на ИИ-нагрузки и энергоэффективными. Рекордные объемы хранения и новые стандарты сетей это подтверждают. Например, в июле вендоры выпустили вместительные HDD-диски на 30 ТБ и высокопроизводительные ИИ-ускорители. Подробнее о каждой новинке — в статье.
Читать: https://habr.com/ru/companies/selectel/articles/937426/
#ru
@database_design | Другие наши каналы
Привет, Хабр! Меня зовут Сергей Ковалёв, я менеджер выделенных серверов в Selectel. Сегодня мы наблюдаем очевидную тенденцию. Серверные комплектующие становятся все более ориентированными на ИИ-нагрузки и энергоэффективными. Рекордные объемы хранения и новые стандарты сетей это подтверждают. Например, в июле вендоры выпустили вместительные HDD-диски на 30 ТБ и высокопроизводительные ИИ-ускорители. Подробнее о каждой новинке — в статье.
Читать: https://habr.com/ru/companies/selectel/articles/937426/
#ru
@database_design | Другие наши каналы
WAP паттерн в data-engineering
Несмотря на бурное развитие дата инжиниринга, WAP паттерн долгое время незаслуженно обходят стороной. Кто-то слышал о нем, но не применяет. Кто-то применяет, но интуитивно. В этой статье хочу на примере детально описать паттерн работы с данными, которому уже почти 8 лет, но за это время ни одна статья не была написана с принципом работы.
Читать: https://habr.com/ru/articles/937738/
#ru
@database_design | Другие наши каналы
Несмотря на бурное развитие дата инжиниринга, WAP паттерн долгое время незаслуженно обходят стороной. Кто-то слышал о нем, но не применяет. Кто-то применяет, но интуитивно. В этой статье хочу на примере детально описать паттерн работы с данными, которому уже почти 8 лет, но за это время ни одна статья не была написана с принципом работы.
Читать: https://habr.com/ru/articles/937738/
#ru
@database_design | Другие наши каналы
От GreenPlum к Mirrorship: Кейс трансформации Bank of Hangzhou Consumer Finance на основе архитектуры Lakehouse
Узнайте, как Bank of Hangzhou Consumer Finance решил проблемы с отслеживаемостью и real-time данными, перейдя с GreenPlum на Lakehouse-архитектуру на базе Mirrorship. Реальный кейс о трансформации дата-платформы в финтехе.
Читать: «От GreenPlum к Mirrorship: Кейс трансформации Bank of Hangzhou Consumer Finance на основе архитектуры Lakehouse»
#ru
@database_design | Другие наши каналы
Узнайте, как Bank of Hangzhou Consumer Finance решил проблемы с отслеживаемостью и real-time данными, перейдя с GreenPlum на Lakehouse-архитектуру на базе Mirrorship. Реальный кейс о трансформации дата-платформы в финтехе.
Читать: «От GreenPlum к Mirrorship: Кейс трансформации Bank of Hangzhou Consumer Finance на основе архитектуры Lakehouse»
#ru
@database_design | Другие наши каналы
Надежное хранение личной информации — 2025 год
Мысль написания такой статьи зародилась по итогам обсуждений на форуме iXBT вопроса о том, как организовать хранение в домашних условиях некоторого количества личной информации. Статья "LLM free", все картинки и текст - органического происхождения ;)
Начнем со вводных параметров:
- есть желание сохранить на длительный срок (для конкретности берем 40 лет) данные, при этом сведя к возможному минимуму вероятность их утраты;
- данные включают в себя - электронные копии документов, семейные фото, видео. У них есть особое свойство - в случае утраты всех копий восстановление невозможно. Это не фильмы или музыка, которые можно найти в Сети и скачать повторно. Объем данных, по результатам опроса знакомых и коллег - не превышает 1 терабайта;
- человек, озаботившийся сохранением данных - не профессиональный сисадмин, и возможно - даже не связан с IT, поэтому написанием скриптов, постройкой СХД, и установкой в кладовке ленточной библиотеки заниматься не будет, все инструменты должны быть доступны простому обывателю и... ;
- ...не требовать чрезмерно много расходов, в идеале - как говорит нам ТРИЗ, "объекта нет - а задача выполняется".
Читать дальше
Читать: https://habr.com/ru/articles/929920/
#ru
@database_design | Другие наши каналы
Мысль написания такой статьи зародилась по итогам обсуждений на форуме iXBT вопроса о том, как организовать хранение в домашних условиях некоторого количества личной информации. Статья "LLM free", все картинки и текст - органического происхождения ;)
Начнем со вводных параметров:
- есть желание сохранить на длительный срок (для конкретности берем 40 лет) данные, при этом сведя к возможному минимуму вероятность их утраты;
- данные включают в себя - электронные копии документов, семейные фото, видео. У них есть особое свойство - в случае утраты всех копий восстановление невозможно. Это не фильмы или музыка, которые можно найти в Сети и скачать повторно. Объем данных, по результатам опроса знакомых и коллег - не превышает 1 терабайта;
- человек, озаботившийся сохранением данных - не профессиональный сисадмин, и возможно - даже не связан с IT, поэтому написанием скриптов, постройкой СХД, и установкой в кладовке ленточной библиотеки заниматься не будет, все инструменты должны быть доступны простому обывателю и... ;
- ...не требовать чрезмерно много расходов, в идеале - как говорит нам ТРИЗ, "объекта нет - а задача выполняется".
Читать дальше
Читать: https://habr.com/ru/articles/929920/
#ru
@database_design | Другие наши каналы
Рефакторинг скриптов liquibase
Неважно почему, но иногда может появиться желание заняться рефакторингом ваших скриптов liquibase. В моём случае постоянно возникали конфликты в общем файле журнала изменений, количество скриптов превратилось в ужасно длинный список, а в самих скриптах невозможно было ориентироваться, поскольку они содержали по 1–2 команды, а в названии файла были только дата и действие. Долго это терпел, долго взвешивал плюсы и минусы, и всё время боролся с желанием всё отрефачить. И в какой-то момент дошёл до точки, когда желание взяло верх.
Решение принято: рефакторингу быть! Сразу скажу, приступать было страшно, но сейчас я очень доволен результатом. «Идеальную» структуру мы не получили, пришлось идти на компромиссы и заплатить свою цену, зато в новой структуре удалось вылечить все проблемы. Теперь в ней удобно ориентироваться и читать код, конфликты создаются очень редко, а все скрипты автоматически детектируются liquibase-ом. Но только это конец истории. А вначале было вообще непонятно, как рефакторить журнал изменений, да так, чтобы в существующие базы данных он смог пролиться, и ничего не поломал при этом!
Приступаем к рефакторингу
Читать: https://habr.com/ru/articles/937956/
#ru
@database_design | Другие наши каналы
Неважно почему, но иногда может появиться желание заняться рефакторингом ваших скриптов liquibase. В моём случае постоянно возникали конфликты в общем файле журнала изменений, количество скриптов превратилось в ужасно длинный список, а в самих скриптах невозможно было ориентироваться, поскольку они содержали по 1–2 команды, а в названии файла были только дата и действие. Долго это терпел, долго взвешивал плюсы и минусы, и всё время боролся с желанием всё отрефачить. И в какой-то момент дошёл до точки, когда желание взяло верх.
Решение принято: рефакторингу быть! Сразу скажу, приступать было страшно, но сейчас я очень доволен результатом. «Идеальную» структуру мы не получили, пришлось идти на компромиссы и заплатить свою цену, зато в новой структуре удалось вылечить все проблемы. Теперь в ней удобно ориентироваться и читать код, конфликты создаются очень редко, а все скрипты автоматически детектируются liquibase-ом. Но только это конец истории. А вначале было вообще непонятно, как рефакторить журнал изменений, да так, чтобы в существующие базы данных он смог пролиться, и ничего не поломал при этом!
Приступаем к рефакторингу
Читать: https://habr.com/ru/articles/937956/
#ru
@database_design | Другие наши каналы
Файловая репликация в СХД АЭРОДИСК ENGINE: для тех, кто устал терять данные по тупым причинам
Данные не ломаются сами по себе — их ломают люди. Уборщица шваброй, приложение, написанное «на отвали», админ в пятничной прострации. Причины разные — результат один: файлов нет, виноватого тоже.
Чтобы не восстанавливать инфраструктуру с нуля по скриншотам из Notion, в АЭРОДИСК ENGINE есть файловая репликация. Это не бэкап, это реальное дублирование файлов между хранилищами, которое спасает, когда кто-то опять «просто немного пофиксил в проде».
Без костылей, без CLI-гимнастики, без надежды на авось. Настроили — и пусть хоть полсервера ляжет, данные у вас уже есть в другом месте.
Разбираемся, как оно устроено, чтобы потом не было «ой, не знал».
Читать: https://habr.com/ru/companies/aerodisk/articles/936862/
#ru
@database_design | Другие наши каналы
Данные не ломаются сами по себе — их ломают люди. Уборщица шваброй, приложение, написанное «на отвали», админ в пятничной прострации. Причины разные — результат один: файлов нет, виноватого тоже.
Чтобы не восстанавливать инфраструктуру с нуля по скриншотам из Notion, в АЭРОДИСК ENGINE есть файловая репликация. Это не бэкап, это реальное дублирование файлов между хранилищами, которое спасает, когда кто-то опять «просто немного пофиксил в проде».
Без костылей, без CLI-гимнастики, без надежды на авось. Настроили — и пусть хоть полсервера ляжет, данные у вас уже есть в другом месте.
Разбираемся, как оно устроено, чтобы потом не было «ой, не знал».
Читать: https://habr.com/ru/companies/aerodisk/articles/936862/
#ru
@database_design | Другие наши каналы
64-битный счётчик транзакций в PostgreSQL
На конференции PgBootcamp 2025 был доклад Евгения Воропаева "Разработка и отладка 64-битного счётчика транзакций". В докладе рассматривались проблемы, которые встретились при переносе патча с 16 на 18 версию PostgreSQL. В статье описывается история патча.
Читать: https://habr.com/ru/articles/937992/
#ru
@database_design | Другие наши каналы
На конференции PgBootcamp 2025 был доклад Евгения Воропаева "Разработка и отладка 64-битного счётчика транзакций". В докладе рассматривались проблемы, которые встретились при переносе патча с 16 на 18 версию PostgreSQL. В статье описывается история патча.
Читать: https://habr.com/ru/articles/937992/
#ru
@database_design | Другие наши каналы
Как YDB изолирует OLTP и OLAP
Привет, Хабр! Меня зовут Олег Доронин, и мы с командой делаем СУБД Яндекса, которая называется YDB. Каждый транзакционный запрос к базе данных обычно работает с небольшим набором строк и быстро отрабатывает за единицы или десятки миллисекунд, но таких запросов каждую секунду поступает огромное количество. А вот аналитические запросы обычно выполняются не так часто, но каждый из них может требовать обработки вплоть до всех строк в одной или нескольких таблицах. Такие запросы могут выполняться секунды, минуты, или даже часы в зависимости от объёмов данных и сложности запрошенных вычислений.
Чтобы эти два принципиально разных паттерна нагрузки не мешали друг другу, гибридным базам данных важно изолировать транзакционную нагрузку от аналитической. Под катом я расскажу, как мы сделали в YDB компоненты для управления смешанной нагрузкой, которые изолируют миллионы RPS от аналитики, и как менеджер смешанной нагрузки устроен внутри.
Читать: https://habr.com/ru/companies/ydb/articles/935506/
#ru
@database_design | Другие наши каналы
Привет, Хабр! Меня зовут Олег Доронин, и мы с командой делаем СУБД Яндекса, которая называется YDB. Каждый транзакционный запрос к базе данных обычно работает с небольшим набором строк и быстро отрабатывает за единицы или десятки миллисекунд, но таких запросов каждую секунду поступает огромное количество. А вот аналитические запросы обычно выполняются не так часто, но каждый из них может требовать обработки вплоть до всех строк в одной или нескольких таблицах. Такие запросы могут выполняться секунды, минуты, или даже часы в зависимости от объёмов данных и сложности запрошенных вычислений.
Чтобы эти два принципиально разных паттерна нагрузки не мешали друг другу, гибридным базам данных важно изолировать транзакционную нагрузку от аналитической. Под катом я расскажу, как мы сделали в YDB компоненты для управления смешанной нагрузкой, которые изолируют миллионы RPS от аналитики, и как менеджер смешанной нагрузки устроен внутри.
Читать: https://habr.com/ru/companies/ydb/articles/935506/
#ru
@database_design | Другие наши каналы
Многоагентная AI-предиктивная диагностика с MongoDB
Производство внедряет мультиагентные AI-системы для предиктивного обслуживания — от обнаружения неисправностей до оптимального планирования ремонтов. MongoDB обеспечивает быструю обработку данных с IoT и поддерживает масштабируемость таких решений, делая их более эффективными и надежными. Новые хранилища данных MongoDB оптимизированы для больших поисковых индексов. Storage-optimized search nodes обеспечивают вдвое больший объём хранилища и снижают затраты до 50%, позволяя эффективно масштабировать поиск без лишних ресурсов и переплат. Новые возможности для векторного поиска: Storage-оптимизированные узлы
Современный ИИ меняет подход к векторному поиску, смещая узкое место с оперативной памяти на хранилище. Storage-оптимизированные узлы позволяют эффективно масштабировать индексирование и поиск, снижая затраты и повышая производительность.
Читать подробнее
#en
@database_design | Другие наши каналы
Производство внедряет мультиагентные AI-системы для предиктивного обслуживания — от обнаружения неисправностей до оптимального планирования ремонтов. MongoDB обеспечивает быструю обработку данных с IoT и поддерживает масштабируемость таких решений, делая их более эффективными и надежными. Новые хранилища данных MongoDB оптимизированы для больших поисковых индексов. Storage-optimized search nodes обеспечивают вдвое больший объём хранилища и снижают затраты до 50%, позволяя эффективно масштабировать поиск без лишних ресурсов и переплат. Новые возможности для векторного поиска: Storage-оптимизированные узлы
Современный ИИ меняет подход к векторному поиску, смещая узкое место с оперативной памяти на хранилище. Storage-оптимизированные узлы позволяют эффективно масштабировать индексирование и поиск, снижая затраты и повышая производительность.
Читать подробнее
#en
@database_design | Другие наши каналы
От REST-монолита к гибкой архитектуре GraphQL-федерации: реальный кейс Авто.ру
Реализация системы с микросервисной архитектурой редко обходится без классического разруливающего REST-гейтвея. Но когда ваша система растёт годами, а в гейтвее плодятся сотни ручек с просачивающейся бизнес-логикой, можно внезапно обнаружить, что ваш REST-гейтвей стал монолитом со всеми вытекающими последствиями.
Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.
Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре.
Читать: https://habr.com/ru/companies/yandex/articles/935948/
#ru
@database_design | Другие наши каналы
Реализация системы с микросервисной архитектурой редко обходится без классического разруливающего REST-гейтвея. Но когда ваша система растёт годами, а в гейтвее плодятся сотни ручек с просачивающейся бизнес-логикой, можно внезапно обнаружить, что ваш REST-гейтвей стал монолитом со всеми вытекающими последствиями.
Мы в Авто.ру шли к этому состоянию гейтвея довольно долго. История его началась в 2015 году: десятки разработчиков, сотни ручек, почти 300 000 строк кода — и релизы, которые можно катить неделю. Чтобы спасти наш стремительно деградирующий time-to-market и вернуть разработке гибкость, мы решили попробовать GraphQL-федерацию. Спойлер: кажется, получилось.
Меня зовут Кирилл Ершов, я бэкенд-разработчик в Авто.ру, и в этой статье я расскажу, как мы перешли от REST к федерации GraphQL: зачем нам это понадобилось, с какими подводными камнями мы столкнулись, как выглядели первые миграции трафика, к чему всё это привело на данный момент в цифрах и инфраструктуре.
Читать: https://habr.com/ru/companies/yandex/articles/935948/
#ru
@database_design | Другие наши каналы
Работа над ошибками
Достаточно большой период времени занимался технической поддержкой СУБД Oracle. Накопилось некоторое количество историй и заметок на полях по этому поводу, не могу не поделиться ими с вами. В общем – садимся по удобнее, берем попкорн, чашку горячего чая или кофе.. Дело было так.
Читать: https://habr.com/ru/articles/938502/
#ru
@database_design | Другие наши каналы
Достаточно большой период времени занимался технической поддержкой СУБД Oracle. Накопилось некоторое количество историй и заметок на полях по этому поводу, не могу не поделиться ими с вами. В общем – садимся по удобнее, берем попкорн, чашку горячего чая или кофе.. Дело было так.
Читать: https://habr.com/ru/articles/938502/
#ru
@database_design | Другие наши каналы
Тестирование CAP-теоремы на примере MongoDB: аварийные ситуации
Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB.
В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB.
В этой статье я покажу результаты тестов при аварийных ситуациях, которые могут происходить в распределенной системе. Сделаем выводы о свойствах набора реплик с точки зрения CAP- и PACELC-теорем для распределенных систем и посмотрим параметры управления CAP-свойствами неоднородных распределенных систем.
Читать: https://habr.com/ru/companies/tbank/articles/938670/
#ru
@database_design | Другие наши каналы
Привет, Хабр! На связи Сергей Гайдамаков. Продолжаем обсуждать и тестировать набор реплик MongoDB.
В предыдущей статье мы рассмотрели структуру отдельного узла MongoDB, разобрали свойства параметров writeConcern и readConcern для работы с набором реплик MongoDB.
В этой статье я покажу результаты тестов при аварийных ситуациях, которые могут происходить в распределенной системе. Сделаем выводы о свойствах набора реплик с точки зрения CAP- и PACELC-теорем для распределенных систем и посмотрим параметры управления CAP-свойствами неоднородных распределенных систем.
Читать: https://habr.com/ru/companies/tbank/articles/938670/
#ru
@database_design | Другие наши каналы
Наш опыт с Cassandra и ScyllaDB: какие есть ограничения у этих key-value-БД и почему стоит присмотреться к альтернативам
Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.
Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.
Но по мере роста проекта возникает необходимость более сложной работы с данными. Например, когда хочется получить информацию в разрезе дат или понять, на каких устройствах какие токены живут. И вот здесь начинают всплывать ограничения архитектуры и типовые грабли, на которые можно наступить (и мы регулярно это делали). В этом материале мы опишем, почему выбрали Cassandra и с какими проблемами столкнулись — надеемся, это поможет правильно определиться с выбором нужного инструмента для ваших систем.
Читать: https://habr.com/ru/companies/ru_mts/articles/935896/
#ru
@database_design | Другие наши каналы
Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.
Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.
Но по мере роста проекта возникает необходимость более сложной работы с данными. Например, когда хочется получить информацию в разрезе дат или понять, на каких устройствах какие токены живут. И вот здесь начинают всплывать ограничения архитектуры и типовые грабли, на которые можно наступить (и мы регулярно это делали). В этом материале мы опишем, почему выбрали Cassandra и с какими проблемами столкнулись — надеемся, это поможет правильно определиться с выбором нужного инструмента для ваших систем.
Читать: https://habr.com/ru/companies/ru_mts/articles/935896/
#ru
@database_design | Другие наши каналы