За последние 40 с лишним лет традиционные реляционные базы данных, такие как DB2, Oracle, SQL Server, Postgres, MySQL и многие другие, оказались фундаментом, на котором были построены приложения на сотни миллиардов долларов. Приложения, которые взаимодействуют с серверными базами данных через SQL, широко распространены во всех отраслях. Если все приложения, использующие SQL, исчезнут в одночасье, наш мир погрузится в абсолютный хаос. Среди неисчислимого количества эффектов: вы не сможете получить доступ или потратить деньги в своем банке, ваши медицинские записи будут недоступны, товары не смогут быть доставлены или отправлены и т. Д. Во многих отношениях современная жизнь была бы неузнаваемой без Приложения на базе SQL.
Расцвет баз данных NoSQL
В начале 2000-х годов количество генерируемых и хранимых данных, скорость их поступления в базу данных и разнообразие типов данных начали стремительно расти. Первоначально это было обусловлено данными о потоках посещений, генерируемыми веб-приложениями, но сегодня многие другие источники данных, такие как Интернет вещей, создают аналогичные проблемы. Традиционные базы данных, где SQL был основным интерфейсом, испытывали трудности в этой новой среде. Подавляющее большинство не имело практического способа горизонтального масштабирования, а жесткая типизация делала их плохо приспособленными для хранения полностью неструктурированных данных.
В ответ на эти вызовы были созданы новые подходы, в основном на основе исследований середины 2000-х годов, проведенных несколькими интернет-компаниями (например, Google, Amazon и Yahoo), которые были перегружены собираемыми данными.
Одна примечательная категория, которая в значительной степени опирается на это исследование, - это базы данных NoSQL, такие как HBase, Cassandra, Dynamo и MongoDB. Эти системы были созданы для работы с огромными объемами данных за счет горизонтально масштабируемых архитектур, которые могут работать с полуструктурированными или неструктурированными данными.
Был ли отказ от SQL ошибкой?
Почему изначально проекты и поставщики NoSQL отказались от SQL? Основными аргументами были: 1) предварительная схема делает ваш бизнес менее гибким при работе с полуструктурированными и неструктурированными данными и 2) SQL работает медленно и его выразительность не требуется.
Во-первых, несомненно, что хороший дизайн схемы сложен и требует от вас понимания данных заранее. Когда типы данных меняются быстро, отсутствие привязки к схеме кажется разумным и привлекательным.
Проблема в том, что любой анализ требует, чтобы вы понимали структуру ваших данных. Чтобы сделать что-нибудь полезное, необходимо применять структуру в виде определенной схемы. Применение структуры только при чтении данных, подход «схема при чтении», действительно сокращает предварительную работу по проектированию данных, но перекладывает проблему на реальных пользователей данных. Обычно это не лучший компромисс. Обычно пользователей данных намного больше, чем инженеров данных, и возложение ответственности на пользователей данных может превратить задачу, которая будет выполняться один раз заранее, в задачу, которую необходимо выполнять несколько раз ниже по цепочке. Кроме того, пользователи данных часто не имеют большого контекста, выходящего за рамки их непосредственных обязанностей, и могут неправильно идентифицировать или злоупотреблять данными. Также существует риск того, что разные пользователи данных могут по-разному интерпретировать данные, что создаст проблемы в понимании и согласовании повторяющихся и противоречивых способов использования.
Во-вторых, оказалось, что выразительность SQL была полезной. Для этого есть множество причин, которых мы коснемся в следующем разделе, но самым очевидным доказательством этого является то, что многие проекты и поставщики NoSQL реализовали языки запросов, подобные SQL. CQL Кассандры - один из примеров. В некотором смысле эти «похожие на SQL» языки запросов полезны. Они эффективно сопоставляют специфический синтаксис NoSQL с более широко понимаемым синтаксисом SQL, уменьшают нагрузку на разработчиков, связанную с «новым языком», и потенциально открывают возможность интеграции со сторонними производителями.
В остальном наличие языка запросов, который выглядит как SQL, но на самом деле не является, контрпродуктивно. Это рискует внушить разработчикам ложное чувство уверенности. Они могут переоценить реальный уровень поддержки SQL в этих языках и обнаружить существенные пробелы только после того, как проект будет успешно реализован. Что еще хуже, функциональность, подобная SQL, которая технически работает в рамках проверки концепции, может не работать в полной производственной системе из-за различий в функциональных свойствах, которые проникают из базовой базы данных NoSQL. Добавление некоторого синтаксического сахара, похожего на SQL, поверх базы данных NoSQL не заставит что-то вроде объединения таблиц «работать» в производственной среде, если базовая база данных NoSQL не была разработана или изменена с этой целью.
Отсутствие SQL в системах NoSQL само по себе не является преимуществом. При прочих равных, отказ от хорошо понятного, чрезвычайно широко распространенного языка запросов данных для языка, специфичного для NoSQL, бесполезен. С другой стороны, полный отказ от SQL или использование языка, подобного SQL, имеет ряд явных недостатков, особенно в контексте модернизации приложений.
Отказаться от SQL - опасно
За последние 40 с лишним лет компании вложили огромные средства в критически важные приложения, которые воплощают их основную компетенцию. Данные являются ядром практически всех приложений, и унаследованные базы данных были основным выбором для хранения и извлечения данных.
Острая необходимость в модернизации этих приложений часто возникает, когда данные, которые приложение хранит и обрабатывает, выросли за пределы того, что может обрабатывать лежащая в основе унаследованная база данных, чтобы сделать приложение более умным за счет использования новых источников данных, которые стали доступны с момента создания исходного приложения. развертывания, а также включить современные методы использования данных, такие как искусственный интеллект и машинное обучение.
Например, приложение планирования спроса для розничного продавца может начать включать данные о текущей погоде или местных событиях, которые могут повлиять на местный трафик, чтобы более эффективно распределять запасы. Или рассмотрите систему страховых возмещений, которая включает данные датчиков транспортного средства и изображения с камер для более интеллектуальной обработки требований.
Базы данных NoSQL часто рассматриваются в этих проектах модернизации приложений. В некотором смысле это имеет смысл. Они действительно предоставляют возможность горизонтального масштабирования для поддержки новых источников данных. Однако при замене устаревшей базы данных SQL на NoSQL вы можете значительно удлинить проект и увеличить риск.
Во-первых, отсутствие полной поддержки SQL требует перезаписи большого количества приложений. Эти приложения говорят на языке SQL. Даже когда в базе данных NoSQL присутствует значительная функциональность, использование этой функциональности требует, чтобы приложение «говорило» на настраиваемом NoSQL или несовместимом «SQL-подобном» диалекте. Кроме того, найти разработчиков с необходимым опытом значительно труднее, чем огромное количество разработчиков, уже свободно владеющих SQL. Инструменты, помогающие преобразовать существующий SQL в диалекты NoSQL, неполны или отсутствуют.
Затем часто необходимо полностью переосмыслить лежащую в основе модель данных. Например, отсутствие эффективных объединений таблиц (или, в некоторых случаях, возможность объединять данные вообще) может вызвать взрыв денормализации данных, который вызывает дублирование данных, которое тратит ресурсы оборудования и требует обширного нового кода, чтобы гарантировать, что дублированные данные остается неизменным во всех своих определениях.
Кроме того, часто бывает трудно достичь производительности, аналогичной устаревшим базам данных. Системы NoSQL обычно отлично справляются с краткосрочными операционными запросами, которые обращаются только к одной строке или нескольким строкам. Производительность аналитических запросов, которые сканируют большие объемы исторических данных, часто низка и недостаточна для удовлетворения потребностей приложения. Часто базы данных NoSQL объединяются с другой системой, более подходящей для длительных аналитических запросов, посредством реализации лямбда-архитектуры. Эти архитектуры сложны, их трудно реализовать, они открывают множество потенциальных возможностей для несогласованности данных и требуют больших затрат на текущее обслуживание.
Кроме того, многие функции базы данных и SQL, на которые опиралось приложение в устаревшей базе данных, часто недоступны и должны быть созданы с нуля вашими разработчиками или полностью исключены. Репликация некоторых функций, присутствующих в устаревших базах данных SQL в системах NoSQL, таких как модель согласованности, которая поддерживает полную поддержку ACID, требует таких специализированных навыков разработчика и таких огромных усилий, что любой проект, основанный на повторной реализации, потребует огромного количества времени. эффективно создавать разовую базу данных вместо фактической модернизации приложения.
Гораздо менее рискованный подход к модернизации приложений - заменить устаревшую базу данных масштабируемой базой данных, обеспечивающей гибкость типов данных и обеспечивающую машинное обучение и искусственный интеллект в базе данных без отказа от SQL. Существует ли такая база данных?
Можете ли вы получить преимущества NoSQL с SQL?
Сегодня на рынке присутствует ряд горизонтально масштабируемых распределенных систем SQL, таких как Snowflake, Cockroach и Google Cloud Spanner, а также компания Splice Machine, которую я основал. Я считаю, что со всем этим можно получить преимущества баз данных NoSQL, не принимая проблемы, описанные выше. Чтобы углубиться в одно из решений, Splice Machine использует систему NoSQL (HBase) в качестве основного механизма хранения, но на ее основе широкие возможности, специально разработанные для модернизации приложений OLTP SQL. Он обеспечивает:
- Исчерпывающий набор поддерживаемого синтаксиса ANSI SQL
- Хранилище строк с первичным ключом для быстрого поиска
- Эффективное хранение столбцов в таблицах, которые можно хранить как дешевое объектное хранилище, такое как S3 или ADLS.
- Полное соответствие ACID и поддержка многострочных транзакций
- Поддержка ограничений, ссылочной целостности, первичных ключей, триггеров и вторичных индексов.
- Распределенная аналитическая обработка в памяти
- Оптимизатор на основе затрат, который разрабатывает эффективные планы запросов и может выбрать выполнение этих планов непосредственно с HBase (обычно для небольших, «рабочих» запросов) или с помощью исполнителей Spark (обычно для более крупных, «аналитических» запросов).
- Поддержка настраиваемых хранимых процедур и функций
- Возможность развертывания локально или на AWS и Microsoft Azure с Kubernetes.
- Возможность хранить полуструктурированные или неструктурированные данные непосредственно в таблицах базы данных или с помощью встроенных функций Spark.
- Интегрированные возможности науки о данных с аналитикой в базе данных, интегрированные записные книжки Jupyter, управление рабочим процессом модели и возможности облачного развертывания
Подобная горизонтально масштабируемая СУБД SQL может облегчить модернизацию устаревших версий.
Во-первых, как и базы данных NoSQL, iit может горизонтально масштабироваться до чрезвычайно больших размеров данных и объемов запросов, намного превосходящих возможности устаревших баз данных. Это также обеспечивает широкую гибкость для хранения и обработки данных.
Во-вторых, это упрощает переход с поддерживающей устаревшей базы данных. SQL, написанный для устаревшей базы данных, практически не требует доработки из-за исчерпывающей поддержки SQL в Splice Machine. Базовая унаследованная модель данных часто не нуждается в модификации и, конечно же, не требует полного переосмысления, которое требуется для перехода на базу данных NoSQL. Splice Machine может обрабатывать всю рабочую нагрузку унаследованных баз данных, будь то операционная или аналитическая по своей природе, без необходимости объединять несколько специализированных систем.
Наконец, он предоставляет возможности, которые позволяют перенастроенному приложению быть «современным». Он может работать локально или на нескольких облачных платформах и абстрагироваться от базовой инфраструктуры с помощью современного «контейнерного» подхода. Это позволяет заниматься наукой о данных непосредственно в базе данных, так что новые источники данных и методы, которые делают приложения более интеллектуальными и ценными, могут применяться без хлопот по извлечению, преобразованию и загрузке данных между несколькими системами.
В итоге
Пользовательские приложения, созданные на основе устаревших баз данных, часто обеспечивают конкурентные преимущества. Вот почему компании сохраняют их индивидуальные, а не лицензионные пакетные приложения. Модернизация этих приложений часто желательна либо потому, что базовая база данных находится под нагрузкой и не может масштабироваться, либо потому, что есть желание использовать современные методы развертывания или искусственного интеллекта. Замена устаревшей базы данных, лежащей в основе этих приложений, базой данных NoSQL, которая требует полной переработки существующей модели данных и бизнес-логики, является рискованной и значительно увеличивает объем и график проекта модернизации. Масштабируемые базы данных SQL, такие как Splice Machine, обеспечивают масштабируемость и гибкость, обеспечивая при этом плавный путь миграции из устаревшей системы баз данных.
Чтобы узнать больше о том, как сделать ваши индивидуализированные приложения гибкими и наполненными интеллектом, загрузите наш технический документ по модернизации унаследованных приложений.
