LINUX.ORG.RU

Распределёные форумы/блоги. Продолжаем разговор. Нужен совет.

 , , , ,


0

1

Продолжение темы
www.linux.org.ru/forum/talks/10414735
http://www.wrk.ru/support/2014/06/t89569--aviabaza-raspredelyonnaya.1622.html

Тут наткнулся на такую проблему. Как писал ранее, оценки показывают, что разбивать мои форумы надо с гранулярностью один репозиторий — один месяц. За месяц публикуется 35..40 тыс. сообщений, так что если репозиторий рассчитывать на год, получается тормозной монстр. Если резать чаще, скажем, каждую неделю, то получается много мусора. 52 репозитория за год!

Но тут лезет проблема. Аттачи. Сейчас совокупный объём всех аттачей растёт на 5..7Гб в месяц. Один только морской форум вырастает на 2..3Гб за месяц. Это снова, во-первых, усложняет работу с репозиториями, во-вторых, наводит на ограничение использования того же GitHub'а — там свободный лимит репозитория до 1Гб, потом начинают вежливо интересоваться «какого фига?».

Вывод — надо или нарезать репозитории конкретных проектов мелко (по тем же неделям) или реализовывать параллельный механизм хранения файлов. Очень интересно было бы задействовать тот же BTSync. Можно реализовать хранение файловых массивов вообще без нагрузки на сервер/репозиторий.

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

Вижу два решения с сохранением целостности, оба не красивые:

— Нарезать репозиторий совсем мелко. Скажем, заводя по новому каждую неделю.

— Вводить жёсткие лимиты на месячные объёмы на проект. А для крупных данных, фоторепортажей всяких и т.п. отправлять в более жирное место, тот же BTSync.

А ведь ещё есть «утягиваемые» картинки, тоже жрут дофига (при вставке в темах изображений с других сайтов глупо ссылаться на внешний ресурс — через 5 лет остаётся живыми дай бог 10% таких ссылок).

Кстати, из-за всего этого, похоже, имеет смысл реализовывать переменную гранулярность для проектов. Мелкие форумы можно хранить как с разбивкой аж по году, так и не разбивая вообще. И, наоборот, надо явно резать по типу один проект == один репозиторий. Проще будет при смешанном использовании дублировать у себя только избранные проекты, а не дружеские ресурсы целиком (ресурс == сайт/хост, проект == набор тематических форумов, например «форумы о СПО/Linux»). Надо только будет максимально автоматизировать вопрос переноса сообщений/тем (со всей историей) между репозиториями.

★★★★★

Есть такая штуковина - RetroShare. Там уже рспределённость, форумы и блоги реализованы. Аутентификация по GPG-ключам.

Quasar ★★★★★ ()
Последнее исправление: Quasar (всего исправлений: 1)

Вы предлагаете коммитить форумы в гитхаб? Это не нарушает terms of usage?

vertexua ★★☆☆☆ ()

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

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

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

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

Вы предлагаете коммитить форумы в гитхаб? Это не нарушает terms of usage?

1. Система может работать на любых репозиториях. Просто github по понятным причинам интересен.

2. Какие конкретно пункты ToU это может нарушать?

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

а старые не хранить совсем

Нет. Архивы обязательны. Иначе смысла никакого нет.

Или можно задействовать сжатие.

Git этим и будет заниматься :)

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

Есть такая штуковина - RetroShare

Это совсем другая идея. Идея того, что делаю я в том что:

— Для простого пользователя вообще ничего не изменится, как были web-форумы (блоги, сайты), так и остались.

— База данных становится распределённой и распределённой на привычной всем DVCS, что позволяет максимально обеспечить сохранность данных.

— Появляется возможность работы с одними проектами с разных хостов (участвующих в система) в произвольных сочетаниях.

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

Нет. Архивы обязательны. Иначе смысла никакого нет.

Складывать в облака?

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

Я не знаю, просто советую еще раз проверить на всякий случай. Руководствоваться логикой не проверяя контракт или соглашение пользователя - ошибочная практика

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

Хотя даже согласно логике - это abuse на шару выделяемого пространства для кода. Они то дают 1 ГБ с учётом что большинство не использует целый ГБ. Нужно не забывать, что если вы на шару получили гигабайт, то это одолжение, а не ваше право

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

vertexua ★★☆☆☆ ()
Последнее исправление: vertexua (всего исправлений: 1)
Ответ на: комментарий от StReLoK

Складывать в облака?

Да. На сервера, поддерживающие git :)

Просто проблема именно в максимальных объёмах. В первую очередь на том же github'е.

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

Я не знаю, просто советую еще раз проверить на всякий случай.

Я проверял, но препятствий такому использованию не нашёл. Что, конечно, не отменяет возможности моей ошибки. Но тем и интересен вариант с DVCS, что при обломе с GitHub не проблема переключиться на другой репозиторий.

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

Ваше решение с Git интересно, но не навредите, захламляя Github

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

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

Тут такой момент. Если сам подход к вопросу станет популярным (о, я бы этого хотел :D), то вопросы размещения репозиториев с «форумами школоты» будет решать эта самая школота. А за свои проекты (и выбор серверов, с которыми им работать) я отвечаю сам :) Более того, основная нагрузка, вообще, будет на своём же сервере. Просто нужно иметь резерв — на то система и распределённая.

KRoN73 ★★★★★ ()

За месяц публикуется 35..40 тыс. сообщений
DVCS и гейт-сайт для отображения, кеширования с целью поиска и т.п.)

elasticsearch для доков и поиска + hbase/voldemort для свалки аттачей. Оба имеют асинхронные клиенты, шардинг, репликацию, дружественны к hadoop и горизонтально масштабируются by-design. Если полнотекстовый поиск не нужен, то можно хорошо сэкономить на оперативке.

Сейчас совокупный объём всех аттачей растёт на 5..7Гб в месяц.

Они обычно несжимаемы, поэтому добавлять новый сервер с винчом на неск.терабайт раз в n лет.

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

Может лучше лить куда нибудь где нет лимитов на объем?

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

elasticsearch для доков и поиска + hbase/voldemort для свалки аттачей

Это вопрос гейта/сайта. Он может иметь множество решений, вплоть до загрузки базы в любой обычный форумный движок (только вопросы с ID надо решить). Фактически, традиционные web-форумы становятся кешем для распределённых данных (которые использовать в лоб будет почти невозможно).

Интересует же именно межгейтовая синхронизация, распределённое хранилище данных. А проблема аттачей — в том, что с одной стороны, хочется всё держать в одном месте, с другой — не хочется «захламлять github» — забивать репозиторий большими объёмами бинарных данных.

Вот нащупать тут удовлетворяющее решение пока не могу.

Они обычно несжимаемы, поэтому добавлять новый сервер с винчом на неск.терабайт раз в n лет.

Задача стоит в построении распределённой устойчивой к запретам и блокировкам системы. Соответственно, подобный сервер становится только нодой системы, но справляться с хранением надо иначе. Тем интересен BTSync — там можно хранить большие объёмы прямо у пользователей. Но это лишняя сущность как в плане софта (одним браузером уже не обойтись), так и в плане расслоения данных — топик форума перестаёт быть чем-то атомарным.

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

Может лучше лить куда нибудь где нет лимитов на объем?

Лучше. Но ещё лучше пробовать решить проблему так, чтобы лимиты сильно не влияли. Это повысит выживаемость системы.

KRoN73 ★★★★★ ()

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

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

Тем интересен BTSync — там можно хранить большие объёмы прямо у пользователей. Но это лишняя сущность как в плане софта (одним браузером уже не обойтись)

Сразу вспоминается peerCDN, вроде его yahoo скупила сейчас.

Задача стоит в построении распределённой устойчивой к запретам и блокировкам системы.

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

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

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

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

Впрочем, даже заблокировав Интернет целиком можно систему не убить — коммиты можно будет носить на флешконете :) Тут только жёстче встанет вопрос спама/вандализма/школоты — разрешить каждому коммитить, значит снять вопрос контроля качества с гейта.

(да, всё сказанное именно к базе сообщений на git, так как BTSync, конечно, блокируется легко).

KRoN73 ★★★★★ ()

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

Возможные решения, что я вижу:

— Инкрементные автоматические ID со смещением. В случае закрытой системы между участниками можно договориться, что в N последних цифр ID прописан номер участника системы. Минусы — жёсткая, тяжело расширяемая структура, сужение диапазона рабочих ID, на большинстве форумов в базах в качестве ID используются 32 бит целые.

— Использовать в качестве ID дату + несколько цифр UUID. Подобная же фигня, ещё большее сужение диапазона ID.

— Назначение при импорте сообщений своих уникальных ID в каждом проекте. Проблема в обмене ссылками. Одно сообщение на разных гейтах получается под разным номером... С другой стороны, по хорошему, парсер форумов не должен сохранять в БД полные URL'ы тем, форумов и сообщений — система распределённая, завтра домен поменяется, ссылки все накроются? А если написано на другом гейте но на форум, копия которого есть в текущем гейте читателя — зачем ему уходить на первый гейт? Так что напрашивается трансляция URL сообщений/тем/форумов во внутренний формат и обратное преобразование при показе. В этом случае несовпадающе ID на гейтах проблемой быть перестают. Достаточно рядом с сообщением хранить реальный UUID и сохранять при размещении ссылки в базу именно его. В этом варианте тоже есть подводные камни, но мне он кажется более реальным.

Ещё как вариант — использовать унифицированный формат ссылок, хранящий и UUID, и локальный ID.

KRoN73 ★★★★★ ()

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

KRoN73 ★★★★★ ()

А если хранить информацию об аттачах в git-annex?

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

Еще интересно выглядят планы по добавлению telehash.

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

А если хранить информацию об аттачах в git-annex?

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

Сами файлы можно хранить где угодно, куча бэкендов есть

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

Еще интересно выглядят планы по добавлению telehash.

А в чём суть?

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

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

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

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

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

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

А в чём суть?

P2P протокол, предполагается использовать для (автоматической) синхронизации изменений между репозиториями, которая в настоящий момент работает через xmpp/ssh. Упомянул как возможную альтернативу проприетарному BTSync.

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