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
Как мы перевезли на новый сайт 700 тысяч рецептов и 6 миллионов фото пирогов, сырников и овсяноблинов

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

Сегодня мы расскажем о том, как нашей команде пришлось переносить данные целого проекта на новую платформу и с чем нам пришлось столкнуться при переезде 6 миллионов фото блюд из 700 тысяч рецептов, которые создали пользователи платформы за 15 лет.


Читать: https://habr.com/ru/companies/itsumma/articles/763536/
Tarantool: как избавиться от «зоопарка технологий» с помощью потоков событий

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

Меня зовут Иван Банников, я ведущий разработчик VK Tech. В этом материале я расскажу об основных предпосылках разрастания используемого стека, а также на примере IoT-платформы, которую мы поддерживали, поделюсь опытом избавления от «зоопарка технологий» в области обработки сообщений.


Читать: https://habr.com/ru/companies/vk/articles/761950/
Boost the Accuracy of E-commerce Search Results with Atlas Vector Search



Read: https://www.mongodb.com/blog/post/boost-accuracy-ecommerce-search-results-atlas-vector-search
Хранение данных: как минимизировать риски с помощью DCAP

Компаниям важно, чтобы личные данные сотрудников, конфиденциальная информация клиентов и документы с грифом «коммерческая тайна» были надежно защищены. С каждым годом такой информации становится больше и она подвергается все новым рискам. Параллельно ужесточаются наказания ответственных лиц за нарушения в отношении данных. Например, в Совете Федерации этим летом начали обсуждать закон, который предусматривает лишение свободы сроком до 10 лет и многомиллионные штрафы. Защита данных — тема обширная, выходящая за рамки статьи, поэтому сегодня я расскажу лишь об одном из инструментов, помогающих избежать некоторых рисков, связанных с хранением неструктурированных данных — о DCAP-системе.


Читать: https://habr.com/ru/companies/bastion/articles/767052/
Автоматизация разработки с помощью подхода DB-first

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

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


Читать: https://habr.com/ru/articles/765446/
Ways to Integrate MongoDB Atlas in Your DevOps Processes



Read: https://www.mongodb.com/blog/post/ways-integrate-mongodb-atlas-your-devops-processes
TON Storage – прорыв в Web3 или провал?

TON Storage - это часть экосистемы TON, изначально спроектированной командой Telegram, во главе с Павлом Дуровым. Она предоставляет возможность хранить, скачивать и делиться файлами децентрализованным способом.

Напомню, что работа TON (Telegram Open Network) на несколько лет была запрещена американским, а проект был передан сообществу и переименован в The Open Network.

TON Storage необходим в блокчейн-экосистеме как дешевый способ хранения больших файлов. Хранение файлов непосредственно в блокчейне будет очень дорогим, а потребность в обмене большими файлами между пользователями блокчейна существует. Например, NFT создаются не только на основе изображений, но и музыки и видео. И все эти данные нужно где-то хранить.


Читать: https://habr.com/ru/articles/767214/
Записки оптимизатора 1С (часть 3). Распределенные взаимоблокировки в 1С системах

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


Читать: https://habr.com/ru/companies/softpoint/articles/765774/
Create and Customize your Own Billing Dashboard with Atlas Charts



Read: https://www.mongodb.com/blog/post/create-customize-your-own-billing-dashboard-atlas-charts
MongoDB Provider for Entity Framework Core Now Available in Public Preview



Read: https://www.mongodb.com/blog/post/mongodb-provider-entity-framework-core-now-available-public-preview
ЦЕРН увеличил объем своего хранилища до первого в истории эксабайта. Как хранятся данные Большого адронного коллайдера

Когда Большой адронный коллайдер запущен — как например, во время своего второго цикла, с начала 2015 года по 2018 год, — он обрабатывает события на частоте 40 МГц. Другими словами, он учитывает 40 миллионов событий в секунду. Это необходимо, чтобы отслеживать столкновения между частицами, длящиеся менее 25 наносекунд.

Каждое событие содержит в себе примерно 1 мегабайт данных. Это значит, что в систему во время работы коллайдера входит примерно 40 терабайт данных. В секунду! Абсолютно фантастический объем информации, ведь петабайт набирается примерно за полминуты. Около 72 000 средних жестких дисков заполнялись бы каждый час.

Обрабатывать всё это на такой же скорости не представляется возможным; для анализа подобных объемов данных после окончания работы установки требуются годы. Значительная часть отфильтровывается еще на этапе сбора, на что тоже уходят огромные вычислительные ресурсы. Но всё‑таки остальную часть информации нужно где‑то хранить. Для этого европейская организация по ядерным исследованиям (ЦЕРН) содержит самый большой ЦОД в мире.


Читать: https://habr.com/ru/companies/first/articles/767546/
Keycloak ― построение отказоустойчивого кластера

Разворачивая у нас в Туту Keycloak мы столкнулись с необходимостью создания отказоустойчивого кластера. И если с БД всё более менее понятно, то вот реализовать корректный обмен кэшами между Keycloak оказалось довольно непростой для настройки задачей.

Мы упёрлись в то, что в документации Keycloak описано как создать кластер используя UDP мультикаст. И это работает, если у вас все ноды будут находиться в пределах одного сегмента сети (например ЦОДа). Если с этим сегментом что‑то случится, то мы лишимся Keycloak. Нас это не устраивало.

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

В этом случае в документации Keycloak довольно неочевидно предлагается создать свой собственный кастомный JGroups транспортный стэк, чтобы указать все необходимые вам параметры.

Бонусом приложу shell скрипт, написанный для Consul, который предназначен для снятия анонсов путём выключения bird и попытки восстановления приложения.


Читать: https://habr.com/ru/companies/tuturu/articles/766284/
Реляционные системы управления базами данных становятся проблемой. Что с этим делать?

С реляционными базами данных я знаком очень давно, с конца 90-х. Мои первые шаги в мире компьютеров и программирования связанны именно с ними. Реляционным БД было отведено особое место в моей образовательной программе и стажировке на инженера-программиста. Они преследовали меня на протяжении всей моей карьеры. Я буквально провалился на самое дно кроличьей норы реляционных систем управления базами данных (РСУБД) – и до сих пор люблю их.

За годы работы я испробовал практически все РСУБД, а их попадалось мне немало: MySQL, Postgres, Oracle, Microsoft SQL Server, DBase, Access, SQLite, DB2, MariaDB, AWS RDS, Azure SQL, Google Cloud SQL. Нельзя любить РСУБД, если не любишь SQL, а это отдельная вселенная. И не все SQL одинаковы. Есть MySQL со своим собственным жаргоном, есть T-SQL от Microsoft и всемирно известный PL/SQL от Oracle. Наверное, не стоит упоминать, что все они несовместимы друг с другом.


Читать: https://habr.com/ru/companies/ispmanager/articles/766608/
Эффективные бэкапы в S3 с помощью Restic: краткое пособие по настройке

В 2007 многие администраторы настраивали бэкапы с помощью утилиты rsync, но для этого нужно было выделять отдельный хост для хранилища. И одной из частых проблем было резервирование этого сервера для бэкапов, которое увеличивало накладные расходы. Также хост бэкапирования располагался рядом с устройствами, для которых нужно было выполнить резервное копирование, настроить мониторинг и другое. Это нарушало правило 3-2-1, поэтому для построения действительно надежной системы нужно располагать хосты в разных дата-центрах.

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

Читать: https://habr.com/ru/companies/selectel/articles/768014/
Главное из книги Fundamentals of Data engineering — фундаментального труда о дата-инжиниринге

Команда VK Cloud перевела статью, в которой автор кратко излагает основные мысли книги Джо Рейса и Мэтта Хаусли Fundamentals of Data engineering. Здесь приводится краткий конспект глав и самые важные моменты, которые полезно знать любому человеку, работающему с данными.


Читать: https://habr.com/ru/companies/vk/articles/766530/
Autonomous Database - Dedicated Observability for Mission Critical Workloads

Oracle Autonomous Database - Dedicated (ADB-D) caters to the stringent observability requirements of mission-critical workloads. By actively participating in the observability cycle and providing comprehensive tools, services, and automation, Oracle empowers customers to ensure the performance, regulatory compliance, and trustworthiness of their databases.

Read: https://blogs.oracle.com/database/post/adb-d-observability-for-mission-critical-workloads
Размерности качества данных: обеспечение качества данных с помощью Great Expectations

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

Согласно опросу Gartner за 2020 год, в среднем потери из-за низкого качества данных составляют примерно $12,8 миллиона за год. Как сообщается в последнем отчёте State of Data Quality, задержки продакшена (задержки с выпуском продукта) — характерный симптом низкого качества данных. Высококачественные и безошибочные данные повышают надёжность и верность полученных из них выводов.

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

В этой статье рассматриваются шесть размерностей качества данных: полнота, согласованность, целостность, вневременная актуальность, уникальность и валидность. Определив их, вы сможете обеспечить исчерпывающее понимание качества данных и выявить аспекты, требующие совершенствования. И здесь нам на помощь приходит Great Expectation (GX).


Читать: https://habr.com/ru/articles/739254/
Building AI with MongoDB: Supercharging Three Communication Paradigms



Read: https://www.mongodb.com/blog/post/building-ai-mongodb-supercharging-three-communication-paradigms
Хранение данных: как минимизировать риски с помощью DCAP

Компаниям важно, чтобы личные данные сотрудников, конфиденциальная информация клиентов и документы с грифом «коммерческая тайна» были надежно защищены. С каждым годом такой информации становится больше и она подвергается все новым рискам. Параллельно ужесточаются наказания ответственных лиц за нарушения в отношении данных. Например, в Совете Федерации этим летом начали обсуждать закон, который предусматривает лишение свободы сроком до 10 лет и многомиллионные штрафы. Защита данных — тема обширная, выходящая за рамки статьи, поэтому сегодня я расскажу лишь об одном из инструментов, помогающих избежать некоторых рисков, связанных с хранением неструктурированных данных — о DCAP-системе.


Читать: https://habr.com/ru/companies/bastion/articles/767052/
Restic: эффективное резервное копирование из Stdin

Про restic я уже рассказывал в статье Бэкап-хранилище для тысяч виртуальных машин свободными инструментами, с тех пор он остаётся моим любимым инструментом для бэкапа.

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

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

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


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