INDB: база данных нового типа, где истина рождается при чтении

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

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

INDB стоит на этом: смысл производится при чтении, а не фиксируется при записи. Вместо CRUD три фазы — вдох (Inhale, принять сырое наблюдение), выдох (Exhale, сжать повторы и отфильтровать шум репутацией), аксиома (Axiom, подписать то, что выжило).

INDB: новая парадигма для противоречивых данных

INDB — это экспериментальная система управления базами данных, которая предлагает радикально иной подход к хранению информации. Вместо традиционной модели CRUD (Create, Read, Update, Delete) она использует три фазы: Inhale, Exhale и Axiom. На фазе вдоха система принимает сырые наблюдения — любые данные, поступающие из внешних источников, без попытки их согласовать. На фазе выдоха происходит сжатие повторов и фильтрация шума с помощью механизма репутации. Наконец, фаза аксиомы подписывает те утверждения, которые пережили фильтрацию, превращая их в факты, доступные для чтения.

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

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

Предыстория и контекст

Проблема, которую решает INDB, не нова. Ещё в 1980-х годах исследователи баз данных обсуждали темпоральные и мультиверсионные модели, позволяющие хранить несколько версий одного факта. Однако на практике большинство систем по-прежнему используют модель «одна строка — одно значение», что приводит к потере информации при конфликтах.

Современные распределённые системы, такие как Cassandra или DynamoDB, используют подход последней записи (last-write-wins), который просто перезаписывает старые данные новыми. Это просто, но теряет важную информацию: если два сенсора показывают разную температуру, знание об обоих показаниях может быть критично для диагностики.

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

Чем INDB отличается от традиционных баз данных?

Главное отличие — в моменте разрешения конфликтов. В классических СУБД конфликт должен быть разрешён до записи: вы обновляете значение, и старое теряется. В INDB конфликт сохраняется, а разрешается только при чтении, когда у вас есть контекст — например, время запроса, местоположение пользователя или его роль. Это позволяет отвечать на вопросы, которые невозможно было предвидеть при проектировании схемы.

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

Технические детали и архитектура INDB

Архитектура INDB строится вокруг трёх фаз, которые автор называет «вдох», «выдох» и «аксиома». На фазе Inhale система принимает наблюдения в сыром виде — это могут быть JSON-объекты, строки, числа, всё что угодно. Каждое наблюдение получает метку времени и идентификатор источника.

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

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

Сравнение с конкурентами: в отличие от Cassandra, которая использует last-write-wins, INDB хранит все версии. В отличие от CouchDB, который хранит конфликты, но оставляет разрешение на усмотрение клиента, INDB автоматически вычисляет доверие на основе репутации.

Кого затронет INDB и как

Разработчики, работающие с IoT и сенсорными сетями, — первая аудитория, которая может выиграть от INDB. Когда десятки датчиков передают данные о температуре, влажности или вибрации, расхождения неизбежны. INDB позволяет хранить все показания и при запросе выдавать медиану или наиболее достоверное значение, а не просто последнее.

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

В России и СНГ интерес к таким системам может быть связан с задачами импортозамещения и построения распределённых систем на отечественных платформах. INDB — открытый проект, его можно адаптировать под локальные требования.

Что будет дальше

На данный момент INDB — это прототип, опубликованный на GitHub. Автор открыт для обсуждения и приглашает разработчиков присоединиться к проекту. В планах — реализация полноценного движка запросов с поддержкой SQL-подобного синтаксиса и интеграция с популярными языками программирования.

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

Итог

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