Первоначально Написано Базз Москетти
Это будет первая публикация в продолжающейся серии, основанной на нашем популярном вебинаре, о различиях в построении приложения с использованием SQL по сравнению с созданием того же приложения с использованием MongoDB.
Прежде всего, прежде чем мы начнем что-то делать, чего мы все пытаемся достичь с помощью наших данных? Несомненно, существуют необходимые пороки, такие как чтение и запись данных из баз данных, размещение данных на шинах сообщений и работа с интеграциями с открытым исходным кодом, но в конечном итоге мы действительно хотим получить информацию, вычислить ее и получить это перед правильными людьми, чтобы помочь им принять лучшие решения.
Бизнес-требования часто кажутся довольно простыми: «Я просто хочу сохранить свои сделки» или «Можем ли мы создать каталог продуктов, который бы обрабатывал ¥, £ и $?» — но способ, которым данные выражаются в коде или в приложении, отличается от способа, которым они оформлены в случае бизнес-использования. Когда вы доберетесь до того, как вариант использования реализован в базе данных, различия станут еще более заметными.
И почему так? Одна из причин заключается в том, что инновации в бизнесе и на уровне кода / приложений намного опередили инновации в технологиях баз данных. СУРБД вышла на сцену в 1974 году. С тех пор бизнес-цели изменились, темпы бизнеса увеличились (время выхода на рынок действительно имеет большое значение сейчас), и мы используем технологии, которые мы даже не могли себе представить, существовавшие 40 лет назад , В то время у нас были довольно простые языки, которые хорошо сочетались с «прямоугольным» и «плоским» миром СУБД. Сегодня у нас есть чрезвычайно мощные языки всех типов с бесконечными потоками обновлений, поступающих из открытых экосистем, которые мы создали. Единственное, что постоянно, это изменение.
| В 1974 году … | В 2014… | |
|---|---|---|
| Цели бизнес-данных | Захватывайте транзакции моей компании ежедневно в 17:30 по восточному поясному времени, каждую ночь добавляйте их и распечатывайте большую стопку бумаги | Захватывайте глобальные транзакции моей компании в режиме реального времени, а также все, что происходит в мире (клиенты, конкуренты, бизнес / нормативные требования / погода), производите любое количество вычисленных результатов и передавайте все это в режиме реального времени прогнозной аналитике с обратной связью модели , Затем результаты доставляются на десятки тысяч мобильных устройств, несколько графических интерфейсов и каналы b2b / b2c. |
| Расписание релизов | Раз в полгода | Вчера |
| Применение / Код | COBOL, Fortran, Algol, PL / 1, ассемблер, проприетарные инструменты | C, C ++, VB, C #, Java, Javascript, Groovy, Ruby, Perl, Python, Obj-C, SmallTalk, Clojure, ActionScript, Flex, DSL, весна, AOP, CORBA, ORM, сторонняя программная экосистема, полностью открытая движение источника … и кобол и фортран |
| База данных | I / VSAM, ранняя RDBMS | Устаревшие СУБД, устаревшие столбцы I / VSAM и хранилища ключей / значений и … MongoDB |
Вот где появляется NoSQL, в частности MongoDB. Что делает MongoDB особенным, так это то, что он хранит данные в богатых структурах (картах карт списков, которые в конечном итоге переходят к целым числам, числам с плавающей запятой, датам и строкам). MongoDB был разработан для того, чтобы не только плавно хранить эти объекты, но и представлять их в API и на языке запросов, который знает, как понимать все типы данных, которые вы храните. Это резко контрастирует с устаревшими технологиями, разработанными и встроенными в программные среды 1970-х годов.
В MongoDB ваши данные являются схемой, и существует симметрия между тем, как данные поступают в базу данных, и тем, как они поступают. При использовании традиционных технологий разница между тем, что означает вводить и выводить данные, увеличивается по мере усложнения приложений. Примеры, которые мы рассмотрим в этой серии, продемонстрируют эти концепции.
И, наконец, ни один учебник по MongoDB не будет полным без следующей диаграммы:
На изображении слева показано хранение данных о клиентах в «прямоугольных» таблицах и схема, необходимая для понимания всего этого. На изображении справа показано, как данные хранятся в MongoDB. Достаточно сказать, что диаграмма слева более сложна, чем диаграмма справа. Теперь, чтобы быть справедливым, диаграмма слева содержит больше сущностей, чем просто клиент и его телефоны, и, по всей вероятности, не выглядела так. Это было, вероятно, относительно просто в начале. Тогда кому-то нужно было нечто, не являющееся скаляром, а кому-то — еще несколько вещей, и прежде чем они узнали, что случилось, то, что когда-то было управляемым, взорвалось тем, что вы видите в данный момент.
Теперь давайте разберемся с фактическими различиями между SQL и MongoDB и тем, как мы передаем наше мышление с помощью кода.
Некоторые основные правила:
- Мы будем использовать Java
- Предположим, у нас есть слой доступа к данным между нашим приложением и MongoDB
- С точки зрения даты, которую мы рассматриваем при рассмотрении примеров, просто рассматривайте их как индикаторы прогресса, а не фактическое время, необходимое для выполнения задачи.
- Мы не будем вдаваться в исключения или обработку ошибок. Мы не будем путать код с шаблонной или персисторной логикой, которая не меняется со дня на день. Мы не будем входить в соединение с базой данных или другие ресурсы установки. Основное внимание будет уделено основному коду обработки данных.
SQL против MongoDB: день 1
Мы начнем с карты, которая позволит нам перемещать данные в наш слой доступа к данным и из него. Карты имеют богатую форму, поэтому мы можем в них многое вставить, и, что еще важнее, нет зависимости от времени компиляции.
Задача: сохранение и выборка контактных данных
Начнем с этой простой плоской формы в слое доступа к данным:
Map m = new HashMap(); m.put(“name”, “buzz”); m.put(“id”, “K1”);
Мы сохраним это так:
save(Map m)
И предположим, что мы можем получить его по первичному ключу следующим образом:
Map m = fetch(String id)
В нашем первом случае у нас есть две очень простые вещи: «сохранить» и «получить». Богатые запросы придут позже. Вот как это может выглядеть в коде для SQL и MongoDB:
В MongoDB «данные — это схема», и нам не нужно создавать таблицу. Если вы посмотрите ближе на функции выборки, вы заметите, что они в основном одинаковы. Важным выводом из этого является то, что в MongoDB ваш основной способ обращения к базе данных на самом деле очень похож на то, как вы бы это делали в RDBMS. Вы строите запрос, передаете его, возвращаете курсор и перебираете курсор. Точность перемещения данных будет меняться по мере прохождения этих примеров, но сейчас давайте предположим, что у нас есть четность.
SQL против MongoDB: день второй
Давайте добавим два поля: заголовок и дату.
Задача: Добавление простых полей
m.put(“name”, “buzz”); m.put(“id”, “K1”); m.put(“title”, “Mr.”); m.put(“hireDate”, new Date(2011, 11, 1));
Обратите внимание, что мы помещаем фактический объект Date в слот hireDate, а не строковое представление, например «2011-11-01». В хорошо спроектированном слое доступа к данным мы всегда хотим использовать максимально точные объекты. Даты, в частности, должны обрабатываться таким образом, чтобы избежать путаницы ГГГГММДД и ГГГГДДММ.
Вот как может выглядеть реализация уровня доступа для использования SQL:
Первое, на что нужно обратить внимание, это проблема изменения таблицы. Прежде чем мы сможем коснуться любого кода, который будет взаимодействовать с новой базой данных, мы должны сначала изменить определение таблицы; в противном случае оператор select, который идет после новых полей, просто не будет работать. В этом нет ничего нового. Это то, к чему все привыкли за последние 40 лет, используя СУРБД. Есть несколько других вещей, которые разработчики также должны учитывать, например чувствительность к регистру и т. Д.
Теперь давайте посмотрим, как это выглядит в MongoDB:
Что мы должны были изменить в MongoDB? Ничего.
Мы помещаем название и дату найма на карту, и мы просто вставляем всю карту в MongoDB. Ранее вставленные элементы остаются без изменений, без полей заголовка и даты проката. Если важна обратная засыпка более старых элементов, у которых нет этих полей, мы можем легко написать 4-строчную программу javascript, которая выполняет итерацию по коллекции и устанавливает значения по умолчанию для заголовка и даты найма.
На следующей неделе мы рассмотрим добавление списков, где начинается настоящее веселье.
В то же время, если вы ищете совет по миграции, воспользуйтесь нашим предложением бесплатно пообщаться с экспертом MongoDB .
Поговорите с экспертом о миграции. БЕСПЛАТНО.
О Базз Москетти
Базз Москетти — корпоративный архитектор в MongoDB. Он является бывшим глобальным руководителем по архитектуре в инвестиционном банке JPMorganChase. В его обязанности входило видение и стратегия информационной и программной архитектуры, разработка бизнес-приложений и процессов, а также разработка стандартов и лидерство в разработке решений для бюджетного финансирования в размере 2,2 млрд. Долл. США для 9000 специалистов по всему миру для всех направлений бизнеса, включая рынки акционерного и долгового капитала, котируемые и внебиржевые деривативы, товары, институциональные, частные и торговые операции с клиентами, расчеты и расчистка, а также исследования. До этой должности он был директором по архитектуре Bear Stearns с 2000 по 2008 год с аналогичными обязанностями. Ранее в своей карьере в Bear Stearns,он был директором по технологиям Группы финансовой аналитики и структурированных транзакций (FAST) в отделе с фиксированным доходом. и руководил проектированием и разработкой пакета приложений для оценки портфеля HYDRA и BondStudio. В сферу его компетенции входят проектирование корпоративных данных, системная интеграция и использование многоязычного многоуровневого программного обеспечения с C / C ++, Java, Perl, Python и Ruby. Он имеет степень бакалавра наук Массачусетского технологического института.Он имеет степень бакалавра наук Массачусетского технологического института.Он имеет степень бакалавра наук Массачусетского технологического института.