Одно из наиболее важных решений, которые принимает разработчик, заключается в том, какую базу данных использовать. В течение многих лет опции были ограничены различными вариантами реляционных баз данных, которые поддерживали язык структурированных запросов (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)
nitrosbase
13.09.2019 14:24+1а также графические базы данных и поисковые системы, такие как Elasticsearch и Solr.
Довольно странно их объединять, что автор, по-видимому, делает, не приводя примеров графовых СУБД. Если бы меня попросили привести ровно два примера графовых СУБД, указал бы на Neo4j и AWS Neptune (спросите почему).
Ну и, конечно, «графовые», а не «графические». Google Translate переводит «graph databases» корректно, а вот Яндекс.Переводчик — нет.
Viceroyalty
13.09.2019 17:51Собственно спрашиваю: почему Neo4j и AWS Neptune?
Просто чувствую, что в моем проекте (десктопное ПО, возможно в будующем смасштабируется до Team версии), скоро понадобится какая-то база данных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а» и пр., но все же интересно узнать больше конкретики о вашем проекте, требующем использования графовой СУБД. Разумеется, эта конкретика важна и при выборе СУБД. Можно в личку.
Ну и вариант написать собственную СУБД, оптимизированную под задачи, быстродейстующую и с низкоуровневым доступом тоже никто не отменял, он даже все более популярным становится.
nikolau
13.09.2019 19:01NoSQL позволяет сохранять любые данные в «документе»
В последних версиях MySQL есть тип данных JSON, там же можно также сохранять любые поля с данными и есть поиск по ним.
D01
14.09.2019 22:46+1Странная реляционная база… Просто у ребенка должны быть два идентификатора родителей (ну или еще одна таблица связей, с типом родителя, например отец один, а живут с другим… и это я еще молчу про просто таблицу людей, с типом, а не разные таблицы на родителей и детей))), а в текущей реализации получается что в одно поле надо набивать кучу ИД, если у родителя больше одного ребенка.
В общем на мой взгляд странное решение (или я что-то не так понял)
stranger_shaman
Cassandra, ClickHouse тоже NoSQL. Но документов там нет, а таблицы есть.
ilnuribat
можно ещё дописать наличие/отсутствие транзакций, согласованность данных
ilyalazarev Автор
тоже заметил, что в статье не хватает