Шардирование гео-данных в Redis

В интернете много статей о том, как можно использовать Redis для реализации задач гео-поиска (поиск объектов поблизости, поиск объектов внутри определенной области и т..д). Во многих упоминается о том, что редис можно легко масштабировать горизонтально, добавляя шарды в кластер, при этом логика распределения данных по шардам он берет на себя, без необходимости реализовывать ее на уровне приложения. На деле же все оказывается не совсем так или совсем не так. Для тех, кто не хочет много читать про то, как мы реализовывали гео-поиск - ключевые слова: geoadd, georadius, пространственные индексы h3. Всем остальным - добро пожаловать под кат.

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

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

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

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

Оптимизация: типичные ошибки программистов и как их можно исправить

Привет, Хабр. Меня зовут Павел Преблагин, я работаю в команде инжиниринга производительности Positive Technologies. Мы анализируем разные продукты компании и пытаемся так или иначе оптимизировать их изнутри. Как уже можно понять, команда наша мультипроектная: у нас нет постоянной кодовой базы, кроме некоторых инструментов анализа и тестирования. Обычно коллеги из других отделов приносят нам для изучения свою, написанную преимущественно на C++, если у них есть подозрения, что что-то работает не так быстро, как должно было бы. Мы в ответ приносим им результаты замеров, патчи и рекомендации. Хотя наша команда относительно молодая, мы уже успели пройтись по нескольким таким продуктам и нанести непоправимую пользу. Все эти проекты разные и принадлежат разным командам, но мы заметили, что некоторые проблемы встречались в той или иной комбинации везде, носили общий характер, а решались примерно одинаково и порой без серьезных усилий. Цель этой статьи — показать подборку из таких, часто встречаемых, ситуаций вместе с возможными вариантами их решения. Кейсы могут показаться тривиальными или даже глупыми, но факт остается фактом: подобное мы наблюдаем с определенным постоянством и видели в других компаниях, еще до прихода в Позитив. Разобраться

https://habr.com/ru/companies/pt/articles/867146/

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

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

https://habr.com/ru/companies/gazprombank/articles/810477/

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

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

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

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

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

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

Внутри S3. Доклад Яндекса

Привет, я Паша, разработчик в Yandex Infrastructure, и я катаю гусей. С 2019 года я развиваю S3-хранилище как для внутренних пользователей Яндекса, так и для клиентов Yandex Cloud. А «гусём» называется наш бэкенд S3 API: он написан на Go, а из словосочетания Go + S3 получился goose. Возможно, вы также слышали про GeeseFS — это наш высокопроизводительный FUSE-клиент для S3. C его помощью вы можете на своём ноутбуке или виртуалке подмонтировать папку, которая будет работать с бакетом S3. Для чего нам «гуси» и прочая орнитология? Яндексовая инсталляция хранилища S3 хранит миллиарды файлов. Это огромные объёмы данных, а также метаданных. Для хранения метаданных мы научились использовать умное шардирование, и теперь сами управляем распределением занятого места и нагрузкой между шардами баз. Так что сегодня я расскажу, как сделать так, чтобы ни один клиент, даже с самым неудобным паттерном нагрузки, не положил сервис.

https://habr.com/ru/companies/yandex/articles/803703/

Шардирование: с нуля до Яндекс Диска

Меня зовут Андрей Колнооченко. Я отвечаю за ядро файловой системы Яндекс Диска. Когда мы запускали сервис, то сразу ориентировались на рост и приняли решение шардировать базу метаданных о файлах. Но за 11 лет Яндекс Диск настолько вырос, что нам пришлось трижды менять подход к шардированию. В статье расскажу, с какими проблемами мы сталкивались по мере роста сервиса и как от MongoDB пришли в итоге к PostgreSQL. Эта статья будет полезна, если вы планируете распределить нагрузку на вашу БД или вам просто интересен опыт развития БД для обработки большого числа запросов.

https://habr.com/ru/companies/oleg-bunin/articles/791018/

Распределенный SQL в Picodata

Недавно мы выпустили новую значительную версию Picodata — распределенной in-memory СУБД с открытым исходным кодом. Это продукт на основе Tarantool c поддержкой плагинов на Rust и некоторыми другими интересными особенностями, о которых можно почитать в статье Picodata: простое масштабирование Tarantool . Одно из главных улучшений в новом релизе Picodata 23.12 — возможность выполнять распределенные (кластерные) SQL-запросы непосредственно из консоли Picodata, без дополнительных настроек. Можно управлять глобальными и шардированными таблицами (DDL), модифицировать данные в них (DML) и, разумеется, читать из них (DQL). Также, мы теперь поддерживаем централизованное управление пользователями, ролями и привилегиями на основе списков контроля доступа (ACL), опять же — в рамках всего кластера. В этой статье я сосредоточусь на нескольких примерах простых SQL-запросов и покажу, как они выполняются для таблиц, распределенных по нескольким шардам. Это позволит лучше понять, как устроены такие таблицы и какие задачи мы решаем для работы с ними. Погрузиться в детали

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