Эволюция обработки данных: от MapReduce к стриминговому движку

Yandex Query Language (YQL) — универсальный декларативный язык запросов к системам хранения и обработки данных, разработанный в Яндексе. А ещё это один из самых нагруженных сервисов: YQL ежедневно обрабатывает около 800 петабайт данных и 600 000 SQL-запросов, и эти показатели постоянно растут.

Изначально YQL основывался на операциях MapReduce, которые эффективны для больших данных. Но для средних объёмов данных (до 50 Гб, которые составляют около 60% запросов) этот подход оказался неоптимальным, потому что нужно было обмениваться данными между операциями через диск. Поэтому разработчики создали новый более гибкий стриминговый движок, который значительно ускоряет обработку данных за счёт выполнения всех вычислений в памяти.

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


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

@database_design

Эволюция обработки данных: от MapReduce к стриминговому движку

Yandex Query Language (YQL) — универсальный декларативный язык запросов к системам хранения и обработки данных, разработанный в Яндексе. А ещё это один из самых нагруженных сервисов: YQL ежедневно обрабатывает около 800 петабайт данных и 600 000 SQL-запросов, и эти показатели постоянно растут.

Изначально YQL основывался на операциях MapReduce, которые эффективны для больших данных. Но для средних объёмов данных (до 50 Гб, которые составляют около 60% запросов) этот подход оказался неоптимальным, потому что нужно было обмениваться данными между операциями через диск. Поэтому разработчики создали новый более гибкий стриминговый движок, который значительно ускоряет обработку данных за счёт выполнения всех вычислений в памяти.

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


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

@database_design

Оптимизация запросов в ClickHouse с помощью создания цепочки материализованных представлений

В ClickHouse материализованные представления (materialized views) являются механизмом, автоматически выполняющим запросы к исходным таблицам при поступлении новых данных.

Материализованное представление (МП) - это специальный тип таблицы, содержащей результат выполнения запроса к исходным данным. Этот результат фактически представляет собой кэшированное представление данных из исходных таблиц. Одной из ключевых особенностей МП в ClickHouse является их автоматическое обновление. При поступлении новых данных в исходные таблицы МП обновляется, автоматически пересчитываясь в соответствии с определенным запросом.


Читать: https://habr.com/ru/companies/otus/articles/810113/

@database_design

Five Languages, One Goal: A Developer's Path to Certification Mastery



Read: https://www.mongodb.com/blog/post/five-languages-one-goal-developers-path-certification-mastery

@database_design

MariaDB Enterprise Server 10.6.17-13 maintenance release

Read: https://mariadb.com/?p=39164

@database_design

Это база: нюансы работы с Redis. Часть 2, репликация

Всем привет, на связи Пётр, инженер компании Nixys. В прошлой статье мы разобрали основные концепции Redis. Теперь рассмотрим базовую репликацию Redis и настроим эту БД на высокий уровень отказоустойчивости.


Читать: https://habr.com/ru/companies/nixys/articles/805463/

@database_design

Greenplum, NiFi и Airflow на страже импортозамещения: но есть нюансы

В статье описывается практическое применение популярных Open-Source технологий в области интеграции, хранения и обработки больших данных: Apache NiFi, Apache Airflow и Greenplum для проекта по аналитике учета вывоза отходов строительства.

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


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

@database_design

Greenplum, NiFi и Airflow на страже импортозамещения: но есть нюансы

В статье описывается практическое применение популярных Open-Source технологий в области интеграции, хранения и обработки больших данных: Apache NiFi, Apache Airflow и Greenplum для проекта по аналитике учета вывоза отходов строительства.

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


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

@database_design

Делаем резервное копирование кластера ClickHouse: простая инструкция

Делаем резервное копирование кластера ClickHouse: простая инструкция

Меня зовут Леонид Блынский и я администратор баз данных в Лиге Цифровой Экономики. В этой небольшой статье расскажу, как я делаю резервное копирование кластера ClickHouse размером 20 ТБ.

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


Читать: https://habr.com/ru/companies/digitalleague/articles/810445/

@database_design

Делаем резервное копирование кластера ClickHouse: простая инструкция

Делаем резервное копирование кластера ClickHouse: простая инструкция

Меня зовут Леонид Блынский и я администратор баз данных в Лиге Цифровой Экономики. В этой небольшой статье расскажу, как я делаю резервное копирование кластера ClickHouse размером 20 ТБ.

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


Читать: https://habr.com/ru/companies/digitalleague/articles/810445/

@database_design

ClearML Data Management

Очевидный для ML-инженера факт: если на вход модели подать мусор — на выходе тоже будет мусор. Это правило действует всегда, независимо от того, насколько у нас крутая модель. Поэтому важно понимать, как ваши данные будут храниться, использоваться, версионироваться и воспроизведутся ли при этом результаты экспериментов. Для всех перечисленных задач есть множество различных инструментов: DVC, MLflow, W&B, ClearML и другие. Git использовать недостаточно, потому что он не был спроектирован под требования ML. Но есть инструмент, который подходит для версионирования данных и не только — это ClearML. О нем я сегодня и расскажу.


Читать: https://habr.com/ru/companies/magnus-tech/articles/810435/

@database_design

Building AI With MongoDB: Integrating Vector Search And Cohere to Build Frontier Enterprise Apps



Read: https://www.mongodb.com/blog/post/integrating-vector-search-cohere-build-frontier-enterprise-apps

@database_design

Second Quarterly Update on Oracle Graph (2024)

Oracle Graph Server and Client 24.2 is now available for download for use with databases in the Cloud (OCI Marketplace image is available) and for databases on-premises. In this release we added new functionality to Graph Server Administrator Dashboard, support for extended LATERAL queries in Graph Server, and support for arbitrary expressions in the Create Property Graph statement for PGQL Property Graphs.

Read: https://blogs.oracle.com/database/post/second-quarterly-update-on-oracle-graph-2024

@database_design

Where is the Complexity? Part 2

Continuation of my series on the complexity of ensuring data consistency in microservice based applications.

Read: https://blogs.oracle.com/database/post/where-is-the-complexity-part-2

@database_design

Как и почему мы построили Единую историю операций на Citus DB

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

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


Читать: https://habr.com/ru/companies/gazprombank/articles/810477/

@database_design

Как Figma удалось открыть себе путь к почти бесконечному масштабированию баз данных

О нашем девятимесячном пути к горизонтальному шардингу Postgres-стека Figma и о возможности обеспечения (почти) бесконечной масштабируемости.

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

С 2020 года стек баз данных Figma вырос почти в сотню раз. Это хорошая проблема, ведь она означает, что наш бизнес расширяется. Но в то же время она стала причиной технических сложностей. В течение последних четырёх лет мы усиленно старались не отставать от прогресса и избегать потенциальных проблем, связанных с ростом. В 2020 году у нас работала единственная база данных Postgres, которая хостилась на самом большом физическом инстансе AWS, но к концу 2022 года мы уже создали распределённую архитектуру с кэшированием, репликами для чтения и десятком вертикально разделённых баз данных. Мы разбили группы связанных таблиц (например, «Figma files» или «Organizations») на отдельные вертикальные разделы, что позволило нам обеспечить удобство инкрементального масштабирования и оставить достаточно пространства для дальнейшего роста.


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

@database_design

Как Figma удалось открыть себе путь к почти бесконечному масштабированию баз данных

О нашем девятимесячном пути к горизонтальному шардингу Postgres-стека Figma и о возможности обеспечения (почти) бесконечной масштабируемости.

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

С 2020 года стек баз данных Figma вырос почти в сотню раз. Это хорошая проблема, ведь она означает, что наш бизнес расширяется. Но в то же время она стала причиной технических сложностей. В течение последних четырёх лет мы усиленно старались не отставать от прогресса и избегать потенциальных проблем, связанных с ростом. В 2020 году у нас работала единственная база данных Postgres, которая хостилась на самом большом физическом инстансе AWS, но к концу 2022 года мы уже создали распределённую архитектуру с кэшированием, репликами для чтения и десятком вертикально разделённых баз данных. Мы разбили группы связанных таблиц (например, «Figma files» или «Organizations») на отдельные вертикальные разделы, что позволило нам обеспечить удобство инкрементального масштабирования и оставить достаточно пространства для дальнейшего роста.


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

@database_design

Why run Oracle Database on Arm

Arm chips became popular on mobile and embedded devices and are now equally popular in the server market. The low energy consumption, lower cost of entry, and compelling performance of Arm chips have enabled database vendors to run databases on Arm-based servers. Oracle Database released its enterprise edition of Oracle Database on Arm in 2023.

Read: https://blogs.oracle.com/database/post/run-oracle-database-on-arm

@database_design

Создаём надёжные API для бэкенда при помощи конечных автоматов: подробное руководство

Я — бэкенд-разработчик, поэтому мне довелось по достоинству оценить, насколько важны конечные автоматы при построении надёжных систем, которые хорошо масштабируются. Конечные автоматы отлично подходят для моделирования сложной бизнес-логики и автоматизации переходов между состояниями. В этом посте будет разобрано, что представляют собой конечные автоматы, в чём их польза для бэкенд-разработки, и как с их помощью решать распространённые задачи.
Что такое конечные автоматы?

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

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

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

@database_design

Building AI with MongoDB: Conversation Intelligence with Observe.AI

The text discusses how Observe.AI uses MongoDB to power its AI-driven conversation intelligence platform. Observe.AI focuses on improving contact center performance by analyzing customer interactions. The company has developed advanced AI and ML models for tasks such as text classification and sentiment analysis. They also use speech processing techniques for tasks like automatic speech recognition. The text highlights the role of MongoDB in storing and processing unstructured data. Additionally, the text features an interview with Markandey Pathak, a certified developer in multiple programming languages, discussing the benefits of having a versatile skill set in the tech industry.

Read: https://www.mongodb.com/blog/post/building-ai-mongodb-conversation-intelligence-observe-ai

@database_design

Where is the Complexity? Part 3

Continuation of my series on the complexity of ensuring data consistency in microservice based applications.

Read: https://blogs.oracle.com/database/post/where-is-the-complexity-part-3

@database_design