Ivanhoe

Лучше поздно, чем никогда)
Twisted — это набор библиотек для асинхронного программирования на питоне вообще, в том числе и для веб-пректов. Tornado — это именно веб-сервер, который может запускать wsgi-приложения (без асинхронности) и приложения, построенные на собственных API (с асинхронностью). Если у вас имеено веб-проект, берите Tornado, он легкий в освоении, в то время как twisted требует более серьезного погружения.

Смотрите в сторону gridFS (часть mongo) и модуля nginx ( github.com/mdirolf/nginx-gridfs ) если память не изменяет то теряете 50% в производительности, но получаете все плюшки облачного хранения файлов.

Производительным не получится, если нет большого кластера, который компенсирует сниженную скорость доступа за счёт распараллеливания. Я предпочитаю хранить картинки на отдельном сервере, а в базе ссылки на них. Вот небольшое исследование этого вопроса, правда двухлетней давности: www.coffeepowered.net/2010/02/17/serving-files-out-of-gridfs/

Совершенно не стоит. Зачем вам вообще лишние запросы к базе? Тем более такие обьемные? Люди наоборот все кешируют и на винт складывают, чтоб доступ быстрей был, а вы наоборот думаете как бы кеш (изображения) убрать из под руки и засунуть в базу.

— Начать, действительно, сложно. Очень долго приходится везжать в задачу.
— В любом случаи нужна, если вы не гений. Очень легко залипнуть на каком-то алгоритме. Нужен сильный математик + кодер как минимум.
— Алгоритм сильно зависит от задачи. Но, в основном, помимо стандартного набора из датамайнинга не плохо бы знать вычислительную математику (градиентные методы, краевая задача, трансоптрная задача и т.п.) и стандартные способы решения стандартных проблем.

Советую flask — flask
Отличная документация, отсутствие магии, поддержка разных БД, около 30 дополнений.
Посмотрите презентацию

Смотря какая работа.
Если работа над сложными проектами, то да, работа над проектом лучше. Больше опыта. Неважно какого вида работа: официальная, на себя или opensource.
Если мелкие поделки на фриланс бирже, то естественно олимпиады лучше.

Это общий взгляд, хотя надо отметить, что существуют множество других факторов — личные предпочтения, возможность знакомства с нужными людьми, перспектива и т.д.

Участие в работе/подработке/open source оттачивает опыт решения объёмных, но обычных, предсказуемых задач. Участие в олимпиадах оттачивает опыт решения небольших, но «концентрированных» нетривиальных задач. Победа/награда — всего лишь символ, признание уже достигнутого уровня.

Определитесь, чем Вы хотите заниматься через 3-5-10 лет. Если работать в конторе программистом, с чёткой карьерной лестницей, но довольно однообразными задачами — Вам больше пригодится опыт участия в проектах. Если же Вы рассматриваете вариант податься в науку или заниматься решением нетривиальных задач (карьера рискованная, потому что может и «не получиться») — участие (а лучше победы) в олимпиадах разовьёт нужные для этого навыки.

Можно провести спортивную аналогию: марафонец может заблудиться в лесу, а КМС по спортивному ориентированию вряд ли осилит марафон. Хотя, казалось бы, и там, и там надо просто хорошо бегать…

В то, что интересно.
Если Вы будете работать в каком-нибудь Research отделе, олимпиады пригодятся больше.

Прежде всего, не нужно зацикливаться на SVM: это всего лишь один из многих методов классификации. Да, у SVM есть своя специфика (у других методов — своя), но на данном этапе Вы вполне можете использовать общие алгоритмы предобработки данных.

какие именно признаки брать?

Это называется feature selection и feature extraction.

Простыми словами, процесс выглядит так:
1. Составляем список имеющихся признаков.
2. Добавляем в него различные функции от признаков (как упомянутый логарифм от веса), комбинации разных признаков (например, длина*ширина*высота), и т.п. Что именно комбинировать и какие преобразования использовать, должно подсказать знание задачи и здравый смысл. Этот процесс относится к feature extraction.
3. Задаём функцию ошибки, то есть определяем как будет оцениваться точность классификации. Например, это может быть отношение правильно распознанных примеров к их общему количеству. Здесь полезно почитать про precision and recall.
4. Переходим на один уровень абстракции выше.
Представим эдакий чёрный ящик, внутри которого находится классификатор вместе с обучающей и тестирующей выборками. На входе ящика — двоичный вектор, указывающий, какие признаки должен использовать классификатор; на выходе — величина ошибки классификации (на тестовой выборке).

Таким образом, задача выбора признаков сводится к задаче оптимизации: нужно найти такой входной вектор, при котором выходное значение ящика (ошибка классификации) будет минимально. Можно, например, добавлять признаки по одному (начиная с тех, которые сильнее всего улучшают результат) — см. градиентный спуск. Можно использовать что-то посерьёзнее, типа генетических алгоритмов.

Нужно ли при этом нормализовывать численные значения этих признаков?

Это сильно зависит от конкретной задачи и самих признаков.

Что делать если количество зерен в реальности (в обучающей выборке) относится к количеству плевел как 1/200? Портит ли это обучающую выборку?

В общем случае, портит: если одних примеров гораздо меньше, чем других, существует риск, что классификатор «запомнит» примеры из обучающей выборки, и не сможет адекватно разпознавать другие похожие примеры (Overfitting).
К тому же, если используется простейшая функция ошибки (правильно_распознанных / размер_выборки), философски настроенный классификатор может всегда отвечать «плевел» — и в 99.5% случаев будет прав :)