Как стать автором
Обновить
1.3

NoSQL *

Не только SQL

Сначала показывать
Порог рейтинга

Зачастую бизнес‑объекты в информационных системах хранятся в классических реляционных базах данных, где каждому атрибуту объекта соответствует колонка в таблице.

Чтобы изменить такую объектную модель, например, добавить или удалить атрибут, нужно внести изменения в схему базы данных, то есть выполнить DDL‑операцию. Она сопровождается блокировками таблиц и увеличением времени простоя при работе с данными. Кроме того, при увеличении числа атрибутов можно превысить ограничение на количество колонок в таблице. Например, в Postgres их можно создать не более 1600.

Эти проблемы можно устранить, используя хранение данных в формате JSON. Основные преимущества такого подхода:

  • отказ от фиксированной структуры таблиц;

  • гибкость без необходимости изменения схемы.

Обращение к динамическим полям может осложниться при работе с Hibernate до версии 6.2. Более ранние версии не позволяют обращаться к полям внутри JSON на уровне HQL, что ограничивает возможности фильтрации и сортировки. Поэтому оптимальный вариант — использовать Native SQL. Hibernate позволяет регистрировать SQL‑функции, чтобы вызывать их из HQL‑запросов. Пример регистрации такой функции для Postgres приведен ниже:

registerFunction("jsonQuery",
    new SQLFunctionTemplate(StandardBasicTypes.STRING,
        "jsonb_path_query_first(?1, ?2)::varchar"));
  • Первый параметр — колонка в БД, внутри которой хранится JSON, выполняющий запрос.

  • Второй параметр — запрос в виде JSON Path, который позволяет добраться до определенных полей.

Пример структуры JSON и использования на ней SQL-функции в запросе:

{
  "CPU_Brand": "Intel",
  "CPU_Model": "Xeon 8380",
  "RAM_Size_GB": 64
}
SELECT obj.id
FROM userObject obj
WHERE jsonQuery(obj.json, '$.CPU_Brand') = 'Intel'

При работе с более сложными вещами, например, фильтрация объектов с вложенными данными, SQL Server требует применения конструкций CROSS APPLY и openjson.

Теги:
Всего голосов 4: ↑2 и ↓2+2
Комментарии3

Базы данных: какие они сейчас и что нас ждёт в будущем

Многие считают базы данных консервативной областью, где всё придумали ещё в 70-х, и с тех пор всё ограничивается незначительным тюнингом. Однако новые СУБД появляются регулярно, обещая консистентность, доступность, низкие задержки и масштабируемость. Есть решения для OLTP, OLAP, специализированные под конкретные задачи и универсальные. Как разобраться в этом разнообразии?

Наши коллеги, Константин Осипов (сооснователь Picodata, входит в группу Arenadata, директор по разработке ScyllaDB) и Ярослав Дынников (руководитель разработки продукта Picodata), стали гостями нового выпуска подкаста «Кода кода».

В эпизоде эксперты обсудили:

  • эволюцию баз данных от 70-х до современных решений;

  • задачи, которые решают новые СУБД;

  • компромиссы в архитектуре современных баз данных;

  • возврат от NoSQL к реляционным системам;

  • работу с доменами отказа и кластерными базами.

Специальный гость эпизода — Алексей Борисов, руководитель проектов технического департамента «Туту». Он рассказал, где лучше использовать in-memory решения и как это делать правильно.

Подкаст ведут Виктор Корейша (Ozon) и Евгений Антонов (Yandex Infrastructure, автор канала «Тимлид Очевидность»).

Слушайте подкаст на Яндекс Музыке, Apple Podcasts и других платформах: https://kodakoda.mave.digital/ep-77

Теги:
Всего голосов 6: ↑6 и ↓0+8
Комментарии0

SQL vs NoSQL: как выбрать архитектуру БД для мобильного приложения

SQL (Structured Query Language) — это язык запросов, которые мы используем для работы с реляционными базами данных. У таких БД жесткая структура в виде таблиц. Вся информация там хранится в столбцах и строках. Структурированность — одно из главных преимуществ SQL баз данных.

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

Чтобы выбрать между SQL и NoSQL, нужно исходить из задач бизнеса.

  • Если вы делаете маленькое приложение на узкую аудиторию или MVP, можно смело выбирать NoSQL. Такие базы быстрые, с ними проще работать, они легко масштабируются. А если проект растет как на дрожжах — NoSQL можно быстро переписать на SQL.

  • Если вы делаете средний по объему проект, лучше SQL. Хотя, если очень хочется, можно и NoSQL. Но тут есть особенности: выбирайте NoSQL, только если у вас есть налаженные ивенты, налаженная имплементация баз данных и опыт работы с NoSQL.

  • Если вы делаете энтерпрайз, лучше выбрать SQL. Представим, что в каком-то крупном маркетплейсе 10 тысяч человек оплатили покупки, но не получили товары, потому что транзакция данных прошла некорректно. Цена ошибки тут слишком высока — поэтому SQL.

Больше подробностей — в нашем блоге.

Теги:
Всего голосов 17: ↑10 и ↓7+3
Комментарии3

Всем привет! Мы продолжаем обзор Redis — системы хранения данных в виде структур. 

Новая статья Петра, нашего DevOps-инженера, — это детальное руководство по базовой репликации Redis. Благодаря ему вы сможете настроить эту СУБД на высокий уровень отказоустойчивости. 

Если суперкратко:

  • Репликация в Redis ассинхронна. 

  • Репликация не блокируется на стороне мастера. 

  • Репликация (почти) не блокируется на стороне слейвов. 

  • У мастера может быть любое количество реплик.

  • Каждый слейв может выступать мастером для другого инстанса.

А ещё в конце вас ждёт приятный бонус в виде разбора атаки на Redis через H2Miner, из-за которой можно полностью потерять данные на инстансе Redis

Нажмите сюда, что начать читать.

Теги:
Всего голосов 4: ↑4 и ↓0+5
Комментарии0

❓100 Вопросов по Машинному обучению (Machine Learning) - Вопрос_10

?Вопрос_10: Что такок Tarantool и как он устроен ? (Часть_2)

  1. Replication: Tarantool предлагает механизм репликации, который позволяет создавать реплики базы данных для обеспечения отказоустойчивости и масштабируемости. Репликация Tarantool основана на механизме репликации мастер-слейв (master-slave) и поддерживает асинхронное и синхронное реплицирование.

  2. Sharding: Tarantool поддерживает горизонтальное масштабирование с помощью шардинга данных. Шардинг позволяет распределить данные по нескольким узлам-серверам, что позволяет обрабатывать большие объемы данных и повышает производительность.

  3. Индексы: Tarantool предоставляет различные типы индексов для оптимизации запросов и обеспечения быстрого доступа к данным. Включая хеш-индексы, деревья и индексы, основанные на отсортированных списках.

    t.me/DenoiseLAB (Еесли вы хотите быть в курсе всех последних новостей и знаний в области анализа данных);

Теги:
Рейтинг0
Комментарии0