Вячеслав Благирев - Digital Book. Книга вторая

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

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

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

Belgian Waffles

$5.95

Two of our famous Belgian Waffles with plenty of real maple syrup

650

Strawberry Belgian Waffles

$7.95

Light Belgian waffles covered with strawberries and whipped cream

900

Berry-Berry Belgian Waffles

$8.95

Light Belgian waffles covered with an assortment of fresh berries and whipped cream

900

French Toast

$4.50

Thick slices made from our homemade sourdough bread

600

Homestyle Breakfast

$6.95

Two eggs, bacon or sausage, toast, and our ever-popular hash browns

950

Здесь закодировано меню завтрака с калориями. То есть 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 архитектор), это выбирать какие инструменты для каких задач нужно использовать. И это не всегда легко и просто. Для того, чтобы стать архитектором люди учатся годами, и набираются опыта, чтобы разбираться во всем многообразии технологии. Я, кстати, тоже закончил на ИТ архитектора, поэтому мне тут проще, и я смогу вам рассказать, как это все устроено. Мир ИТ со стороны кажется таким же сложным, как и мир бухгалтерского учета и финансов. Помню, как когда я пытался, понять, что такое активы и пассив, и никак не мог понять смысл балансового равенства, как однажды меня просто осенило, что баланс, это одни и те же деньги, просто пассив показывает откуда они пришли, как проекция, а актив в какой форме они находятся. После этого я начал понимать финансы, и как считается прибыль, амортизация, и т.д. Зачем все это делается и какие задачи это решает.