Авиабаза распределённая

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

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

— Устойчивость подразумевает децентрализацию. Пусть не полный p2p, хотя бы на уровне разных субпроектов. Типа, если проблемы с политической частью, работает хотя бы научно-техническая. Эта же децентрализация в какой-то степени позволит защищаться и от блокировок, если одни и те же материалы смогут быть доступными по разным местам. Однако, это же порождает и проблемы, например, с монетизацией. С одной стороны, это будет снижать поисковые рейтинги, что будет снижать появление новых пользователей, с другой — позволит кому-то легко использовать материалы для собственной выгоды (грубо говоря, крутить их со своей рекламой). Кроме того, хочется построить такую систему, чтобы она могла продолжать работать даже в случае, когда я уже не смогу этим заниматься (все мы смертны).

— Простой в использовании — значит, не требующий от пользователей особых знаний. Да, в том же FreeNet или хотя бы за i2p сейчас можно построить прекрасно защищённую систему, заблокировать которую на уровне нынешних законов будет сложно (хотя при сильном закручивании гаек в будущем — легко, конечно). То есть, желательно иметь возможность заходить простому пользователю через один только браузер.

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

Какие особенности и компоненты должны быть в системе.

— Единая база пользователей. Полная анонимность и безнаказанность губительна по целому ряду причин. Начиная от простого г***ометания, кончая спамерами. Даже во FreeNet пришлось вводить систему WebOfTrust, реализующую пусть и анонимную, но систему оценок/рейтингов. Иначе — никак.

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

— Вообще, нужно очень много внимания уделять data-mining'у, автоматизации поиска актуальных материалов.

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

Компоненты могут быть разных классов:

— Сайты. Пока фактически у нас реализована только сама Авиабаза. Из которой потенциально могут отпочковаться несколько разделов, в первую очередь — флотский. Со статической частью проблем нет. Уже вполне работает (хотя окончательно не допилен) вариант построения сайта через DVCS и Zim-Wiki: Новый формат разработки сайтов. И airbase.ru в частности. Тут вообще всё просто. И писать материалы можно спокойно на локальной машине и репозитории могут быть сколь угодно распределёнными, даже в случае отказа/блокировки центрального сайта, и формат данных универсальный, поддерживаться сможет кем угодно даже без меня. Это пока самая «решённая» часть задачи.

— Форумы. Тут, с одной стороны всё понятно со логической структурой, с другой — масса концептуальных проблем с технической стороны. Понятно, что нынешний вариант с централизованной БД подходит для распределённой системы очень плохо. Можно, конечно, заниматься репликацией данных, но это сложно, капризно, уязвимо. Была у меня мысль делать форумы на DVCS. Даже на старом сервере начал эксперименты. То есть логика такая — основные данные (топики, сообщения) лежат в DVCS, откуда кешируются в базу данных, которая уже и отдаёт странички. Вопрос распределённости решается легко.

Увы, типичные объёмы наших форумов (условно — 6 млн. файлов, 10Гб данных) показали совершенную непригодность имеющихся DVCS и железа для эффективной работы (коммиты новых сообщений, отслеживания изменений).

Нарезка на мелкие категории по одной на репозиторий во-первых, спасает мало. Во-вторых — практически ставит крест на перемещении материалов (топиков) в другие категории («вынос политики с ракетомодельного»).

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

— Блоги. Это то, что делать надо обязательно. По сложности будет где-то между сайтами и форумами. Но вопрос совсем ещё не продуманный.

Ещё моменты. Приватность сообщений. От неё придётся отказываться полностью. Нынешние закрытые материалы придётся подвергнуть сортировке. Часть вывести снова в открытый доступ (эротика всякая, мусор/спам и т.п.), только скрыв от гостей на сайте (потому и скрывалось). Часть, реально приватное, оставить на старом движке без переноса в распределённую систему.

Кстати, система должна ещё и смешивать удобно и эффективно разнородные решения. Скажем, кроме упомянутых открытых чисто распределённых иметь ещё обычные форумы для приватного или аварийного общения, чаты, блог-системы, под которые есть приличные мобильные клиенты (тот же WordPress) и т.п.

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

Более детальные мысли по распределённым форумам.

Пожалуй, нарезка репозиториев по дате сообщений обеспечит достаточную производительность. Также не будет проблем с репликацией. Надо будет поэкспериментировать.

Нарезать, видимо, надо именно по сообщениям. Если резать по темам, то затруднится перенос сообщений между темами.

Формат хранения, думаю, нужен дублированный. JSON для обработки и что-то человекочитаемое для чтения в ручном режиме. Скажем, в формате e-mail. Аттачи можно хранить рядом с сообщениями. Хотя есть и проблема — например, хотелось бы иметь в таком же человекочитаемом виде возможность просмотра сообщений по выбранным топикам. В случае Linux можно обойтись симлинками. Но непонятно, как на такие репозитории будет реагировать Windows. Надо будет проверить... Проверил, в Git всё плохо — симлинк превращается в файл с именем, на кого указывает :-/

Хотя, с другой стороны... Может, и вправду, распределять по темам? Перемещение будет всё равно в рамках одного репозитория, просто из каталога в каталог файл скопируется. А в человекочитаемом виде можно будет оставить один файл — файл темы. Например, в формате mailbox...

В общем, решаемо, хотя надо думать.

Два вопроса пока не могу решить:

1. Вопрос идентификаторов. Теоретически сообщения могут писаться с разных ресурсов одновременно и нужно избежать конфликтов. uuid тут явно неудобен. Создавать номер из времени сообщения и ID автора? Но от ID автора в текстовом виде хочется уйти. Например, в сторону e-mail автора.

2. Вопросы ограничений для пользователей. Например, те же временные R/O. Как вариант, конечно, отказаться от блокировок вообще и вводить только возможность игнора. Но тогда вылезет проблема спама.

Экспорт текстов сообщений за 2013 год выдал 1.3Гб данных. Более 300 тыс. файлов. Это без аттачей. git на таких объёмах тормозит сильно. Видимо, нужно резать по месяца. Один репозиторий = 1 месяц.

Проблема с авторством. Единственный универсальный способ иднтифицировать пользователя — его e-mail. Но проблема в том, что все данные репозитория будут публичными. А e-mail'ы многие светить не хотят. Наверное, всё же, придётся делать авторизацию с привязкой по хостам(проектам). Типа Balancer@Airbase.

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

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

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

...

Пока делаю экспортёр в такую файловую структуру:

+---Проект [категория первого уровня]
  |
  +---Категория [Военспец, Танцпол, Авиабаза]
    |
    +---Форум [без вложенности в случае подфорумов, всё на одном уровне]
      |
      +---Топик
        |
        +---posts [каталог с файлами сообщений]
        +---attaches [аттачи]
        +---index.html [файл для просмотра темы одним файлом]
        +---index.md [то же самое, но в виде текста]

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

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

Обсуждение также на

Перенос файлов в git из репозитория в репозиторий:

Работа с ЭЦП в PHP:

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

Пока остаётся открытой проблема спама.

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

Изначально планировал использовать формат «один постинг = один файл JSON».

Сейчас думаю, не надо ли переходить на формат «один топик = один файл JSON». Иначе больно много мелких файлов выходит. Для FS лишняя нагрузка.

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

Интересно, а в природе нет чего-нибудь embedded, типа sqlite, но на plain-text?

Так вот ты какой, гипертекстовый фидонет

Поиграл с git и mercurial на месячном срезе форумов. В принципе, почти идентично. Так что, хоть мне нравится mercurial, буду делать ставку на git — он более распространён, проще будет и с хостингами, и с поддержкой.

Решил сохранять в JSON постингов и приватную информацию проекта, например — IP постера (чтобы можно было спокойно восстановить полную структуру БД из одного только репозитория). Ясно, что надо её шифровать. Пробую шифровать открытым ключом с последующей, если потребуется, расшифровкой закрытым. При длинном ключе получается длинная же итоговая строка. Большую часть записи занимает приватные данные, хотя там записано только несколько байт IP. Значит, надо ключ брать покороче, тем более, что данные там хранятся не настолько приватные, чтобы ломать голову — это скорее моральных соображений вопрос.

Минимальная длина ключа для sha256 — 384 бита. Получается минимальная строка в 64 символа. Достаточно ли этого для поверхностной защиты?

Добавил в репозиторий аттачи. Вышло сразу по 3+Гб за месяц (декабрь 2013 на тесте). При чём 2.2Гб из них — Морской Ещё 580Мб — Ракетомодельный. Дальше уже по мелочи (84Мб Политика, 72Мб Наука и техника и т.д.)

Январь 2014:
Всего — 2.8Гб, Флот — 1.9Гб, Ракетомодельный — 594Мб, Политика — 160Мб.

Ракетомоделисты-то у нас активные, оказывается, по объёму вторыми за моряками идут

В копилку.