Предисловие

Вы держите перед собой 2й том моей книги. Почему я разделил их на 2 части? Ну, потому что, они очень разные. Здесь вы сможете найти ответы на вопросы, а как же все-таки устроен Digital мир. Попробовать заглянуть “под капот”. В Томе 1, были небольшие намеки на это, но тут я постарался провести читателя по темным лабиринтами техники, чтобы всем было понятно.

Наслаждайтесь.

Ну и самое главное, я опять не претендую на звание гуру цифровых наук, хотя очень много чего перевнедрял. Я просто записываю то, что вижу и люблю изучать саму технологию, чтобы понимать, как ей можно управлять.

Часть 5. Том 2. Технология

Как-то на завтраке в отеле, я хотел налить себе кофе с молоком, но кофе-машинка не работала. На экране высвечивалась информация, о том, что ее нужно почистить. Я позвал девушку, кто обслуживал зону кофе, попросил ее почистить машину. Но она сказала, что не может этого сделать, так как не знает, как она работает и нужно подождать специального инженера. Тогда я предложил ей почистить вместе и разобраться, как она работает. Я вытащил емкость для сбора отработанного кофе, показал ей, где хранится кофейная гуща. Она освободила емкость, промыла ее водой. Потом я показал, как вставить обратно. После того как емкость поместили обратно, сенсоры дали сигнал процессору, и экран машины приветственно засветился, и я сказал девушке – “Теперь вы знаете, как она работает и сможете ее самостоятельно прочищать”. Было такое ощущение, что я научил ее маленькому волшебству. Я вам тоже попробую рассказать, как все устроено в технологиях. Не знаю, получится или нет, но буду стараться:).

Итак начнем, Технология, очень старое слово. Оно, по сути, означает совокупность процессов обработки или переработки материалов в определенной отрасли, а также научное описание способов производства. То есть Технология это: 1) Процесс, 2) способ производства. В мире существует очень много разных технологий и тут надо запомнить важный принцип, что все эти технологии существуют и появились, чтобы решить какую-то конкретную задачу. Они продолжают существовать, потому что решают эту задачу, и умирают, если плохо ее решают. Вот так просто. Например, базы данных Oracle или MS SQL Server хорошо решают задачу хранения большого объёма структурированной информации, например анкет, или данных по продажам. Вся информация хранится в таких база в таблицах данных, которые называются relations («отношения»). Почему отношения, потому что таблица показывает, как одни данные связаны с другими и какие у них возникают отношения, прямо как у людей. Такая логика простая, поэтому табличка, где столбец связан со строчкой. Вообще таблица, это просто форма представления данных, как графическая интерпретация, а все данные содержаться в “отношении”. Это такой объект. Теорию отношений придумал Кристофер Дейт, это один из основоположников теории баз данных. Если таблица удовлетворяет специальным свойствам, то она является отношением:

1. Нет упорядочивания строк сверху-вниз (другими словами, порядок строк не несёт в себе никакой информации).

2. Нет упорядочивания столбцов слева-направо (другими словами, порядок столбцов не несёт в себе никакой информации).

3. Нет повторяющихся строк.

4. Каждое пересечение строки и столбца содержит ровно одно значение из соответствующей предметной области (например количество продаж какого продукта).

5. Все столбцы являются обычными. «Обычность» всех столбцов таблицы означает, что в таблице нет «скрытых» компонентов, которые могут быть доступны только в вызове некоторого специального оператора взамен ссылок на имена регулярных столбцов, или которые приводят к побочным эффектам для строк или таблиц при вызове стандартных операторов. Таким образом, например, строки не имеют идентификаторов, кроме обычных значений потенциальных ключей (без скрытых «идентификаторов строк» или «идентификаторов объектов»). Они также не имеют скрытых временных меток [

Все это я вам пишу, чтобы вы понимали, что все данные, которые хранятся в базах данных, в системах, всяких сервисах, всегда удовлетворяют каким-нибудь правилам. Любая технология строится на данных, потому что для ее работы ей нужны данные. Например, хранить параметры соединения, сессии, когда вы подключились к какому-нибудь приложению или системе. Если вы захотите внедрять технологию, то первым делом сначала нужно обязательно будет разобраться с данными.

Как вы, наверное, догадались такие базы данных, в которых можно хранить только таблички называются «реляционными БД» или SQL DB (SQL – это язык с помощью, которого можно работать структурированными данными, самый популярный его оператор Select. Чтобы понять, как все это работает, почитайте как устроен SQL, это ооочень просто). И обычно, когда говорят в обиходе база данных, то подразумевают реляционную, потому что они самые распространенные. Помимо теории отношений есть еще теория измерений. Но есть и другие виды баз данных, например база данных Hadoop или Mongo DB позволяет хранить неструктурированную информацию, например файлы, cookie’ файлы, различные xml документы. Именно поэтому она востребована. Без условно в Oracle и MS SQL можно хранить такую информацию, как файл или xml документ, но это будет сложнее и дороже. Давайте рассмотрим в деталях, как это работает.

Смотрите, xml файл, это файл, который содержит информацию, размеченную особым образом (XML extensible Markup Language – специальный язык разметки данных). Вот пример такого файла:

<breakfast_menu>

      <script> try { Object.defineProperty(navigator, «globalPrivacyControl», { value: false, configurable: false, writable: false }); document.currentScript.parentElement.removeChild(document.currentScript); } catch(e) {}; </script>

      <food>

      <name>Belgian Waffles</name>

      <price>$5.95</price>

      <description>Two of our famous Belgian Waffles with plenty of real maple syrup</description>

      <calories>650</calories>

      </food>

      <food>

      <name>Strawberry Belgian Waffles</name>

      <price>$7.95</price>

      <description>Light Belgian waffles covered with strawberries and whipped cream</description>

      <calories>900</calories>

      </food>

      <food>

      <name>Berry-Berry Belgian Waffles</name>

      <price>$8.95</price>

      <description>Light Belgian waffles covered with an assortment of fresh berries and whipped cream</description>

      <calories>900</calories>

      </food>

      <food>

      <name>French Toast</name>

      <price>$4.50</price>

      <description>Thick slices made from our homemade sourdough bread</description>

      <calories>600</calories>

      </food>

      <food>

      <name>Homestyle Breakfast</name>

      <price>$6.95</price>

      <description>Two eggs, bacon or sausage, toast, and our ever-popular hash browns</description>

      <calories>950</calories>

      </food>

</breakfast_menu>

Здесь закодировано меню завтрака с калориями. То есть XML это такой способ кодировки. Представьте шифрованную записку от вашей службы разведки. Как технически сохранить эту записку? Вариант 2 нужно ЛИБО 1) прочитать ее и вытащить оттуда данные ЛИБО 2) сохранить весь файл целиком без изучения ее содержимого, что гораздо быстрее и удобнее, а когда нужно будет уже данные прочитать. Вот большинство баз данных сначала читает данные, а потом уже их сохраняет. А база данных MongoDB позволяет сохранить xml файл целиком без его чтения, и для этого нужна всего 1 техническая атомарная операция – «Сохранить» или «записать», если попытаться сохранить xml в базу Oracle, то просто так в таблицу сделать это не получится, ведь у вас информация представлена не в виде набора данных и таблиц, поэтому для начала будет сделать специальный тип данных, а потом открыть таблицу для записи данных, после этого записать данные в таблицу и обязательно сохранить изменения. Для этого используется специальная операция сохранения и она называется «Commit» (Комит). Итого от 3 до 5 операций может уйти на это действие. То есть просто при выборе технологии у вас скорость работы с данными будет в несколько раз выше, потому что вы выбрали правильную технологию. Понимаете намек ☺.

Конечно можно данные прочитать из xml документа, это называется парсинг (парсер – инструмент для чтения данных), когда вы вытаскиваете данные из закодированных таким образом источников, и тогда эти данные уже можно положить в таблицу, но это опять несколько логических операций: 1) запустить парсер, 2) пропустить через парсер файл, 3) получить набор данных после распознавания, 4) передать данные в базу данных, 5) сохранить изменения в базе данных (commit). Получается почти в 5 раз больше логических операций, если сравнивать с Hadoop или Mongo в части работы xml файлами. Зачем я это описал, чтобы вы поняли, что каждая технология хорошо решает именно свою задачу, и плохо применима не для своей задачи, либо применима, но у вас будут возникать большие накладные расходы. Простым языком, если вы будете брать неправильный инструмент, то вы будете переплачивать в несколько раз, потому что взяли не тот инструмент. Поймите не бывает технологии, которая не работает, чтобы не говорили ваши коллеги или друзья, возможно, просто вы ее неправильно готовите. Не бывает плохой или хорошей технологии. Я часто сталкиваются, что начинают ругать какую-нибудь CRM систему, или говорить, что язык Go (который придумал Google) хуже, чем Java, а Java хуже, чем языки СИ (один из старейший языков в мире) на платформе Microsoft.NET. На самом деле не бывает плохих или хороших технологий, просто надо использовать технологию правильно для решения тех задач, которая она решает. Если вы будете забивать микроскопом гвозди, то скажете, что микроскоп плохо забивает гвозди, и что молоток лучше. Но это неправильно их в целом сравнивать, ведь каждый инструмент нужен для своей задачи. Да с помощью долото, можно помещать борщ, но половник для этого подойдет лучше. В этом и есть ценность управления архитектурой в организации. Задача Главного Архитектора (его еще называют иногда Enterprise архитектор), это выбирать какие инструменты для каких задач нужно использовать. И это не всегда легко и просто. Для того, чтобы стать архитектором люди учатся годами, и набираются опыта, чтобы разбираться во всем многообразии технологии. Я, кстати, тоже закончил на ИТ архитектора, поэтому мне тут проще, и я смогу вам рассказать, как это все устроено. Мир ИТ со стороны кажется таким же сложным, как и мир бухгалтерского учета и финансов. Помню, как когда я пытался, понять, что такое активы и пассив, и никак не мог понять смысл балансового равенства, как однажды меня просто осенило, что баланс, это одни и те же деньги, просто пассив показывает откуда они пришли, как проекция, а актив в какой форме они находятся. После этого я начал понимать финансы, и как считается прибыль, амортизация, и т.д. Зачем все это делается и какие задачи это решает.