Как подойти к внедрению DWH, чтобы не было «больно»? Какие методологии использовать и какой стек выбрать?
В статье рассказываем о том, кому стоит задуматься о внедрении DWH, как сократить вероятность ошибок на этапе разработки проекта, выбрать стек, методологию и сэкономить ИТ-бюджеты.
Читать: https://habr.com/ru/articles/809551/
@database_design
В статье рассказываем о том, кому стоит задуматься о внедрении DWH, как сократить вероятность ошибок на этапе разработки проекта, выбрать стек, методологию и сэкономить ИТ-бюджеты.
Читать: https://habr.com/ru/articles/809551/
@database_design
Векторные базы данных: простым языком про устройство и принцип работы
Только изучили один инструмент, как сразу же появились новые? Придется разбираться! В статье мы рассмотрим новый тип баз данных, который отлично подходит для ML задач. Пройдем путь от простого вектора до целой рекомендательной системы, пробежимся по основным фишкам и внутреннему устройству. Поймем, а где вообще использовать этот инструмент и посмотрим на векторные базы данных в деле.
Читать: https://habr.com/ru/companies/tochka/articles/809493/
@database_design
Только изучили один инструмент, как сразу же появились новые? Придется разбираться! В статье мы рассмотрим новый тип баз данных, который отлично подходит для ML задач. Пройдем путь от простого вектора до целой рекомендательной системы, пробежимся по основным фишкам и внутреннему устройству. Поймем, а где вообще использовать этот инструмент и посмотрим на векторные базы данных в деле.
Читать: https://habr.com/ru/companies/tochka/articles/809493/
@database_design
Временное хранилище данных на Apache Druid: почему это эффективно сработало для загрузки табличных файлов
Всем привет! Меня зовут Амир, я Data Engineer в компании «ДЮК Технологии». Расскажу, как мы спроектировали и реализовали на Apache Druid хранилище разрозненных табличных данных.
В статье опишу, почему для реализации проекта мы выбрали именно Apache Druid, с какими особенностями реализации столкнулись, как сравнивали методы реализации датасорсов.
Читать: https://habr.com/ru/articles/809751/
@database_design
Всем привет! Меня зовут Амир, я Data Engineer в компании «ДЮК Технологии». Расскажу, как мы спроектировали и реализовали на Apache Druid хранилище разрозненных табличных данных.
В статье опишу, почему для реализации проекта мы выбрали именно Apache Druid, с какими особенностями реализации столкнулись, как сравнивали методы реализации датасорсов.
Читать: https://habr.com/ru/articles/809751/
@database_design
Collaborating to Build AI Apps: MongoDB and Partners at Google Cloud Next '24
Read: https://www.mongodb.com/blog/post/collaborating-build-ai-apps-mongodb-partners-google-cloud-next-24
@database_design
Read: https://www.mongodb.com/blog/post/collaborating-build-ai-apps-mongodb-partners-google-cloud-next-24
@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
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
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
В 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
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
Read: https://mariadb.com/?p=39164
@database_design
Это база: нюансы работы с Redis. Часть 2, репликация
Всем привет, на связи Пётр, инженер компании Nixys. В прошлой статье мы разобрали основные концепции Redis. Теперь рассмотрим базовую репликацию Redis и настроим эту БД на высокий уровень отказоустойчивости.
Читать: https://habr.com/ru/companies/nixys/articles/805463/
@database_design
Всем привет, на связи Пётр, инженер компании 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
В статье описывается практическое применение популярных 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
В статье описывается практическое применение популярных 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 размером 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
Делаем резервное копирование кластера 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
Очевидный для 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
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
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
Oracle
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…
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
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
Oracle
Where is the Complexity? Part 2
Continuation of my series on the complexity of ensuring data consistency in microservice based applications.
Как и почему мы построили Единую историю операций на Citus DB
Доступ к единой истории операций — функция, которую сегодня ожидают видеть пользователи любого современного интернет-банкинга. В приложениях Газпромбанка функция существует уже много лет, но некоторое время назад мы решили существенно её переработать. В этой статье я расскажу, что мы поменяли, как и почему мы решили это сделать, а также почему мы гордимся результатом.
Сразу оговорюсь, что не буду углубляться в технические детали и остановлюсь на подходе, который мы решили использовать. Иначе есть риск что статья превратится в километровое полотнище. А если возникнут вопросы, то либо отвечу на них в комментах, либо аккумулирую и попробую разобрать в следующей статье.
Читать: https://habr.com/ru/companies/gazprombank/articles/810477/
@database_design
Доступ к единой истории операций — функция, которую сегодня ожидают видеть пользователи любого современного интернет-банкинга. В приложениях Газпромбанка функция существует уже много лет, но некоторое время назад мы решили существенно её переработать. В этой статье я расскажу, что мы поменяли, как и почему мы решили это сделать, а также почему мы гордимся результатом.
Сразу оговорюсь, что не буду углубляться в технические детали и остановлюсь на подходе, который мы решили использовать. Иначе есть риск что статья превратится в километровое полотнище. А если возникнут вопросы, то либо отвечу на них в комментах, либо аккумулирую и попробую разобрать в следующей статье.
Читать: 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
О нашем девятимесячном пути к горизонтальному шардингу 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
О нашем девятимесячном пути к горизонтальному шардингу Postgres-стека Figma и о возможности обеспечения (почти) бесконечной масштабируемости.
Вертикальное разбиение было относительно простым и важным инструментом масштабирования, позволившим нам быстро добиться существенных улучшений. Кроме того, оно стало важным этапом на пути к горизонтальному шардингу.
С 2020 года стек баз данных Figma вырос почти в сотню раз. Это хорошая проблема, ведь она означает, что наш бизнес расширяется. Но в то же время она стала причиной технических сложностей. В течение последних четырёх лет мы усиленно старались не отставать от прогресса и избегать потенциальных проблем, связанных с ростом. В 2020 году у нас работала единственная база данных Postgres, которая хостилась на самом большом физическом инстансе AWS, но к концу 2022 года мы уже создали распределённую архитектуру с кэшированием, репликами для чтения и десятком вертикально разделённых баз данных. Мы разбили группы связанных таблиц (например, «Figma files» или «Organizations») на отдельные вертикальные разделы, что позволило нам обеспечить удобство инкрементального масштабирования и оставить достаточно пространства для дальнейшего роста.
Читать: https://habr.com/ru/articles/810185/
@database_design