NoSQL *

Всем привет! Я Илья Глазунов, системный аналитик в проекте карточного хранилища T-Pay Online — быстрого способа оплаты для наших клиентов. В качестве БД в проекте хранилища мы используем Apache Cassandra. В статье — обзорный материал, который поможет познакомиться с БД.

В культуре Т-Банка важно, чтобы системные аналитики знали особенности интеграционных схем с другими компонентами, умели строить схемы БД так, чтобы минимизировать издержки, связанные с i/o-операциями. А еще — чтобы могли вычислять узкие места в кейсах и влиять на выбор верхнеуровневого компонента в проекте. 

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

Разберем, для чего нужна Cassandra, рассмотрим основные концепции архитектуры, разложим принципы проектирования БД с ее особенностями модели данных и затронем некоторые принципы расчета конфигурирования БД Cassandra.

Привет, Хабр! Меня зовут Анастасия Нечепоренко, я QA Lead и преподаватель курса "JavaScript QA Engineer" в Отус. В этой статье кратко разбираю самые живучие мифы о SQL и NoSQL и почему не стоит воспринимать выбор между ними как бинарный.

В интернете есть книги и множество статей, таких как эта, в которых авторы приводят аргументы в пользу использования Postgres для всего. Я решил рассмотреть один из вариантов использования — применение Postgres вместо Redis для кэширования. Я довольно часто работаю с API, поэтому я создал очень простой HTTP-сервер, который отвечает данными из этого кэша. Я начал с Redis, так как часто сталкиваюсь с этим на работе, а затем переключился на Postgres с использованием нежурналируемых таблиц и посмотрел, есть ли разница.

Быть или не быть? Стоит ли использовать key-value-базы данных в большом продакшне? На связи Иван Храмов, CTO МТС ID, и Николай Диденко, техлид из команды инфраструктуры МТС Web Services. Мы используем Cassandra в МТС ID и за годы эксплуатации познали и сильные, и слабые стороны этого решения.

Главная особенность и одновременно ограничение Cassandra и ScyllaDb — это то, что они строго key-value-хранилища. Именно с этим они справляются отлично — быстрое чтение и запись по ключу, георезервирование и масштабирование. На этом этапе все выглядит радужно.

Но по мере роста проекта возникает необходимость более сложной работы с данными. Например, когда хочется получить информацию в разрезе дат или понять, на каких устройствах какие токены живут. И вот здесь начинают всплывать ограничения архитектуры и типовые грабли, на которые можно наступить (и мы регулярно это делали). В этом материале мы опишем, почему выбрали Cassandra и с какими проблемами столкнулись — надеемся, это поможет правильно определиться с выбором нужного инструмента для ваших систем.

ClickHouse не тормозит, но теряет данные. Набор простых действий с объяснениями, позволяющий избежать потери данных.

ScyllaDB — это высокопроизводительная NoSQL база данных, созданная как улучшенная версия Apache Cassandra на C++. Она способна обрабатывать миллионы операций в секунду, что делает ее лидером среди распределенных баз данных. Такая производительность достигается благодаря особой архитектуре хранения данных, в центре которой находится процесс компактизации данных. Правильный выбор стратегии компактизации данных и ее оптимизация - это ключ к высокой производительности и отказоустойчивости распределенной базы данных ScyllaDB.

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

Привет, Хабр!

В этой статье мы коротко рассмотрим, как работает TTL в трёх популярных NoSQL-хранилищах — Redis, MongoDB и Cassandra.

Привет, Хабр! Это Александр Коваль, я разработчик IoT-сервисов в МТС Web Services. При работе с данными часто возникает вопрос: как быстро система может вернуть результат по определенным параметрам? Не является исключением и ScyllaDB.

Для ответа нужны инструменты измерения и возможность настраивать систему. Java-драйвер для ScyllaDB умеет передавать информацию о своей внутренней работе, и ему можно настроить отдельные компоненты. Звучит как отличный план — в этом материале я поделюсь результатами экспериментов с java-драйвером для ScyllaDB при различных запросах к данным.

Код, ссылки и ресурсы располагаются в GitHub.

Когда начинают говорить о транзакциях в redis некоторым представляется в голове что‑то типа «postgresql»: «...Суть транзакции в том, что она объединяет последовательность действий в одну операцию „всё или ничего“. Промежуточные состояния внутри последовательности не видны другим транзакциям, и если что‑то помешает успешно завершить транзакцию, ни один из результатов этих действий не сохранится в базе данных...». Если говорить в ЭТОМ контексте, то транзакций в redis НЕТ и мы имеем дело с морской свинкой («не морская и не свинка»). А что же есть и как это можно мониторить.

ScyllaDB — это высокопроизводительная распределённая NoSQL-база данных, совместимая с Apache Cassandra, но в разы более быстрая за счет того, что написана на C++. Однако, несмотря на сверхбыструю скорость работы, можно ли сделать ее еще быстрее?

До версии 7.4 в redis срок жизни можно было указать срок действия только для конкретного ключа. C версии 7.4 это можно сделать и для поля в хештаблиц(hashes).
Как это работает? Какие могут быть сложности с точки зрения удаления сущностей с истекшим сроком действия которые надо учесть при проектировании схемы хранения?
Текущая ситуация такова, что для ключей и полей хеш-таблиц это работает по разному.

Когда приходится работать большими redis базами в десятки Гб понимание “а как оно там?”, “откуда такой размер? - может быть полезно. База данных redis (статья написана по redis_version:8.0) это сложное хранилище состоящее из большого количества hash-таблиц...

Всем привет! Меня зовут Артемий Иванов, и это моя первая статья на Хабре. В ней я хочу поделиться опытом, который получил, работая над задачей кастомизации поиска.

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

Разобраться во всех нюансах было непросто — приходилось вникать в обилие терминов и тонкостей «на ходу». В этой статье я покажу, как можно сделать поиск гибче с помощью Spring Data Elasticsearch — и всё это на конкретных примерах из практики.

Привет, Хабр! Это Ахмед Шериев, сооснователь стартапа VoxOps, а сегодня — еще и гостевой автор блога Friflex. Это вторая статья про мой опыт разработки офлайн-приложений — первая была про кэширование.

Если пользователи в офлайне должны менять данные, а потом синхронизировать изменения с сервером, есть два основных подхода. Первый — синхронизировать сами данные. Второй — синхронизировать команды или события.

Привет, Хабр! Мое имя Александр Коваль, я разработчик IoT-сервисов в МТС Web Services. Сейчас ScyllaDB поддерживает ограниченное количество функций, в том числе агрегационных. В стандартном наборе: min, max, count, avg. Но ее функциональность расширяется двумя типами пользовательских функций: скалярными (scalar functions) и агрегационными (aggregate functions). Первые работают со значениями одной строки, а вторые — нескольких. Реализовать такие функции можно на Lua или Rust.

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

Дисклеймер: этот материал написан на основе личного опыта — все решения получены методом проб и ошибок. Конструктивные предложения и советы по их улучшению приветствуется. Код с примерами и ссылки на ресурсы можно найти у меня в репозитории GitHub.

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

Apache Kafka является одной из самых популярных платформ для обработки потоков данных, обеспечивая высокую пропускную способность и низкие задержки при передаче сообщений. В высоконагруженных системах, где необходимо обрабатывать миллионы сообщений в секунду, важность правильной настройки Kafka трудно переоценить. Без оптимизации её параметров можно столкнуться с серьёзными проблемами, такими как рост задержек, потеря сообщений и переполнение очередей. Эффективная настройка Kafka критична для обеспечения бесперебойной работы в условиях высокой нагрузки и стабильной обработки данных в реальном времени.

Цель этой статьи — рассмотреть основные аспекты настройки Apache Kafka, которые влияют на производительность системы. Мы сосредоточимся на оптимизации параметров брокеров и продюсеров для достижения максимальной пропускной способности, минимальных задержек и надежности. Также рассмотрим важность мониторинга и тестирования системы для своевременного выявления и устранения узких мест.

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

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

C Neo4j я познакомился ещё в далеком 2018-м году, в рамках задачи создания более приятной системы корпоративных знаний чем классические Wiki (некий такой корпоративный Obsidian), ну или основные его части. Это сейчас вы можете радоваться всем благам цивилизации, а в то далёкое время нам надо было очень внимательно относиться к структуре корпоративной базы знаний, т.к. даже поисковые алгоритмы часто оставляли желатель лучшего. Никакого вам ранжирования статей в выдаче по просмотрам и времени создания.

Но в целом с точки зрения базы знаний даже текущие варианты Wiki с ранжированием статей, отображением связанных, последних просмотренных, которые смотрят вместе и т.п. всё равно не решает вопрос оперативного поиска информации. А вот граф - уже другая история. Использовали Obsidian? Понравилось представление информации связанных заметок? Особенно если качественно проставлять связи. Собственно именно таким образом мы обычно и оперируем информацией. Табличная модель конечно удобна, но несколько более синтетическая история, которую придумали чтобы упростить себе жизнь, потому как оперировать графами технически всё-таки более сложная история.

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

Зачем это нужно? Репликация позволяет: во-первых, держать данные ближе к пользователям (уменьшая задержку при запросах); во-вторых, продолжать работу системы даже при сбое отдельных узлов (повышая доступность); в-третьих, масштабировать систему, увеличивая число узлов для обслуживания запросов на чтение (повышая пропускную способность)​.

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