Как варианты использования определяют архитектуру системы

Давным-давно когда компьютеры были большими, данные маленькими и о Big Data еще никто не слышал, а каналы связи узкими и не очень длинными Эдгар Кодд предложил реляционную модель данных. Очевидно, что за сорок с лишним лет многое изменилось. Можно долго перечислять появившиеся технологии но, в конечном счете, важным является совсем не это. Технологические изменения привели к изменению сценариев использования (use case) информационных систем. Люди взаимодействуют с компьютером совершенно иначе, чем в стародавние времена.

Как это было в 70-х годах прошлого века? У человека на столе стоял алфавитно-цифровой терминал, способный отображать на одном экране 25 строк из 80 символов (если я правильно помню). Провода от терминала тянулись в соседнюю комнату с табличкой «Вычислительный центр». Именно там и располагалась ЭВМ. Одна вычислительная машина «тянула» несколько десятков терминалов. Работа с ЭВМ осуществлялась следующим образом. В заранее зарезервированное время человек садился за терминал. Вычислительный ресурс был дорог и потому расписание использования машинного времени составляли заранее. Так вот, человек садился за терминал, открывал сессию и на протяжении нескольких часов в рамках этой сессии отправлял компьютеру из соседней комнаты запросы и смотрел «вычисленные» им результаты. Если результаты занимали несколько больше одного экрана, то их скидывали в файл, который потом частенько отправляли на печать и изучали уже в виде бумажной копии, в свободное от работы время. Аналогично поступали и с запросами,время выполнения которых превышало зарезервированное время использования терминала. Такие задания отправляли в пакетный режим и запускали на выполнение по ночам, а с утра смотрели результаты в виде распечатки.

Интересно то, что идея структурирования данных на внешних дисках в виде двумерных массивов(1-ая нормальная форма реляционных баз данных) пришла в голову только Эдгару Кодду. Ведь многие люди изо дня в день видели таким образом  отформатированные данные на экранах своих терминалов.

Что изменилось. Сначала появились [много]оконные интерфейсы. Т.е. на одном экране пользователь видел результаты нескольких выборок данных: список записей, форму с отображением полей одной конкретной записи, выпадающие списки с набором допустимых параметров, загруженным из какого-то справочника и т.д. Одним словом, на построение одной экранной формы делалось множество запросов к базе данных, причем каждый запрос, как правило, связывал данные из нескольких таблиц. Эстафету экранных форм подхватили windows-приложения, с закладками (tabs) списками (порой иерархическими), а затем и web-приложения с фреймами, айфремами, виджетами и т.д.

Второе. Развивались сети передачи данных. TCP/IP позволил работать с некоторым сервером не только людям из соседней комнаты, но и с другого этажа, из другого здания, с другого конца света. Естественно, протоколы с установленным соединением (stateful) не могли обеспечить одновременной работы с сервером тысяч пользователей. Потому HTTP – протокол без поддержания сессии (stateless) оказался как нельзя кстати. К тому же, web-страница может собирать в себе данные с нескольких серверов, что решает проблему масштабирования web-сервера. К сожалению, это не решает проблему работы с базой данных. Масштабировать (реляционные) базы данных сложно и дорого.

Одним словом, в некоторый прекрасный момент разработчики web-приложений оказались в ситуации, когда им нужно обслуживать огромное количество запросов, для каждого запроса делать несколько сложных выборок данных и делать все это достаточно быстро. Естественно, они не могли выжить в архитектуре хранилища данных, пришедшей из 70-х годов прошлого века. До определенного момента кеширование и огромное количество железа спасало ситуацию, но бесконечно это продолжаться просто не могло. Так появились NoSQL хранилища данных. Стратегия построения таких систем довольно простая. Первое что необходимо сделать – сократить и количество запросов к хранилищу и упростить их выполнение. Для этого нужно денормализовать данные. В идеале, все данные, необходимы для отображения пользователю, должны лежать в одной записи и извлекаться из хранилища одним легким запросом. (Вспоминаем как выглядит запись в MongoDB). Во вторых, данные необходимо распределить по узлам сети (sharding) и сделать это так, чтоб увеличение емкости можно было производить линейно простой установкой дополнительных узлов. И третье – развести операции чтения и изменения данных. Кстати, протокол HTTP этому способствует. Правда, для использования этих преимуществ протокола программисты не должны модифицировать данные посредством HTTP GET запросов. Почему некоторые это делают до сих пор, мне понять не дано.

Компьютеры стали маленькими, данные сделались большими, а провода вообще исчезли из поля зрения. Осталась только реляционная модель хранения данных в наших головах. Интересно, надолго ли?

Реклама

4 responses to “Как варианты использования определяют архитектуру системы

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s