Алексей Черемисин

Таблица разметки GPT самая современная, позволяет размечать разделы до петабайт, DOS - 32битная и не позволяет адресовать пространство диска более 2Тб, т.е. Все, что больше этой цифры будет неразмечено.
Рекомендую GPT, ее даже уиндоуз современный поддерживает.

У вас будет примерно 11 запросов в секунду (+ роботы, +бекапы, +cron), это хорошая нагрузка. Берите xeon 2630v3 (а лучше два), и 16/32гб памяти (зависит от контента), и диски парочку в raid1, а то и четыре в raid5 (1 под hotspare). По поводу контроллера для дисков, можно не заморачиваться и сделать softraid. потеряете немного, а выигрыш в плане восстановления колоссальный. По поводу памяти, берите максимум, который сможете. Захочется кешей разных для ускорения (mysql, nginx, и в битриксе), и это хорошо.
Сервер сразу берите с запасом, так как через года два-три легче будет купить новый, чем купить памяти или найти второй проц, проверено неоднократно!
Вообще-то я всем советую покупать всегда по максимуму бюджета, проект будет расти, захочется еще сайтов или каких-то свистелок, а просто так взять и добавить коксу возможности может и не быть...

PS. Даже просто, вдруг захотите поставить другую CMS, ведь скорее всего захочется поднять ее рядом и сделать new.mydomain.com и old.mydomain.com. (мой случай)

PPS. Вынес наверх
Хотя, конечно, что-то я загнул, на 4 диска что раид10, что раид5 с хотспаре - одинаковой емкости, извиняюсь, каюсь и исправляюсь... Raid10 и только!

Ну, буду немногословен, берите 5 штук rasberrypi, ставьте на каждый mpd www.musicpd.org и вперед.
Упс. по запросу rasberry pi + mpd - habrahabr.ru/post/195458

Для чего я использую tornado, точнее cyclone.io, порт tornado под twisted.

- для системы miidleware ТВ-приставок. Приставка лезет за страничкой к серверу, а в остальное время общается с ним по json/REST/comet. Админка статистики этого дела работает на отдельном порту и содержит 10 страниц + json/comet/rest.
- для системы доступа к кластеру с тонких клиентов, сервер отдает данные в json о доступных точках входа на сервера кластера и запоминает выбор пользователя. Всего 30 строк кода, Карл :-) С одной стороны сервер подключается в influxdb, с другой отдает данные пользователям.
- для админок к разным устройствам
- для вещей, когда просто нужен вебсервер и шаблоны, и не нужна база данных, ORM, и куча лишнего говна.
- для вещей, когда web-интерфейс как небольшая часть остального функционала
- для web, когда нужно быстро туда-сюда прогнать данные.

Если посмотреть на отличия с django, то django умеют делать отличный фреймворк для web, а торнадо - отличный фреймворк для http!

Дополнил

А чего далеко ходить. Простая конфигурилка для линукса, интерфейсы, логин/пароль, просмотр и конфигурилка запущенных служб. Раньше я это делал на webmin, теперь cyclon + angularjs.

А вот.. вот делаю дизайн html для битрикс (уж простите...). Как-то нужно смотреть html/css + картинки + javascript, причем, все с путями реального сайта - 10 минут и у меня всё готово. Ну не апач с nginx для этого разворачивать же?

Ну и как-то была задача типа чата (для удаленных устройств), когда нужно было обеспечить около 10к подключений. Без танцев с бубном и минимум кода.

В общем везде, где просто нужен быстрый и простой web-сервер с моторчиком из питона. Раньше я для этого использовал jetty (java) с моторчиком на яве соответственно. На питоне это проще в два/три раза только из-за того, что можно по ssh зайти и тупо поправить в коде без компиляции (maven) и среды разработки (eclipse).

А, дьюди, такая же проблема! Под OSX он совсем не нативный и работает через ж.., упс, через ХеОкна11, страх и ненавись. Я для себя эту проблему решил по другому, установил в пареллелях Ubuntu и ненарадуюсь обладанию inkscape. Собственно и в винде под параллелями тоже хорошо работает.

Здесь как минимум нужно немного залезть в предметную область и ответить себе на вопросы (до таблиц и полей):
- что такое "погода", чем она измеряется, какие у нее характеристики, есть ли табличные данные: типа привязки к местности (город, район и т.д.), таблицы комфорта (комфортно не очень, не комфортно) или влажности (сухо, влажно, мокро и т.д.)?
- тоже самое расписываем для прогноза.
- теперь по отчетам, какие типы отчетов планируются ( за день по местности, пелевантность по прогнозу и т.д.).
Что касается отчетов, то они бывают (обычно) двух типов.
Одни формируются простой выборкой из базы данных с агрегацией - это простые агрегированные отчеты (средняя температура за час, или минимум/максимум за период по местности). Для таких отчетов обычно не нужно создавать таблиц и хранить промежуточные данные, если только не для ускорения предоставления и не в целях архивации (например подсчет и сохранение средней температуры день/ночь ежедневно по окончании суток).
Вторые - аналитические. Например средняя ошибка в прогнозах за одинаковые периоды по местностям. Это те отчеты, которые требуют агрегации нескольких выборок, здесь приходится создавать промежуточные таблицы с результатами выборок, и уже по ним формировать выходные данные ( как нахождение второй и третьей производных функций).
В общем, сначала описываете СЛОВАМИ что у вас есть на входе по погоде и температуре, и какие отчеты хотелось бы получить. А уже из этого делаете модель данных под простые отчеты, и в самом конце занимаетесь аналитикой. Также сразу позаботьтесь об объемах данных, вдруг их придется шардировать, архивировать и т.д..
Наводящие вопросы я задал. Отвечайте, двинемся дальше.