LINUX.ORG.RU

Децентрализованная база данных

 , , ,


1

4

Одноранговая (p2p) сеть или федерация - не суть важно. Данные всех пользователей хранятся распределённо. Пользователи авторизуют приложения для доступа к тем или иным данным. Условный ЛОР может сделать запрос (SQL или иной QL) и получить данные, скажем, о пользователях при условии, что те авторизовали ЛОР на чтение этой информации. Аналогично с постами, новостями и комментариями.

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

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

Reedych ★☆ ()
Ответ на: комментарий от outtaspace

Не, это про обычную модель, где все БД объединяются в кластер и контролируются одним лицом / одной стороной.

Я хочу, чтобы у тебя была своя БД (тобой контролируемая), где ты решаешь, доступ к каким таблицам какому пользователю (читай: приложению) дать. И у меня своя такая же. Обе БД (контролируемые разными людьми) объединяются в кластер. Теперь можно обычным SQL подобным языком делать сложные запросы (включая всякие JOIN), получая лишь ту информацию, к которой авторизован.

dazdraperma ()

Условный ЛОР может сделать запрос (SQL или иной QL) и получить данные, скажем, о пользователях
Аналогично с постами, новостями и комментариями.
Существует что-то подобное?

Я что-то подобное планирую в своей Infonesy (см. ссылки на https://github.com/Balancer/infonesy )

Никакого «SQL или иного QL», но систему можно запросить через любой поддерживаемый протокол. Сейчас это JSON-файлы с запросом, размещаемые в каталоги btsync или syncthing. Т.е. кидаем запрос в виде файла в каталог, кто-то, кто может его обработать, возвращает ответ. Так получаются файлы постов/новостей/комментариев/аттачей/пользователей.

Основное назначение — синхронизация разнородных форумных и блоговых платформ. Типа, пишут контент на ЛОРе, он распространяется по другим форумам, сидящим в сети (с их собственными ограничениями, например, баны каких-то пользователей, перераспределение в другие топики и т.п.). Там отвечают — ЛОР может принять такой ответ. Сейчас система в глубоком концептуальном тестировании. Например, все сообщения с моих форумов для теста через такой механизм транслируются на тестовый http://www.unlimit-talks.tk/

Т.е. решал кто-то задачу децентрализации на уровне БД, чтобы децентрализованным можно было сделать уже существующий софт

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

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

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

dazdraperma ()
Ответ на: комментарий от dazdraperma

А как это работает с приватными данными?

На глобальном уровне никак. Я планирую целиком открытую систему. Исключений мало. На глобальном уровне — идентификация пользователя только по MD5(email), т.е. аккаунты разных систем объединяются по хешу от почты и других публичных данных нет. В частном случае возможен обмен приватными данными по открытому общему каналу с использованием асимметричного шифрования. Но я этот момент практически не рассматриваю, так как между доверенными нодами системы может быть установлен просто закрытый канал обмена данными.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

На глобальном уровне — идентификация пользователя только по MD5(email), т.е. аккаунты разных систем объединяются по хешу от почты и других публичных данных нет.

А есть какая-то защита от подделки данных? Ну то есть ты пишешь

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

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

alozovskoy ★★★★★ ()
Ответ на: комментарий от alozovskoy

А есть какая-то защита от подделки данных?

Сейчас — нет. Вопрос доверия нод. Или ты доверяешь ноде и принимаешь данные, или не доверяешь и не принимаешь :) Теоретически, подумываю о частично федерализации, когда в системе могут быть сервера, отвечающие за достоверность пользователей и нод, но это дальняя перспектива. Для начального этапа (те, 4-6 форумов, что готовы влиться в систему) это не актуально, а в будущем, если взлетит, то будет проще разрабатывать, так как может появиться команда, а если не взлетит — то и голову ломать нет смысла :)

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

Для этого в систему должна начать писать недобросовестная нода. Каждое сообщение идентифицируется ID ноды и ID пользователя, md5(email). Соответственно, если пользователь на честной ноде, то он зарегистрирован с живого e-mail и уже этим достаточно однозначно определяется. Если нода подсовывает левые данные или хотя бы регистрирует пользователей с непроверенными e-mail, то это повод считать её недоверенной. И или не принимать данные с неё вообще, или отмечать их как недостоверные.

KRoN73 ★★★★★ ()
Ответ на: комментарий от KRoN73

Не совсем понял про идентификацию по email. А почему не организовать регистрацию нод прежде чем они начнут писать? Ну то есть сначала руками на оба конца этого канала добавляются какие-то ключи\сертификаты, а потом только начинается обмен? Или я не правильно понял и так на самом деле все и работает?

alozovskoy ★★★★★ ()
Ответ на: комментарий от alozovskoy

Не совсем понял про идентификацию по email.

При обмене сообщениями нужен уникальный глобальный ID пользователя. Чтобы пользователь мог писать с разных нод, но в рамках одной ноды все сообщения, даже написанные на других нодах, ассоциировались с ним. Почти любая современная регистрация, от собственной до OpenID включает e-mail. И у большинства пользователей e-mail для общения один и тот же. Логично в качестве глобального ID (UUID) использовать e-mail. Но просто отпускать e-mail'ы в доступный всем поток данных — это рай спаммерам. Поэтому каждого пользователя удобно подписывать необратимым хешем от e-mail. Самое популярное преобразование — md5. Заодно можно автоматом, не имея больше никаких данных, кроме UUID, нарисовать граватарку :)

А почему не организовать регистрацию нод прежде чем они начнут писать?

Это процесс ортогональный идентификации пользователей.

KRoN73 ★★★★★ ()
Ответ на: комментарий от tzukko

Глять на ipfs.

ipfs не позволяет модифицировать данные. Есть ipns, но пока там один мутабельный ключ на всю ноду — он не практичен.

ipfs удобен для обмена файлами в Infonesy. Поэтому, когда кто-то кидает аттач на форум, в поток данных у меня сыплется только ipfs-хеш аттача. А уже приёмные ноды могут выдернуть файл из ipfs или забить на него.

В принципе, можно для такого обмена использовать и более привычные инструменты, от btsync/syncthing до rsync/lsyncd, но там, во-первых, требуется согласование, во-вторых, при исчезновении ноды-источника файлы новым нодам могут стать недоступными. А в ipfs файлы могут храниться долго, а при наличии особой обработки на вторичных нодах — хоть вечно.

KRoN73 ★★★★★ ()

В гипервизорах есть механизм HA, когда 2 сервера в реальном времени поддерживают актуальное состояние, но один из них работает, а второй резервный. Фокус в том, что такой механизм требует низкой латентности (то есть нужен FC, ибо на LAN получим дикие лаги), а если увеличивать время репликации, то рано или поздно получим противоречивое состояние и БД похерится, что лишает смысла всю идею. Так же можно использовать rsync или git, но природа проблемы имхо не изменится - либо синхронизация в реальном времени, либо костыли и боль.

Lordwind ★★★★★ ()
Ответ на: комментарий от Lordwind

то есть нужен FC, ибо на LAN получим дикие лаги

Открой для себя cut-through свичи.

svr4 ()
Ответ на: комментарий от svr4

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

Lordwind ★★★★★ ()

SQL для таких целей подходит мало, есть hadoop но это эпичное жабоговно.

DNA_Seq ★★☆☆☆ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.