𝔾ℝ
хм. хотя... если выбирать не все записи, а скажем LIMIT'ом ограничить по 1000 штук может не будет так тупить. надо проверить
Size: a a a
2018 March 20
DD
Норм решение. сразу import multiprocessing заюзай )
𝔾ℝ
ну с этим я ещё не сталкивался, надо почитать по нему сабжей
DD
он красив и не сложен. Потратил время на вкуривание как конектиться к MQ. Потрать еще на мультипроцессы )
𝔾ℝ
да, надо почитать.
n
хм. хотя... если выбирать не все записи, а скажем LIMIT'ом ограничить по 1000 штук может не будет так тупить. надо проверить
там еще PRAGMA можно покрутить. и вродь редис в памяти висит, ежели скьюлайт туда же пихать, то и скорость поживее станет )
𝔾ℝ
ну я боюсь, что оперативки может не хватить. там ХДД 15 гигов вроде всего дали
𝔾ℝ
и оперативки гиг
DD
ну я боюсь, что оперативки может не хватить. там ХДД 15 гигов вроде всего дали
а на что оперативы? Вчера тоже читал про нее тут. Но так и не понял. Тыже в памяти не много держать будешь
𝔾ℝ
ну если всю базу попытаться запихнуть, чтоб в :memory: создать её, точно не хватит
DD
не надо так делать )
DD
хорошо? )
𝔾ℝ
ну я тож думаю, что не самая хорошая идея 😊
DD
ну я тож думаю, что не самая хорошая идея 😊
у тебя есть одно узкое место, это время ответа от сервиса. Имеет смысл держать данные в оперативе если тебя ограничивает I/O файловой системы. А тут, не стоит. Забрал ответ, поработал, забыл.
𝔾ℝ
ну это да. дело в том, что сами операции с базой крайне медленно проходят. может как варик на несколько таблиц разбить попробовать
𝔾ℝ
один селект на 3 миллионах записей работал 25 секунд
DD
Селект с условием?
𝔾ℝ
ну да. если в поле founded=0
𝔾ℝ
найденные ссылки будут обновлять это поле в 1
DD
Поле проиндексировано?