NoSQL *

Одним из трендов при проектировании сервисов в последнее время выступает использование в качестве баз данных NoSQL-систем. Мы также стараемся идти в ногу со временем и, конечно же, имеем в своем IT-ландшафте несколько таких решений. Одно из них — шардированный кластер MongoDB. Эксплуатация этой СУБД сопряжена с проблемами производительности, архитектуры, взаимодействия и т.д. Удивительно, но факт - зачастую, все мы сталкиваемся с тем, что ошибаются разработчики самой СУБД. Кто бы мог подумать.., что после штатной перезагрузки узла конфигурационного сервера MongoDB в процессе обновления может произойти аварийное завершение работы сервиса базы данных и наш стенд превратится в «тыкву»!

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

Дисклеймер: нижеописанные события произошли после того, как была опубликована рекомендация производителя не использовать версию 4.4.4.

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

Мне не нравится тратить время на настройку SQL базы данных, думать, как управлять шардированием данных, тратить много времени на изучение интерфейсов коннекторов. Хочется просто написать несколько строчек кода и запустить его, чтобы все работало из коробки. В быстрой разработке распределенных приложений мне помогает Cartridge — фреймворк для управления кластерными приложениями на основе NoSQL базы данных Tarantool.

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

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

Однако недавно я понял, что хватит это терпеть и настало время разобраться что происходит под капотом, как это происходит и зачем. Статья подойдёт тем, кто каждый день работает с базами данных и не особо вникает в подробности, людям, кто как и я заинтересовался тем, как всё работает и не знает откуда начать копать или просто тем, кто хочет немного освежить своё понимание баз данных.

После публикации статьи “Какую СУБД выбрать и почему? (Статья 1)” ко мне поступили справедливые комментарии о том, что я не упомянул такие типы СУБД, как Time Series и Spatial. В этой статье я кратко опишу их и добавлю еще два типа — Search engines и Object-oriented (объектные).

Всем привет! В компании Querify Labs мы создаем компоненты СУБД, включая оптимизаторы SQL-запросов.

Любой SQL-запрос может быть выполнен множеством способов. Задача оптимизатора - найти эффективный план выполнения запроса.

В этой статье мы обсудим rule-based оптимизацию - популярную архитектуру оптимизатора, в котором планирование запроса разбито на последовательность атомарных трансформации. Мы рассмотрим особенности реализации данного подхода в Apache Calcite, Presto, и CockroachDB.

MongoDB — это NoSQL-база данных, которую в том или ином виде используют более четверти разработчиков. MongoDB и другие NoSQL-базы данных привлекают своей гибкостью: вместо жесткой схемы и вертикального масштабирования, у вас есть возможность развивать схему постепенно и масштабироваться горизонтально. Компания MongoDB вышла на биржу в 2017 году и сегодня стоит более 17 миллиардов долларов.

Документные базы данных используют вместо реляционных таблиц и столбцов вложенные пары ключ-значение. Одно из преимущество такого подхода в том, что вам не нужно преобразовать данные для взаимодействия с фронтендом — данные уже хранятся в необходимом виде (плюс-минус .map или .reduce). 

Работа с MongoDB через командную строку не всегда удобна, и в этом посте мы рассмотрим доступные графические инструменты.

Первая часть в серии статей про СУБД, в которых будут представлены простые и понятные критерии, на основе которых можно будет получить подсказку, какую СУБД выбрать для своего проекта.

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

NoSQL ("не только SQL") — это подход к проектированию баз данных, который позволяет хранить и запрашивать данные вне традиционных структур, используемых в реляционных базах данных. Он был создан в первую очередь для работы с неструктурированными данными, которые генерируются из многочисленных источников, таких как документы, аудио, видео, социальные сети и т.д. Базы данных NoSQL лучше всего подходят для современных приложений, где модели данных эволюционируют, а масштабируемость имеет большое значение. Эта база данных приобрела популярность в последние годы, поскольку сейчас компаниям приходится иметь дело с неструктурированными данными больше, чем когда-либо прежде. Эта модель хранит данные иначе, чем традиционные реляционные таблицы, позволяя хранить связанные данные в единой структуре данных. Базы данных NoSQL можно разделить на четыре категории:

Ядро Tarantool-а написано на C, а вся бизнес-логика создаётся на Lua. Это не самый сложный язык, но и не самый популярный. Поэтому сегодня я расскажу, как начать работать с Tarantool, написав всего три строчки кода на Lua. А всё остальное приложение написано на Golang. Чтобы было еще интереснее, я даю альтернативный вариант на Python. Что за проект? Делаем приложение, которое позволяет ставить метки на карте: дом, работа, первое свидание, первый Hello World, первый "too long wal write" Tarantool.

Поехали!

Многие не знают, что некоторые сложные для написания и неэффективные для выполнения SQL-запросы можно легко выразить и эффективно выполнить в графовой базе данных. Это справедливо даже для тех, кто уже знает, что графовые алгоритмы являются наиболее эффективным, а иногда и единственным решением для сложных бизнес-задач, таких как кластеризация пользователей (с использованием Лувенского алгоритма), поиск инфлюенсеров - людей или компаний (алгоритмом PageRank) или прогнозирование поведения пользователей для персональных рекомендаций (алгоритмом label propagation).

В этой статье мы опишем SQL запрос с 24 JOIN в корпоративный knowledge graph и покажем, что задачу можно решить в графовой базе данных - и это будет понятней, более легко поддерживаться и эффективно выполняться. Пример взят из проблемы, описанной в сообществе: https://community.tigergraph.com/

В декабре 2020 года, завершив работать в научном институте, я увлёкся задачей добычи данных из соцсетей, в частности из Инстаграма. Прежде я работал только с готовыми данными, поэтому мне всегда было интересно, как эти данные можно добывать. За несколько дней до Нового Года я написал достаточно базовую статью про то как парсить Инст. В первых числах января мне написал заказчик и попросил сделать для него масштабный парсер инстаграма, который был бы способен делать более 10.000 запросов в сутки.

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

В рамках данной статьи я хочу рассказать про путь развития своего Pet-Project в потенциально мощный и серьёзный инструмент. Впереди вас ждёт увлекательное путешествие от хранения данных в простых Json-ах на жестком диске сервера, до облачной базы данных и автоматической инициализации cron расписания запуска процессов внутри докер контейнера, поехали!

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

Казалось бы, зачем может потребоваться извлекать схему данных в schemaless database? Однако это может быть крайне полезно и в некоторых ситуациях абсолютно необходимо:

•  Репликация данных в аналитическое хранилище

•  Интерактивная аналитика из BI-инструментов (SQL)

•  Аудит имеющейся структуры БД

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

В этой статье будет показано как создать Rust бэкэнд, который использует MongoDB, документо-ориентированную БД, для хранения данных и Redis для кэширования, ограничения количества HTTP запросов и нотификаций пользователя. Для большей наглядности созданное приложение также будет предоставлять REST API. В итоге будет получена следующая архитектура:

MongoDB является хранилищем, в то время как Redis используется для следующего:

• кэш (включая изображения)
• ограничение количества HTTP запросов
• нотификации с использованием паттерна publish-subscribe

Эксперимент по секвенированию транскриптома (RNA-seq) стал практически рутинной процедурой для изучения как модельных организмов, так и для сельскохозяйственных культур. В результате биоинформатической обработки таких экспериментов получаются объемные разнородные данные, представленные нуклеотидными последовательностями транскриптов, аминокислотными последовательностями и их структурно-функциональной аннотацией. Полученные данные важно представить широкому кругу исследователей в виде баз данных (БД). В публикации мы рассмотрим гибридный подход к созданию молекулярно-генетических баз данных, которые содержат информацию о последовательностях транскриптов и их структурнофункциональной аннотации. Сущность подхода в одновременном хранении в БД информации как структурированного типа, так и слабо структурированных данных. Технология использована для реализации БД транскриптомов сельскохозяйственных растений. В публикации рассматриваются особенности реализации такого подхода и примеры формирования как простых, так и сложных запросов к такой базе данных на языке SQL. Данная статья является укороченным пересказом нашей работы doi: 10.17537/2020.15.455 в которой я являюсь соавтором.

ArangoDB – мультимодельная БД с возможностью хранения данных как графов, документов и ключ-значение.

• PostgreSQL для хранения данных
• Redis для координации очередей фоновых заданий (и некоторых ограниченных атомарных операций)

Сценарий 1: очередь заданий

В DataStax работают над созданием производительной модели данных для Apache Cassandra. В чём заключается эта работа и как её делать правильно, на конференции Cassandra Day Russia 2021 рассказал Артём Чеботко, Solutions Architect в DataStax.

Речь пойдет о разработке производительной модели данных для Apache Cassandra. Над этой задачей я долгое время работаю в DataStax. Есть довольно большое количество проектов и use cases, в которых нужна была производительная модель данных. Мы поговорим о методологии и как это сделать правильно.
Начнем с более простых вещей. Обсудим, как Cassandra хранит данные, чтобы понимать, на что нужно особенно обращать внимание. Потом обсудим методологию. Здесь также есть 3 примера, о которых я хотел бы поговорить. Они разные, в них есть разные оптимизации, которые можно обсудить.

Чуть более года назад мне посчастливилось погрузиться в углублённое изучение Redis. Всё, что я знал про него на тот момент, это две команды — get и set. Примерно в это же время у нас начался плавный переход со Standalone Redis на Redis Cluster.

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

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

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

"Размышления без практики приводят к заблуждению, практика без размышления приводит к затруднению."

Мы ведём войну с индивидуальностью у шардов в кластере MongoDB. Это продолжение статьи Шардинг от которого невозможно отказаться, а это значит, что наступила пора конкретики.

Как я и обещал, здесь мы рассмотрим подробнее:

• настройку процесса выравнивания размера шардов
• расчет поправок для коррекции границ
• мониторинг распределения данных в коллекциях