Высокий технологический стек масштабируемости [закрывается]
Попробовать Ehcache? Это позволяет Вам включать свои собственные алгоритмы истечения кэширования, таким образом, Вы могли управлять своей функциональностью быстрого взгляда.
можно сериализировать к диску, базе данных, через кластер и т.д.
5 ответов
Это не тот вопрос, на который здесь можно ответить иначе, как в общем обзоре. Некоторые общие указания:
- Аппаратное обеспечение: два варианта в основном представляют собой множество маленьких дешевых коробок или меньшее количество более мощных коробок. Более дешевые коробки, ну, дешевле, но обычно потребляют намного больше энергии для того же процессора или памяти (что важно для вас), чем коробки большего размера. Люди часто забывают о иногда значительных затратах на энергопотребление;
- Серверная часть: у вас есть несколько вариантов выбора: от большого (Oracle, SQL Server) до массового (MySQL). MySQL, очевидно, дешевле, и вы можете далеко уйти от MySQL, но нет никаких сомнений в том, что Oracle (с которым я более знаком, чем SQL Server) имеет лучший оптимизатор, более функциональный и надежный, чем MySQL. Однако вы заплатите за это;
- Бюджет: это огромный фактор, поскольку, возможно, стоит платить за хорошее коммерческое программное обеспечение, а не платить за разработку для использования «бесплатного» программного обеспечения. Разработка программного обеспечения - одна из самых дорогих затрат из всех;
- Вертикальная и горизонтальная масштабируемость: вопрос, на который вы в основном пытаетесь ответить, заключается в том, создаете ли вы (большие блоки и т. Д.) Или создаете (кластерные среды) ). Самые масштабируемые решения имеют почти линейную горизонтальную масштабируемость, но в краткосрочной перспективе вертикальная масштабируемость может быть дешевле.
Что касается вашего обычного стека, я бы придерживался его, если у вас нет особых требований, о которых вы не упомянули. запрещает это. В конце концов, PHP - это проверенная технология, с помощью которой работает около 4 из 20 лучших сайтов в Интернете (Facebook, Wikipedia, Flickr и Yahoo). Если это достаточно хорошо для них, это достаточно хорошо для вас.
Что еще более важно, вы это знаете. Известные вам стеки технологий почти во всех случаях превосходят стеки технологий, которых вы не знаете. Остерегайтесь ловушки «зеленого пастбища», которую представляет собой последний разрекламированный стек технологий.
Memcache - это хорошо. Еще одна вещь, которую вы, возможно, захотите добавить к этому миксу, - это beanstalkd в качестве процессора распределенной рабочей очереди.
Один важный вопрос, на который нужно ответить: насколько хорошо вы можете разделить свое приложение? Приложения, которые легко поддаются разделению, намного проще масштабировать. Те, которые нет, как правило, модифицируются каким-либо образом, чтобы упростить их разделение.
Хорошим примером этого является простое приложение для торговли акциями. Вы можете разделить рыночную информацию на основе биржевого кода (AC на одном сервере, DF по другому и тд). Для многих таких приложений это подойдет.
http://highscalability.com/ здесь есть чему поучиться, вы, вероятно, найдете свой ответ.
Я могу добавить хороший компонент для вашего стека: MemCache .
торнадо похоже на то, что я бы попробовал на таких проблемах http://bret.appspot.com/entry/tornado-web-server по крайней мере, вы знаете, что это проверенное и проверенное решение.
PHP, memcached + DB in general scales well but there may be ways to do it with lower costs i.e. a stack that's able to handle more concurrent requests per machine.
Given your comment here...
My goal is not a large scalable system, just a simple technology stack. I'm not growing a DB, Search, crawler, etc. Just a simple request, query, respond, and store. Any recommendations for technology stack for my purpose?
.. it sounds like the DB part might be solvable by Amazon's S3 ([what?!?][1]), assuming you only need to locate items by key. That would also give you Cloudfront for reads, if you don't mind the eventual consistency.
Meanwhile server-side something using async IO to handle requests should significantly boost the number of concurrent requests each machine can handle. As another poster already said tornado (bret.appspot.com/entry/tornado-web-server) would be worth a look here - haven't seen an API for async IO that's friendlier.
You'd probably still need memcached to keep reads fast but you want to watch out there that the memcached client isn't going to end up blocking the server process while trying to make concurrent requests - PHP wouldn't normally have this problem as each PHP (or Apache) process has it's own memcached connection and is only ever doing one thing at a time. This python client - should support async IO - the underlying libmemcached has support for asynchronous requests.
Same goes for HTTP requests from server to S3 - how do you handle concurrent requests there? boto seems to use a connection pool for that, each connection holding a different socket open. Memory use?
Disclaimer: I'm being an armchair architect here - haven't actually done this and the smartest advice might be finish the project on time with the stack you know well and aren't going to fail with.
Sorry about the links