Предисловие

Вдохновение и теоретическая поддержка исходят от «NoSQL Essence».

Введение в «Сущность NoSQL»

Книгу «Сущность NoSQL» написал Мартин, известный эксперт по разработке программного обеспечения. Автор: Фаулер,Его наиболее известные работы включают «Рефакторинг: улучшение дизайна существующего кода» и «Сущность UML». В первой половине книги подробно описывается история возникновения библиотеки NoSQL и принципы ее проектирования.,и предоставляет обзор различных типов библиотек данных NoSQL. Во второй половине подробно рассматриваются основные методы работы различных библиотек данных NoSQL.,и как реализовать включитьпоследовательность、делаиметь дело с、Доступность、QueryFunctionи Масштабируемостьключевые функции включены。Эта книга подойдет в качестве вводного пособия по научно-популярной тематике.,Это помогает читателям сформировать предварительное мнение о выборе типа библиотеки данных.

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

1. Природа предметов – в памяти

В чем суть объекта, например класса POJO в Java?

Можно ли рассматривать его экземпляр как карту с фиксированным значением ключа?

public class Order {
    private int orderId;
    private String orderName;
}
Order order = new Order();
order.setOrdreId(1);
order.setOrderName("Заказ А");

Так что мы могли бы также быть смелыми. Если значение ключа не фиксировано и количество ключей не фиксировано, что станет парой «ключ-значение» в чистом виде?

Map<String, Object> orde = new HashMap<>();
order.put("orderId", 1);
order.put("orderName", «Заказ А»);

Наиболее подходящим текстовым описанием пары ключ-значение памяти является файл json.

{
    "orderId": 1,
    "orderName": «Заказ А»
}

Итак, можем ли мы напрямую использовать json для представления экземпляров объектов. Ответ — да. Именно так реализована база данных документов в базе данных NoSQL.

Нет необходимости заранее изменять определение структуры, вы можете свободно добавлять поля и обрабатывать нестандартные данные.

2. Природа объектов – в реляционных базах данных

Расстройка импеданса

Пример, приведенный в книге «Природа объектов в памяти», показывает, что, когда значения объектов имеют все базовые типы, объекты памяти ведут себя лаконично и элегантно.

Но в объекте есть вложенная связь,Его производительность не кажется подходящей,Эта разница называется Расстройка импеданса.

ORMобъект — платформа реляционного сопоставления,Например, знаменитые Hibernate и Mybatis.,Частично может решить проблему Расстройки импеданса.,Но в сценариях, чувствительных ко времени отклика,Если слишком сильно полагаться на производительность запросов ORM, это снизит.

3. База данных NoSQL

Технический опыт

Проблемы, вызванные миграцией кластера

По мере перехода крупных предприятий на кластеры возникает новая проблема. Реляционные базы данных не предназначены для использования в кластерах.

Даже реляционные базы данных, подходящие для кластеров, такие как Oracle RAC или SQL Server, которые поддерживают кластеры, для работы полагаются на концепцию, называемую «подсистемой общего диска». По сути, две базы данных можно рассматривать как одну автономную реляционную базу данных, развернутую на ней. большой диск.

Библиотека данных NoSQL изначально поддерживает распределенные преимущества

NoSql(Кромеграфовая база Помимо данных), он естественно поддерживает распространение. И я《в Тот же пример, упомянутый в «Сущности объектов памяти»,

Нет необходимости заранее изменять определение структуры, вы можете свободно добавлять поля и обрабатывать нестандартные данные.

контраст

Диаграммы E-R и традиционные реляционные базы данных имеют структуры хранения, больше похожие на реляционные таблицы.

Структура хранения nosql больше похожа на фактическое состояние модели памяти.

Преимущества

Можно сказать, что все они созданы с учетом недостатков реляционных баз данных в эпоху распределенности.

1. Гибкая модель данных：Как указано вышеобъектсуть,Структура библиотеки данных NoSQL очень гибкая.,Может адаптироваться к быстро меняющимся потребностям бизнеса и постоянно меняющейся структуре данных.
2. Высокая масштабируемость：NoSQLданныеобъединение библиотекданные Принять распределенную архитектуруи Горизонтально масштабируемая конструкция может удовлетворить потребности быстрого роста бизнеса.。
3. высокая производительность：NoSQLданные Библиотеки обычно используют памятьи Технология индексирования,И параллельные вычисления и технологии распределенных вычислений.,Обеспечивает хранение данных и возможности выполнения запросов для обеспечения высокой производительности. Выполнение операций чтения и записи данныхчас,Библиотека данных NoSQL отвечает быстро,Обеспечьте доступ к данным с низкой задержкой.
4. Высокая доступность и отказоустойчивость：многоNoSQLСистема использует резервированиекопироватьи Автоматический механизм аварийного переключения,Убедитесь, что услуги могут поддерживаться на высоком уровне, даже если некоторые узлы выходят из строя.Доступностьиданныебезопасность。Это делаетNoSQLданные Библиотекасуществоватьиметь дело скрупный масштабданныеиключевой бизнесчас Имеют более высокую надежностьистабильность。
5. Обработка больших данных в режиме реального времени：в большомданные В приложении,Библиотека данных NoSQL пользуется популярностью из-за ее эффективных возможностей пакетной обработки и потоковой передачи. Они способны быстро обрабатывать и извлекать большие объемы документов.,Удовлетворение потребностей фактического анализа и обработки.

Недостатки

Поскольку компания NoSQL решила разработать именно слабые места реляционных баз данных, она не показала таких хороших результатов в исходном положении реляционных баз данных. Однако реляционные базы данных и базы данных nosql не являются антагонистическими. Мы можем выбрать подходящую технологию в соответствующем бизнес-сценарии и даже объединить их для гибридного хранилища.

1. Сильная последовательность и транзакции：NoSQLданные Библиотеки обычно используют финальную версиюпоследовательность Модель,Это означает, что могут быть задержки в синхронизации данных между разными узлами.,Это приводит к несоответствию данных. В некоторых сценариях, требующих более высокой согласованности данных,Например, финансовая система или система обработки дел.,Библиотека данных NoSQL может быть неприменима.
2. отсутствие стандартизации：NoSQLданные Широкий выбор библиотек,Каждый использует свою модель данных и язык запросов.,Отсутствие единой стандартизации. Это создает дополнительные затраты на обучение при использовании и управлении библиотеками NoSQL.,И увеличивает сложность системы и затраты на обслуживание. То же, что и час,потому чтоотсутствие стандартизация, миграция данных и интеграция между библиотеками данных NoSQL также могут столкнуться с трудностями.

Классификация баз данных NoSQL и применимые сценарии

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

Ориентирован на агрегирование

Это упомянутая категория баз данных NoSQL, которые по своей сути поддерживают распределенные

Агрегация — это концепция в «[[DDD Domain-Driven Design]]». Это означает работу с группой взаимосвязанных объектов как с единым целым. Этот блок называется агрегацией. Например, если вы размещаете заказ электронной коммерции через корзину покупок, он содержит основной заказ (корзина покупок), список подзаказов (каждый продукт), заказ транзакции, подзаказ транзакции, складской заказ, логистический заказ и т. д. . Все операции по подпозициям основного заказа мы выполним оперируя основным заказом. В NoSQL агрегат используется как наименьшая единица для поддержания атомарности.

Сценарии, в которых NoSQL неприменим

1. Требуйте строгой последовательности

2. Требует обработки транзакций в реальном времени, например торговых сценариев.

база данных К-В

Представитель — старый знакомый redis, который широко используется для кэширования, хранения файлов cookie и чтения конфигурации.

Хранилище K-V не предоставляет сложных функций запросов, таких как операции JOIN, запросы диапазона, полнотекстовый поиск и т. д.

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

KVданныебиблиотекаНеприменимые сценарии запроса: Объект очень большой, и каждый раз для расчета необходимо брать только часть значения. Данные необходимо искать на основе нескольких полей, а не одного значения K. Потому что каждый раз v вынимается полностью.

база данных документов

Представители: ElasticSearch, MongoDB.

Применимые сценарии

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

Поле запроса, полнотекстовый поиск, получение журнала.

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

Вы можете выполнить простое отслеживание полных ссылок на основе журналов.

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

Не подходит для быстрых запросов с частыми небольшими объемами данных.часто обновляетсяданные,Необходимо переиндексировать из-за обновления ElasticSearch в данныхчас.,Поэтому в сценариях, где требуются частые обновления,Использование ElasticSearch может привести к снижению производительности.

База данных столбцов

Представитель Clickhouse byte, который использует Tencent.

Он подходит для хранилищ данных, анализа данных, крупномасштабного чтения, мелкомасштабного обновления и сценариев запросов.

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

Он не подходит для сценариев с высокой степенью параллелизма и частой записью, изменением и удалением.

OLAP и традиционный контраст OLTP

OLTP

Традиционную OLTP (обработку транзакций в режиме онлайн) можно понимать как MySql в узком смысле. Он имеет характеристики ACID (атомарность, согласованность, изоляция, долговечность).

фокус

Фокус заключается в практической обработке информации и быстром реагировании.

Сценарии использования

Например, онлайн-сервисы банков подчеркивают точность, низкую задержку и высокий уровень параллелизма.

OLAP

OLAP можно понимать в узком смысле как кликхаус.

фокус

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

Сценарии использования

Система хранилища данных.

Комплексная сцена

ERP (планирование ресурсов предприятия) функционально связано с обоими.

Выберите OLTP для обработки данныхERPСистемные потребностииметь дело с Многоизповседневные деладанные,Включая обработку заказов, управление запасами, финансовый учет и т. д. Эти процессы обычно носят деловой характер.,Нужен немедленный ответ и точность,Следовательно, система ERP должна поддерживать функцию OLTP (онлайн-обработка).

Принятие решений и анализ данных с использованием OLAPОднако,В дополнение к ежедневной деловой обработке,ERP-система также должна поддерживать принятие управленческих решений и данные анализы. Это,Технология OLAP (онлайн-аналитическая обработка) особенно важна. Технология OLAP может выполнять многомерный анализ и запросы к данным в системе ERP.,Включая данные о продажах, количестве продаж, типе продукта, регионе, пространстве и других измерениях. Помогите корпоративному руководству понять условия ведения бизнеса,Используйте информацию о тенденциях продаж, чтобы улучшать продукты, определять самые продаваемые продукты и заранее запасаться ими, а также обнаруживать региональные различия.,Внедрять дифференцированные стратегии ценообразования и продвижения и т. д.,Это обеспечивает поддержку принятия решений.

краткое содержание

OLAP обрабатывает данные, а OLTP анализирует данные.

неагрегированный

графовая база данных

Это оптимальное решение для разделенных территорий.

Применимые рисунки: социальная сеть,Предпочтения продукта,Персональные рекомендации.

Не подходит для развертывания кластера. Все сцены, кроме «Примененные сценарии».

Представитель Neo4J

Упомянутая ранее библиотека данных NoSql предназначена для решения проблемы библиотеки реляционных данных «Расстройка». импеданса, предназначенный для сложного расширения. графовая база данныхэто решить Реляционная библиотека данных Еще один недостаток конструкции——объектсложные отношения между。Например, запись такая, как показано на рисунке3.1Группа записей с относительно сложной взаимосвязью.。Характерной особенностью является то, что узлы очень простые.,Но структура узлов очень богата. Например, вы можете запросить,Найдите книги о библиотеках данных,Автор наверняка понравится кому-то из моих друзей.

Neo4J может прикреплять объекты Java в качестве атрибутов к узлам и ребрам бессхемным способом; Infinite Graph может хранить объекты Java как объекты подклассов своих встроенных типов и хранить их как узлы и ребра.

После построения структуры графа с узлами и ребрами,,Просто используй этоВыполните поиск в Интернете графической базы данных по запросу, специально предназначенному для «изображений».Понятно。Этографовая база данныхи Реляционная библиотека данныхважные различия。Хотя реляционные данные Библиотеки также могут реализовывать такие отношения через внешние ключи, но операторы JOIN, необходимые для навигации по различным отношениям, отнимают очень много времени. час。потому чтографовая база данные потратят больше времени на вставку данных отношений, чтобы сократить время, необходимое для прохождения часов отношений. Подходит для сценариев с частыми запросами и небольшим количеством вставок.

4. Две основные модели внедрения баз данных в отрасли.

Интегрированная база данных

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

Ценаданныедизайн библиотеки приноситбольше сложности,Больше проблем с параллелизмом,а такжеданные Библиотекапроблема одной точки——Проблемы с производительностью затрагивают все приложения.,Сбой «убьет» все приложения.

Даже если все вышеперечисленные проблемы будут решены,Если приложение A выполняет операции DDL над нижней таблицей M,Приложение B, которое также использует нижнюю таблицу M, будет затронуто.,Этот видсдерживая друг другаСценарии также неизбежны при развитии команды.。

Основная идея состоит в том, чтобы совместно использовать базу данных через SQL.

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

Ввиду этого есть второе решение — база данных приложения.

база данных приложения

Если говорить проще, то это разработать приложение специально для доступа к базе данных, скажем, оно называется DBApp, и заложить в код приложения работу по поддержанию целостности базы данных.

Другие приложения единообразно используют стандартную доменную модель состояния памяти в DBApp, которая также называется агрегатным корнем в доменно-ориентированном дизайне DDD.

Основная идея заключается в совместном использовании баз данных через программные интерфейсы.

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

потому чтонуждатьсяиз Он распространяетсяделаизпоследовательность,деламожно передатьDBAppраспределенныйдела(ТСС или САГА)изпуть впередконтроль。а не в узком смыслеизк Реляционная библиотека данныхизделаконтроль,Поэтому при выборе технологии библиотеки данныхчас,Мы также можем рассмотреть нереляционные библиотеки данных.,Вы даже можете использовать различные библиотеки данных, охватывающие реляционные и нереляционные типы.,Объединено в окончательную модель памяти,Наконец-то прошла база данных Приложение обеспечивает возможности доступа к данным (т. е. гибридное сохранение).

Как использовать функции NoSql в традиционных реляционных базах данных

Вы можете использовать реляционный объект, переносить значение ExtendMap в качестве поля расширения и использовать этот ExtendMap в качестве объекта NoSql kv, чтобы повысить масштабируемость исходного объекта.

Случай

Например, в цепочке поставок Alibaba выполнение заказов.,В реальных сценариях эксплуатации,Сразуиспользовать Понятнобаза данных приложения。

5. Дополнительные мысли

Суть баз данных заключается в совместном использовании данных, при этом необходимо использовать сетевые протоколы. Итак, какие сетевые протоколы используются в технологии баз данных, помимо передачи данных в базе данных, в каких еще технологиях используются эти сетевые протоколы? На примере наиболее знакомого протокола TCP/IP взаимосвязь между уровнями сети выглядит следующим образом.

MySQLпротоколиспользоватьTCP/IPруководитьданныепередача инфекции,Может использоваться для зашифрованных SSL-соединений.

Dubbo Платформа предоставляет настраиваемый высокопроизводительный RPC. коммуникацияпротокол：На основе HTTP/2 Тройной протоколы и на основе TCP Даббо2 протокол。

краткое содержание

Прикладной уровненные визиты обычно основаны на Прикладной уровень(HTTP)протоколиз,Библиотека данных обычно основана на транспортном уровне сети (TCP/IP). Данные на разных уровнях передаются на внешний интерфейс через соответствующий сетевой протокол.,Целью является передача данных с носителя данных на внешний интерфейс. «Как дела» — это средство поддержания последовательности,В сценарии горизонтального сегментирования базы данных и сегментирования таблиц,последовательность Это также может быть реализовано на основе кодирования。

6. Расширение

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

1. Вертикальная подбаза данных и подтаблица: существовать垂直分Библиотекаподтаблицасередина,Каждая библиотека или таблица отвечает за разные бизнес-функции или типы данных. В этом случае,дела могут быть ограничены одной библиотекой или столом,Гарантия дел такая же, как и у традиционных одиночных библиотечных дел.,Никакой дополнительной обработки не требуется.
2. Горизонтальная подбаза данных и подтаблица:
   • Менеджер распределенных транзакций: 可киспользоватьраспределенныйделаменеджер по пересечению Библиотекауправлятьдела,Такие как Атомикос, Битроникс и т.д. Эти инструменты могут координировать работу различных библиотек данных.,Гарантированное распространениеделаизатомарность、последовательность、Изоляция и долговечность (ACID).
   • Двухфазная фиксация (2PC): 2PC Это общий распределенный протокол дел, который использует координатора для координации процесса отправки участниками дел для достижения согласованности дел в библиотеках данных. Однако 2 ПК На практике могут возникнуть проблемы с производительностью, надежностью и сложностью, поэтому это не лучший выбор.
   • Компенсационные операции (TCC): TCC — это решение распределенных дел, основанное на вознаграждении. существовать TCC середина,дела были разложены на три этапа Try, Confirm и Cancel.,Выполнив предварительноиметь дело сикомпенсационная операция для обеспеченияделаизфинальныйпоследовательность。
   • Доставка с наилучшими усилиями: Уведомление о максимальных усилиях — это простоеизраспределенныйделаплан,Участники асинхронно уведомляют координатора после совершения дела,Координатор обрабатывает результаты уведомления участников. Хотя метод никто не гарантирует строгую последовательность,但是可к提供满足应用需求изфинальныйпоследовательность。
   • дела САГА：Первоначально предложено SAGA Цель состоит в том, чтобы избежать блокировки ресурсов библиотеки данных между большими делами на длительное время, а затем постепенно превратиться в большие дела, разложенные. на Серия схем оформления родных дел. САГА Состоит из двух операций。Частично это разделение большой транзакции на несколько мелких транзакций.,Распределить всюдела T разложен на n Сын дела, мы назвали Т1, Т2,…,Ти,…,Тн. Каждое под-под-дела должно или может рассматриваться как атомарное поведение. Если распределенодела T могут быть отправлены нормально, то их влияние на данные (конечная согласованность) должно быть таким же, как и при успешной последовательной отправке субданных. Ti эквивалентность。Другая часть — разработать соответствующие компенсационные действия для каждой субтранзакции.Рекомендация к прочтению: TCC и SAGA распределенных транзакций.