Комментарии

Использование Redis только как основной базы данных

Вот плюсы и минусы использования redis.

Плюсы

— Быстрый

— транзакция (поскольку однопоточная)

Минусы

— Отсутствие поддержки вторичного ключа

— Нет поддержки переиндексации

— Нет надежных потоков изменений, в отличие от mongodb, dynamodb

— Стоимость (поскольку все данные должны храниться в памяти, нам нужно всё больше и больше оперативной памяти)

— Нет надёжного сохранения данных. (P.S. Люди говорят, что моментальный снимок rdb служит резервным хранилищем для Redis, но помогите мне понять, что происходит, когда у нас 12 ГБ оперативной памяти и мы помещаем 13 ГБ данных. В Redis будет только 12 ГБ данных, но если я использую моментальный снимок rdb и запускаю другой Redis с 20 ГБ оперативной памяти, будут ли в нём все мои данные или 1 ГБ исчезнет навсегда. Насколько надёжен этот механизм??)

— Отсутствует автоматическая балансировка ключей. (сегментирование на уровне приложения является обязательным)

Учитывая вышеперечисленные плюсы и минусы, я вижу лишь несколько вариантов использования, при которых мы можем использовать Redis в качестве единственного и основного хранилища данных.

— Хранилище сеансов.

Я что-нибудь упускаю? Каких дополнительных возможностей не хватает redis по сравнению с другими базами данных, такими как mongodb, mysql (Здесь я говорю только о готовности к производству и надежности, а не о том, чтобы начинать дебаты nosql vs sql

Redis улучшает производительность и скорость работы приложений. Начать знакомство с этой СУБД можно с основных команд и типов данных. Необходимо также разобраться в конфигурациях Redis Sentinel и Redis Cluster. Ещё важно учитывать, что Redis работает в оперативной памяти. Поэтому, чтобы не потерять информацию, регулярно создавайте резервные копии.

Redis улучшает производительность и скорость работы приложений. Начать знакомство с этой СУБД можно с основных команд и типов данных. Необходимо также разобраться в конфигурациях Redis Sentinel и Redis Cluster. Ещё важно учитывать, что Redis работает в оперативной памяти. Поэтому, чтобы не потерять информацию, регулярно создавайте резервные копии.

Да верно, тут сразу от начала и доконца Вас ведут, даже когда уже запустите маркетплейс они все равно Вас ведут и не бросают, можно в ДСТ доказывать например наполнение товарами, ведение соц сетей, сделать моб приложения или еще чего там нужно

В ДСТ как понял прям все делают сами они верно? Ну то есть и коробочные решения, которые нужно купить и поддержку и установку и настройку и консультации верно понимаю?

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

А чего тогда о CS Cart и Битрикс скажете, они помогают?

Я бы сказал, что 50% трудностей ДСТ Платформ решает сразу, так как это не только готовое, но и проверенное решение для маркетплейсов. Кроме того, специалисты ДСТ, которые регулярно проводят запуски и предоставляют бесплатные консультации, помогают ещё примерно на 20-30%.

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

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

Как понимаю проще купить готовое коробочное решение, то же ДСТ Платформ и закрыть 40-50% мучений, особенно в разработке

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

Теперь о том — почему стоит создавать маркетплейс

— Рост электронной коммерции — рынок онлайн-торговли постоянно увеличивается

— Снижение конкуренции с крупными игроками

— Новые возможности для малого бизнеса

— Доход с комиссий — стабильный источник заработка

Пошаговая инструкция создания

— Исследование рынка

— Анализ конкурентов

— Определение целевой аудитории

— Выбор ниши

— Оценка спроса и предложения

— Разработка бизнес-модели

— Определение комиссий

— Система регистрации продавцов

— Правила модерации товаров

— Условия работы с покупателями

— Техническое воплощение

— Выбор технологической платформы

— Разработка дизайна

— Создание административной панели

— Интеграция платежных систем

— Запуск и продвижение

— Привлечение первых продавцов

— Маркетинговая стратегия

— SEO-оптимизация

— Работа с отзывами

Ключевые функции платформы

— Каталог товаров с фильтрацией и сортировкой

— Система рейтингов и отзывов

— Личный кабинет для продавцов

— Корзина и оформление заказа

— Интеграция с платежными системами

— Служба поддержки пользователей

Монетизация маркетплейса

— Комиссия с продаж

— Платные места в каталоге

— Рекламные места

— Премиум-аккаунты для продавцов

— Дополнительные сервисы

Распространенные ошибки

— Недостаточное исследование рынка

— Неправильный выбор ниши

— Слабая техническая база

— Отсутствие системы безопасности

— Плохая поддержка пользователей

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

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

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

Ну если вообщих чертах, то примерно вот как.

Планирование и исследование рынка

Анализ конкурентов

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

Определение целевой аудитории

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

Выбор бизнес-модели

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

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

Выбор платформы и технологий

Готовые решения

Существуют готовые платформы (DST Platform, Arcadier, CS-Cart), которые позволяют быстро запустить маркетплейс с минимальными затратами. DST Platform как по мне самый профессиональный и мощный.

Самостоятельная разработка

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

Популярные технологии для разработки маркетплейсов:
— Языки программирования: PHP (я например отдаю ему предпочтение), JavaScript (Node.js, React), Python (Django), Ruby (Ruby on Rails)
— Базы данных: MySQL, PostgreSQL, MongoDB

Разработка и дизайн

Прототипирование

Начните с создания прототипа маркетплейса. Это поможет визуализировать структуру и функционал, получить раннюю обратную связь от пользователей. Используйте инструменты для прототипирования (Figma, Sketch). Прототипирование позволяет быстро тестировать идеи и избегать дорогостоящих ошибок на поздних этапах.
Дизайн интерфейса

Создайте удобный и интуитивно понятный интерфейс. Обратите внимание на:
— Пользовательский опыт (UX)
— Внешний вид (UI)
— Простоту навигации
— Доступность основных функций

Используйте современные дизайн-паттерны и следуйте рекомендациям по доступности.

Разработка функционала

Основные функции маркетплейса:
— Регистрация и авторизация пользователей
— Управление товарами
— Поиск и фильтрация
— Корзина и оформление заказа
— Система отзывов и рейтингов
— Платежные системы

Постепенно добавляйте новые функции на основе обратной связи от пользователей. Учитывайте вопросы безопасности и защиты данных.

Тестирование

Проведите тщательное тестирование:
— Функциональное тестирование
— Тестирование производительности
— Тестирование безопасности

Используйте автоматизированные инструменты для тестирования. Регулярно проводите аудит безопасности и производительности.

Запуск и продвижение маркетплейса

Предзапусковая подготовка

Перед запуском убедитесь:
— Все основные функции работают корректно
— Подготовлены маркетинговые материалы
— Проведено внутреннее и бета-тестирование
— Разработан план действий на случай непредвиденных ситуаций

Маркетинговая стратегия

Используйте различные каналы продвижения:
— Социальные сети
— Контекстная реклама
— SEO
— Email-маркетинг

Создайте контент, интересный целевой аудитории. Разработайте программу лояльности и реферальную систему.

Обратная связь и улучшения

После запуска:
— Активно собирайте обратную связь
— Регулярно обновляйте функционал
— Создайте систему поддержки пользователей
— Проводите опросы и интервью с пользователями

Ну и главное по моему мнению это — постоянное развитие и улучшение маркетплейса — ключ к его долгосрочному успеху и росту.

Можете дать советы о том, как создать маркетплейс с нуля? Пожалуйста, поделитесь инструкцией для начинающих.

Некоторые преимущества двоичного квантования:
— Улучшенная производительность. Представление векторов двоичными кодами (0 и 1) позволяет использовать расстояние Хэмминга в качестве показателя сходства.
— Повышенная эффективность. Двоичное квантование сжимает векторы из 32-битных чисел с плавающей запятой в 1-битные двоичные цифры, что резко снижает требования к хранению.
— Применение в системах рекомендаций. Двоичное квантование расширяет возможности систем рекомендаций за счёт преобразования векторов функций пользователя и элемента в компактные двоичные коды.
— Помощь в обработке естественного языка (NLP). Двоичное квантование помогает обрабатывать и анализировать текстовые данные за счёт снижения требований к хранению в векторной базе данных.

Однако обратить процесс двоичного квантования вспять невозможно, что делает его методом сжатия с потерями.

Модели согласованности в распределённых системах устанавливают критерии синхронизации данных и определяют, как пользователи и приложения должны интерпретировать изменения данных на нескольких узлах.

Некоторые модели согласованности:
— Строгая согласованность. Все узлы в системе всегда имеют одинаковое представление данных. Любая операция чтения возвращает самую последнюю запись в элемент данных.
— Конечная согласованность. Допускает временные несоответствия между узлами, но гарантирует, что, если в элемент данных не будут внесены новые обновления, в конечном итоге все обращения к этому элементу вернут одно и то же значение.
— Причинно-следственная согласованность. Гарантирует, что если одно событие причинно предшествует другому, все узлы будут соблюдать одинаковый причинный порядок событий. Эта модель важна в системах, где важен порядок выполнения операций, например, в распределённых очередях сообщений или приложениях совместного редактирования.
— Согласованность чтения и записи. Гарантирует, что после завершения операции записи все последующие операции чтения от того же клиента вернут значение записи или более свежее значение.
— Монотонная согласованность. Гарантирует, что если процесс считывает определённое значение элемента данных, он никогда не увидит более старое значение для этого элемента в будущем.
— Согласованность сеанса. Взаимодействие пользователя в рамках сеанса должно быть согласованным, но в разных сеансах допускается небольшая несогласованность.

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

Сколько можно это обсуждать:

— В CAP partition, consistency и availability это атомарные величины. В реальности — непрерывные. И вопрос звучит так: «сколько процентов доступности или согласованности вы готовы потерять при заданном проценте partition».

— Пока вы работаете в одном датаценре, то можете считать что никаких partition у вас нет. Я знаю, что в облаке они могут случиться даже в рамках одного «региона», но это тоже крайне редкое явление.

— CAP теорема не рассматривает поведение клиента. Если клиент умеет повторять запросы, то можно нивелировать «недоступность» по CAP и не только по CAP. Более того, повторяя запросы между серверами можно нивелировать partition.

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

— CA-системы это давно известные и прекрасно работающие системы на основе кворума. Как и подавляющее большинство современных NoSQL баз.

— AP-системы это кэш в том или ином виде над некоторым консистентным хранилищем или без него.

— Комбинируя AP и CA системы можно выполнить нужные вам требования.

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

Три вида согласованности данных

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

Попробуем обозначить три основных типа согласованности.

Согласованность в теореме Брюера

Первый из них обозначен буквой C в аббревиатуре CAP в теореме Брюера (Consistency, Availability, Partition tolerance). Согласно этой теореме, в распределенной системе можно обеспечить выполнение только двух из трех следующих свойств:

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

Далее в теореме Брюера поднимается вопрос: чем вы жертвуете? Доступностью ради сохранения согласованности или согласованностью ради сохранения доступности?

— В сущности, теорема Брюера рассматривает репликацию, в частности, сбои сети во время репликации.

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

Однако, как нам напоминает Вернер Фогельс, «все постоянно ломается». И ваша сеть тоже.

Согласно теореме Брюера, нам нужно решить, что делать в этом случае — как изолированному узлу C реагировать на запрос от клиента?

— Если вы выбираете подход AP (доступность и устойчивость к разделению), узел C выдает в ответ данные, находящиеся локально на этом узле. В этом смысле узел C доступен: он может выдать корректный ответ, который, правда, не всегда будет наиболее актуальным.
— Если остановиться на подходе CP (согласованность и устойчивость к разделению), вы не разрешите узлу C выдать ответ, ведь у него могут быть устаревшие данные. Если для вас в приоритете согласованность данных, узел C не сможет ответить, что снижает доступность системы (в терминологии теоремы Брюера).
— Если вы выбираете подход CA (согласованность и доступность), вы жульничаете! Помните, мы исходим из допущения о нарушении связности сети.

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

— Она рассматривает работу системы только в условиях сбоя. Сбои неизбежны, и неплохо бы знать, как ваша база данных поведет себя в этом случае. Правда, скорее всего, большую часть времени она будет функционировать нормально. Но и в этой ситуации в ее работе будут интересные компромиссы, их обсудим ниже.
— Речь идет о конкретных сбоях. А именно о нарушении связности сети между узлами. Но ведь есть масса других неисправностей — от нехватки памяти на отдельном узле до пожара в ЦОД. Все это может серьезно повлиять на доступность системы, и не только в том смысле, в каком ее рассматривает теорема Брюера. Поэтому важно учитывать и эти неполадки.
— В ней используется уникальное понятие «доступность». Согласно теореме Брюера, понятие доступности подразумевает корректный ответ от корректно работающего узла. Это значит, что, если клиент обращается к изолированному узлу C, он считается доступным, если выдал успешный ответ.

Мы часто думаем о доступности как о проценте успешных ответов за определенный период времени (то есть сколько у системы «девяток» доступности). У системы на базе подхода CP может все-таки оказаться очень высокая доступность благодаря тому, что все клиенты обязательно используют большинство узлов без нарушения связи. О доступности можно подробнее прочитать в статье Марка Брукера «Доступность и доступность».

Несмотря на эти ограничения, теорема Брюера помогает осознать, на какие компромиссы приходится идти при репликации данных в распределенной системе.

Согласованность в ACID-транзакциях

Второй тип согласованности связан с ACID-транзакциями. Аббревиатура ACID обозначает совокупность гарантий относительно поведения базы данных при объединении нескольких действий в единую логическую операцию, которую часто называют транзакцией.

Теорема Брюера — это концепция, касающаяся репликации в распределенных системах. ACID же применима только к базам данных. Четыре составляющие ACID-транзакции:

— Атомарность: все операции будут выполнены полностью или не выполнены совсем.
— Согласованность: после транзакции база данных остается в допустимом состоянии.
— Изолированность: параллельные транзакции рассматриваются как выполняемые последовательно.
— Надежность: завершенная транзакция сохраняется даже в случае сбоя.

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

То есть в каждом столбце значения относятся к нужным типам данных и необходимые значения будут предоставлены. Хотя транзакции не особенно усложняют здесь суть дела.

Более вероятный источник проблем с согласованностью — это, скорее, ссылочная целостность. Если в таблице указан внешний ключ, благодаря согласованности запись, на которую он указывает, будет все еще существовать после завершения транзакции.

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

Изолированность как часть ACID — это интересная концепция, имеющая довольно много общего с темой согласованности. Подробнее мы поговорим об этом дальше.

Модели согласованности базы данных

Третье определение термина также применимо к базам данных — это концепция моделей согласованности базы. Много интересного о моделях согласованности можно узнать из аналитики Jepsen — это блог, набор статей и консалтинговый сервис Кайла Кингсбери. Кайл проверяет на прочность разные распределенные системы, выясняя, как они ведут себя при том или ином сбое. Это качественное, интересное решение. Сотрудники Jepsen отлично разбираются в распределенных системах, так что не переживайте, если вы несколько раз перечитали представленный анализ и поняли процентов 15 написанного.

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

В модели согласованности базы данных есть два основных элемента:

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

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

Обратите внимание, что Linearizability в обязательном порядке подразумевает подход CP. С Linearizability связаны и не такие строгие модели согласованности: они обеспечивают высокую доступность (в терминах теоремы Брюера).

По-видимому, Linearizability (и ее более мягкие версии) не предусматривает конечную согласованность. Особенно в системах с балансировкой нагрузки, таких как DynamoDB, в которой не поддерживаются тесные связи с определенным узлом. Поговорим о конечной согласованности подробнее.

Linearizability = один фрагмент данных, Serializability = несколько фрагментов. В частности, Serializability — это способ обработки параллельных транзакций, выполняемых с одними и теми же фрагментами данных.

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

Что не так с дискуссиями на тему согласованности

Теперь, когда мы разобрались с основной терминологией, давайте перейдем к доброжелательной критике. Вот несколько идей, которые направят ваш мыслительный процесс.

Неполнота теоремы Брюера

Теорема Брюера полезная и правильная. Что бы вы ни думали, вы не можете волевым решением создать систему на базе подхода CA. И все же теорема неполна. Например, в дискуссиях часто говорят: «Мы не можем выбрать $DATABASE, потому что это система на базе подхода AP, а нам не нужна конечная согласованность».

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

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

Первые три буквы аббревиатуры PACELC совпадают с буквами аббревиатуры CAP (Partition tolerance, Availability, Consistency). Следующие три буквы обозначают действия в режиме без нарушения связности. ELC расшифровывается как «а еще оптимизировать время задержки или согласованность?».

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

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

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

Вольное применение ACID

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

Сериализуемость — это аспект моделей согласованности, связанный с транзакциями. Хоть и считается, что большинство реляционных баз данных поддерживают ACID-транзакции, они не дают полной гарантии сериализуемости при их выполнении. Обычно они предлагают довольно вольные гарантии, такие как повторное чтение или Snapshot isolation, что иногда приводит к неожиданным проблемам при выполнении параллельных операций.

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

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

Слишком много разговоров про абсолют

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

Например, время от времени руководители или ведущие архитекторы компаний-разработчиков БД утверждают, что им удалось создать систему на базе подхода CA. Это просто неправильное понимание CAP. Но есть и крупица правды в том, что нарушения связности сети реже встречаются в определенных ситуациях. По мере того как развиваются наши дата-центры, а в сетях повышается устойчивость к сбоям, решение в пользу согласованности или доступности становится все менее кардинальным.

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

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

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

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

Приведем еще один пример использования ИИ — в системе заказов в сети ресторанов McDonald’s. Начиная с 2020 года, там стали применять ИИ-систему для размещения заказов. Разработка была выполнена в партнерстве с IBM.

Ошибки в ее работе не замедлили себя ждать. Блогеры стали сообщать, то о получении заказа из девяти чашек чая вместо одной, то о получении заказа с добавлением бекона к мороженому. После серии таких скандальных видеороликов в прошлом году было решено отказаться от использования этой ИИ-системы и возврату к размещению заказов через человека.

Хайп пройдет и все откажутся от ИИ? Вряд ли. Конкуренты «Макдональдса», такие как White Castle и Wendy’s, сразу же поспешили сообщить о своих успехах по части автоматизации работы с заказами. Поэтому никто не собирается отказываться от ИИ, но тема своевременного выявления ошибок в работе ИИ-систем остается актуальной.

Генеративный ИИ и его ошибки в сфере кибербезопасности

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

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

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

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

Выводы

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