Вредные советы по масштабируемости | Participants
|
- Statistics
- Participants
- Translate into Russian
- Translation result
- 61% translated in draft.
If you do not want to register an account, you can sign in with OpenID.
Scalability Worst Practices - | ||
Introduction | ||
Over the course of building out a number of large, distributed systems I've had the opportunity to observe (and implement) some worst practices. Most of these worst practices start innocently enough, but if neglected they will jeopardize the growth and scalability of a system. A number of articles focus on best practices to ensure an easily maintainable and scalable system, but in this article I'll highlight some worst practices to avoid. | Участвуя в нескольких разработках крупных распределенных систем, я имел возможность наблюдать (и применять) некоторые дурные приемы, которые могут поставить под угрозу развитие и масштабируемость системы, хотя большинство из них поначалу кажутся вполне безобидными. В ряде статей рассматриваются полезные советы по построению легкомасштабируемых и поддерживаемых систем. Я же в этой статье хочу выделить некоторые методы, которые наоборот следует избегать. | |
Technology | ||
No one technology or architecture can fulfill all requirements. Understanding when to re-think existing ideas, how to look beyond the local scope or how to exercise diligent control of dependencies all are key attributes to scalability. Let's look more closely at each. | Ни одна технология или архитектура не способна полностью удовлетворить всем требованиям. Понимание того, когда следует пересмотреть сформировавшиеся идеи, умение смотреть шире, способность тщательно контролировать все взаимосвязи - все это ключи к построению масштабируемых приложений. Рассмотрим подробнее каждый из них. | |
The Golden Hammer | ||
The Golden Hammer refers to the old adage: if all you have is a hammer, everything looks like a nail. Many developers fall prey to the idea of using only one technology - the cost of this is having to build and maintain an infrastructure in the chosen technology which may be readily available in another technology which is more suited to the specific problem area's functionality or abstractions. Forcing a particular technology to work in ways it was not intended is sometimes counter-productive. | Как говорится в старой пословице: "Если у тебя есть только молоток, всё вокруг становится гвоздями". Многие разработчики становятся жертвами принципа - использовать только одну технологию. В результате приходится разрабатывать и поддерживать в рамках выбранной технологии инфраструктуру, которая уже может быть полностью реализована в другой технологии, более подходящей для функционала данной предметной области или абстракции. Использование технологий не по прямому назначению порой непродуктивно. | |
As an example, a common solution to the problem of persisting key-value pairs is to use a database. This choice is usually made because the organization or developer has a well-established database practice and naturally follows the same solution path for many problems. The problems arise when the features of a database (relational integrity, locking, joins and schemas) become bottlenecks or inhibit scaling. This occurs because the cost of growing a database-based solution for this application is generally much more expensive than other available technologies. As the access rate of the key-value store increases, the concurrency model of a database can begin to degrade performance while the advanced features that the database provides are not used. Many alternatives to the traditional relational database are available to address these short-comings such as CouchDB, SimpleDB or BigTable. | В качестве примера - типичное решение использовать базу данных для хранения пар ключ-значение. Такой выбор обычно обусловлен тем, что организация или разработчик имеют неплохую практику работы с базами данных и буквально идут по этой проторенной дорожке при решении многих задач. Проблемы возникают, когда особенности баз данных (ссылочная целостность, блокировки, объединения (joins) и схемы) начинают препятствовать расширению системы. Для приложения стоимость развития такого решения на основе базы данных, как правило, гораздо выше, чем при использовании других технологий. По мере увеличения частоты запросов к хранилищу пар ключ-значение, параллельная работа процессов базы данных снижает производительность, в то время как дополнительные возможности, которые предоставляет база данных, не используются. А ведь существует множество альтернатив традиционным базам данных, такие как: CouchDB, SimpleDB, BigTable. |
Comment was deleted
— Вообще по сути стоило бы назвать "Что мешает масштабируемости". В статье не описываются плохие практики реализации масштабируемости, здесь идет речь о том, что ей мешает. — xxegorov