Проблема работы 140+ участников в одном хранилище

Рустам “тоже” человек

Комментарий выше прилетел после вчерашнего факапа, случившегося во время занятия по заметковедению на курсе “Второй мозг”. А в этой короткой заметке хочу поделиться своим “открытием”.

Я регулярно утверждаю, что в сегодняшних реалиях самый верный способ остаться без своих данных — это доверить хранение всяким облачным сервисам. Если мы говорим про заметковедение как некий сложный процесс, то оставлять свои записи в облаках, которые могут отключить потому, что “почесался мизинец правой ноги в полнолуние”, — глупейший поступок, на который способен заметковед.

Отсюда тезис: если это не на твоём компьютере и не контролируется тобой — это не твоё, и каждый может это у тебя отобрать. А меня, если чему и научил “двор”, так это тому, что если кто-то что-то пытается у меня отобрать или даже намекает на это своими поступками и словами — сначала бей (вместо “здрасте”), а потом разговаривай. Этот подход, кстати, работает и в корпоративной среде, когда, например, идёт “делёж” бюджета на следующий год или выставляют показатели на очередной отчётный период (обычно завышенные). Однако вернёмся ко “Второму мозгу” и открытию.

На текущем потоке “Второго мозга” 140 участников, которые исследуют методы логического анализа, работы с информацией (“нечтение”) и практикуют заметковедение.

Логика и “нечтение” — это прекрасно настроенные и выверенные образовательные программы, которым уже по три года. А вот “заметковедение” — это молодой, но крайне перспективный курс. В моей картине мира он выступает фундаментом для двух других — инструментом фиксирования личного опыта и формализации (в виде конспектов) знания, полученного в результате практик логики и “нечтения”. Иными словами — очень важный элемент.

Когда я тестировал совместное заметковедение в открытых группах, на занятия приходило от 20 до 60 участников, и в каждом из форматов мы тренировали разные механики работы с файлами. Больше всего мне понравился формат с использованием общего хранилища — он работал прекрасно на группе в 20 участников (может, даже 40), но сломался в “боевых” условиях на 140 участниках. Почему?

Сначала думал, что железо, то есть сервер, слабенький. Ну да, слабенький NAS 218j был очень слабой машинкой, и он буквально задыхался от такого “внимания”. Не проблема — обновимся. Сейчас это 923+ с 32 гигами оперы и половиной терабайта SSD-кеша и прочими плюшками. Для сравнения — аналогичный моему Synology VPS обойдётся ± в 20к в месяц. Протестировал скорость — это магия, просто супер! Ну, думаю, следующее занятие пройдёт, как я планировал, а напланировал я очень много и интересно.

Но не тут-то было, как говорится: мы предполагаем, а Бог располагает. Начались проблемы иного характера. Когда 90 участников подключилось к серверу и начали работать с файлами, проблема была не в скорости — сервак справлялся, у меня ещё в запасе было 80% мощности (во всём: от использования дисков и процессора до памяти и сети), — а в логике работы. Этого я не предусмотрел.

Три месяца назад, когда я только планировал занятия по заметковедению в Obsidian, связался с разработчиками (у нас достаточно тёплые отношения) и спросил, могу ли я использовать Obsidian Sync для того, чтобы подключить 150 участников. Ответ был однозначный: нет, максимум — 20 человек. Я подумал, что это ограничение их синка. Однако моя ошибка была не в этом. Проблема не в синке — он будет работать. Проблема в логике.

Obsidian работает на файлах, не в облаке, а это значит, он ПОСТОЯННО их “касается” — на хранилищах участников. С двадцатью участниками, работающими в одном хранилище, всё ещё возможны “неприятные сбои” — такие как создание конфликтных файлов, исчезновение расширений у файлов .md. Но риск возникновения подобного — где-то около 1%, то есть, в моей картине мира, незначительный настолько, что могу проигнорировать. Однако когда количество пользователей одного хранилища вырастает до 150 человек, риск с 1% взлетает до 40%, а это уже — почти у каждого второго.

Ровно так и случилось: через одного участника Obsidian не видел файлов, “терял” расширения, создавал конфликты. Что добавляло стресса лично мне. И комментарий в самом начале — это из обратной связи. За что огромное спасибо нашей с Максом аудитории — вы САМЫЕ лучшие, терпеливые и вообще мимишечки :slight_smile:

Тем не менее, несмотря на все “невозможно” от разработчиков, я, кажется, нашёл решение, которое и думаю протестировать в это воскресенье с участниками потока. Плюс попробуем новое занятие курса “Как (не)читать книги”.

Как вы думаете, какое решение я придумал? И какое можете рекомендовать еще.

Если гит, то … есть что-то удобное для пользователей, требующее наименьшего напряжения с их стороны.

проблема в решении конфликтов при одновременной работе пользователей с одними файлами. то есть это должно делать какое-то умное хранилище, и отдавать результат обсидиану.
возможно объектное хранилище как-то может помочь.

1 лайк

это что такое … какое-то особое хранилищ?


вот оно

Проблема не в объектом хранилище, я у себя дома ± аналогично поднял, а проблема в единовременно обращении 140+ пользователей к файлам на этом хранилище и создании конфликтов.

Моя система тоже отлично отрабатывает конфликты, но обсик не предназначен для такого, он начинает очень странно себя вести, создавать файлы без расширений, бесконечно дублировать уже созданные, потому что 10 обсидианов разных пользователей “коснулись” файлов и посмотрели их мету и что-то в ней обновили, незаметно для всех, но заметно для облачного сервиса, вот такая вот канитель

@Semyon объяснил верно, проблема именно в этом. У тебя Synology выступает в роли хранилки, т.е. это по сути обычная сетевая шара, основанная на файлах. При обращении к одному и тому же файлу нескольких пользователей для его изменений, возникает конфликт версий. Synology в роли файлового хранилища никак эту проблему решить не сможет, без разницы чем файл открыли Obsidian/Notepad/etc. При попытке сохранить файл, который уже кем-то в этот момент отредактирован, но еще не закрыт возникает ошибка доступа, что приводит к тому, что Obsidian “клинит” и он начинает “дурить” пытаясь во что бы то ни стало сохранить документ, создавая дубли и в особо тяжелых приступах сохраняя без расширения. Для решения в том числе таких проблем и изобрели всякие git-ы и объектные хранилища типа S3.

1 лайк

Такую штуку нашел -

2 лайка

Так … уже интересно, то есть если я на свое синолоджи разверну объектное хранилище, то этой проблемы может не возникать, верно понимаю?

Прикольная штука … пойду изучать …

Я пока настроил вот такое решение, но не уверен, что это самое оптимальное

Короче, почитал, но ни одно из решение, даже объектные хранилища не решат сейчас этой задачи, одновременного синка 100+ девайсов. Система начинает вести себя непредсказуемо после 20 пользователей.

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

Второй мне, честно очень даже нравится … скорее всего даже сильнее чем решение с гитом, потому что слишком много “движений”

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

Там проблема даже не в конфликтах при редактировании одного файла. Из 100 человек одновременно что-то прявят только 30%, каждый из них правит свой файл, т.е. именно конфликтов на уровне файлов - около 0.

Проблема в том, что обсидиан:

  1. Сохраняет файлы каждые 2 секунду, т.е. это получаается 15 правок в секунду.
  2. Да ещё и сохраняет их атомарно с т.з. файловой системы: сначала сохраняет файл с временным именем, а потом его переименовывает.

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

  • увидел событие временного файла
  • пошёл читать
  • пока шёл читать - файл переименовали и программа синхронизации прочитала “пусто” во временном файле
  • потом к ней прилетело событие переименовать файл в нормальный, она и переименовывает пустой временный файл в нормальный.

или что-то похожее. На MacOS я помониторил файловые операции и у себя такого не нашёл, но по логам получается что “плохие файлы” могут заливаться из любой ОС (мак, windows, linux) не со всех, т.е. возможно мне повезло и просто у меня ничего не ломалось.

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

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

Через Git работают команды гораздо больше и с гораздо более сложными правками (при разработке софта).

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

Совершенно верно, не решает глобально — все в одном хранилище, но решает локально, малые группы друг-друга видят.

Я же попробую в этот раз работать через шарды, но на следующий поток решать задачу с единым хранилищем :))

Тем более что инструкция с гитом уже готова :slight_smile:

А сейчас почему решил продолжать с шардами?

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

Результат был не самый однородный, то есть из десяти 5 справились на отлично, 2 нужна была легкая помощь, три требовали пошаговой поддержки.

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

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

В то время как с драйвом – все просто, настраиваешь один раз и все работает.

Я не исключаю, что ГИТ будет в следующем потоке, но пока шарды. Вчера система показала себя на 57 участниках отлично.

Мне доступ к заметкам нужен с одной, вполне конкретной целью – выявить привычки участников. Я хочу наблюдать, то как они работают, как связывают и как вообще относятся к подобной системной работе. Это ведь лишь начало, завтра, например, будет первая “домашка” на всю неделю, где будет использованы ручки и бумаги, ну другие принадлежности. Я расскажу на встрече и для чего.

Если достаточно чтобы только у тебя был доступ ко всем заметкам, тогда шарды точно проще и задачу решают.

Кстати можно не пушить и не пуллить: в git-плагине естъ кнопка ‘commit and sync’ (стрелка вверх в кружочке). По моему её достаточно - можно воспринимать её просто как кнопку принудительной синхронизации тогда, когда тебе это надо.

если ещё настроить Auto commit and sync и шаблон сообщения при автокоммите, то остаётся разобраться с первоначальной установкой git-а и конфликтами.

Можно даже имя/email в настройки плагина зашить - чтобы после установки git-а их не настраивать.

А с конфликтами - дописать в плагин режим, когда при конфликтах он вместо git-diff-а просто создаёт копию файлов так же, как synology.

Чем этот вариант будет лучше synology:
можно настроить чтобы файлы синхронизировались только после окончания правок. Т.е. это не 15 коммитов в секунду, а гораздо меньше: когда человек задумался на минутку. И при этом раз человек файлы уже не трогает, то нет риска схватить тот самый пустой временный файл.

минус: при совместной работе не будет видно в реалтайме что коллеги в заметке пишут - нужно будет воспринимать на слух или шарить экран (так же как при ручном перекидывании файлов).

Я вот эти вещи забрал себе.

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

Хотя гит все равно придется на комп ставить, без этого никуда, так же как и с драйвом. На маке интересно можно без xcode’a устанавливать гит?

Через Homebrew можно установить.

Для Homebrew, если мне не изменяет память Xcode тоже нужен.
Можно попробовать Github Desktop. Приложение специально сделано для новичков в git, визуально-кнопочное :grinning_face_with_smiling_eyes:

Да, в том то и сложность, что нет простого решения для гит ((

Может имеет смысл попробовать, действительно эту приблуду поставить.