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

[Rintz]

майки рулят, тупскрипт, вс код, вин10 круто

[Drakonian]

GoldRobot написал 40 минут назад:

Цитата

Cosmos DB is Microsoft's proprietary

И зачем вы это в проект затянули 

Если твой главный продукт это ERP от Microsoft, то закономерно что все твои инструменты будут скорее всего от Microsoft, иногда иначе тупо никак, а иногда просто намного проще

пиздят кароч
как минимум 600 рекордов в секунду инсертится должно
https://weblogs.asp.net/pglavich/cosmosdb-and-client-performance

[Grohuf]

Drakonian написал 34 минуты назад:

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

Цитата

Cosmos DB is Microsoft's proprietary

И зачем вы это в проект затянули 

Если твой главный продукт это ERP от Microsoft, то закономерно что все твои инструменты будут скорее всего от Microsoft, иногда иначе тупо никак, а иногда просто намного проще

пиздят кароч
как минимум 600 рекордов в секунду инсертится должно
https://weblogs.asp.net/pglavich/cosmosdb-and-client-performance

Так это очевидно, что ни одна современная БД не может так медленно работать и это ребята в API натупили. Где-нибудь квадратичную или того хуже кубическую сложность забубенили вот и результат.

Там есть тест, когда в однопотоке инсертятся в базу элементы как я понимаю по одному (то есть каждый раз новый коннект создается). И там скорость 10000 записей в минуту. То есть за 6 минут управилась бы. А там больше часа по факту.

[Index]

Господа, такая задача. 

Нужно реализовать бек

файловая система (корневой каталог и подкаталоги с файлами)

БД в которой будет хранится метаинформация о папках/файлах.

 

Надо реализовать что-то типо CRUD эндпоинтов. Построение на фронте дерева, хуе мое детальная информация о папке, файле, загрузка удаление.

 

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

 

  Потому что я уже не уверен, что я иду по хорошему пути

Например вот я решил, что у меня будет одна таблица условно

CREATE TABLE IF NOT EXISTS metadata.asset_metadata
(
    id           UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    parent_id    UUID REFERENCES metadata.asset_metadata (id) ON DELETE CASCADE ,
.... далее идут метаполя

Путь вида /хуй/пизда/ёлка будет строиться при выгрузке данных из базы в модель. 

Плюсы:

удаление папки выполняет каскадное удаление всего что находится ниже искаропки

перемещение/переименование папки вызывает просто правку одной записи в таблице

Минусы: 

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

 

path[] UUID но опять же это нужно будет это поле пересчитывать при любых изменениях хуй знает блять

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

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

Другое дело, что 90% таких програм просто используют путь к файлу как ключ, хранят в базе путь в виде строки и хуй клали на построение каких-то деревьев а в случае каких-то проблем просто делают переиндексацию так как single source of truth там файловая система.

У меня же single source of truth должно быть содержимое базы, а не файловая система. 

[Grohuf]

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

Index написал 1 час назад:

У меня же single source of truth должно быть содержимое базы, а не файловая система. 

Звучит как хуевый план.

PS И почему тебе какая-нибудь иерархическая DB не подходит типа MongoDB, если тебе прям хочется продублировать иерархическую структуру файловой системы?

[GoldRobot]

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

[universal]

GoldRobot написал 30 минут назад:

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

ток если ты не дохуллиард итемов хранишь которые юзеры сами генерят

[Index]

Grohuf написал 59 минут назад:

Чел, всю информацию о файлах и каталогах хранит файловая система. Нет нужды это дублировать.

Чел мне нужна связь файл -> ( теги, ключевые слова, описание, хуе мое ) метаданные короче.

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

[Grohuf]

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

GoldRobot написал 33 минуты назад:

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

ток если ты не дохуллиард итемов хранишь которые юзеры сами генерят

Чем плохо обычное 8 байтовое целое?

[Index]

GoldRobot написал 33 минуты назад:

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

Пилю https://en.wikipedia.org/wiki/Digital_asset_management систему.

Теперь понятнее стало?

  Пример UI такой подобной системы из гугла.

[universal]

Grohuf написал 5 минут назад:

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

GoldRobot написал 39 минут назад:

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

ток если ты не дохуллиард итемов хранишь которые юзеры сами генерят

Чем плохо обычное 8 байтовое целое?

 

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

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

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

[Grohuf]

universal написал 5 минут назад:

Grohuf написал 13 минут назад:

universal написал 16 минут назад:

GoldRobot написал 47 минут назад:

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

ток если ты не дохуллиард итемов хранишь которые юзеры сами генерят

Чем плохо обычное 8 байтовое целое?

 

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

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

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

Так у каждой таблицы свои id. Какой тебе смысл делать сквозной Id в sql базе?

[universal]

так я и говорю, что для каждой таблицы нужен свой инкрементер, в таком случае

[Just.Doit]

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

Just.Doit написал 8 часов назад:

Drakonian написал 10 часов назад:

кто то работал с говном CosmoDB? 

Пацаны, если мы посылаем Request в API который должен создавать 57.000 записей в CosmoDB то это занимает 1час и 15мин времени. Пацаны которые это API сделали говорят что это норм. Но это же пиздец, не? Блять хочу глянуть че они там накодили

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

 

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

почему ты думаешь что челы там какие-то не такие? они просто решали не твою задачу и делали с условием ограниченного времени и ресурсов

Я просто не верю что это такая говно ДБ которая чат интсертит 57к записей, мне не кажется что БД это узкое место

ну это относится к любому ПО

создано под определенный профиль требований

в определенных ограничениях бюджета и ресурсов

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

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

Наша база данных не оптимизирована для добавления данных.

ну это кстати очень часто бывает

реляционки например. которые на запись масштабируются супер хуево в большинстве кейсов

 

Grohuf написал 4 часа назад:

Там есть тест, когда в однопотоке инсертятся в базу элементы как я понимаю по одному (то есть каждый раз новый коннект создается). И там скорость 10000 записей в минуту. То есть за 6 минут управилась бы. А там больше часа по факту.

ну у дмагера же не синтетика на пустой базе. хер знает какие там у него индексы, триггеры, и текущий объем бд

 

[Grohuf]

universal написал 4 минуты назад:

так я и говорю, что для каждой таблицы нужен свой инкрементер, в таком случае

Ну вообще ты можешь доверить это DB, указав, что поле автоинкрементируемое. Но и в ручном инкременте проблемы нет. Хотя это точка зрения плюсовика.

Index написал 31 минуту назад:

Grohuf написал 1 час назад:

Чел, всю информацию о файлах и каталогах хранит файловая система. Нет нужды это дублировать.

Чел мне нужна связь файл -> ( теги, ключевые слова, описание, хуе мое ) метаданные короче.

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

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

Вообще описание задачи выглядит как типичный кейс https://ru.wikipedia.org/wiki/Документоориентированная_СУБД

 

[Just.Doit]

Grohuf написал 30 минут назад:

universal написал 34 минуты назад:

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

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

ток если ты не дохуллиард итемов хранишь которые юзеры сами генерят

Чем плохо обычное 8 байтовое целое?

я не эксперт. но кажется вероятностью коллизий при "децентрализованной генерации"

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

все усугубляется большим количеством генераций за период времени и долгим временем жизни идшников

 

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

Index написал 3 часа назад:

Минусы: 

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

а почему собственно это минус? )

----

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

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

не особо вижу проблем положить все в табличку с рекурсивным парентом

[UglyBastard]

Index написал 43 минуты назад:

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

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

Пилю https://en.wikipedia.org/wiki/Digital_asset_management систему.

Теперь понятнее стало?

  Пример UI такой подобной системы из гугла.

И типо если ты удаляешь в юи то должно и в фс удалиться? Поэтому ты пишешь, что у тебя бд первично, а не фс?

[Just.Doit]

собственно на SO походу чела забанили - https://stackoverflow.com/questions/3362669/what-are-the-known-ways-to-store-a-tree-structure-in-a-relational-db

besteady написал 4 минуты назад:

Index написал 49 минут назад:

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

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

Пилю https://en.wikipedia.org/wiki/Digital_asset_management систему.

Теперь понятнее стало?

  Пример UI такой подобной системы из гугла.

И типо если ты удаляешь в юи то должно и в фс удалиться? Поэтому ты пишешь, что у тебя бд первично, а не фс?

потому что ФС (как я понял) там вообще не фигурирует с точки зрения бизнеса. он сами блобы файлов может хоть в с3 хранить

Изменено 25 ноября 2021 пользователем Just.Doit

[UglyBastard]

Just.Doit написал 5 минут назад:

собственно на SO походу чела забанили - https://stackoverflow.com/questions/3362669/what-are-the-known-ways-to-store-a-tree-structure-in-a-relational-db

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

Index написал 52 минуты назад:

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

Лично я вообще нихуя не понял что ему нужно.

Но для ID использовать рандомный uuid, это очень странно и непонятно.

Пилю https://en.wikipedia.org/wiki/Digital_asset_management систему.

Теперь понятнее стало?

  Пример UI такой подобной системы из гугла.

И типо если ты удаляешь в юи то должно и в фс удалиться? Поэтому ты пишешь, что у тебя бд первично, а не фс?

потому что ФС (как я понял) там вообще не фигурирует с точки зрения бизнеса. он сами блобы файлов может хоть в с3 хранить

 

Ааа понял

Ну это реально должно легко гуглиться 

Алсо в СУБД можно рекурсию писать в запросах если что. Так что необязательно костыльно идти снизу вверх

И реально необязательно реляционную юзать 

[Index]

Конкретно с точки зрения бизнеса у нас к ФС должен быть и ридонли доступ для пользозователей (в виде сетевого диска) и стурктура должна быть хьюман ридабл и естественно повторять дерево с UI.

Если бы задача была бы чисто блобы хранить было бы проще.

Just.Doit написал 16 минут назад:

собственно на SO походу чела забанили

Ну решил в моем любимом комьюнити для начала спросить.

Изменено 25 ноября 2021 пользователем Index