Статьи

После 50 лет SQL, можете ли вы представить себе действительно NoSQL подход?

Сентябрь 1, 2017

Представьте, что вы можете использовать объектно-цепочечные операторы и операции без несоответствия между СУБД и ООП ; представьте слабую связь между СУБД и API; подумайте о клиенте базы данных API, который больше похож на мост для извлечения или передачи данных. Можете ли вы представить себе действительно API базы данных NoSQL?

Вступление

За десятилетие исследований систем NoSQL я заметил огромные усилия многих поставщиков по созданию SQL-совместимых API. Да, за этой тенденцией к отраслевой линии есть довольно веская причина. Все научились программировать на SQL, и все знают, как получить доступ к СУБД с помощью SQL.

Что ж, я думаю, что после пятидесяти лет работы СУБД на основе SQL должен быть лучший подход, чтобы завоевать признание программиста, но, похоже, никому не удалось достичь такой масштабной цели. Никто не осмеливается предложить что-то другое для лучшего решения, и даже те немногие, кто пробовал что-то другое (на ум приходят язык Apache Tinkpop-Gremlin ,  GraphQL и Cypher ), не смогли убедить большинство ИТ-пользователей перейти подключается к предлагаемой среде запросов. Другие были более радикальны в своем подходе и даже вообразили подключенную семантическую сеть, но когда они разработали свой язык запросов, SPARQL , он выглядел очень похожим на SQL, и даже его аббревиатура напоминает нам SQL.

Я могу начать писать много причин, почему все эти подходы не достигли консенсуса для большинства ИТ-пользователей. Я мог бы также привести ряд фактов о том, почему отрасль и несколько консорциумов продолжают использовать SQL в качестве своего любимого языка запросов к СУБД. Но в этой статье я хотел бы, чтобы вы сфокусировались на очень конкретном моменте, и, возможно, я смогу поделиться своим воображением о том, как можно по-разному получить доступ к СУБД; с большей гибкостью, чем SQL; без потери комфорта вашего языка программирования или препятствий в SQL; и самое главное, зарабатывая при этом интерес и уважение разработчиков.

Вам также могут понравиться: NoSQL против SQL: объяснения различий

Два подхода к парадигме программирования для API-интерфейса NoSQL

Что такое SQL? Это предметно-ориентированный язык, разработанный специально для управления данными в реляционной СУБД, хотя многие сторонники реляционной теории правильно утверждают, что эти СУБД не следуют реляционным принципам Кодда. Но это еще одна важная история, которую нужно рассказать в другой раз.

Недавно, в последнее десятилетие, графовые базы данных стали очень популярными, но, что интересно, многие крупные поставщики расширили язык SQL, чтобы охватить обход графов и другие связанные операции. Столбчатые базы данных, другой очень успешный тип NoSQL, также следовали той же тактике в отношении языка запросов. Поэтому, хотя модель данных и реализация на физическом уровне могут сильно различаться, SQL пытается создать искусственное единство.

Но опять же, SQL зависит от предметной области, запускается как модель данных и остается декларативным языком запросов. Главный вопрос — что происходит на стороне API, то есть на стороне языка программирования, и именно здесь происходят все интересные, специфические вещи. Как именно вы подключаетесь к серверу СУБД и какой драйвер СУБД используется для передачи данных? Насколько хорошо объекты соответствуют объектам и атрибутам в вашей СУБД, изменениям схемы и объектной модели, обнуляемой и частичной загрузке полей-атрибутов, персистентности, состояния, параллелизма и кэширования объектов? Для поклонников ООП и других, то, что я кратко описал, известно как проблема несоответствия объектно-реляционного импеданса , Вьетнам компьютерных наук . И не заблуждайтесь: это все еще «Вьетнам».

Цепные операторы и операнды

ООП, пожалуй, самая популярная парадигма программирования. все же из-за магического заклинания SQL все должно было быть сжато в табличной форме, используя один ORM или другой. Но за все эти годы моих личных исследований и разработок я заметил одну особенность этих API-интерфейсов ORM, которая связана с используемым подходом поиска данных. Здесь есть три основные тенденции: Query-By-Example (QBE) — предшественник GraphQL, Query-By-API (QBA) — предшественник Gremlin и Query-By-Language (QBL), где классифицируются все языки запросов, подобные SQL. , GQLне исключение Практический опыт разработчиков показал, что некоторые сложные запросы, особенно с объединениями, было труднее представить в QBA и QBE, и еще раз SQL снова выиграл эту битву. Но неудивительно, что сторонники технологии графовых баз данных лишь частично коснулись несоответствия объектно-реляционного импеданса. Это требует более глубокого архитектурного проектирования и многоперспективного подхода, чем только сравнение того, насколько хорошо узлы графа соответствуют объектам класса.

Итак, это было честное сражение между QBA и QBL? Ответ отрицательный из-за существующего доминирования SQL в СУБД и имитации операций объединения SQL. Вот где воображение входит в игру. Представьте себе, что вы можете использовать операции с цепочками объектов, используя метод проектирования интерфейса , или QBA, без несоответствия между СУБД и ООП, то есть представьте слабую связь между СУБД и API, представьте, что клиент базы данных API больше похож на мост для выборки или передавать данные. Метод объединения операторов запросов действительно многообещающий, он может выиграть второй раунд бокса с SQL. Я кратко объясню почему.

ООП основан на концепции объектов, которые могут обмениваться сообщениями и изменять их внутреннее состояние. Поэтому такой свободный интерфейс очень естественен для языков ООП. С другой стороны, самые сложные запросы можно визуализировать и обрабатывать как конвейер данных. Мой вопрос к тем, кто разрабатывает GQL , следующий международный стандарт языка запросов, почему вы продолжаете придерживаться тупикового декларативного подхода? Разве не было бы более естественным и привлекательным для пользователей следовать методологии конвейера данных путем стандартизации операндов и операций? Существует множество веских доказательств того, что это не предположение. Вспомните приведенную выше ссылку на TinkerPop-Gremlin, а в Python есть очень популярная библиотека анализа данных Pandas (23621 запускается на GitHub).

Функциональные операции

Говоря о языках программирования, какова другая очень конкурентоспособная парадигма в разработке программного обеспечения? Возможно, это функциональный, но функциональные требования для такого API более неясны. Но такой API существует на одном из самых мощных функциональных языков программирования в ИТ-индустрии, Mathematica. Посмотрите, как тщательно они разработали функции языка Wolfram для операций с базами данных над наборами данных и вычислений со структурированными наборами данных, и насколько они идеально подходят для многих других функций того же языка.

Взгляд из будущего

Достаточно сказано; разработка программного обеспечения — не теоретическая вещь, она основана на практике. Я приведу вам пример. Одним из недостатков SQL является то, что у вас нет прямого доступа к управлению информацией из словаря данных, так как СУБД обрабатывает это более или менее автоматически. Gartner недавно сообщила, что инструменты качества данных и интеграции данных включают каталоги данных. Это, безусловно, шаг в правильном направлении, и вам необходим API запросов, способный управлять как данными, так и метаданными, используя единый подход.

Рассмотрим следующий фрагмент кода в Python:

Первая команда демонстрирует выборку метаданных с использованием цепных методов Python ООП:


питон