Сергей

Если планируются высокие нагрузки, берите Erlang или Elixir для бэкенда.
Отлаживание сервера под живыми пользователями без перерывов в обслуживании ни в каком другом языке не сделали настолько простым и удобным.
Опыт Whatsapp вполне релевантен думаю.

Просто вставьте полный URL в поисковую строку:

В индексе:

======
Не в индексе:

Можно попробовать использовать Scrapy как фетчер а потом сырые страницы закидывать в какую-то очередь типа RabbitMQ или Kafka.
Scrapy хорош тем, что он очень модульный (по крайней мере был, когда я последний раз пользовался). Не нравится встроенный планировщик очередей - замени на свой. Не нравится как работает с заголовками / прокси / кешированием - добавляешь свой middleware.

Главная претензия в моём случае была однопоточность и сложность Twisted. Когда начали упираться в производительность переписали на Erlang просто. Но в целом опыт понравился.

https://habrahabr.ru/company/sphinx/blog/61807/ я вот такое прикручивал как-то давно

В случае Python могу посоветовать www.django-rest-framework.org - кода много писать не нужно, особенно в простых случаях.
Ну и доступ к куче питоновских библиотек.
OAuth через psa.matiasaguirre.net

Не нужен вам XPath. lxml.de/tutorial.html#elements-are-lists
Делайте итерацию по элементам и рекурсивную функцию (или просто вложенные циклы).
Что плохо - это то, что у вас структура XML неоднозначно соответствует структуре python словарей. Ну и приведённый XML невалидный - нет корневого элемента (или он неполный?).

def to_dicts(element):
  obj = {'tag': element.tag,
        'attrs': element.attrs,
        'childs': [to_dicts(child) for child in element]}
  return obj

Ограничение по кол-ву запросов с одного IP + капча.
Первое защитит от простых случаев, второе от случаев, когда злоумышленник использует прокси.
Можно сделать сложнее - активировать капчу, если поток запросов SMS по всей системе возрос. Например, всё время средний поток запросов 10 в минуту а тут скакнул до 100 - включаем всем капчу.
Ну и капча не является 100% защитой - на antigate.com их разгадывают по 1$ за 1000 штук. Но сама необходимость работать с антигейтом существенно усложняет бота.
P.S.: я сам защиту строить не пробовал, но ботов часто пишу.

Правильно понял, что вам нужно вывести на странице несколько лотов с картинками?
Храните в 2-х таблицах и выбирайте 2-мя запросами, 2-й с id IN (...).
В postgresql могли бы использовать array_agg + JOIN и выбирать всё одним запросом. Но тут тоже лучше бенчмаркать что лучше - 2 запроса или один, но с JOIN и аггрегацией.

Как верно заметили, зависит от того, чем сейчас занимаетесь и чем хотите заниматься. Если WEB2.0 сайты, то с Python особо нет смысла куда-то уходить. Тут тебе и фреймворки и ORM-ы и шаблонизаторы в ассортименте и опыта много наработано.
Если сетевые какие-то сложные высококонкуррентные или низколатентные демоны, то идите к нам, в Erlang.
Go в плане вычислительных задач хорошо работает, ну и для конкуррентных сетевых штук тоже потихоньку Erlang догоняет. Думаю, может найти в онлайн-игрушках применение, если сборщик мусора не станет помехой.

Вы бы запрос отформатировали поаккуратнее - читать неудобно

SELECT hy_content.seo,
       hy_content.id,
       hy_content.date,
       hy_content.sham_photos,
       hy_content.title
FROM hy_content
LEFT JOIN gl_views ON (hy_content.seo=gl_views.seo)
WHERE hide=2
      AND hy_content.date > (NOW() - INTERVAL 1 DAY)
ORDER BY gl_views.read DESC
LIMIT 10

Запрос вполне нормальный, если вам нужно вывести именно новости, опубликованные сегодня, которые больше всего посмотрели (посмотрели за всё время, но т.к. всё время это и есть сегодня, то ок).
Если же нужно именно "самые просматриваемые за сегодня новости, неважно когда опубликованные", то нужно структуру таблиц менять. Т.е. если новость вышла год назад, а на неё вдруг именно сегодня зашла толпа народу.

www.neo4j.org ? Сам с ней не работал.

Если обязательно использовать Python, то я бы взял gevent и urllib2. Вместо использования HEAD (который многие серверы не понимают) советую просто не скачивать тело ответа.

Вот тут пример есть https://github.com/surfly/gevent/blob/master/examp... но он совсем уж простой - на практике лучше иметь пул из ограниченного числа гринлетов.

Ну и строчку
data = urllib2.urlopen(url).read()
нужно заменить на

resp = urllib2.urlopen(url)
print resp.getcode()
resp.close()

Чтоб только заголовки качать, без тела.

Насчёт keep-alive лучше не заморачивайтесь, это экономия на спичках (если только у вас не все запросы к одному серверу)

Twisted лучше не смотрите - это безперспективняк =)

Писать собственный рендерер, да ещё на питоне это хардкорно конечно. Я бы не решился.
Мне кажется, для хранения правил CSS все же нужно непосредственно накладывать последовательно правила на DOM дерево без использования промежуточных хранилищ. Т.е. строим DOM дерево. Считываем последовательно правила из вашего CSS:

a { display: block; font-size: 12pt; }
div p.links a { color: green; display: inline; }

и последовательно накладываем правила по селектору (перезаписывая конфликтующие правила, учитывая !important и пр). Получается, что при модификации дерева придется все правила прогонять заново.

Код браузера можно попытаться тут: github.com/WebKit/webkit/tree/master/Source/WebCore/css поковырять, но там комментариев в коде нет, вряд-ли удастся что то понять =)

desktop-mode (встроенный в Emacs) делает примерно это: сохраняет список открытых файлов при выходе и открывает их при запуске.

Надеюсь эту картинку вы знаете?



Допустим, таблица A это SELECT * FROM games, а таблица B это SELECT * FROM uploaded_games WHERE user_id = ?.

Т.е. вам нужно из таблицы A вычесть таблицу B (в терминах теории множеств). На картинке это левый столбец, второй сверху.

SELECT *
FROM games as A
LEFT JOIN uploaded_games as B ON (A.game_id = B.game_id)
WHERE B.game_id is NULL AND B.user_id = ?

Можно записать более наглядно, но, скорее всего, MySQL его не соптимизирует эффективно

SELECT *
FROM games
WHERE game_id NOT IN (
  SELECT game_id FROM uploaded_games WHERE user_id = ?
)

У меня половина опыта работы — именно написание пауков и веб-парсеров.
Писал их и на PHP + CURL, потом на голом питоне + треды.
Потом узнал о Scrapy (асинхронный фреймворк для граббинга сайтов на Python) и на нём штук 5 независимых проектов реализовал, в том числе один, где нужно аггрегировать и периодически обновлять информацию с 20 различных форумов. Основная его проблема — он асинхронный, но однопоточный. Так что больше одного ядра им не нагрузить и долгий запрос к БД не сделать. А так очень хороший фреймворк.
Потом несколько пауков делал на Python с помощью Celery.
А совсем недавно переписал довольно сильно нагруженного паука (50-70Мбит/с через списки прокси) с Python + Celery на Erlang и понял, что это ОНО! Мало того, что стал работать в 2-3 раза быстрее, но понял, что для этой задачи что-то более подходящее сложно придумать.
Поясню — у паука на Erlang можно без остановки процесса, например, изменить число потоков, обновить код, перезагрузить конфиги. Можно на ходу отпрофилировать код чтобы узнать, почему скорость упала или что так нагружает CPU. Можно совмещать зеленые потоки, асинхронную работу с сетью и долгие запросы к БД. И всё это фактически из коробки. В конце концов, код получается более логичный.