Б
сначала + 100%, потом скидки до 80%? 😁
😆 как всегда
Size: a a a
2019 November 19
DL
В mysql кто силен? Got timeout reading communication packets такую фигню выдает
250к для sql в принципе - понты （если не тулишь в 1 ячнйку войну и мир 😀）
тут либо насторойки надо смотреть （крутить димиты）
либо сам запрос оптимиз.
либо уник столб оч. большой －какой тип ячейки там где уник？
тут либо насторойки надо смотреть （крутить димиты）
либо сам запрос оптимиз.
либо уник столб оч. большой －какой тип ячейки там где уник？
DS
Такое при примерно 250 000 записей (уникальный один столбик) В пустую таблицу все гуд получается. Сервак не самый слабый.. 8 гиг оперативки. Как-то можно такого избежать, но чтоб проверка на уникальность оставалась? А то переносить таблицы при достижении 200к какой-то адский костылище.
Попробуй проверять уникальность не всей ячейки, а её хэша. Новый столбец с индексацией. Или даже отдельная таблица "Индекс той записи - её хэш". Чем хэшировать чтобы быстро было - не подскажу, гуглить надо.
s
да обычным md5 от данных
J
Мужики, поделитесь советом. Есть база с телефонными номерами клиентов. Хочу вытянуть у них фото с товаром, чтоб таким образом собрать фото-отзывы на товар.
Подскажите, каким софтом можно спарсить аккаунты инстаграма имея в наличии номера телефонов?
Подскажите, каким софтом можно спарсить аккаунты инстаграма имея в наличии номера телефонов?
MV
250к для sql в принципе - понты （если не тулишь в 1 ячнйку войну и мир 😀）
тут либо насторойки надо смотреть （крутить димиты）
либо сам запрос оптимиз.
либо уник столб оч. большой －какой тип ячейки там где уник？
тут либо насторойки надо смотреть （крутить димиты）
либо сам запрос оптимиз.
либо уник столб оч. большой －какой тип ячейки там где уник？
bigint
MV
250к для sql в принципе - понты （если не тулишь в 1 ячнйку войну и мир 😀）
тут либо насторойки надо смотреть （крутить димиты）
либо сам запрос оптимиз.
либо уник столб оч. большой －какой тип ячейки там где уник？
тут либо насторойки надо смотреть （крутить димиты）
либо сам запрос оптимиз.
либо уник столб оч. большой －какой тип ячейки там где уник？
11111111111111111 типа так запись выглядит в ячейку
n
Мужики, поделитесь советом. Есть база с телефонными номерами клиентов. Хочу вытянуть у них фото с товаром, чтоб таким образом собрать фото-отзывы на товар.
Подскажите, каким софтом можно спарсить аккаунты инстаграма имея в наличии номера телефонов?
Подскажите, каким софтом можно спарсить аккаунты инстаграма имея в наличии номера телефонов?
позвони спроси
DL
bigint
хм, не работал никогда с ним, int юзаю, мож. есть смысл поменять на int и посмотреть？
ща глянул на свою бд - 1.4 млн. строк / 2 уник. ячейки - хавает 946 мб. озу
ща глянул на свою бд - 1.4 млн. строк / 2 уник. ячейки - хавает 946 мб. озу
MV
да я думаю что попробовать не INT - а тхт надо. Почему bigint поставил - потому что тут ID собираются, а они 15-17 значные.
DL
тогда лучше вообще varchar
MV
да, попробую. И интересно количество потоков какое потянет... Сейчас проверю. Спасибо за советы
DL
15-17 int тоже хватит 😀
в него что-то около 2 млн. влазит кажись
в него что-то около 2 млн. влазит кажись
DL
т.е. млрд.
NK
пепетка\-.*?
NK
В конце чем заканчивается html или php или \/
F
Такое при примерно 250 000 записей (уникальный один столбик) В пустую таблицу все гуд получается. Сервак не самый слабый.. 8 гиг оперативки. Как-то можно такого избежать, но чтоб проверка на уникальность оставалась? А то переносить таблицы при достижении 200к какой-то адский костылище.
Какая то ошибка, может конекшины не закрываешь или еще что-то. 250к записей с бигинт - это вообще ниочем, летать все должно
MV
скорее всего с конекшенами и трабл - я кубиками зенковскими заливал. Моржет там нет закрытия сессии. надо на шарпе по правильному написать будет.
MV
именно в потоках проблемы.
MV
то есть штук 100 потоков и ппц, когда таблица к 200к подходит - таймауты начинаются