vilgeforce: про произвольный алфавит понял, но так как возможны примерно 64 факториал возможных перестановок, то определить конкретный использованный алфавит врядли получится, правильно?
Philipp: допустим у меня есть раздел в котором после последнего обновления было 5 миллионов пользователей, теперь я опять получаю данные и мне нужно узнать кто к этим 5 миллионам добавился, а кто ушел. Это возможно быстро сделать?
Дмитрий Энтелис: это используется для таргетирования рекламы. Если человек сегодня подписался на свадебный паблик, то вероятно он готовится к свадьбе и вообще свадьбы - его текущий интерес, а если он подписался год назад, то уже скорее всего женат или больше этим не интересуется. Я успел выяснить, что Redis хранит данные в памяти. У меня 1 гб на сервере, подозреваю, что много я в него не сохраню.
Дмитрий Энтелис: у ВК хороший API. 5 миллионов пользователей собираются за 12 минут и при желании можно ещё ускорить, если собирать в несколько потоков. Проблема именно в том, как их хранить и что ещё важнее, как быстро сравнить старые данные с новыми. В общем, пошел читать про Redis. Спасибо.
Дмитрий Энтелис: ладно, не буду темнить. У меня парсер для вконтакте. Мне нужно получать участников групп и сравнивать кто добавился, а кто удалился. Потом записывать добавившихся в одну таблицу, а удалившихся в другую с указанием группы и даты. В ВК порядка 80 000 000 групп и наверное 300 000 000 аккаунтов, понятно что около 80% групп никого не интересуют, но остается всё равно много. Попробовал два раза спарсить группу MDK (5.5 миллионов человек). Получил две таблицы и сравнивал их при помощи left join, чтобы узнать кто удалился и добавился. Запросы выполнялись очень долго (больше минуты каждый), индексы есть на user_id и на group_id. Всё это непрерывно - идём по очереди групп, парсим, когда доходим до конца очереди начинаем сначала.
Никаких подстрок не будет. Если использовать одну большую таблицу, то там будут записи вида id раздела, id пользователя, т.е. если пользователь состоит в трех разделах, то для него будет три записи.
Интересно. Я так понимаю, для этого нужно иметь несколько MySQL серверов. Можно ли их где-то арендовать, т.е. заказать не полный хостинг или vds, а только нужное количество MySQL серверов?
А есть какой-то удобный способ (из коробки) заставить его работать непрерывно? Потому что это одна из причин, которые удерживают меня от использования PHP.
Это мне приходило в голову, но у меня создалось впечатление, что решение, как минимум не самое изящное. Например, одно задание может выполняться пол часа, а для PHP, это вроде как-то не очень. А кроме того, что будет, если крон сработает пока задание ещё выполняется? Я получу несколько заданий, которые будут выполняться параллельно?
Да, Qrator действительно похож, но предоставляет много такого, что мне не нужно, а потом дороговат. Насколько, вообще, сложно организовать платный сервис, который просто будет посредником между клиентом и сервером, безо всяких дополнительных примочек? Мне казалось, что такой сервис был бы простым в реализации, дешевым и снимал бы большую часть проблем с безопасностью - не знаешь где сервер, значит нечего взламывать или атаковать. Спасибо за ответ, в любом случае.