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

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

задачу децентрализации на уровне БД

https://en.wikipedia.org/wiki/Distributed_database

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

man steem

https://steemit.com/@soomrack/

Глять на ipfs.

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

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

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

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

Глять на ipfs.

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

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

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

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

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

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

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

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

IPFS