Cegorach
Die meistgenutzte #NoSQL-DB bleibt Excel.
Habr

Алгоритмы консенсуса Paxos, Raft и Zab в распределённых системах

В распределённых системах критически важно обеспечить консенсус – согласованность данных или решений между множеством узлов (серверов), даже при сбоях и задержках сети. Алгоритмы консенсуса позволяют группе несовершенных узлов действовать как единое надёжное целое. Три классических алгоритма – Paxos , Raft и Zab – стали основой для построения отказоустойчивых систем. Они гарантируют, что при наличии кворума узлов (обычно большинства) все узлы придут к единому решению и последовательности операций, сохраняя консистентность данных. В данной статье мы рассмотрим устройство этих алгоритмов «под капотом», их этапы (выбор лидера, репликация журнала, обработка сбоев и восстановление), области применения в реальных системах (от координаторов в кластерах Kubernetes и Apache Kafka до распределённых баз данных), а также сравним готовые реализации (такие как etcd, ZooKeeper, Consul и др.) по ключевым характеристикам.

habr.com/ru/articles/903792/

#paxos #raft #микросервисы #sql #nosql #распределенные_системы #высоконагруженные_проекты #высоконагруженные_приложения #высокая_доступность #высокая_нагрузка

Алгоритмы консенсуса Paxos, Raft и Zab в распределённых системах

Введение В распределённых системах критически важно…

Хабр
Linuxiac

Redis, a popular in-memory data store, is being deprecated in Arch Linux's repo; Valkey steps in as a high-performance BSD-licensed replacement.
linuxiac.com/arch-says-goodbye

#arch #redis #valkey #nosql #database #OpenSource

Habr

Выбор индексов в базах данных для highload-систем

Индексы – это «ускорители» доступа к данным в базах данных. Правильно выбранные индексы могут многократно ускорить запросы, что особенно критично в highload-системах с большими объёмами данных и большим числом запросов. Однако за ускорение чтения приходится платить усложнением записи и дополнительным расходом памяти. В этой статье мы подробно рассмотрим, как работают разные типы индексов в реляционных СУБД, как выбирать индекс под конкретный запрос, обсудим подводные камни (например, блоат, переиндексация, избыточные индексы) и затронем индексацию в NoSQL (MongoDB, Cassandra). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.

habr.com/ru/articles/897766/

#postgresql #mysql #mongo #cassandra #sql #nosql #базы_данных #нагрузка #высокая_производительность #распределенные_системы

Выбор индексов в базах данных для highload-систем

Введение Индексы – это «ускорители» доступа к данным…

Хабр
Habr

Как правильно выбрать базу данных для разработки: понимание моделей репликации

Выбор подходящей системы управления базами данных (СУБД) — важнейшая задача при проектировании программных систем. Разработчики и архитекторы учитывают множество факторов: модель данных (реляционная или NoSQL), поддержку транзакций, масштабируемость, требования к согласованности и многого другое. Одним из ключевых архитектурных аспектов, влияющих на эффективность и надежность системы, является модель репликации данных . Репликация означает поддержание копий одних и тех же данных на нескольких узлах (серверах), соединённых по сети​. Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​. Однако реализация репликации сопряжена с серьёзными архитектурными компромиссами. Согласно теореме CAP, в распределённой системе невозможно одновременно гарантировать все три свойства: консистентность данных, доступность сервиса и устойчивость к разделению сети. При возникновении сетевых сбоев (разбиении на изолированные сегменты) системе приходится жертвовать либо мгновенной согласованностью данных, либо доступностью части узлов. Поэтому разные СУБД делают разные выборы в этих компромиссах. Архитектурная модель репликации , лежащая в основе СУБД, определяет, как база данных достигает (или не достигает) консистентности, доступности и отказоустойчивости. Понимание этих различий крайне важно для архитекторов и разработчиков: зная поведение репликации, вы сможете выбрать такую СУБД, которая лучше соответствует требованиям вашего проекта по масштабу, геораспределенности, допустимой задержке и устойчивости к сбоям.

habr.com/ru/articles/895544/

#sql #nosql #mongodb #postgresql #cassandra #web_scalability #базы_данных #разработка #сервисы #нагрузка_на_сервер

Как правильно выбрать базу данных для разработки: понимание моделей репликации

Введение Выбор подходящей системы управления базами…

Хабр
Habr

5 причин плохого настроения. История одного Flutter-проекта, который заставил нас поломать голову

Привет! На связи Никита Грибков, Flutter-разработчик AGIMA. В прошлом году я стал свидетелем жутких событий, которые разворачивались на одном из наших проектов. В сущности, жуткими они были только потому, что техзадание состояло из сложных и нестандартных задач — но всё-таки они изрядно потрепали нам нервы. Времени на всё про всё, как водится, было по минимуму. Мы закатали рукава, вооружились всеми доступными инструментами — и начали подбирать решение для каждой проблемы. Ниже опишу, что представлял собой проект и какие именно задачи заставили нас поднапрячься.

habr.com/ru/companies/agima/ar

#flutter #nosql #isar #bloc #модальные_окна #globalkeys #tween #AnimatedOpacity #ddd #drift

5 причин плохого настроения. История одного Flutter-проекта, который заставил нас поломать голову

Привет! На связи Никита Грибков, Flutter-разработчик…

Хабр
Wilda Software

LinkedIn, jak to wielka platforma, przetwarza dużo danych. Musi to robić szybko i sprawnie, stąd tutaj zwykła baza danych nie wystarczy i infrastruktura jest "trochę" większa. Warto wiedzieć, jak to robią duże serwisy.

#DataProcessing #NoSQL #SQL #Oracle #BazaDanych #ArchitekturaOprogramowania

blog.bytebytego.com/p/how-link

How LinkedIn Scaled User Restriction System to 5 Million Queries Per Second

Disclaimer: The details in this post have been derived…

ByteByteGo Newsletter