Shardman. Краткое пособие архитектора

Миф о волшебном параметре fast=true жив и здоров, но в распределённых СУБД появляется ещё один — distributed=true. Ни тот, ни другой не спасут, если не пересобрать схему, ключи шардирования, последовательности, запросы и процесс миграции. Мы трезво проходим по всем углам: от выбора ключей и colocated-таблиц до CDC, топологий и ограничений внешних ключей; показываем, где действительно ускорится, а где станет дороже — и что с этим делать.

https://habr.com/ru/companies/postgrespro/articles/939396/

#шардирование #шардинг #postgresql #база_данных #postgres_pro #shardman #postgres_pro_shardman

[Перевод] Оптимизация поисковых систем: баланс между скоростью, релевантностью и масштабируемостью

Будучи разработчиками, мы постоянно стремимся создавать системы, которые не просто работают, но и отличаются эффективностью и масштабируемостью. В мире, где пользователи ожидают всё более быстрые и точные результаты, оптимизация производительности поиска становится ключевым приоритетом в современной разработке приложений. Эта статья основана на нашем выступлении на конференции QCon San Francisco 2024, где мы рассмотрели эволюцию подходов к индексированию данных, их извлечению и ранжированию. Для платформ вроде Uber Eats, обрабатывающих сложные запросы на больших объёмах данных, оптимизация поиска — это серьёзный вызов, требующий продвинутых стратегий: индексирования, шардинга и параллельной обработки запросов. Сложность поисковых систем продолжает расти, и необходимость соблюдения баланса между скоростью, релевантностью и масштабируемостью становится как никогда актуальной. В этой статье мы рассматриваем ключевые техники таких оптимизаций и их влияние на пользовательский опыт и производительность системы.

https://habr.com/ru/companies/otus/articles/934186/

#шардинг #Индексирование #поиск #Масштабируемость #производительность #apache_kafka #apache_spark #big_data #ранжирование

Как мы делали Go-VShard-router

Привет, меня зовут Нуржан Сактаганов, я ведущий разработчик в Почте и Облаке Mail. Хочу рассказать о нашей библиотеке Go-VShard-router и поделиться трюками и выводами, которые мы сделали при разработке.

https://habr.com/ru/companies/vk/articles/897488/

#golang #tarantool #vshard #шардинг

Используем несколько баз данных в Laravel

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

https://habr.com/ru/articles/896568/

#mysql #postgresq #laravel #шардинг #оптимизация #php #2_базы_данных

[Перевод] Путь к масштабированию PostgreSQL: от теории к практике

"Postgres масштабируется" - нет других двух слов, которые вызывали бы больше споров. По крайней мере, в кругах, где я общаюсь, в подвале компании, где инфраструктурные эльфы заставляют Rails-приложение работать. Многие верят, вопреки всему и маркетинговым кампаниям Big NoSQL, что знакомая технология лучше, чем новый неизвестный инструмент, о котором только что рассказали на совещании руководства. Честно говоря, я понимаю их позицию. Заставить Postgres писать больше данных может быть сложно. Вам нужно больше оборудования. В большинстве случаев его можно получить, просто нажав кнопку "Обновить". Но когда вы дошли до экземпляра r5.24xlarge с 5 репликами такого же размера, и ваши процессы vacuum всё ещё отстают от графика, ситуация становится довольно пугающей. Именно здесь начинается испытание для настоящего инженера. На пределе возможностей. Я говорю не о WebAssembly . Я говорю об инженерном духе, который смотрит на проблему под давлением руководства и вместо того, чтобы бежать к ближайшей команде продаж с большими обещаниями (но малым количеством фактов о вашем конкретном случае), решает её, используя базовые принципы. А базовый принцип говорит нам, что нам нужно. У Postgres закончилась пропускная способность для записи. Либо из-за блокировок при работе с WAL , либо что-то застопорило vacuum. Вероятно, это та неактивная транзакция, которая открыта уже 45 секунд, пока приложение делает запрос к Stripe, но это не наша забота. Мы - инфраструктурная команда, и наша задача - заставить базу данных работать.

https://habr.com/ru/articles/891122/

#postgresql #шардинг #масштабирование_postgresql #репликация_базы_данных #отказоустойчивость #высокие_нагрузки #базы_данных #devops #оптимизация #инфраструктура

Горизонтальное масштабирование базы данных. Репликация. Партицирование. Шардирование

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

https://habr.com/ru/articles/875708/

#базы_данных #масштабирование #горизонтальное_масштабирование #репликация #партиционирование #шардинг #шардирование #партицирование #system_design #программирование

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

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

https://habr.com/ru/articles/810185/

#figma #postgres #sql #шардинг

Шардирование (sharding). Эпизод 2: шардирование по гео

Viam supervadet vadens (дорогу осилит идущий) Есть много счастливчиков, которым повезло работать в ситуации, когда объёмы по-настоящему огромны и требования кажутся невыполнимыми. Но есть те, кому по настоящем крупно повезло! Я говорю о тех, кто решал задачи в пространствах, где размерность больше 1. Давайте разбросаем осколки по всей земле? Разбрасываем?

https://habr.com/ru/articles/807931/

#шардирование #шардинг #распределенные_системы #архитектура

Шардирование (sharding). Эпизод 1: Начало и шардирование по идентификатору

Divide et impera (разделяй и властвуй) – древний принцип для управления чем-то большим и сложным. Многие из нас программируют. Многие из нас делают системы, сложные системы. Но некоторым повезло работать в ситуации, когда объёмы по-настоящему огромны и требования кажутся невыполнимыми. Шардировние – один из излюбленных счастливчиками, которых зовут приключения, приемов. Что-нибудь разбить на кусочки – это круто! Переходите на сторону шардирования у нас есть печеньки! За кусочками!!!

https://habr.com/ru/articles/804827/

#шардирование #шардинг #распределенные_системы #архитектура

Записки хирурга. Распиливание слонов PostgreSQL наживую и без анестезии

Привет, Хабр! С вами снова AliExpress Order Management System. Сегодня поговорим о том, как мы увеличивали количество шардов без длительного даунтайма. Спойлер: в конце - самое интересное ;) Дальше

https://habr.com/ru/companies/aliexpress_russia/articles/796409/

#Решардинг #postgresql #базы_данных #бакет #система #ecommerce_solutions #шардинг

Решил освежить в памяти тему шардинга, читаю статью, ору:

Another reason why some might choose a sharded database architecture is to speed up query response times. When you submit a query on a database that hasn’t been sharded, it may have to search every row in the table you’re querying before it can find the result set you’re looking for. For an application with a large, monolithic database, queries can become prohibitively slow.

Индексы вышли из чата.

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

В статейке диджиталоушена в одном абзаце говорят что шард-кей должен быть статичным, в другом что это может быть email пользователя. :philosoraptor:

Хотя, если добавлять шарды основываясь на диапазонах значений, то политика "выбрать самый неравномерно жирный шард и разрезать его диапазон так, чтобы выкинуть с него хотя бы 30% данных" - вроде неплохой заход, никакой параллельной дрочильни всех нод (только ту, которая и так страдает, кек).