https://gist.github.com/SergProduction/84ecf93b85c0857f29429d98a355a2c9

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

почему var в начале кода?

кстати да а что вы делаете на ноде с проблемой require('../../../../../my-module')? в вебпаке там алиасы есть

симлинк my-module в node-modules

потом es6 дальше

Проверь. Не в этом проблема)

let dirArr = fs.readdirSync( path.join(__dirname, 'base/jpg/') )

мб тут?

если там 5к жпегов

Ааа

Может

Но думаю нет

хотя... он же файлнеймы читает

вообще --inspector творит просто магию

Сто файлов он обрабатывает меньше чем за минуту

3к файлов, я запустил 10 мин назад, только 300 обработал

глянь в htop

мб память скушалась

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

baseArray.forEach( (row, i, arr) => { fileName.forEach( (file, z) => {

Может быть, есть способы задействовать всю оперативу

?

вставь на вызове equalBase вывод длины baseArray

baseArray.forEach( (row, i, arr) => { fileName.forEach( (file, z) => {

Ааа, да - кажется здесь. baseArray.length = 220k fileName.length = 3k

там цикл в цикле

И Того 220к * 3к

а задача-то вообще какая?

там цикл в цикле

Естественно, а и иначе как сравнить имя файла с записями в бд(baseArray)

чето тут не бд, а json

Ага

https://www.npmjs.com/package/lowdb

если там 220*3 кк, то чтение json целиком и парсинг могут оказаться значительно быстрее, чем гоняние массивов

хотя... без индексов anyway тормоза будут это же seqScan

Там json на 40мб я сперва пробывал его целиком прочесть, нода выкинула ошибку о том что память закончилась, теперь я читаю кусками через потоки

readJsonСhunk -> insert manipulating delete * from table

перебор на 220 строк это ужс что

Может быть есть способы задействовать всю оперативу?

Не сдавайся, ответ совсем рядом.

оператива не даст тебе нормальный поиск)

/stat@combot

combot.org/chat/-1001041204341

С поиском все нормально, 100 картинок копируются меньше чем за минуту с той же базой.

оператива не даст тебе нормальный поиск)

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

эм

ну лан)

или брать дерево

но деревьев будет несколько судя по количеству сравнений

Ммм

row[5] == file.date && row[4] == file.show && row[3].match(/\d+/)[0] == file.id субд такое сделает за мгновение + если ты ищешь конкретно по row[3].match - стоит положить это доп. элементом в массив?

С поиском все нормально, 100 картинок копируются меньше чем за минуту с той же базой.

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

Да, придется

я когда писал утилитку в электрон так и делал

Не хотелось задействовать бд, но вижу что здесь она необходима

можно и деревьями, но надо в деревья уметь:)

а какая разница, если данные в памяти не помещаются?

там 220к строк поиск идет по date, show (не знаю че там, мб буль?) и fileid все три легко кастятся в int три дерева на 220к листьев влезут в ram

хотя тут не совсем дерево-то ну короче алгоритмы и структуры затащщат если надо,

а вообще ты мог выкидывать копирование в отдельные процессы. было бы в разы быстрее

ребят, еще вопросик

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

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

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

PUT - полное обновления ресурса, то есть ты должен кинуть весь ресурс целиком PATCH - частичное, ты можешь кидать только то, что нужно обновить

PUT - полное обновления ресурса, то есть ты должен кинуть весь ресурс целиком PATCH - частичное, ты можешь кидать только то, что нужно обновить

понял, спасибо

Sergey а сколько там ram? я сейчас json на 180Мб на 400к+ строк распарсил за 7 секунд на 1 гб оперативы

зохавало 700-800 Мб примерно

даже меньше

632Мб

Sergey а сколько там ram? я сейчас json на 180Мб на 400к+ строк распарсил за 7 секунд на 1 гб оперативы

2gb win7

да, там уже гига вряд ли будет лишнего

тогда точно через субд - они умеют хорошо работать в условиях "не влазит в ram"

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

а сколько доступной?

Прости, не могу посмотреть, комп рабочий, я уже приехал домой

Примерно 500 мб доступной оставалось

С учётом того что win7 в среднем 1гб на свое существование берет

может и не хватить

попробуй в коде вставить console.log(`node has taken ${process.memoryUsage().rss/1024/1024} mb`)

Sergey а сколько там ram? я сейчас json на 180Мб на 400к+ строк распарсил за 7 секунд на 1 гб оперативы

Именно сам парсинг 220к и внутри цикл на 100, я пробовал - расспросил за 2сек. А если при этом копировать файлы 100 штук, то примерно сек 40

Но как только запускаю копирование на 3к файлов, копирование происходит примерно со скоростью 3 файла в минуту

А ты попробовал просто 3000 файлов переложить ?