image

Одно из наиболее важных решений, которые принимает разработчик, заключается в том, какую базу данных использовать. В течение многих лет опции были ограничены различными вариантами реляционных баз данных, которые поддерживали язык структурированных запросов (SQL). К ним относятся MS SQL Server, Oracle, MySQL, PostgreSQL, DB2 и многие другие.

За последние 15 лет на рынке появилось много новых баз данных в рамках подхода No-SQL. К ним относятся хранилища ключей-значений, такие как Redis и Amazon DynamoDB, широкие колоночные базы, такие как Cassandra и HBase, хранилища документов, такие как MongoDB и Couchbase, а также графовые базы данных и поисковые системы, такие как Elasticsearch и Solr.

В этой статье мы попробуем разобраться в SQL и NoSQL, не влезая в их функционал.
Кроме того, мы немного повеселимся в процессе.

Объясняем бабушке SQL


Бабушка, представь, что я не единственный твой внук. Вместо этого мама и папа любили друг друга как кролики, у них было 100 детей, затем они усыновили еще 50.

Итак, ты любишь всех нас и не хочешь забыть ни одного из наших имен, дней рождений, вкусов любимого мороженого, размеров одежды, хобби, имен супругов, имен отпрысков и других супер важных фактов. Однако давай посмотрим правде в глаза. Тебе 85 лет, и старая добрая память просто не в состоянии справиться.

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

На одном листе бумаги мы составляем список под названием «Внуки». Каждый внук записан с некой существенной информацией о нем, включая уникальный номер, который теперь будет обозначать, каким внуком он является. Кроме того, ради организованности мы выписываем именованные атрибуты в верхней части списка, чтобы мы всегда знали, какую информацию этот список содержит.
id name birthday last visit clothing size favorite ice-cream adopted
1 Jimmy 09-22-1992 09-01-2019 L Mint chocolate false
2 Jessica 07-21-1992 02-22-2018 M Rocky road true
…продолжаем список!
Cписок внуков

Через некоторое время ты во всем разбираешься и мы почти закончили со списком! Однако ты поворачиваешься ко мне и говоришь: «Мы забыли добавить место для супругов, хобби, внуков!» Но нет, мы не забыли! Это следует дальше и требует нового листа бумаги.

Так что я вытаскиваю еще один лист бумаги, и на нем мы называем список Супруги. Мы снова добавляем атрибуты, которые нам важны, в начало списка и начинаем добавлять в строках.
id grandchild_id name birthday
1 2 John 06-01-1988
2 9 Fernanda 03-05-1985
…больше супругов!
Список супругов

На этом этапе я объясняю бабушке, что если она хочет знать, кто с кем состоит в браке, то ей нужно только сопоставить id в списке внуков с grandchild_id в списке супругов.

После пары десятков печений мне нужно вздремнуть. «Можешь продолжить, бабуля?» Я ухожу, чтобы вздремнуть.

Я возвращаюсь через несколько часов. А ты крута, бабуля! Все выглядит отлично, за исключением списка хобби. В списке около 1000 хобби. Большинство из них повторяются; что случилось?
grandchild_id hobby
1 biking
4 biking
3 biking
7 running
11 biking
…продолжаем!

Извини, совсем забыл сказать! Используя один список, можно отслеживать только хобби. Затем в другом списке нам нужно отследить внуков, которые занимаются этим хобби. Мы собираемся назвать это «Общий список». Видя, что тебе это не нравится, я начинаю переживать и возвращаюсь в режим списка.
id hobby
1 biking
2 running
3 swimming
…больше хобби!
Список хобби

Как только у нас есть наш список хобби, мы создаем наш второй список и называем его «Увлечения внуков».
grandchild_id hobby_id
4 1
3 1
7 2
…больше!
Общий список внуки хобби

После всей этой работы у бабушки теперь есть крутая система запоминания для слежки за всей ее удивительно большой семьей. А потом — чтобы задержать меня подольше — она задает волшебный вопрос: «Где ты научился все это делать?»

Реляционные базы данных


Реляционная база данных — это набор формально описанных таблиц (в нашем примере это листы), из которых можно получить доступ к данным или собрать их различными способами без необходимости реорганизации таблиц базы данных. Существует много разных типов реляционных баз данных, но к сожалению список на листе бумаги не является одной из них.

Отличительная черта наиболее популярных реляционных баз данных — язык запросов SQL (Structured Query Language). Благодаря нему, если бабушка перенесет свою систему запоминания в компьютер, она сможет быстро получить ответ на такие вопросы, как: «Кто не посещал меня в прошлом году, женат и не имеет никаких увлечений?»

Одна из наиболее популярных систем управления базами данных SQL это MySQL с открытым исходным кодом. Она реализована в первую очередь как система управления реляционными базами данных (RDBMS) для программных приложений на базе веб-технологий.

Некоторые ключевые особенности MySQL:

  • Она довольно известна, широко используется и тщательно протестирована.
  • Есть много квалифицированных разработчиков, имеющих опыт работы с SQL и реляционными базами данных.
  • Данные хранятся в различных таблицах, что позволяет легко устанавливать связь с использованием первичных и внешних ключей (идентификаторов).
  • Он прост в использовании и эффективен, что делает его идеальным для больших и малых предприятий.
  • Исходный код находится на условиях GNU General Public License.

Теперь забудь ВСЕ.

Объясняем бабушке NoSQL


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

К счастью, я, не желая, чтобы ты забыла мой день рождения и любимый вкус мороженого, могу помочь. Поэтому я бегу в ближайший магазин, беру тетрадь и возвращаюсь к тебе домой.

Первый шаг, который я делаю, это пишу «Внуки» большими жирными буквами на обложке тетради. Затем я перелистываю на первую страницу и начинаю писать все, что ты должна помнить обо мне. Через несколько минут страница выглядит примерно так.

{ 
  "_id":"dkdigiye82gd87gd99dg87gd",
  "name":"Cody",
  "birthday":"09-12-2006",
  "last_visit":"09-02-2019",
  "clothing_size":"XL",
  "favorite_ice_cream":"Fudge caramel",
  "adopted":false,
  "hobbies":[ 
     "video games",
     "computers",
     "cooking"
  ],
  "spouse":null,
  "kids":[ 

  ],
  "favorite_picture":"file://scrapbook-103/christmas-2010.jpg",
  "misc_notes":"Prefers ice-cream cake on birthday instead of chocolate cake!"
}

Я: “Кажется все готово!”
Бабушка: “Подожди, а как же остальные внуки?”
Я: “Да, точно. Тогда выделяем по странице на каждого.”
Бабушка: “А мне нужно будет записывать всю ту же самую информация для всех, как я делала для тебя?”
Я: “Нет, только если ты хочешь. Давай покажу.”
Забрав у бабушки ручку, я перелистываю страницу и быстро записываю информацию о моем самом нелюбимом двоюродном брате.

{ 
  "_id":"dh97dhs9b39397ss001",
  "name":"Tanner",
  "birthday":"09-12-2008",
  "clothing_size":"S",
  "friend_count":0,
  "favorite_picture":null,
  "remember":"Born on same day as Cody but not as important"
}

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

Когда все уже сделано, она задает волшебный вопрос: «Где ты научился все это делать?»

Базы данных NoSQL


Существует множество баз данных NoSQL (“не только SQL”). В наших примерах мы показали базу данных документов. Базы данных NoSQL моделируют данные способами, исключающими табличные отношения, используемые в реляционных базах данных. Эти базы данных стали популярными в начале 2000-х годов среди компаний, которым требовалась облачная кластеризация баз данных из-за их явных требований к масштабированию (например, Facebook). В таких приложениях согласованность данных была намного менее важной, чем производительность и масштабируемость.

В начале базы данных NoSQL часто использовались для нишевых задач управления данными. В основном, когда дело доходило до веб и облачных приложений, базы данных NoSQL обрабатывали и распределяли значительные объемы данных. Инженерам, работающим с NoSQL, также понравилась гибкая схема данных (или ее полное отсутствие), так что были возможны быстрые изменения в обновляемых приложениях.

Ключевые особенности NoSQL:

  • Очень гибкий способ хранения данных
  • Горизонтальное масштабирование до кластеров
  • Возможная последовательность на постоянство / распространение
  • Документы, которые идентифицируются с использованием уникальных ключей

Детальное сравнение


MySQL требует определенной и структурированной схемы.
NoSQL позволяет сохранять любые данные в «документе».

MySQL поддерживает огромное сообщество.
У NoSQL есть небольшое и быстро растущее сообщество.

NoSQL отличается простотой масштабирования.
MySQL нуждается в большей управляемости.

MySQL использует SQL, который применяется во множестве типов баз данных.
NoSQL — это база данных на основе дизайна с популярными реализациями.

MySQL использует стандартный язык запросов (SQL).
NoSQL не использует стандартный язык запросов.

MySQL имеет много отличных инструментов отчетности.
В NoSQL есть несколько инструментов отчетности, которые сложно стандартизировать.

MySQL может выдать проблемы с производительностью для больших данных.
NoSQL обеспечивает отличную производительность на больших данных.

Мысли 8base


В компании 8base, в которой я работаю, мы обеспечиваем рабочую область каждого проекта реляционной базой данных Aurora MySQL, которая размещается на AWS. Хотя NoSQL является логичным выбором, когда требования вашего приложения требуют высокой производительности и масштабируемости, мы считаем, что строгая согласованность данных, обеспечиваемая СУБД, необходима при создании SaaS-приложений и другого программного обеспечения для бизнеса.

Для стартапов и разработчиков, создающих такие бизнес-приложения, которые нуждаются в отчетности, целостности транзакций и четко определенных моделях данных, вкладываться в работу с реляционными базами данных — это, по нашему мнению, правильный выбор.

Узнайте больше о разработке с Aurora, Serverless и GraphQL с помощью 8base.com здесь.

Комментарии (11)


  1. stranger_shaman
    13.09.2019 12:29

    NoSQL позволяет сохранять любые данные в «документе»

    Cassandra, ClickHouse тоже NoSQL. Но документов там нет, а таблицы есть.


    1. ilnuribat
      13.09.2019 19:03

      можно ещё дописать наличие/отсутствие транзакций, согласованность данных


      1. ilyalazarev Автор
        13.09.2019 19:04

        тоже заметил, что в статье не хватает


  1. nitrosbase
    13.09.2019 14:24
    +1

    а также графические базы данных и поисковые системы, такие как Elasticsearch и Solr.

    Довольно странно их объединять, что автор, по-видимому, делает, не приводя примеров графовых СУБД. Если бы меня попросили привести ровно два примера графовых СУБД, указал бы на Neo4j и AWS Neptune (спросите почему).


    Ну и, конечно, «графовые», а не «графические». Google Translate переводит «graph databases» корректно, а вот Яндекс.Переводчик — нет.


    1. Viceroyalty
      13.09.2019 17:51

      Собственно спрашиваю: почему Neo4j и AWS Neptune?
      Просто чувствую, что в моем проекте (десктопное ПО, возможно в будующем смасштабируется до Team версии), скоро понадобится какая-то база данных


      1. nitrosbase
        14.09.2019 01:37

        Ну, указать — не то же самое, что рекомендовать…


        Neo4j я указал бы по той причине, что самая популярная. Дальше для полноты картины хочется указать что-то с поддержкой Gremlin в противоположность Cypher; что-то с поддержкой модели RDF наряду или в противоположность поддержке LPG; что-то облачное в противоположность on-premise. А позиция всего одна осталась. Но вот Neptune позволяет проиллюстрировать все эти «альтернативы» одним примером.


        Если облачность читателю заведомо неинтересна, можно указать AnzoGraph. Он правда, скорее OLAP-решение (кстати, вот еще одна «координата»), создан выходцами из IBM Netezza и Amazon Redshift, но это современный такой OLAP, ближе к HTAP даже.


        Короче говоря, выбор обусловлен сугубо дидактическими соображениями. Из этих же соображений не стал бы указывать CosmosDB, OrientDB, ArangoDB, которые следуют сразу за Neo4j на DB-engines. «На самом деле» они документные, как пишу об этом здесь.


        Если же пытаться рекомендовать…


        • В плане производительности Neo4j обычно «сакральная жертва» во всех бенчмарках. Но раз у вас не что-то «высоконагруженное», может, и хватит. Кстати, совсем «встраиваемое» не рассматриваю, раз вы все-таки хотите team-версию.

        • Разные enterprise-характеристики (та же горизонтальная масштабируемость) вам тоже, видимо, не очень нужны будут, да? Тогда круг кандидатов расширится. Если требуется с возможностью бесплатного использования в коммерческом продукте или опенсорсное, естественно, сузится.


        • Мультимодельность и развитые API (language integrated queries и пр.) в перспективе сокращают время разработки. «В перспективе» — это чаще в «следующем проекте», конечно, но как знать, может, успеется и в текущем. Так что ArangoDB и OrientDB я бы вернул в список кандидатов.



        Тут интереснее ваша задача. Я-то, конечно, не удивлен, нынче повсюду «connected datа» и пр., но все же интересно узнать больше конкретики о вашем проекте, требующем использования графовой СУБД. Разумеется, эта конкретика важна и при выборе СУБД. Можно в личку.


        Ну и вариант написать собственную СУБД, оптимизированную под задачи, быстродейстующую и с низкоуровневым доступом тоже никто не отменял, он даже все более популярным становится.


    1. ilyalazarev Автор
      13.09.2019 19:04

      поправил


  1. nikolau
    13.09.2019 19:01

    NoSQL позволяет сохранять любые данные в «документе»

    В последних версиях MySQL есть тип данных JSON, там же можно также сохранять любые поля с данными и есть поиск по ним.


    1. ilyalazarev Автор
      13.09.2019 19:20

      Теперь да


    1. mgramin
      14.09.2019 11:48

      А PG это умеет уже лет 10


  1. D01
    14.09.2019 22:46
    +1

    Странная реляционная база… Просто у ребенка должны быть два идентификатора родителей (ну или еще одна таблица связей, с типом родителя, например отец один, а живут с другим… и это я еще молчу про просто таблицу людей, с типом, а не разные таблицы на родителей и детей))), а в текущей реализации получается что в одно поле надо набивать кучу ИД, если у родителя больше одного ребенка.
    В общем на мой взгляд странное решение (или я что-то не так понял)