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

В ответ на пост

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

Все начинается с главного вопроса: для чего мы вообще храним эти данные? Что мы с ними должны делать?

Если наши данные — это строгие таблицы с четкими связями, как в бухгалтерии, то лучше подойдет реляционная база. Это кстати характерно и для ЛИМС. Хотя я описывал ЛИМС с документной базой данных - Senaitie. Это повлияет на то, как будут работать функции в приложении: объекты и формы ввода в программе будут повторять структуру этих таблиц, а интерфейсы будут заточены под основные операции — создать, прочитать, обновить, удалить. Но если мы бы строили социальную сеть, где важны связи между людьми, то понадобилась бы графовая база. А значит и механизмы поиска, фильтраций, рекомендаций программировались бы по другому. Кстати в разных приложениях онлайн-маркетов тоже используются графовые или векторные базы, для формирования рекомендаций к покупке. Развилось это в том числе за счет развития соцсетей.

Крайне важно понять, какова основная нагрузка на систему. Скажем в ЛИМС не требует постоянно искать по всему массиву информации, да и запись данных будет не столь частая, а вот если бы это было приложение, где тысячи пользователей постоянно что-то делают — совершают покупки, пишут сообщения, комментарии, то для такго приложения были бы критически важны скорость и надежность каждой операции. Возможно что в приложении нужно анализировать огромные массивы данных, строить отчеты и выявлять тенденции. Это аналитическая нагрузка, OLAP.Под аналитику часто строят отдельный архитектурный слой, который не мешает основной работе приложения, и используют специальные инструменты для обработки данных. Может даже использоваться несколько раздельных механизмов для хранения и анализа данных. В одну базу данных постоянно пишется информация и периодически выгружаются аналитические срезы в другую базу данных, заточенную под аналитику - Витрину данных.

Объем данных и скорость их поступления — это еще один ключевой фактор. Если мы получаем несколько тысяч мегабайт данных каждую секунду, как в системах IoT, простой базой данных не обойтись. Архитектура сразу усложнится: нам потребуются буферы, чтобы принимать этот поток, и специальные базы, которые умеют с такой скоростью работать. Архитектура будет строиться вокруг управления этим потоком. При разработке и использовании ЛИМС это может понадобиться, если мы хотим включить в ЛИМС все производственные датчики предприятия. Но это уже получается система класса МЕС (MES), а не ЛИМС. Но если в ЛИМС историчность данных важна, в МЕС бывает достаточно периодически сохранять из общего потока срезы данных, которые хранятся в отдельной витрине данных. Туда же можно перенаправлять данные из ЛИМС, при этом можно использовать например очереди сообщений с соответствующим брокером (Kafka, RabbitMQ), или какую-то ETL систему, например Apache NiFi.

Также нужно решить, должны ли данные храниться вечно или они временные. Для сессии пользователя на сайте подойдет быстрая память, а для результатов испытаний в ЛИМС — надежное постоянное хранилище. Это решение напрямую влияет на надежность системы и то, как мы будем обрабатывать сбои. Для временных данных мы будем использовать кэши, а это уже отдельный сервис в вашей архитектуре. Хотя, когда пользователей мало никто кэши отдельно не хранит, они вполне помещаются в оперативной памяти сервера. Но при большой нагрузке имеет смысл дополнительно устанавливать кэширующие базы данных. Конечно в случае ЛИМС такой потребности просто нет. Пользователей у нас много не будет никогда.

#ЛИМС #LIMS #ПО #Архитектура