NoSQL *

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

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

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

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

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

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

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

Комментарии в соцсетях — это как чипсы: начал читать, остановиться невозможно. Но в ОК до 2024 года они были плоскими — вместо структурированного диалога под постом пользователи видели бесконечную ленту сообщений, где ответы терялись в хронологическом порядке. Представьте: под постом про котиков кто-то спросил про корм, но ответ на вопрос появился в самом низу, через 500 комментариев с обсуждением хвостатых. Найти ответ на вопрос в такой системе, если он вообще существует, — тот ещё квест.

Меня зовут Александр Косницкий. Я разработчик в компании ОК. В этой статье я расскажу, как мы переходили с линейной структуры отображения комментариев к древовидной: с чего начали, с чем сталкивались и что получили в результате.

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

Времени на всё про всё, как водится, было по минимуму. Мы закатали рукава, вооружились всеми доступными инструментами — и начали подбирать решение для каждой проблемы. Ниже опишу, что представлял собой проект и какие именно задачи заставили нас поднапрячься.

Redis — это высокопроизводительное хранилище «ключ-значение» в оперативной памяти, известное своей невероятной скоростью. Фактически, один сервер Redis может обрабатывать до 100 000 запросов в секунду (QPS). Такая скорость часто удивляет, особенно если учесть, что Redis в основном работает по однопоточной модели обработки запросов. Так почему же Redis работает так быстро, несмотря на однопоточный подход? Давайте рассмотрим ключевые факторы, влияющие на производительность Redis.

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

Всем привет. Меня зовут Женя Редько, я работаю в ядре Диадока — это сервис электронного документооборота от Контура. В моей подкоманде Документов мы занимаемся основными бизнес-сценариями Диадока. 

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

Современные web-фреймворки для реализации управления состоянием используют библиотеки, такие, например, как Redux для React или Pinia для Vue. У традиционной реализации управления состоянием есть недостатки. Store в таком варианте является частью скрипта страницы, и его данные при её перезагрузке теряются. Кроме того, если нам в приложении нужно организовать управление отображением контента в нескольких окнах браузера, оказывается, что традиционный Store не может этого обеспечить.

Да будет Хабр снова торт! Да приидут на него статьи о программировании! И да пребудут на нем всегда технические обсуждения. А теперь к делу... Каждый развивающийся программист, рано или поздно сталкивается с тем, что ему нужна облачная база данных для своего проекта. Между тем, ваш проект может быть не денег ради, а души для, друзей, знакомых, небольшой аудитории, и посему платить деньги за настоящее облачное хранилище данных жалко. Предлагаю вам простое в подключении, проверенное мной лично, хакерское решение, в котором не потребуется указывать никаких платежных или личных данных...

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

No subject appears to be more controversial to distributed systems engineers than the oft-quoted, oft-misunderstood CAP theorem. The CAP FAQ

— Сейчас я тебе объясню... — Объяснить я и сам могу, ты расскажи, что на самом деле происходит! (Из разговора политологов, но для CAP-теоремы подходит тоже)

— Давайте уже запишем CAP-теорему на языке Coq и посмотрим, что там на самом деле. (Я)

Как мы создали микросервисное приложение для анализа вакансий с hh.ru: Docker, Kafka, Elasticsearch и ещё немного магии

Наша компания — Netflix — способна организовывать бесперебойную, высококачественную потоковую передачу видео миллионам пользователей благодаря своей надёжной глобальной серверной инфраструктуре. В самом центре этой инфраструктуры лежит множество онлайновых распределённых баз данных. Среди них — Apache Cassandra — NoSQL-СУБД, известная высокой доступностью и хорошей масштабируемостью. Cassandra играет роль опорной технологии для множества самых разных возможностей Netflix: от механизма входа пользователя в систему — до хранения истории просмотренных материалов и до поддержки аналитики реального времени и прямых трансляций.

Со временем появлялись новые базы данных типа «ключ-значение» (Key-Value, KV), владельцы сервисов вводили в строй новый функционал. В результате мы столкнулись с массой сложностей, связанных с неправильным использованием хранилищ данных. Во-первых — разработчикам сложно оперировать такими понятиями, как производительность хранилищ данных, согласованность и устойчивость данных. Ведь речь идёт о взаимодействии со сложной системой глобальных масштабов, представленной множеством хранилищ. Во-вторых — разработчикам приходилось постоянно переучиваться, осваивая новые подходы к моделированию данных и распространённые, но очень важные паттерны доступа к данным. В перечень сложностей, встающих перед разработчиками, входят высокие задержки, которым подвержен небольшой процент запросов, находящихся в «хвосте» распределения задержек (tail latency) и идемпотентность операций. Тут же можно упомянуть и поддержку работы «широких» разделов хранилищ с множеством строк, и работу в условиях, когда для хранения данных применяется единственный «толстый» столбец, и медленную пагинацию ответов. Кроме того — наши системы были связаны с множеством собственных API разных баз данных — с API, которые постоянно развивались, и в которых иногда появлялись изменения, нарушающие обратную совместимость. Всё это привело к тому, что инженеры, в масштабах всей организации, тратили много времени на поддержку и оптимизацию механизмов доступа к данным наших микросервисов.

Redis — хранилище из семейства нереляционных (NoSQL) баз данных. Redis является очень быстрым хранилищем данных благодаря своей архитектуре in-memory. Он идеально подходит для задач, требующих быстрого доступа к данным, таких как кэширование, очереди сообщений, сессионная информация и многое другое. Go также известен своей высокой производительностью за счет компиляции в машинный код и эффективного управления памятью.

Инструменты Firebase уже больше десятилетия помогают разработчикам быстрее создавать приложения, начиная с push-уведомлений и аутентификации и заканчивая базой данных Firestore. В этом году на Google I/O было анонсировано, что Firestore теперь поддерживает SQL в форме Data Connect, наконец позволив разработчикам выбирать между NoSQL и SQL.

Представьте, что вы возвращаетесь домой и замечаете, что кто-то съел ваш ужин или полежал на вашей кровати. Не нравится? Вот и владельцам информационных систем не нравится, когда они не могут понять, кто же хулиганит в их бизнес-процессах. Меня зовут Светлана Мелешкина, и я ведущий разработчик Банка Идей НЛМК. Именно в Банке Идей иногда происходили такие детективные истории.

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

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

В статье рассматриваются основные принципы и особенности использования Redis в режиме Pub/Sub для масштабируемых и высоконагруженных приложений. Описаны два подхода к обеспечению высокой доступности — Redis Sentinel и Redis Cluster, их преимущества, ограничения и примеры настройки. Приведены примеры использования Pub/Sub в реальных системах, а также практические конфигурации и код для настройки отказоустойчивого кластера Redis. Статья предназначена для разработчиков, которые ищут решения для создания надежных систем обмена сообщениями с высокой производительностью и отказоустойчивостью.

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

Эта статья предназначена для тех, кто хочет освоить основы Elasticsearch и научиться использовать его возможности на практике. Мы рассмотрим ключевые концепции, такие как индексы, документы и запросы, а также научимся настраивать окружение и выполнять основные операции. Независимо от того, являетесь ли вы разработчиком, аналитиком или просто хотите расширить свои знания о современных технологиях обработки данных, это руководство поможет вам уверенно шагнуть в мир Elasticsearch. Подготовьтесь к увлекательному путешествию в мир поисковых технологий!

Всем привет! Меня зовут Дмитрий Бахтенков, и я .NET-разработчик. Сегодня мы проведем эксперимент — напишем полноценное веб-приложение с использованием решений, которые написаны на C# и платформе .NET. Больше моих статей можно прочитать в медиа вАЙТИ.

Что я имею в виду?

Как мы знаем, в общем случае веб-приложение состоит из бэкенда, фронтенда, базы данных и иногда из кеша. С бэкендом и фронтендом всё понятно: у нас есть замечательный фреймворк ASP.NET Core для сервера и blazor или razor pages для клиента. Однако инфраструктурные части приложения — БД, кеши — чаще всего пишутся на других, более низкоуровневых языках, таких как C и C++.

К счастью, недавно Microsoft выпустила решение для кеширования — аналог Redis, который называется Garnet. В качестве основной базы данных можно использовать документную БД RavenDB, которая как раз написана на C#.