Программирование[10]

Собаки лают, а караван идет

Drakonian написал Только что:

Собаки лают, а караван идет

ну это понятно, активности майков по опенсорсированию всего и вся + перевод дотнета на юниксовые рельсы кайф

вот только от слов ферма, шарик, миграция с 10 на 13 и сп девелопер мне плохо ещё год будет наверно

Шарпойнт архитектор и no-code инфлюенсер

Grohuf написал 8 часов назад:

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

ну давай, объясни мне плз, каким образом ты собираешься БЕЗ ДУБЛИРОВАНИЯ структуры фс хранить её в базе?

один простой вопрос

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

пора написать свой драйвер фс видимо поверх существующего, изи задачка

Kant написал 12 минут назад:

Grohuf написал 8 часов назад:

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

ну давай, объясни мне плз, каким образом ты собираешься БЕЗ ДУБЛИРОВАНИЯ структуры фс хранить её в базе?

один простой вопрос

 

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

 

пора написать свой драйвер фс видимо поверх существующего, изи задачка

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

Kant написал 12 минут назад:

пора написать свой драйвер фс видимо поверх существующего, изи задачка

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

Собственно нужно хранилище, которое умеет сохранить блоб, отдав его ID в хранилище (чтобы привязать к записи в БД), скачать по ID и удалить по ID. У яндекса подобные сервисы есть. Не знаю, какими средствами располагает Index. Мб он и впрямь будет хранить на винте одной машины.

у меня впечатление, что ты думаешь что я говорю о том, что я думаю говоришь ты, потому что я писал строго противоположные вещи тому, что ты написал в последнем посте

Kant написал 3 минуты назад:

у меня впечатление, что ты думаешь что я говорю о том, что я думаю говоришь ты, потому что я писал строго противоположные вещи тому, что ты написал в последнем посте

А у меня впечатление, что ты не догоняешь, что тебе говорят.

Тебе сказали, что нет смысла дублировать иерархическую структуру данных и в базе, и в файловой системе. Ее нужно хранить только в одном месте.

но и я про это 

Kant написал 32 минуты назад:

но и я про это 

ты предлагал путь к файлу хранить в бд 

Ну и сравнивать sql базу данных и файловую систему по эффективности… Базы данных плевали на размер. Они считают, что у них есть нужные ресурсы. Файловые системы же ужимаются как могут 

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

зашел в папку настоящую, надо метаданные файла - взял слазил в базу, все счастливы

но удобно ли это будет зависит от того, как часто и что будет делаться

Kant написал 2 минуты назад:

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

зашел в папку настоящую, надо метаданные файла - взял слазил в базу, все счастливы

но удобно ли это будет зависит от того, как часто и что будет делаться

Но полный путь к файлу - это информация об иерархии

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

залез в фс, увидел файл, взял путь, залез в базу за метаданными этого файла, конец

Kant написал 14 минут назад:

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

зашел в папку настоящую, надо метаданные файла - взял слазил в базу, все счастливы

но удобно ли это будет зависит от того, как часто и что будет делаться

У такого варианта возникают сложности при перемещении ветвей, удалении и тд и тп, что уже обсуждалось.

Буду использовать рекурсивные CTE.

https://schinckel.net/2014/11/27/postgres-tree-shootout-part-2:-adjacency-list-using-ctes/

Kant написал 9 минут назад:

залез в фс, увидел файл, взял путь, залез в базу за метаданными этого файла, конец

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

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

делаешь параллельную ветку с другим корнем, где лежат только метаданные, или вообще хранишь рядом с ними, профит

насчет слишком медленная - это еще требует доказательств, что твоя рекурсивная цте не сдохнет раньше, тк реляционки как бы не предназначены для этого

Kant написал 11 минут назад:

делаешь параллельную ветку с другим корнем, где лежат только метаданные, или вообще хранишь рядом с ними, профит

Не, хранить такие вещи в ФС это будет пиздец лол. 

Это же REST там будут конкурирующие модификации метадаты и тд и тп. И если в базе есть транзакции и локи, то с файлами мне придется свой велосипед делать лол. А от IOPSов вообще все охуеет.

А сколько времени займет getAll() который в базе делается SELECT * from meta; А тут мне придется обойти рекурсивно терабайты файлов, тысячи папок.

Но параллельная ветка к слову будет. Вернее параллельно будет плоская структура папка id -> содержимое со всякими превьюшками которые придется генерить на беке для рендера на фронте.

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

Kant написал 8 минут назад:

делаешь параллельную ветку с другим корнем, где лежат только метаданные, или вообще хранишь рядом с ними, профит

насчет слишком медленная - это еще требует доказательств, что твоя рекурсивная цте не сдохнет раньше, тк реляционки как бы не предназначены для этого

Где она сдохнет? Простейший B-tree индекс нужной глубины решает все проблемы.

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

Эм я не сильно понимаю о каком рассинхронизации может идти речь.

База является главным источником данных, она права по определению.

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

Нужно залить файлик? Заливаешь, и в конце только, после заливки, помечаешь как залитое. Не получилось пометить, а залилось? Ну и хуй с ним.

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

Кроме того, такой вариант дает 

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

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

Структура ФС в базе так же позволит проще поддерживать версионность, очевидно. Файлик удалили, а тебе еще год его нужно в бэкапе держать. Если хранить информацию о удалении в базе, а структуру дергать с ФС напрямую, то тебе потом это как-то еще смерждить придется, ну его нахуй.

Index написал 12 часов назад:

Kant написал 12 часов назад:

делаешь параллельную ветку с другим корнем, где лежат только метаданные, или вообще хранишь рядом с ними, профит

Не, хранить такие вещи в ФС это будет пиздец лол. 

Это же REST там будут конкурирующие модификации метадаты и тд и тп. И если в базе есть транзакции и локи, то с файлами мне придется свой велосипед делать лол. А от IOPSов вообще все охуеет.

А сколько времени займет getAll() который в базе делается SELECT * from meta; А тут мне придется обойти рекурсивно терабайты файлов, тысячи папок.

 

Но параллельная ветка к слову будет. Вернее параллельно будет плоская структура папка id -> содержимое со всякими превьюшками которые придется генерить на беке для рендера на фронте.

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

 

а что ос локи файлов не дает? вроде всю мою жизнь давала

и самый главынй вопрос, а нахуя тебе в фс getAll(), где его вызывать будут?

иопсы возможно, но ты же про внутренюю залупу с сетевой папкой, какие нахуй иопсы, там 100 юзеров одновременно не будет никогда

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

если там промышленного размера программа, то с такими вопросами на пд не ходят

Grohuf написал 12 часов назад:

Kant написал 13 часов назад:

делаешь параллельную ветку с другим корнем, где лежат только метаданные, или вообще хранишь рядом с ними, профит

насчет слишком медленная - это еще требует доказательств, что твоя рекурсивная цте не сдохнет раньше, тк реляционки как бы не предназначены для этого

Где она сдохнет? Простейший B-tree индекс нужной глубины решает все проблемы.

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

солнышко моё, ты базу трогал за яйца хоть раз?

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

В итоге надобность прокрутить дерево от конца до начала может у тебя потребовать 10 прогрузов страниц с диска по факту, тк прелоад никогда не сможет угадать, откуда надо грузить заранее, а в каталоге с фс 1-2, тк она для этого сделана была.

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

вот я ща в тотале зашел в AppData, нажал ктрл+б и мне тотал через 7 секунд выдал плоским списком 130к файлов и хуй знает сколько папок он обошел при этом, я успел заметит число 40к, но оно слишком быстро бежало

GoldRobot написал 2 часа назад:

Эм я не сильно понимаю о каком рассинхронизации может идти речь.

 

База является главным источником данных, она права по определению.

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

Нужно залить файлик? Заливаешь, и в конце только, после заливки, помечаешь как залитое. Не получилось пометить, а залилось? Ну и хуй с ним.

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

 

Кроме того, такой вариант дает 

 

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

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

Структура ФС в базе так же позволит проще поддерживать версионность, очевидно. Файлик удалили, а тебе еще год его нужно в бэкапе держать. Если хранить информацию о удалении в базе, а структуру дергать с ФС напрямую, то тебе потом это как-то еще смерждить придется, ну его нахуй.

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

Kant написал 2 часа назад:

вот я ща в тотале зашел в AppData, нажал ктрл+б и мне тотал через 7 секунд выдал плоским списком 130к файлов и хуй знает сколько папок он обошел при этом, я успел заметит число 40к, но оно слишком быстро бежало

Ну сравнивать локальный диск с сетевым доступом по SMB одно и то же

ну и ты видимо плохо понимаешь что такое REST/CRUD и какие операции могут быть