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

мысли вслух по поводу архитектуры и решений (много букв)
 
1 2 3
RU Dmb_2007 #05.05.2014 21:51  @Balancer#23.04.2014 23:11
+
-
edit
 

Dmb_2007

опытный

Balancer> Да, что-то общее отчасти просматривается в идее :) Кстати, если припрёт, в рамках этой системы можно будет обмениваться обновлениями при отсутствии онлайна, на «флешконете» :)
Вот это - по теме?
AREA: R50.SYSOP (Region 2:50 official Sysop echo)
FROM: Yura Vdovytchenko 2:5034/10.921
TO : All
SUBJ: Динамические сайты в FidoNet

Hello All!
Подскажите плиззз в какой эхе сабж будет правильно обсудить тему.
Интересует мнение друзей :)

Расшифровка сабжа.
Сайты в Fido.(FidoСайты). Прошу не путать с интернет-сайтами и шлюзами из инета в Фидо.
Это сайты которые могут инкрементно распространяться по фидо-сети и работать в режиме оффлайн на ПК пользователя.

В течении 4х лет:
Разработана объектная файловая ДБ для хранения и инкрементного обновления инфы - это электронные каталоги. Разработан редактор электронных каталогов (win-софт). Разработано ПО ITCodAPI для доступа Web-виджетов к БД. Разработана технологией Web WidGet - многослойные интерактивные Web-интерфейсы ИС.
В сумме получаем динамические сайты которые могут инкрементно распространяться по любым каналам связи включая Fido (через фэхи). Сайт может работать локально в браузере на ПК пользователя. по факту запуска на пк пользователя - может использовать инет или иную сеть (если есть) для отправки и получения инфы из различных онлайн источников.

По схеме лицензирования все наши разработки в FidoNet можно использовать бесплатно (некоммерческое использование).

С наилучшими пожеланиями, 2:5034/8 Yura Vdovytchenko.

wfido

 
Si vis pacem, para bellum  34.0.1847.13134.0.1847.131
RU Balancer #05.05.2014 21:53  @Dmb_2007#05.05.2014 21:51
+
-
edit
 

Balancer

администратор
★★★★★
Dmb_2007> Вот это - по теме?

Похоже, да. Но они планируют что-то сильно самостоятельное. Таких проектов море и все они не взлетают — обычный массовый пользователь, даже квалифицированный, не хочет разбираться. А неквалифицированный и вообще не может.

Я же планирую более простую систему на уже активно используемых решениях, которая легко понятна специалисту, а не специалисту вся сложность будет только найти очередной web-гейт, если забанят старый.
 34.0.1847.13134.0.1847.131
+
-
edit
 

Balancer

администратор
★★★★★
Хочется сделать возможность заведения репозиториев в проектах уровня GitHub. Но тогда надо укладываться в 1Гб объёма на репозиторий. Сейчас же месячный объём составляет около 5Гб. Первая мысль — резать, всё же, разные проекты по разным репозиториям. Это и автономность лишнюю даст к тому же. Но как ни режь, а Морской жрёт 2Гб в месяц. То ли вводить лимиты на аттачи (для файлопомойки предлагая пользоваться решениями, типа BTSync), то ли размещать подобные крупные проекты не на открытых репозиториях а только на своём сервере. Первый вариант — введение ограничения и лишней сущности. Второй — снижает устойчивость системы :-/
 35.0.1916.11435.0.1916.114
+
-
edit
 

Balancer

администратор
★★★★★
Очень хочется пользоваться для файлопомойки чем-то типа BTSync, но так пока и не могу придумать как лучше :) Как ни кручу в голове, всё фигня получается.

С пользователями, всё же, придётся переходить на вариант userhost и использовать конкретные централизованные хранилища.

В балансе human readable / machine readable склоняюсь больше к последнему. Локальную ручную работу с базой можно поменять на работу локального софта для просмотра/редактирования. Но ещё буду думать...
 3434
+
-
edit
 

Balancer

администратор
★★★★★
Некоторое суммирование основный идей/понятий, с которыми, в общем, вопросов нет.

— Один проект — один репозиторий. Проект — набор форумов и подфорумов определённой тематики.

— Один временной срез — один репозиторий. Для мелких проектов вообще без деления по времени, для крупных — с нарезкой по годам, месяцам, даже неделям(?)

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

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

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

— Требуется реализация переноса сообщений и тем (со всей историей) между проектами.

— Вопрос доверия (WoT) частично решается системой игнорирования.

Вопросы нормально не решённые:

— Проблема с аттачами в больших объёмах. Хранить в репозитории проекта накладно, выносить в отдельную сущность не хочется.

— Проблемы со спамом. Очевидно, решать проблему придётся гейту. И не сложно фильтровать гейты, которые будут этим злоупотреблять. Однако, мусор в системе будет накапливаться. Ведь удаление материалов в системе в явном виде отсутствует.
 3434
+
-
edit
 

Balancer

администратор
★★★★★
Неожиданная весьма актуальная цель. В связи с регулярной гибелью всяких рекомендательных сервисов (вот, Имхонет тут недавно банили, сам он страшно испортился...) появилась мысль хранить в распределённой базе ещё и наборы объектов (книги/музыка/фильмы — в смысле, не сами произведения, а статьи по ним) плюс наборы оценок этих объектов. Что позволит строить рекомендательные системы с открытыми данными (сами системы и алгоритмы могут быть закрытыми на конкретных проектах, главное — доступность и сохраняемость данных).
 35.0.1916.15335.0.1916.153
+
-
edit
 

Balancer

администратор
★★★★★
Сегодня продолжил возиться с форматом хранения. Один из промежуточных вариантов закоммитил в

По размышлениям последних дней, связанных с другими вопросами, вдруг пришёл к выводу, что сообщения в архиве лучше хранить не в JSON, а в Markdown с метаданными. То есть, Markdown тут вообще не при чём, всё равно разметка у нас — надмножество BB-Code (хотя можно для простых сообщений и чистый Markdown задействовать), но тут прикол именно в хранении в ещё более человеко-читаемом формате, чем JSON. В шапке Markdown-сообщения метаданные в YAML-формате (что уже автоматически означает и поддержку JSON — он является подмножеством YAML), а потом идёт собственно текст сообщения в обычном виде. И как формат хранения получается нормально (хотя и медленнее парсинг, чем для чистого JSON) и читать прямо с файлов нормально выйдет.

Также решил, что нужно вести разбивку по каталогам не в виде ДАТА/КАТЕГОРИЯ, а, наоборот, КАТЕГОРИЯ/ДАТА — это позволит естественным образом делать для разных категорий разные объёмы репозиториев. Где-то можно всю категорию разместить в одном репозитории, где-то один репо == один год, где-то — разбивка по месяцам.
 3737
RU Balancer #16.10.2014 16:43  @Balancer#16.10.2014 10:51
+
-
edit
 

Balancer

администратор
★★★★★
Здорово. Оказывается, этот формат метаданных (YAML в Markdown) вполне понимает GitHub. Так что записанные в этом формате сообщения можно прямо с GH читать. Например Приучить ещё народ пользоваться Markdown, который перекрывает 90% потребностей — вообще шикарно будет :D
 38.0.2125.10438.0.2125.104
+
-
edit
 

Balancer

администратор
★★★★★
Морской слишком жирный получается, чтобы постить на том же GitHub'е в формате репо == месяц. За месяц пишут по 2-3Гб :) Резать по неделе — уже как-то извращённо получается... Так что его репозитории, наверное, придётся у себя держать. Вот Человек и общество — тот по 150..250Мб в месяц. Нормальный размер. Ещё и поменьше будет, если вынести Политический в отдельную категорию.

Моделисты потребляют по 0.7-1.3 Гб в месяц.
 38.0.2125.10438.0.2125.104
+
-
edit
 

Balancer

администратор
★★★★★
Дамп БД форумов в Markdown доступен через BTSync для чтения по ключу
BMENNNKEXTAJDWZS6TMDJYMPTRJWH6JFH
(сейчас 20Гб, в итоге будет гигабайт за 100, наверное, конвертация идёт за май этого года в направлении декабря 1999-го)
 38.0.2125.10438.0.2125.104
RU Balancer #16.10.2014 17:02  @Balancer#16.10.2014 16:59
+
-
edit
 

Balancer

администратор
★★★★★
Если нужно скачать только тексты, без картинок (которые и жрут много) или только отдельные категории — есть файл .SyncIgnore

Bittorrent Sync. FAQ

Перевод неофициального FAQ по программе BitTorrent Sync. GreatMarko, спасибо за разрешение на публикацию! Содержание документа Официальная документация Где можно скачать последнюю версию BitTorrent... // voipinforu.wordpress.com
 

(пошла конвертация за апрель 2014).
 38.0.2125.10438.0.2125.104
+
-
edit
 

Balancer

администратор
★★★★★
Из изменений по формату — наверное, поменяю информационные файлы с json на yaml и переименую поля — приятнее читать будет, плюс заточка под будущее взаимодействие с чужими форумами.
 38.0.2125.10438.0.2125.104
RU Balancer #16.10.2014 22:04  @Balancer#16.10.2014 16:59
+
-
edit
 

Balancer

администратор
★★★★★
Дамп за 2013..2014 гг занял 55Гб. BTSync проиндексировал пока половину.
 38.0.2125.10438.0.2125.104
+
-
edit
 

Balancer

администратор
★★★★★
Всё же, Zim при всех плюсах имеет существенный минус — нестандартная разметка. Что затрудняет и работу с документами в ручном режиме (мне Zim часто просто лень запускать, а mcedit или Far Manager открыты всегда), и поддержку альтернативными инструментами, в т.ч. в будущем.

С другой стороны, сегодня очень активно развивается синтаксис Markdown.

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

В остальном — то же самое. GitHub со SparkleShare, вывод на сервере индексируемых данных, забираемых с GitHub и т.п.

Разве что сейчас нет прямого аналога Zim в роли десктопной Markdown-Wiki. Ковыряюсь вручную с текстовыми файлами. Затравка (на сайт пока не выводится):

Balancer/airbase

airbase - Static sources for Airbase.ru // github.com
 

Побочный бонус: оно ещё и на GitHub нормально смотрится и даже редактировать файлы можно прямо там, онлайн:

Balancer/airbase

airbase - Static sources for Airbase.ru // github.com
 
 3838
+
-
edit
 

Balancer

администратор
★★★★★
Продолжаю эксперименты, изыскания, размышления...

— Каждый объект в системе должен иметь свой однозначный UUID. Пост, аттач, топик, форум, запись блога, утянутая копия внешней (реального Интернета) страницы... Должна быть возможность направленно, прямо и обратно связывать произвольные объекты (пост указывает на аттач, запись блога — на утянутую ссылку, в аттаче можно посмотреть, кто на него ссылается и так далее)

— Для этого нужен P2P-DNS. В копилку  — http://habrahabr.ru/post/120015/ (но решение спорное)

— Пока таких DNS нет, можно развивать систему в расчёте на малые объёмы и внутреннее доверие ресурсам

...

— Файловая система должна быть p2p, распределённой. Хранение больших объёмов данных на одних только Web-гейтах ущербно и делает систему уязвимой. Нужно смотреть в сторону Gluster, Tahoe или аналогов. Лучше всего именно чтобы каждый участник мог предоставлять сколько не жалко и иметь доступ в R/O ко всей системе, а в режиме хранения собственных данных — пропорционально отданному пространству.

— Пока такая ФС не подобрана нужно проектировать систему на классических ФС с синхронизацией. BTSync, для мелочи — всякие DropBox и т.п.

...

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

...

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

...

— Много мыслей крутится в плане регулирования ресурсов и политики. Хранение ресурсов, потенциально или прямо нарушающих авторские права или государственные законы должно порождать какой-то «децентрализованный» институт регулирования. Что-то типа «инфомилиции», «модераторов-на-рейтинге». Сама суть системы состоит в том, чтобы выводить информацию из под ударов государства, так что она должна получаться [над/вне]законной. При этом она должна иметь какой-то сетикет, не позволяющий свалиться в тупое файлохранилище порнухи, вареза, спама. Нужны те, кто всё это будет чистить, оставляя то, что отвечает интересам большинства пользователей. Материалы, нарушающие авторские права, в зависимости от их рейтинга потенциально можно использовать для добровольной выплаты авторам соответствующих вознаграждений. Это может и авторов привлечь к системе и решение сделает более этичным. Я, всё же, верю в то, что многие готовы платить за качественные вещи, особенно если оплата будет разумной, будет как-то внешне отображаться, процесс оплаты лёгким... В общем, тут много надо думать. И уже заранее.
 39.0.2171.9539.0.2171.95
+
-
edit
 

Balancer

администратор
★★★★★
С точки зрения форумов — нужно написать пару плагинов для MyBB, позволяющих просто подключить свой форум к системе для двухсторонней синхронизации. Это, кстати, автоматом свяжет (для начала) основной и запасной сервера.
 39.0.2171.9539.0.2171.95
LT Bredonosec #04.01.2015 03:51  @Balancer#04.01.2015 02:02
+
+1
-
edit
 
Balancer> — Файловая система должна быть p2p, распределённой. Хранение больших объёмов данных на одних только Web-гейтах ущербно и делает систему уязвимой. Нужно смотреть в сторону Gluster, Tahoe или аналогов. Лучше всего именно чтобы каждый участник мог предоставлять сколько не жалко и иметь доступ в R/O ко всей системе, а в режиме хранения собственных данных — пропорционально отданному пространству.
а как гарантировать, что каждый участник будет именно гарантированным хранилищем, а не зловредом, который возьмет и попортит (частично изменит, удалит) данные? Или будет юзать информацию для всяких нехороших дел типа отслеживания оппонентов по ипам (напр, участников из уа, мягко говоря, не поддерживающих теперешний строй там, с целью передачи сбу, а это - цена жизни человека), и т.д. - словом, несанкционированной деятельности.
не будет-ли решение, создающее адекватную ценности защиту, неадекватным в плане легкости работы системы? Учитывая, что мощности, выделяемые на преодоление защиты, в некоторых случаях могут быть значительными, сам концепт раздачи будет-ли адекватен?

(несколько лет назад в более легкой форме сталкивался со случаем "неправильного человека у рычагов": один из "админов" взял и наделил всеми правами туловище, обязавшееся диз красивый соорудить. Туловище вместо этого освоилось, и по своему разумению удалило примерно треть тем обсуждений (сути которых не поняло и потому решило, что они скучные), а равно несколько сотен или тысяч (уже не понять) фотографий. Потом была забавная войнушка со взаимными банами-разбанами-разжалованиями-наделениями прав, и т.д. С тех пор еще более внимательно отношусь к вопросу "кому доверять рычаги")
Voeneuch, учи физику, манажор ))  26.026.0
RU Balancer #04.01.2015 11:55  @Bredonosec#04.01.2015 03:51
+
-
edit
 

Balancer

администратор
★★★★★
Bredonosec> а как гарантировать, что каждый участник будет именно гарантированным хранилищем, а не зловредом

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

Bredonosec> Или будет юзать информацию для всяких нехороших дел типа отслеживания оппонентов по ипам

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

Bredonosec> не будет-ли решение, создающее адекватную ценности защиту, неадекватным в плане легкости работы системы?

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

Bredonosec> (несколько лет назад в более легкой форме сталкивался со случаем "неправильного человека у рычагов": один из "админов" взял и наделил всеми правами туловище

Именно для таких целей я и отрабатываю понемногу подходы, типа форумной RPG. И планирую базироваться на p2p-технологиях. Это защитит систему от индивидуального произвола, позволит принимать коллективные решения, а в случае серьёзных расколов позволит хотя бы сохранить старые данные и «уйти в подполье», создав свою отдельную систему с единомышленниками.

Bredonosec> и по своему разумению удалило примерно треть тем обсуждений

Если бы ты читал эту тему с начала, то увидел бы, что я думаю вообще о DVCS — распределённой системе контроля версий. Где хранится история изменений, где грохнуть старые данные очень сложно и эти данные легко архивировать всем желающим. Вопрос даже не в произволе администраторов, а в элементарной децентрализации, уходе от блокировок, от зависимости от работоспособности серверов и т.п. Хотя, скорее всего, придётся отказаться от использования DVCS для аттачей, иначе выходит очень громоздко. Т.е. версионная целостность будет только для текстов. А файлы, в принципе, могут быть повреждены/удалены доверенной нодой. Но, поскольку доступны они будут всем участникам, то любой желающий сможет делать их бэкап у себя самостоятельно и при необходимости получит возможность восстановить.
 3939

AXT

инженер вольнодумец
★☆
Balancer> — Каждый объект в системе должен иметь свой однозначный UUID. Пост, аттач, топик, форум, запись блога, утянутая копия внешней (реального Интернета) страницы... Должна быть возможность направленно, прямо и обратно связывать произвольные объекты (пост указывает на аттач, запись блога — на утянутую ссылку, в аттаче можно посмотреть, кто на него ссылается и так далее)

Криптостойкий хэш, хотя бы 256 бит, и база данных по трансляции хешей обратно в ссылки на ресурсы. Криптостойкость хеша гарантирует, что подсунуть фальшивую ссылку не выйдет, ибо запаришься подбирать хэш.
Кстати, думаю в ленивом режиме примерно год уже насчёт реализации подобного в игровом движке самопальном. Цель — исключение конфликтов модов благодаря (почти) гарантированному уникальномуу идентификатору.

Balancer> — Пока такая ФС не подобрана нужно проектировать систему на классических ФС с синхронизацией. BTSync, для мелочи — всякие DropBox и т.п.

На самом деле ты сейчас говоришь о классической key-value database, просто видимо не осознаёшь. :) Фрагменты поля тоже могут иметь свой индекс.

Balancer> — Git, боюсь, для крупных компонентов, всё же, вещь неподъёмная. Надо или отказываться от версионности или придумывать что-то обходное.

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

Balancer> — Хреново, что так пока и нет энтузиастов, готовых помочь в разработке системы. В одно рыло такое дело поднимать не столько сложно, сколько концептуально неоптимально. Можно проморгать какое-то удобное решение, реализовать не нужное, да и мысли лучше формулируются в процессе общения, а не в процессе внутреннего монолога :) Так что хоть такие записи приходится делать, порой, чтобы не терялось и оформлялось.

Увы, мне на свою деятельность-то не хватает времени, а то бы помог, ибо идея "гарантированного распределённого хранилища информации" мне нравится. А то вдруг, в самом деле, случится катаклизм какой-нибудь, и хранящаяся на единственном сервере ценная инфа помрёт, вместе с бекапами?
Так что только на словах могу.

Balancer> Я, всё же, верю в то, что многие готовы платить за качественные вещи, особенно если оплата будет разумной, будет как-то внешне отображаться, процесс оплаты лёгким... В общем, тут много надо думать. И уже заранее.

Да. Открыть ящик Пандоры легко, закрыть — невозможно.
... так пускай наступает на нас холодным рассветом новый день ...  13.0.782.22013.0.782.220
+
-
edit
 

Balancer

администратор
★★★★★
Balancer>> — Пока такая ФС не подобрана нужно проектировать систему на классических ФС с синхронизацией
AXT> На самом деле ты сейчас говоришь о классической key-value database

Не совсем. Основная задача — возможность работать с системой прямо через ФС. Классические key-value это делать не позволяют. Если только на них эмулировать сразу опять «настоящую» ФС :)

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

А у нас итак основные данные каждого объекта — самостоятельный JSON-файл. Git нужен даже не столько для версионности, сколько для доступного распределения системы хранения по репозиториям. Чтобы была децентрализация, возможность работы при отказе основных хранилищ, ну и чтобы нельзя было незаметно модифицировать чужой код (но это уже снова версионность). В принципе, Git тут подходит хуже, чем Mercurial, первый позволяет значительно легче модифицировать историю, но зато он очень популярен. Приходится искать компромиссы...

AXT> А то вдруг, в самом деле, случится катаклизм какой-нибудь, и хранящаяся на единственном сервере ценная инфа помрёт, вместе с бекапами?

Пока куда актуальнее давление государств (не только России) на свободу распространения информации. А это — способ выхода из под такого давления. Потребуют убрать какой-то топик с форума (по сути — Web-гейта) — да ради Бога, я законопослушный гражданин. А то, что работающая версия этого же топика доступна в p2p или через иностранные гейты (а также i2p/tor/etc) — это меня уже не касается. Я формально требование выполнил. И уже не моя вина, что информационный век требует новых подходов и информацию так просто не задавать :)

То, что вырастает ещё и защищённость от катаклизмов/произвола администраторов/т.п. — это уже очень важный и приятный, но бонус :)
 39.0.2171.9539.0.2171.95

AXT

инженер вольнодумец
★☆
Balancer> Не совсем. Основная задача — возможность работать с системой прямо через ФС. Классические key-value это делать не позволяют. Если только на них эмулировать сразу опять «настоящую» ФС :)

Так ФС и есть key-value database по определению. Ключ — имя файла. Т.е. тут всё инвариантно. Разница только в том, где конкретно ключик преобразовывается в значение. В операционке или в нашей программе.

Balancer> Чтобы была децентрализация, возможность работы при отказе основных хранилищ, ну и чтобы нельзя было незаметно модифицировать чужой код (но это уже снова версионность).

В git на самом деле тоже нельзя незаметно; после, например, rebase хэши коммитов поменяются. И старая история не сотрётся сразу, а "уйдёт в тень". И вытащить её оттуда можно через поиск невидимых голов ... или если помнить оригинальные хэши. Только git gc убьёт окончательно.
Но в любом случае, придётся делать свою БД. Увы. Я шерстил всю Сеть в поисках подходящей для меня — нифига не нашёл. Либо сверхтяжёлая, либо функционала нет, либо лицензия идиотская.
... так пускай наступает на нас холодным рассветом новый день ...  13.0.782.22013.0.782.220
+
-
edit
 

Balancer

администратор
★★★★★
AXT> Так ФС и есть key-value database по определению.

Не совсем :)

AXT> Ключ — имя файла.

Только кроме содержимого файла по имени у нас есть каталоги, поиск, атрибуты, чтение/запись по смещению, отслеживание изменений и т.д., и т.п. Всё это в чистом key-value отсутствует. И хотя в key-value всё это можно реализовать, но это именно эмуляция более сложной системы.

AXT> Только git gc убьёт окончательно.

О чём и речь. В результате можно «незаметно» изменить БД так, что если сразу изменение не всплывёт, концов потом не найти.

AXT> Но в любом случае, придётся делать свою БД. Увы.

Я планирую (в теме уже расписывал) использовать Git/JSON в качестве основного хранилища, а классические БД — в роли кеша для локальной работы гейтов и/или приложений (когда дело дойдёт до них). Т.е. вместо цепочки
клиент <-> браузер <-> БД
или даже
клиент <-> браузер <-> сервер <-> БД <-> репликация <-> БД <-> сервер <-> браузер <-> клиент
получается множество цепочек
клиент <-> браузер <-> сервер <-> БД <-> раcпределённое хранилище.

При чём формат распределённого хранилища будет унифицирован, а вот связка БД/сервер будут произвольными, что позволит работать с общим бэкендом разным форумным движкам или клиентам. В общем случае вплоть до локальной работы
клиент <-> приложение <-> распределённое хранилище
или даже ручной работы
клиент <-> распределённое хранилище.

Правда, понятно, такие варианты уже доступны будут только для доверенных пользователей. Хотя в режиме «только чтение» — сколько угодно. Я, вот, и с Авиабазой уже экспериментировал с раздачей хранилища в R/O — Авиабаза распределённая [Balancer#16.10.14 10:51] (Git) и Авиабаза распределённая [Balancer#16.10.14 16:59] (BTSync)

Например: https://github.com/Balancer/forums-society-2014-10/tree/...

Кстати, раньше форумов наверняка заработают сделанные таким образом «распределённые» сайты:

Авиабаза распределённая [Balancer#27.11.14 15:37]

Всё же, Zim при всех плюсах имеет существенный минус — нестандартная разметка. Что затрудняет и работу с документами в ручном режиме (мне Zim часто просто лень запускать, а mcedit или Far Manager открыты всегда), и поддержку альтернативными инструментами, в т.ч. в будущем. С другой стороны, сегодня очень активно развивается синтаксис Markdown. Так что почесал я репу, почесал, да и решил развивать идею статических распределённых сайтов, базирующихся на разметке Markdown. Разве что с расширенной…// Авиабаза
 


Авиабаза, в принципе, уже готова отдавать страницы в таком формате. Я практически реализовал подобную систему на Zim:

Новый формат разработки сайтов. И airbase.ru в частности. [Balancer#14.01.14 17:00]

Процесс отладки подходит к концу. Пример страницы, созданной через Zim-wiki: Harbin Z-19 @ударные_вертолёты @Harbin_Z-19 @HAIC @КНР Второй, после CAIC WZ-10, бронированный ударный вертолёт КНР с тандемной схемой размещения экипажа. Разработан китайской компанией HAIC (Harbin Aircraft Industrial Corporation) на основе Harbin Z-9. Z-19 является специализированным ударным вертолетом на основе Harbin Z-9, но отличается от исходной версии тандемной кабиной. Силовая установка, роторная система и…// Авиабаза
 


Но потом решил отказаться от пусть и удобного, но форматоспецифичного приложения, сделав ставку на Markdown/JSON:

Balancer/airbase

airbase - Static sources for Airbase.ru // github.com
 

Хотя работать локально с таким вариантом сейчас менее удобно, но намного перспективнее и удобнее в плане хранения :)
 39.0.2171.9539.0.2171.95
LT Bredonosec #09.05.2015 16:06  @Balancer#09.05.2015 03:40
+
-
edit
 
Сообщение было перенесено из темы Бронеюмор: фото и картинки.
Balancer> Это не у нас :) Я, всё же, стараюсь избегать внешних ссылок, когда есть свои материалы. А то кто знает, что будет с этой ссылкой ещё 5..10 лет спустя? Материалы-то наших форумов я хотя бы в перспективе стараюсь сделать распределёнными и серверно-независимыми :)
логика правильная, согласен полностью и поддерживаю )
Хотя за сохранность руборда я уверен )
почти 2 млн юзеров гарантией :)
Voeneuch, учи физику, манажор ))  26.026.0
RU Balancer #13.05.2015 15:06  @Bredonosec#09.05.2015 16:06
+
+1
-
edit
 

Balancer

администратор
★★★★★
Bredonosec> почти 2 млн юзеров гарантией :)

Google, закрывавший на порядки более масштабные проекты смотрит с недоумением :)

Единственная более-менее гарантия сохранности данных — это их децентрализация. Авиабаза сама по себе тоже ничего не может гарантировать, потому я и стараюсь реализовать децентрализованную систему.
 42.0.2311.13542.0.2311.135
LT Bredonosec #13.05.2015 20:11  @Balancer#13.05.2015 15:06
+
-
edit
 
Balancer> Google, закрывавший на порядки более масштабные проекты смотрит с недоумением :)
у него были другие, более интересные проекты. Для него 2 млн - это мелочь.
Борда - это проект фактически компании тогда молодых парней (Batva, Dimon, еще несколько), теперь рулят там несколько других человек из коллектива, - то есть, это не проект какой-то большой конторы, которой насрать на мелкое. Для команды это вполне себе большое.

Balancer> Единственная более-менее гарантия сохранности данных — это их децентрализация.
децентрализация? В плане рассредоточения по разным хостингам-серверам-веб-узлам, но в рамках одного проекта? Честно говоря, думаю, это скорее защита от направленного уничтожения властями какой-либо страны. Как защита от рассыпания и смерти в случае отказа (неважно почему) создателя продолжать работу с проектом - это не спасет.

Так что, в этом плане борда ничуть не менее надежна.
Voeneuch, учи физику, манажор ))  26.026.0
1 2 3

в начало страницы | новое
 
Поиск
Настройки
Твиттер сайта
Статистика
Рейтинг@Mail.ru