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

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

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

не верно, тк доступ к ФС дается на ридонли пользователям

Ну, ктож знал то?

всем привет!

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

вот и в итоге на прочтение записей, добавление записей ушло сток времени (добавлял/читал через goroutine, а не циклом если чо)

параллельно создалось примерно 60 бин файлов в которых очередь хранилась и создались несколько лог файлов 

вот норм результат или хуево(по времени), подскажите новичку 

Rilay написал 7 минут назад:

вот норм результат или хуево(по времени), подскажите новичку

может хотябы среднее значение на операцию посчитаешь

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

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

(добавлял/читал через goroutine, а не циклом если чо)

в задачах, связанных с IO (диск, сеть) производительность таких вещей не важна (потому что она составляет меньше 1% от времени выполнения всей операции) 

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

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

ты писал параллельно или однопоточно

паралелльно

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

сразу вычитывал очередное записанное или сначала записал все, а потом вычитал все

записи паралелльно записывались и читались в рандомном порядке

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

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

паралелльно

сами записи тоесть тоже записывались параллельно друг другу?

сразу все 10000 одновременно? или в 2..N потоков записывались?

Кстати респект, реально сделал и оно даже работает. Это как раз то что отличает рандомных залетных от настоящих потенциальных программистов. Есть работодатель, есть таски, есть факт их выполнения, даже если частично.

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

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

паралелльно

сами записи тоесть тоже записывались параллельно друг другу?

сразу все 10000 одновременно? или в 2..N потоков записывались?

Ну сами записи писались не паралельно друг другу, а друг за другом, одним потоком 

И чтение тоже одним потоком было 

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

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

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

Так как БД жрут все ресурсы, то их недостаток обычно компенсируется наращиванием железа. То есть, если у тебя миллиард файлов, то индекс займет ну от силы 35 Гб (хотя, конечно, зависит от структуры индекса, если бы делал я, то вышло бы не более 20) и при желании СУБД его весь может закэшировать, видя, что ей собираются всю таблицу перебрать.

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

Чтобы были понятны масштабы, миллиард файлов например на NTFS - это 1 Терабайт размер MFT. Если каждый файл занимает только один кластер (4 кБ), то это еще 4ТБ. Поэтому речь идти о количестве файлов, при которых SQL индекс начнет становиться дико неэффективным на серверном железе, не идет.

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

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

всем привет!

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

вот и в итоге на прочтение записей, добавление записей ушло сток времени (добавлял/читал через goroutine, а не циклом если чо)

параллельно создалось примерно 60 бин файлов в которых очередь хранилась и создались несколько лог файлов 

вот норм результат или хуево(по времени), подскажите новичку 

0.1 секунда, чтобы записать элемент и потом прочитать? То есть по сути 20 RPS держишь. Ну там выше жаловались, что ребята сделали API, которое держит менее 15 RPS. Так что говоря, что такое API мог написать Rilay я тебя неоценил. Ты можешь лучше...на 5 RPS 

PS Хз, нормально ли это

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

0.1 секунда, чтобы записать элемент и потом прочитать? То есть по сути 20 RPS держишь. Ну там выше жаловались, что ребята сделали API, которое держит менее 15 RPS. Так что говоря, что такое API мог написать Rilay я тебя неоценил. Ты можешь лучше...на 5 RPS 

и 1 и 2 это не rps (если я правильно понял что 2 - это 57000 данных за 1+ часов)

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

во втором это отправка 1го запроса с кучей данных и пересчет времени выполнения на единицу данных. тоже совсем не рпс

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

вот норм результат или хуево(по времени), подскажите новичку 

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

если сравнивать с относительно промышленными решениями - я бы ожидал не более 1-2 мс на непосредственную запись 1 сообщения в фс/очередь, и хотябы 3-10 мс на работу по сети/по хттп точно такой же записи 1 сообщения, (если брать нагрузку/режим работы который ты описал в тесте - последовательная запись небольших сообщений)

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

 

во втором это отправка 1го запроса с кучей данных и пересчет времени выполнения на единицу данных. тоже совсем не рпс

Как я понял, Cosmos DB не поддерживает batch запросы. Так что ходили они в нее поэлементно. Само API да, возможно туда пачкой данные отправлялись. ХЗ.

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

Так что ходили они в нее поэлементно

да, но возможно они делали это последовательно)

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

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

Я так понял, запросы выполнялись параллельно. И это время выполнения ВСЕХ запросов поделенное на количество запросов. А не время выполнения одного запроса.

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

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

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

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

Так как БД жрут все ресурсы, то их недостаток обычно компенсируется наращиванием железа. То есть, если у тебя миллиард файлов, то индекс займет ну от силы 35 Гб (хотя, конечно, зависит от структуры индекса, если бы делал я, то вышло бы не более 20) и при желании СУБД его весь может закэшировать, видя, что ей собираются всю таблицу перебрать.

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

Чтобы были понятны масштабы, миллиард файлов например на NTFS - это 1 Терабайт размер MFT. Если каждый файл занимает только один кластер (4 кБ), то это еще 4ТБ. Поэтому речь идти о количестве файлов, при которых SQL индекс начнет становиться дико неэффективным на серверном железе, не идет.

 

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

конечно, всё верно

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

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

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

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

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

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

 

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

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

если я правильно понял, тебе в апи  надо будет целых нихуя методов

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

гетфайл по пути к файлу выбранному в предыдущем пункте

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

создать/удалить/переместить файл по путям из первого пункта

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

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

и чтобы их сделать тебе надо целых 3 строчки в каждом

достать в базе для текущего юзера путь к его корню его хранилища на твоем сетевом диске (или там общие папки, хз)

выполнить дефолтную фс функцию твоего языка соответствующую методу по пути из бд + из запроса

запамить ответ во вьюмодель для фронтов

???

фурион

пишется за рабочий день и сходу работает

у нас на работе уже к сетевому диску прикручена вот эта залупа

https://www.synology.com/ru-ru/dsm

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

и при этом вся часть касательно файлов прекрасно работает безо всяких баз в принципе

ты заходишь в её интерфейс и делаешь всё что хочешь с файлами

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

жмешь рефреш на противоположной стороне и вуаля, вся инфа обновляется

а тебе лишь к каждому файлу метаданные еще сверху бахнуть

нас там 80 человек ходит, не считая постоянного дрочева дисков скриптами млщиков, тк их исходники там лежат, и никто на скорость не жалуется

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

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

0.1 секунда, чтобы записать элемент и потом прочитать? То есть по сути 20 RPS держишь. Ну там выше жаловались, что ребята сделали API, которое держит менее 15 RPS. Так что говоря, что такое API мог написать Rilay я тебя неоценил. Ты можешь лучше...на 5 RPS 

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

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

гетлист по относительному пути

Загружается фронт, там пусто, теперь фронту нужно отрисовать фс, какой путь относительный?

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

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

ну так и просишь свой корень у фс, как ты думаешь проводник работает?

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

или что у тебя в языке отсутствует аналог
https://docs.microsoft.com/en-us/dotnet/api/system.io.directory.enumeratefilesystementries?view=net-6.0

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

это абсолютно дефолтное действие, которое делает каждый первый файловый менеджер

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

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

Rilay написал 23 минуты назад:

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

0.1 секунда, чтобы записать элемент и потом прочитать? То есть по сути 20 RPS держишь. Ну там выше жаловались, что ребята сделали API, которое держит менее 15 RPS. Так что говоря, что такое API мог написать Rilay я тебя неоценил. Ты можешь лучше...на 5 RPS 

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

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

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

Я так понял, запросы выполнялись параллельно.

перечитай, это не так

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

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

что значит "циклом записывать читать по очереди"