Проект Graphite

Глава 7 из книги "Архитектура приложений с открытым исходным кодом", том 1.

Оригинал: Graphite, глава из книги "The Architecture of Open Source Applications" том 1.
Автор: Chris Davis
Перевод: Н.Ромоданов

7.10. Размышления о проекте

Мой опыт работы с пакетом Graphite подтвердил мое убеждение, что масштабируемость имеет очень мало общего с низким уровнем производительности, а является результатом общего устройства проекта. По пути я сталкивался со многими узкими местами, но каждый раз я искал решения в преобразовании проекта, а не в повышении производительности. Я много раз спрашивал, почему я написал Graphite на языке Python, а не на Java или на C++, и я всегда отвечал, что я до сих пор не гонюсь за той производительностью, что мог бы предложить другой язык. В работе [Knu74], Дональд Кнут сказал знаменитую фразу, что преждевременная оптимизация есть корень всех зол. Пока мы считаем, что наш код будет продолжать развиваться нетривиальными способами, любая оптимизация [6] в некотором смысле преждевременна.

Одной из самых сильных и самых слабых сторон Graphite является то, что он, в действительности, очень мало «проектировался» в традиционном смысле слова. По большому счету Graphite развивался постепенно и брал препятствия по мере того, как возникали проблемы. Много раз препятствия можно было предвидеть и различные упреждающие решения казались естественными. Однако, было бы лучше избегать решения проблем, с которыми вы еще не столкнулись, даже если кажется, что они вскоре возникнут. Причина в том, что вы можете узнать гораздо больше от внимательного изучения фактических неудач, чем при теоретизировании о превосходной стратегии. Решение проблемы обуславливается как эмпирическими данными, которые у нас есть под рукой, так и нашими собственными знаниями и интуицией. Я узнал, что сомнения в достаточности собственных знаний может заставить вас посмотреть более тщательно на ваши эмпирические данные.

Например, когда я впервые написал whisper, я был убеждён, что он должен быть переписан на язык C с тем, чтобы увеличить скорость, и что код на языке Python мог бы служить исключительно в качестве прототипа. Если бы тогда я не был в цейтноте, я бы, скорее всего, полностью исключил применение языка Python. Однако, оказывается, что ввод/вывод становится узким местом гораздо раньше, чем процессор, и что на практике меньшая эффективность языка Python вряд ли вообще имеет значение.

Как я уже говорил, эволюционный подход также является большой слабостью проекта Graphite. Интерфейсы, как оказалось, плохо поддаются постепенной эволюции. Хороший интерфейс для максимальной предсказуемости должен быть согласованным и должен отвечать соглашениям об использовании. По этому показателю, интерфейс URL API в Graphite является, на мой взгляд, в настоящее время неудовлетворительным. С течением времени добавлялись параметры и функции, иногда образовывались небольшие острова согласованности, но в целом общей согласованности не хватает. Единственный способ решить такую проблему является переход к версиям интерфейсов, но здесь тоже есть свои недостатки. Как только разрабатывается новый интерфейс, от старого интерфейса становится трудно избавиться и он сохраняется повсюду как эволюционный багаж, похожий на аппендикс у человека. Это может казаться достаточно безобидным, пока однажды у вашего кода этот аппендицит не воспалится (т.е. Не возникнет ошибка, связанная со старым интерфейсом) и вам придется прибегнуть к операции. Если бы я на ранней стадии должен был изменить в Graphite только одну вещь, то я бы уделил гораздо больше внимания разработке внешних интерфейсов API, обдумывая их заранее, а не собирая их по крупицам.

Другим аспектом Graphite, который вызывает некоторое разочарование, является ограниченная гибкость иерархической модели именования метрик. Хотя она довольно проста и очень удобна в большинстве случаев, с ее помощью становится трудно и даже невозможно делать некоторые сложные запросы. Когда я впервые подумал о создании Graphite, я с самого начал знал а, что для создания графиков хотел иметь интерфейс API на основе URL, который мог бы редактировать человек [7]. Хотя я до сих пор рад, что в Graphite сегодня есть эта возможность, я боюсь, что такое требование заставляет ограничиться в API исключительно простым синтаксисом, который делает сложные выражения громоздкими. Иерархия делает проблему определения «первичного ключа» для метрики достаточно простой, поскольку для узла в дереве первичным ключом, по существу, является путь. Недостаток состоит в том, что все описательные данные (т.е. данные в столбцах) должны встраиваться непосредственно в пути. Возможное решение состоит в поддержке иерархической модели и добавлении отдельной базы метаданных, которая с помощью специального синтаксиса предоставит более усовершенствованные способы выборки метрик.

7.11. Переход в статус открытого кода

Оглядываясь на эволюцию Graphite, я все еще удивляюсь тому, как далеко он зашел как проект, и как далеко он завел меня как программиста. Он начался, как любимое занятие, в котором был всего лишь несколько сотен строк кода. Движок отрисовки стартовал в качестве эксперимента просто для того, чтобы я мог увидеть, смогу ли написать его. whisper был написан в течение выходных от отчаяния для решения непреодолимой проблемы к критической дате запуска. carbon переписывался столько раз, что сложно вспомнить. Когда в 2008 году мне только что разрешили выпустить Graphite под лицензией открытого исходного кода, я не ожидал, что будет отклика. Через несколько месяцев Graphite был упомянут в статье в CNET, что было замечено в Slashdot и проекта вдруг стал популярным и его популярность продолжается до сих пор. Сегодня существуют десятки крупных и средних компаний, использующих Graphite. Сообщество достаточно активно и продолжает расти. Проекту далеко до завершения, есть много классной экспериментальной работы, которая выполняется, и это поддерживает интерес к работе и открывает большие перспективы.

Примечания

---

Далее: К началу статьи

---

---