В чем минусы повторного использования кода

Наш клиент разработал устройство и специальную программу, позволяющие снимать электрокардиограмму не в условиях стационара. Далее данные передавались на специальный сервер, который их обрабатывал, а потом посылал ответ пациенту: либо подтверждение, что все нормально, либо предложение обратиться к соответствующему специалисту. При этом в режиме онлайн давалась возможность в своем регионе выбрать врача-консультанта. Затем специальная программа осуществляла автодозвон и связь с медиком.

Инвестор проекта поставил задачу, чтобы система могла обрабатывать 1000 запросов в секунду. При этом было еще одно условие: легкость масштабирования проекта — быстрый переход от минимального количества запросов к максимальному.

Задача была непростая, потому что нужно было совместить хорошую агрегацию данных по разным параметрам с быстрым масштабированием. Хотя проект был в основном рассчитан на работу программистов, мы использовали методику DevOps, пригласив к мозговому штурму и системных инженеров.

Дело в том, что программисты предложили использовать реляционную базу данных PostgreSQL, которая позволяет легко делать выборку по имени пользователя, полу, дате рождения и т. д. Однако она выполняла лишь одну часть задачи: легкость и быстроту доступа и поиска данных. Вопрос с масштабированием и распределенным облачным хранилищем она не решала. Одна кардиограмма равна примерно 1 мегабайту информации, и при 1000 запросов в секунду база должна расти со скоростью 1Гб в сек.

Системные инженеры предложили использовать для этого нереляционную (NoSQL) базу данных, что сначала не устроило программистов. После длительного обсуждения решили использовать сразу две базы данных: реляционная должна была обеспечивать удобство работы с информацией и хранить метаданные, позволяющие обращаться к нереляционной базе данных, обеспечивающей распределенное хранение массива информации и быстрое масштабирование проекта.

В качестве второй базы данных мы взяли сначала HBase, являющуюся частью экосистемы Hadoop. Оказалось, что масштабируется она хорошо, но зато имеет высокие задержки при холодном пуске и до рабочего состояния разгоняется медленно. Тогда мы перешли на базу данных Cassandra, которая полностью подошла под условия нашей задачи. Таким образом, в пилотной зоне у нас оказались 1 сервер под PostgreSQL и 14 серверов под Cassandra.

В результате работа над проектом заняла у нас полгода. В ходе разработки мы еще раз убедились, что для каждого проекта необходимо использовать решение, полностью соответствующее задачам проекта, то есть нетиповое.
Очень часто даже крупные компании при реализации нового проекта пытаются использовать прежние наработки, готовые программы, которые они применяли ранее на других проектов. Вначале никто не обращает внимания на неприятные нюансы, которые впоследствии превращаются в серьезные проблемы, требующие костылей. А они влияют на быстродействие, отказоустойчивость и другие параметры проекта. Даже готовая база данных, как в нашем случае, хорошо себя показавшая в предыдущем проекте, на этот раз не давала тех результатов, которые нам требовались. Пришлось брать другую и писать под нее оригинальное программное обеспечение.