
Одно из наиболее важных решений, которые принимает разработчик, заключается в том, какую базу данных использовать. В течение многих лет опции были ограничены различными вариантами реляционных баз данных, которые поддерживали язык структурированных запросов (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 | L | Mint chocolate | false | ||
| 2 | Jessica |  |  | M | Rocky road | true | 
| …продолжаем список! | 
Через некоторое время ты во всем разбираешься и мы почти закончили со списком! Однако ты поворачиваешься ко мне и говоришь: «Мы забыли добавить место для супругов, хобби, внуков!» Но нет, мы не забыли! Это следует дальше и требует нового листа бумаги.
Так что я вытаскиваю еще один лист бумаги, и на нем мы называем список Супруги. Мы снова добавляем атрибуты, которые нам важны, в начало списка и начинаем добавлять в строках.
| id | grandchild_id | name | birthday | 
| 1 | 2 | John | |
| 2 | 9 | Fernanda |  | 
| …больше супругов! | 
На этом этапе я объясняю бабушке, что если она хочет знать, кто с кем состоит в браке, то ей нужно только сопоставить 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)
 - nitrosbase13.09.2019 14:24+1- а также графические базы данных и поисковые системы, такие как Elasticsearch и Solr. - Довольно странно их объединять, что автор, по-видимому, делает, не приводя примеров графовых СУБД. Если бы меня попросили привести ровно два примера графовых СУБД, указал бы на Neo4j и AWS Neptune (спросите почему). 
 - Ну и, конечно, «графовые», а не «графические». Google Translate переводит «graph databases» корректно, а вот Яндекс.Переводчик — нет.  - Viceroyalty13.09.2019 17:51- Собственно спрашиваю: почему Neo4j и AWS Neptune? 
 Просто чувствую, что в моем проекте (десктопное ПО, возможно в будующем смасштабируется до Team версии), скоро понадобится какая-то база данных - nitrosbase14.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а» и пр., но все же интересно узнать больше конкретики о вашем проекте, требующем использования графовой СУБД. Разумеется, эта конкретика важна и при выборе СУБД. Можно в личку. 
 - Ну и вариант написать собственную СУБД, оптимизированную под задачи, быстродейстующую и с низкоуровневым доступом тоже никто не отменял, он даже все более популярным становится. 
 
 
 - nikolau13.09.2019 19:01- NoSQL позволяет сохранять любые данные в «документе» 
 В последних версиях MySQL есть тип данных JSON, там же можно также сохранять любые поля с данными и есть поиск по ним.
 - D0114.09.2019 22:46+1- Странная реляционная база… Просто у ребенка должны быть два идентификатора родителей (ну или еще одна таблица связей, с типом родителя, например отец один, а живут с другим… и это я еще молчу про просто таблицу людей, с типом, а не разные таблицы на родителей и детей))), а в текущей реализации получается что в одно поле надо набивать кучу ИД, если у родителя больше одного ребенка. 
 В общем на мой взгляд странное решение (или я что-то не так понял)
 
           
 

stranger_shaman
Cassandra, ClickHouse тоже NoSQL. Но документов там нет, а таблицы есть.
ilnuribat
можно ещё дописать наличие/отсутствие транзакций, согласованность данных
ilyalazarev Автор
тоже заметил, что в статье не хватает