NoSQL *

Для чего существуют принципы ACID? Можно ответить по бумажке, сказать, что это нужно для того, чтобы каждая транзакция обрабатывалась надежно, данные оставались в безопасности и системы работали предсказуемо.

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

В этой статье вы узнаете, почему так важны принципы ACID и что это за принципы. Оставайтесь со мной, если интересно!

Научная группа из Московского Энергетического Института сделала обзор основных преимуществ баз данных SQL или NoSQL. Итак, в чем разница между данными базами данных, и какую базу данных выбрать в том или ином случае? Представьте, что вам нужно организовать хранение информации. У вас есть два подхода: аккуратно разложить всё по папкам с ярлыками в строгом порядке (это SQL) или скинуть всё в один большой складской ящик, но с умной системой быстрого поиска нужной вещи (это 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). Завершим чеклистом, который поможет выбрать оптимальный индекс под вашу задачу.