NoSQL *

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

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

Всем привет! Это моя первая статья на Хабре и в ней я хочу рассказать о том, как мы можем интегрировать Elasticsearch в наше Spring Boot приложение. Этот проект предназначен для ознакомления с технологиями и служит скорее шпаргалкой/пособием или же фундаментом для дальнейшего погружения в тему.

Hyper Chance: Этап 0. Знакомство

Hyper Chance - бесплатный технический акселератор коммерческих проектов от Hyper Dev Guild для разработчиков на основе фреймворка $mol

Обратная связь приветствуется! ^-^

Это третья и заключительная статья из цикла, в которой рассмотрим стандартную модель ранжирования документов в Elasticsearch.

После того как определено множество документов, которые удовлетворяют параметрам полнотекстового запроса, Elasticsearch рассчитывает метрику релевантности для каждого найденного документа. По значению метрики набор документов сортируется и отдается потребителю.

В Elasticsearch существует несколько моделей ранжирования документов. По умолчанию используется Okapi BM25.

В Redis уже много лет используется язык программирования Lua для исполнения пользовательского кода налету (eval) или определении пользовательских функций. Lua действительно удобный язык, но скорее с точки зрения встраивания внутрь проекта на C/C++ для выполнение простых скриптов. Большинство же разработчиков, которые используют Redis, предпочли бы не учить новый язык, а работать с уже известным и более популярным скриптовым языком, таким как JavaScript. И это наконец-то случилось.

Предлагаю ознакомиться с тем, как команда Redis в релизе 7.2 дошла до долгожданного внедрения JavaScript и как сделать первый шаги по запуску триггеров и функций.

В мире баз данных идентификаторы имеют решающее значение для уникальной идентификации записей. Традиционно многие разработчики предпочитали автоматически увеличивающиеся целочисленные идентификаторы. Однако есть еще один вариант, который набирает популярность: универсально уникальные идентификаторы (UUID). В этой статье мы рассмотрим, почему UUID часто являются лучшим выбором по сравнению с автоматически увеличивающимися идентификаторами.

Автор статьи: Артем Михайлов

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

В статье я рассмотрю: с чего начать миграцию, зачем нужна миграция, подход PoC и парадигмы баз данных, тестирование и стратегии миграции.

Это вторая статья из цикла. В первой части я рассказывал про самые базовые понятия Elasticsearch. В этом же посте разберем устройство анализа текста и немного пощупаем полнотекстовый поиск.

Несколько слов про анализ текста

Анализ текста — процесс преобразования оригинального текста в структурированный формат, оптимизированный под эффективное хранение и быстрый поиск.

Мы уже познакомились с некоторыми типами Elasticsearch, но в этом разделе будем рассматривать только два — keyword и text. Тип text анализируется для полнотекстового поиска. Тип keyword преимущественно остается без изменений для точного поиска, сортировки и агрегации.

Привет! Меня зовут Глеб, я разработчик команды продукта «Сервис персонализации» в SM Lab. В цикле из трех постов я расскажу про основы полнотекстового поиска в Elasticsearch.

Данный цикл статей предназначен для всех, но будет особенно актуальным для тех читателей, кто только начинает свое знакомство с Elasticsearch. Я надеюсь, каждый из вас найдет что-то полезное для себя.

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

Итак, начнём с самых базовых понятий.

Всех приветствую! Меня зовут Кирилл, я Go-разработчик в компании Ozon. Сейчас моим полем деятельности является разработка микросервисов в департаменте Fresh, однако я также успел принять участие в некоторых других интересных проектах.

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

На кластерах клиентов, которые мы обслуживаем, есть как «одноголовые» инсталляции Redis (обычно для кэшей, которые не страшно потерять), так и более отказоустойчивые решения — Redis Sentinel или Redis Cluster. По нашему опыту, во всех трех вариантах можно безболезненно переключиться с Redis на KeyDB и получить прирост производительности. Точнее, избавиться от бутылочного горлышка Redis в одно ядро. Хотя в новых версиях Redis(r) появилась обработка I/O в отдельных тредах, иногда этого бывает недостаточно.

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

В итоге у нас есть несколько реплик довольно дорогого in-memory-хранилища, а в рабочем процессе используется только часть из них. Остальные — на подхвате. Хотя в большинстве кейсов операции с in-memory NoSQL DB — это именно операции чтения.

Однако если посмотреть в сторону KeyDB, то можно увидеть, что там есть киллер-фича — и даже две: я говорю о режимах Active Replica и Multi-Master. Использование этих режимов позволяет получить распределенный отказоустойчивый KeyDB, совместимый с Redis, писать в любую ноду, читать из любой ноды. И все это с точки зрения приложения выглядит как один экземпляр Redis без всяких Sentinel — то есть в коде приложения ничего менять не придется. 

Звучит как фантастика?

Исповедь о том как принес в проект проблему, которую так и не устранил в течение долгого времени.

Осторожно! Статья может вызвать обострение профессиональных заболеваний вплоть до боли ниже поясницы.

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а также можем предоставить оптимальную конфигурацию для системы, которая передана на эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.

В материале я расскажу именно об Apache Cassandra: какие ошибки можно совершить при ее использовании, на что стоит обратить внимание и чем лучше не пренебрегать.

Cost reduction - весьма популярное направление, особенно в дни кризиса IT. Вполне естественным является желание оптимизации расходов на “железо” с минимальной потерей производительности, ведь чем больше данных хранится, тем больше может оказаться профит. В данной статье описан кейс эксплуатации Cassandra на HDD дисках как один из способов оптимизации, имеющей смысл при достаточно большом объеме данных.

Я стал большим сторонником DynamoDB за последние несколько лет. Эта база данных имеет много сильных сторон, которых нет у конкурентов, таких как гибкая ценовая модель, соединение без состояния (stateless), которое прекрасно работает для беcсерверных (serverless) вычислений, и постоянное время ответа, даже когда ваша база данных масштабируется до огромных размеров.

Однако разработка структуры данных с помощью DynamoDB вызывает трудности у тех, кто привык к реляционным базам данных, которые доминировали в течение последних нескольких десятилетий. Существует несколько особенностей в создании структуры данных с помощью DynamoDB, но самая значимая - это рекомендация от AWS использовать одну таблицу для всех ваших записей.

Привет, Хабр! Меня зовут Евгений Абрамкин, я руководитель поддержки третьего уровня в направлении омниканальных решений Лиги Цифровой Экономики. Моя команда — последняя «инстанция» во флоу по решению инцидентов. Мы пишем доработки и фиксы, чтобы победить проблему клиента, а еще предоставляем оптимальную конфигурацию для системы, которая передана в эксплуатацию или требует масштабирования. Это может быть кластер Elasticsearch, балансировщики nginx или что поинтереснее — распределенная NoSQL СУБД Apache Cassandra.