История изменений

LDAP страх и ужас, но ничего другого нет. NC быстро работает только с LDAP. SQL не нужен, для всего есть LDAP и ФС. Так?

Правильная версия: LDAP это единственное на сегодня работающее решение. Оно очень далеко от идеальности особенно в плане настройки. Это похоже на квест как в свое время была настройка FIDO mailer. Но при этом LDAP и системы достаточно, чтобы работать с файлами быстро.

NC использует LDAP исключительно для авторизации и не использует его для доступа к файлам! Вместо этого в любом случае используется SQL - отсюда и дикие тормоза, так как база читается при каждом чихе.

Делать чистое LDAP решение Nextcloud не хочет - очевидно потому как отваляться все пользователи. Автоматической универсальной настройки LDAP для всех нет!

Т.е. «NC быстро работает только с LDAP» - это фантазии. Не существует в природе такого NC, который бы действительно работал с LDAP.

но мое мнение LDAP в целом медленнее работает с данными, чем SQL

Это не соответствует действительности! Сама фраза не имеет смысла от слова вообще. Я специально писал, что LDAP это протокол = язык общения. В роли backend у LDAP может выступать база SQL. В стандартном варианте в роли backend выступает LMDB, но можно хоть текстовые файлы использовать.

В случае с NC база SQL работает поверх файловой системы, от которой никуда не уйти. Т.е. она все равно есть и все равно используется. Только вместо адекватного режима она работает в однопользовательском режиме, а кому какой файл принадлежит уже берет на себя SQL. Это называется дублирование функциональности. Оно всегда принципиально медленней, чем вариант без дубляжа.

LDAP же тесно интегирован с системой авторизации в Linux. И самодостаточен для работы с FS напрямую. Т.е. пользователь авторизуясь через веб интерфейс может получать свои файлы напрямую и все коллизии разрешает сама файловая система.

Те же интернет магазины вполне себе держат пользователей в SQL и хорошо себя чувствуют

Провайдеры мобильной связи с миллионами абонентов держат своих пользователей в базе LDAP. Погуглите доклад автора ReOpenLDAP! В интернет магазинах кроме 2-4 наиболее известных редко бывает много клиентов и каждый клиент редко постоянно там сидит.

Клиенты операторов мобильной связи очевидно постоянно сидят на связи... Подумайте над этим. У China Mobile если я правильно помню порядка 800млн клиентов...

Версионирование, например не все ФС поддерживают, а привязываться к одной фс, так себе идея.

Если включать голову и выбирать ФС с умом, то особенно выбора не остается. Учитывая доступность данных через инет и заведомо меньшую пропускную способность по сравнению с локальным доступом требование к сохранности данных выходит на первый план. Собственно друго требования и нет. И в таком случае выбор ФС невелик. Для меня он сузился до одной единственной системы.

С другой стороны я спокойно могу жить без версионирования. Т.е. любая система подойдет. А вот с базой будет проблема.

Вместо одной точки отказа мы имеем 2! Казалось бы ФС в порядке данные целы, а вот SQL упала и унесла все данные с собой. В итоге мы получаем такой геморой на восстановление, что хуже и придумать сложно.

LDAP страх и ужас, но ничего другого нет. NC быстро работает только с LDAP. SQL не нужен, для всего есть LDAP и ФС. Так?

Нет. Вы читать не умеете? Приведите цитату, где я такое говорил.

Правильная версия: LDAP это единственное на сегодня работающее решение. Оно очень далеко от идеальности особенно в плане настройки. Это похоже на квест как в свое время была настройка FIDO mailer. Но при этом LDAP и системы достаточно, чтобы работать с файлами быстро.

NC использует LDAP исключительно для авторизации и не использует его для доступа к файлам! Вместо этого в любом случае используется SQL - отсюда и дикие тормоза, так как база читается при каждом чихе.

Делать чистое LDAP решение Nextcloud не хочет - очевидно потому как отваляться все пользователи. Автоматической универсальной настройки LDAP для всех нет!

Т.е. «NC быстро работает только с LDAP» - это фантазии. Не существует в природе такого NC, который бы действительно работал с LDAP.

но мое мнение LDAP в целом медленнее работает с данными, чем SQL

Это не соответствует действительности! Сама фраза не имеет смысла от слова вообще. Я специально писал, что LDAP это протокол = язык общения. В роли backend у LDAP может выступать база SQL. В стандартном варианте в роли backend выступает LMDB, но можно хоть текстовые файлы использовать.

В случае с NC база SQL работает поверх файловой системы, от которой никуда не уйти. Т.е. она все равно есть и все равно используется. Только вместо адекватного режима она работает в однопользовательском режиме, а кому какой файл принадлежит уже берет на себя SQL. Это называется дублирование функциональности. Оно всегда принципиально медленней, чем вариант без дубляжа.

LDAP же тесно интегирован с системой авторизации в Linux. И самодостаточен для работы с FS напрямую. Т.е. пользователь авторизуясь через веб интерфейс может получать свои файлы напрямую и все коллизии разрешает сама файловая система.

Те же интернет магазины вполне себе держат пользователей в SQL и хорошо себя чувствуют

Провайдеры мобильной связи с миллионами абонентов держат своих пользователей в базе LDAP. Погуглите доклад автора ReOpenLDAP! В интернет магазинах кроме 2-4 наиболее известных редко бывает много клиентов и каждый клиент редко постоянно там сидит.

Клиенты операторов мобильной связи очевидно постоянно сидят на связи... Подумайте над этим. У China Mobile если я правильно помню порядка 800млн клиентов...

Версионирование, например не все ФС поддерживают, а привязываться к одной фс, так себе идея.

Если включать голову и выбирать ФС с умом, то особенно выбора не остается. Учитывая доступность данных через инет и заведомо меньшую пропускную способность по сравнению с локальным доступом требование к сохранности данных выходит на первый план. Собственно друго требования и нет. И в таком случае выбор ФС невелик. Для меня он сузился до одной единственной системы.

С другой стороны я спокойно могу жить без версионирования. Т.е. любая система подойдет. А вот с базой будет проблема.

Вместо одной точки отказа мы имеем 2! Казалось бы ФС в порядке данные целы, а вот SQL упала и унесла все данные с собой. В итоге мы получаем такой геморой на восстановление, что хуже и придумать сложно.