С наступлением эры больших данных все больше и больше веб-сайтов и систем приложений должны поддерживать массивное хранение данных, большое количество одновременных запросов, высокую доступность, высокую масштабируемость и другие характеристики. Традиционные реляционные базы данных стали не в состоянии справиться с этими корректировками. выявляет множество проблем, которые можно решить. В результате различные базы данных NoSQL (не только SQL) быстро развивались как мощное дополнение к традиционным реляционным данным.
В этой статье будут проанализированы проблемы, связанные с существованием традиционных баз данных, и то, как несколько типов NoSQL решают эти проблемы, в надежде предоставить вам рекомендации по выбору технологии хранения в различных бизнес-сценариях.
1 Недостатки традиционных баз данных
Высокая скорость ввода-вывода в сценариях с большими данными
Поскольку данные хранятся в строках, даже если операция выполняется только с одним из столбцов, реляционная база данных будет считывать всю строку данных с устройства хранения в память, что приведет к большому количеству операций ввода-вывода.
Сохраняет записи строк и не может хранить структуры данных
Расширение схемы структуры таблицы неудобно
Если вам нужно изменить структуру таблицы, вам необходимо выполнить DDL (язык определения данных), модификацию оператора, период модификации приведет к блокировке таблицы, а некоторые службы будут недоступны.
Функционал полнотекстового поиска слабый
В реляционных базах данных можно выполнять только запросы на сопоставление подстрок.Когда данные в таблице постепенно становятся больше, сопоставление подобных запросов будет очень медленным, даже при наличии индекса. Более того, реляционные базы данных не должны индексировать текстовые поля.
Слабая способность хранить и обрабатывать сложные реляционные данные
Многим приложениям требуется понимание и навигация по взаимосвязям между тесно связанными данными, чтобы обеспечить такие варианты использования, как социальные приложения, механизмы рекомендаций, обнаружение мошенничества, графы знаний, науки о жизни и ИТ/сети. Однако традиционные реляционные базы данных плохо справляются с отношениями между точками данных. Их табличная модель данных и строгая схема затрудняют добавление новой или другой связанной информации.
2 решения NoSQL
NoSQL, который обычно относится к нереляционным базам данных, можно рассматривать как мощное дополнение к SQL.
Хотя производительность NoSQL во многих аспектах намного выше, чем у нереляционных баз данных, она часто сопровождается отсутствием некоторых функций, наиболее распространенной из которых является отсутствие транзакционных функций базы данных транзакций.
Четыре основных элемента для правильного выполнения транзакций базы данных: ACID:
название
описывать
A
Atomicity (атомарность)
Все операции в транзакции либо завершены, либо не завершены, и не будут заканчиваться определенной ссылкой посередине. Если во время выполнения транзакции возникает ошибка, она будет отброшена к состоянию до начала транзакции, как если бы транзакция никогда не выполнялась.
C
Consistency последовательность
Ограничения согласованности данных не нарушаются до начала транзакции и после ее завершения.
I
Isolation изоляция
Способность базы данных позволять нескольким параллельным транзакциям одновременно читать, записывать и изменять данные. Изоляция может предотвратить несогласованность данных из-за перекрестного выполнения, когда несколько транзакций выполняются одновременно.
D
Durability Упорство
После завершения транзакции изменение данных является постоянным и не будет потеряно даже в случае сбоя системы.
Ниже представлены пять типов решений для данных NoSQL для устранения недостатков традиционных реляционных баз данных:
2.1 Столбчатая база данных
Столбцовая база данных — это база данных, которая хранит данные в архитектуре хранилища, связанной со столбцами, и в основном подходит для пакетной обработки данных и мгновенных запросов. Соответственно, это база данных строк, в которой данные размещаются в архитектуре хранения, связанной со строками, которая в основном подходит для обработки небольших пакетов данных и часто используется для обработки транзакционных данных в режиме онлайн.
Основываясь на характеристиках хранения столбцов в столбцовой базе данных, вы можетеРешите проблему большого количества операций ввода-вывода в реляционных базах данных в некоторых конкретных сценариях.
2.1.1 Основные принципы
Традиционная реляционная база данных хранит базу данных в соответствии со строкой, которая называется «базой данных строк», в то время как столбцовая база данных хранит данные в соответствии со столбцом.
Есть два способа поместить таблицу в систему хранения, и мы в основном используем хранилище строк.
Метод хранения строк заключается в размещении строк в смежных физических местах, как в традиционных системах записи и файлов.
Метод хранения столбцов заключается в хранении данных в базе данных в соответствии со столбцами, что аналогично хранению строк.На следующем рисунке представлено графическое объяснение двух методов хранения:
2.1.2 Общие базы данных столбцов
HBase
HBase — это нереляционная распределенная база данных (NoSQL) с открытым исходным кодом, основанная на модели Google BigTable и реализующая язык программирования Java. Он является частью проекта Hadoop Apache Software Foundation и работает поверх файловой системы HDFS для предоставления услуг, подобных BigTable, для Hadoop. Следовательно, он может безотказно хранить огромные объемы разреженных данных.
BigTable
BigTable — это сжатая, высокопроизводительная и масштабируемая система хранения данных на основе файловой системы Google (GFS), которая используется для хранения крупномасштабных структурированных данных и подходит для облачных вычислений.
2.1.3 Связанные функции
Преимущества заключаются в следующем:
Эффективное использование пространства для хранения**
Из-за различных алгоритмов, изобретенных их характеристиками данных для разных столбцов, база данных столбцов часто имеет более высокие коэффициенты сжатия, чем у многострочной базы данных, а общая линейная база данных обычно сжимается от 3: 1 до 5: 1, и Коэффициент сжатия базы данных столбца обычно составляет от 8: 1 до 30: 1.
Более распространенные сжатые данные по словарю:
Вот оригинальный вид. После сжатия данных после Dictionary строка в таблице становится числом. Поскольку каждая строка появляется в таблице словаря только один раз, цель сжатия достигается (немного похоже на стандартизированную и нестандартизированную нормализацию и деномализацию).
Высокая эффективность запросов
Эффективно читать один и тот же столбец из нескольких фрагментов данных, потому что эти столбцы хранятся вместе, и одна дисковая операция может прочитать все указанные столбцы данных в память.
На следующем рисунке показаны преимущества хранения по столбцам (и сжатия данных) при выполнении запроса.
执行步骤如下：
i. 去字典表里找到字符串对应数字(只进行一次字符串比较)。
ii. 用数字去列表里匹配，匹配上的位置设为1。
iii. 把不同列的匹配结果进行位运算得到符合所有条件的记录下标。
iv. 使用这个下标组装出最终的结果集。
подходит для агрегации
Подходит для больших объемов данных, а не для небольших данных
Недостатки следующие:
Не подходит для сканирования небольших объемов данных
Не подходит для случайных обновлений
Не подходит для операций в реальном времени, связанных с удалением и обновлением.
Данные одной строки — ACID. В случае многострочной транзакции нормальный откат транзакции не поддерживается, изоляция I (изоляция) (последовательная фиксация транзакции), устойчивость D (долговечность) и A (атомарность). ) атомарность не может быть гарантирована. , C (Consistency) согласованность
2.1.4 Сценарии использования
Возьмите HBase в качестве примера для иллюстрации:
Большой объем данных (данные на уровне 100 ТБ) и необходимость быстрого произвольного доступа
Приложения с интенсивным записью, приложения с огромным количеством операций записи в день и относительно небольшим количеством операций чтения.
Например, исторические сообщения IM, игровые журналы и т. д.
Приложения, которые не требуют сложных условий запроса для запроса данных
HBase поддерживает только запросы на основе rowkey. Для HBase допустима одна запись или небольшой диапазон запросов. Крупномасштабные запросы могут незначительно влиять на производительность из-за распределенных причин. HBase не подходит для объединений. Уровневые индексы, сложные модели данных с табличными отношениями
Приложения с очень высокими требованиями к производительности и надежности
Поскольку у самого HBase нет единой точки отказа, доступность очень высока.
Приложения с большими объемами данных и непредсказуемым ростом требуют элегантного расширения данных.
HBase поддерживает онлайн-расширение, и даже если объем данных растет экспоненциально с течением времени, он также может расширяться горизонтально через HBase для выполнения функций.
Храните структурированные и полуструктурированные данные
2.2 База данных К-В
Относится к базе данных, в которой используется хранилище «ключ-значение», а ее данные организованы, индексированы и хранятся в виде пар «ключ-значение».
Хранилище KV очень подходит для данных, которые не включают слишком много отношений данных и деловых отношений, и может эффективно сократить количество операций чтения и записи на диск.Он имеет лучшую производительность чтения и записи, чем хранилище базы данных SQL, и можетРешить проблему, заключающуюся в том, что реляционные базы данных не могут хранить структуры данных..
2.2.1 Общие базы данных K-V
Redis
Redis — это сетевая база данных с открытым исходным кодом, хранящаяся в памяти, с необязательным хранилищем ключей и значений, написанная на ANSI C. Начиная с июня 2015 года разработка Redis спонсировалась Redis Labs, а с мая 2013 года по июнь 2015 года ее разработка спонсировалась Pivotal. До мая 2013 года его разработка спонсировалась VMware. Согласно ежемесячному рейтингу веб-сайта DB-Engines.com, Redis является самой популярной базой данных хранилища ключей и значений.
Cassandra
Apache Cassandra (обычно именуемый в сообществе C*) — это распределенная система баз данных NoSQL с открытым исходным кодом. Первоначально разработанный Facebook для хранения данных в простых форматах, таких как почтовые ящики, он сочетает в себе модель данных Google BigTable с полностью распределенной архитектурой Amazon Dynamo. Facebook сделал Cassandra открытым исходным кодом в 2008 году. С тех пор, благодаря хорошей масштабируемости и производительности, Cassandra была принята такими известными веб-сайтами, как Apple, Comcast, Instagram, Spotify, eBay, Rackspace, Netflix и т. д., и стала популярная распределенная схема хранения структурированных данных.
LevelDB
LevelDB — это встроенная библиотека программирования системы управления базами данных с парой ключ/значение (Key/Value Pair), разработанная Google и выпущенная под лицензией BSD с открытым исходным кодом.
2.2.2 Связанные функции
Возьмите Redis в качестве примера:
Преимущества заключаются в следующем:
Чрезвычайно высокая производительность: Redis может поддерживать более 10 Вт TPS.
Богатые типы данных: поддержка Redis включает String, Hash, List, Set, Sorted Set, Bitmap и hyperloglog.
Богатые возможности: Redis также поддерживает публикацию/подписку, уведомление, истечение срока действия ключа и другие функции.
Недостатки следующие:
Для ACID транзакции Redis не могут поддерживать атомарность и устойчивость (A и D), только изоляцию и согласованность (I и C).
В частности, упомянутая здесь атомарность не гарантируется и предназначена для транзакционных операций Redis, поскольку транзакции не поддерживают откат и из-за однопоточной модели Redis,Обычные операции в Redis атомарны
Большинству предприятий не нужно строго следовать принципу ACID, например, в отношении рейтинга игр в реальном времени, внимания фанатов и т. д. Даже если какие-то данные не сохраняют свою актуальность, влияние на бизнес на самом деле очень мало. Поэтому при разработке схемы необходимо сделать выбор в соответствии с особенностями и требованиями бизнеса.
2.2.3 Использование сцены
Применимая сцена
Храните информацию о пользователе (например, сеансы), профили, параметры, корзины покупок и многое другое. Эта информация обычно связана с идентификатором (ключом)
Не применимая сцена
Его нужно запрашивать по значению, а не по ключу. Просто нет возможности сделать запрос по значению в базе данных Key-Value.
Отношения между данными должны быть сохранены. Данные не могут быть связаны двумя или более ключами в базе данных "ключ-значение".
Требуется сопровождение сделки. Откат не может быть выполнен, если в базе данных "ключ-значение" произошел сбой.
2.3 База данных документов
База данных документов (также известная как база данных документов) — это тип базы данных, предназначенный для хранения частично структурированных данных в виде документов. Базы данных документов обычно хранят данные в формате JSON или XML.
Из-за того, что базы данных документов не содержат схемы, произвольные данные могут храниться и считываться.
Поскольку используется формат данных JSON или BSON, поскольку данные JSON самоописываемы, нет необходимости определять поля перед использованием, а чтение поля, не существующего в JSON, не вызовет синтаксических ошибок, таких как SQL.Это может решить проблему неудобного расширения схемы структуры таблицы реляционной базы данных.
2.3.1 Общие базы данных документов
MongoDB
MongoDBЭто документно-ориентированная система управления базами данных, написанная на C++ для решения большого количества реальных проблем в сообществе разработчиков приложений. В октябре 2007 года MongoDB была разработана командой 10gen. Впервые запущен в феврале 2009 года.
CouchDB
Apache CouchDB — это база данных с открытым исходным кодом, ориентированная на простоту использования и "Базы данных, которые полностью охватывают Интернет". Это база данных NoSQL, которая использует JSON в качестве формата хранения, JavaScript в качестве языка запросов, MapReduce и HTTP в качестве API. Одной из примечательных функций является репликация с несколькими мастерами. Первая версия CouchDB была выпущена в 2005 году и в 2008 год стал проектом Apache.
2.3.2 Связанные функции
Возьмите MongoDB в качестве примера для иллюстрации
Преимущества заключаются в следующем:
Добавлять поля легко
Нет необходимости выполнять операторы DDL для изменения структуры таблицы, как в реляционной базе данных, а программный код можно напрямую читать и записывать.
Легко совместим с историческими данными
Для исторических данных, даже если нет нового поля, это не вызовет ошибки, а только вернет нулевое значение.На данный момент код совместим с обработкой.
Легко хранить сложные данные
JSON — это мощный язык описания, описывающий сложные структуры данных.
По сравнению с традиционной реляционной базой данных недостатком базы данных документов является слабая поддержка транзакций для нескольких записей данных, что реализуется следующим образом:
атомарность
Поддерживает только атомарность на уровне одной строки/документа, а не атомарность с несколькими строками, несколькими документами и несколькими операторами.
Изоляция (изоляция)
Уровень изоляции поддерживает только зафиксированный уровень чтения, что может привести к неповторяющимся операциям чтения и фантомным чтениям.
Сложные запросы не поддерживаются
Например, запрос на соединение, если вам нужен запрос на соединение, вам нужно несколько раз работать с базой данных.
MongonDB также поддерживает согласованность и надежность многодокументных транзакций.
Хотя официально объявлено, что MongoDB официально запустит поддержку многодокументных транзакций ACID в версии 4.0, окончательную реализацию еще предстоит увидеть.
2.3.3 Сценарии использования
Применимая сцена:
Объем данных очень велик или станет очень большим в будущем
Структура таблицы непонятна, а поля постоянно увеличиваются, например, система управления контентом, система управления информацией
Неприменимые сценарии:
Транзакции необходимо добавлять в разные документы. Базы данных, ориентированные на документы, не поддерживают транзакции между документами.
Для нескольких документов напрямую требуются сложные запросы, такие как соединения
2.4 Полнотекстовая поисковая система
Традиционная реляционная база данных в основном использует индекс для достижения цели быстрого запроса.В бизнесе полнотекстового поиска индекс бессилен, в основном отражается в:
Условия полнотекстового поиска можно произвольно скомпоновать и комбинировать, если индекс удовлетворяется, то количество индексов очень велико.
В методе нечеткого сопоставления полнотекстового поиска индекс не может быть удовлетворен, и может использоваться только подобный запрос, а подобный запрос представляет собой сканирование всей таблицы, что очень неэффективно.
Появление полнотекстовых поисковых системРешить проблему слабой функции полнотекстового поиска реляционной базы данных
2.4.1 Основные принципы
Технический принцип системы полнотекстового поиска называется «инвертированный индекс», который представляет собой метод индексации, основным принципом которого является создание индекса слов для документов. Напротив, это «прямой индекс», основной принцип которого состоит в том, чтобы индексировать документы до слов.
Теперь у нас есть следующая коллекция документов:
Положительный индекс получает индекс следующим образом:
Видно, что положительный индекс подходит для запроса содержимого документа по имени документа.
Простой инвертированный индекс выглядит следующим образом:
Перевернутый индекс с информацией о частоте слов выглядит следующим образом:
Видно, что инвертированный индекс подходит для запроса содержимого документа по ключевым словам.
2.4.2 Распространенные полнотекстовые поисковые системы
Elasticsearch
Elasticsearch — поисковая система на основе Lucene. Он предоставляет распределенную, многопользовательскую полнотекстовую поисковую систему с веб-интерфейсом HTTP и файлами JSON без схем. Elasticsearch разработан на Java и выпущен с открытым исходным кодом в соответствии с условиями лицензии Apache. Согласно рейтингу DB-Engines, Elasticsearch является самой популярной поисковой системой для предприятий, за ней следует Apache Solr на базе Lucene.
Solr
Solr — это корпоративная поисковая платформа с открытым исходным кодом проекта Apache Lucene. Его основные функции включают полнотекстовый поиск, маркировку попаданий, фасетный поиск, динамическую кластеризацию, интеграцию с базами данных и обработку форматированного текста (например, Word, PDF). Solr обладает высокой масштабируемостью и обеспечивает распределенный поиск и репликацию индексов.
2.4.3 Связанные функции
Возьмите Elasticsearch в качестве примера:
Преимущества заключаются в следующем:
Высокая эффективность запросов близка к массивным данным
Масштабируемость
Кластерная среда может быть легко расширена в горизонтальном направлении, она может нести данные уровня PB.
Высокая доступность
Устойчивость кластера Elasticsearch — они обнаружат новые или неисправные узлы, реорганизуют и перебалансируют данные, обеспечат безопасность и доступность данных.
Недостатки следующие:
Недостаточная поддержка ACID
Данные одного документа являются ACID, а транзакция, содержащая несколько документов, не поддерживает нормальный откат транзакции, поддерживает изоляцию I (изоляция) (на основе механизма оптимистической блокировки), устойчивость D (долговечность),Не поддерживает атомарность A (атомарность), согласованность C (согласованность).
Слабая поддержка сложных операций объединения нескольких таблиц через внешние ключи в аналогичных базах данных.
Существует определенная задержка при чтении и записи, и записанные данные могут быть извлечены за самые быстрые 1 с.
Производительность обновления низкая, базовая реализация заключается в том, чтобы сначала удалить данные, а затем вставить новые данные.
Большой объем памяти, поскольку Lucene загружает индексную часть в память.
2.4.4 Сценарии использования
Применимыми сценариями являются следующие:
Распределенная поисковая система и система анализа данных
Полнотекстовый поиск, структурированный поиск, анализ данных
Обработка массивных данных в режиме, близком к реальному времени
Массовые данные могут быть распределены на несколько серверов для хранения и поиска.
Неприменимые сценарии:
Данные необходимо часто обновлять
Требуются сложные реляционные запросы
2.5 Графическая база данных
База данных графов применяет теорию графов для хранения реляционной информации между сущностями.. Самый распространенный пример — отношения между людьми в социальной сети. Эффект реляционной базы данных для хранения "реляционных" данных не очень хорош. Ее запрос сложный, медленный и превосходит все ожидания. Уникальный дизайн графовой базы данных как раз восполняет этот недостаток, решая функцию хранения реляционной базы данных и обработки сложных реляционных данных. данные более слабый вопрос.
2.5.1 Общие базы данных графов
Neo4j
Neo4j производится Neo4j, Inc. Разработана система управления графовой базой данных. Neo4j, описанная разработчиками как ACID-совместимая транзакционная база данных с собственным хранилищем и обработкой графов, является самой популярной графовой базой данных в соответствии с рейтингом DB-Engines.
ArangoDB
ArangoDB — это родная многомодельная система баз данных, разработанная triAGENS GmbH. Система базы данных поддерживает три важные модели данных (ключ/значение, документ, граф) с ядром базы данных и унифицированным языком запросов AQL (ArangoDB Query Language). Язык запросов является декларативным, что позволяет комбинировать различные шаблоны доступа к данным в одном запросе. ArangoDB — это система баз данных NoSQL, но AQL во многом похож на SQL.
Titan
Titan — это масштабируемая база данных графов, оптимизированная для хранения и запроса графов, содержащих десятки миллиардов вершин и ребер, распределенных по кластерам с несколькими машинами. Titan — это транзакционная база данных, которая может поддерживать тысячи одновременных пользователей, выполняющих сложные обходы графов в режиме реального времени.
2.5.2 Связанные функции
Возьмите Neo4j в качестве примера:
Neo4j использует концепцию графов в структурах данных для моделирования.
Двумя наиболее фундаментальными понятиями в Neo4j являются узлы и ребра. Узлы представляют объекты, а ребра представляют отношения между объектами. И узлы, и ребра могут иметь свои собственные свойства. Различные объекты связаны через различные отношения для формирования графов сложных объектов.
Для реляционных данных структуры хранения двух баз данных различаются:
В Neo4j при хранении узлов используется «безиндексная смежность», то есть каждый узел имеет указатель на свои соседние узлы, что позволяет нам находить соседние узлы за время O(1). Кроме того, согласно официальному заявлению, край является самым важным в Neo4j, который является «сущностями первого класса», поэтому он хранится отдельно, что выгодно для повышения скорости при обходе графа, а также его можно легко передвигается в любом направлении.
Следующие преимущества:
высокая производительность
Обход графа представляет собой уникальный алгоритм структуры данных графа, то есть, начиная с узла, по его отношению связи он может быстро и легко найти соседние с ним узлы. На этот метод поиска данных не влияет размер данных, поскольку запрос близости всегда находит ограниченные локальные данные, а не выполняет поиск по всей базе данных.
Гибкость дизайна
Естественные характеристики растяжения структур данных и их неструктурированные форматы данных позволяют проектам графовых баз данных иметь большую масштабируемость и гибкость. Поскольку узлы, отношения и их атрибуты, добавленные при изменении спроса, не повлияют на нормальное использование исходных данных.
Гибкость разработки
Интуитивно понятная и понятная модель данных, начиная от обсуждения требований, заканчивая разработкой и внедрением программы, и, наконец, сохраненная в базе данных, ее внешний вид как будто не изменился, и даже можно сказать, что она точно такая же
Полная поддержка ACID
В отличие от других баз данных NoSQL, Neo4j также имеет полные функции управления транзакциями и полностью поддерживает управление транзакциями ACID.
Недостатки следующие:
Имеет ограничение на количество поддерживаемых узлов, отношений и атрибутов
Разделение не поддерживается
2.5.3 Сценарии использования
Применимыми сценариями являются следующие:
В некоторых высокореляционных данных, таких как социальные сети
Рекомендательный двигатель. Если представить данные в виде графика, это будет очень полезно для формулировки рекомендаций.
Неприменимые сценарии:
Запись больших объемов данных о событиях (таких как записи журнала или данные датчиков)
Обработка крупномасштабных распределенных данных, аналогичная Hadoop
Подходит для структурированных данных, хранящихся в реляционных базах данных
хранение двоичных данных
3 Резюме
При выборе реляционных баз данных и баз данных NoSQL часто необходимо учитывать несколько показателей:
Объем данных
параллелизм
в реальном времени
Требования соответствия
Чтение и запись дистрибутива и типов
безопасность
Стоимость эксплуатации и обслуживания
Общая ссылка на выбор базы данных системы программного обеспечения выглядит следующим образом:
Управляемая система для внутреннего использования
Например, в операционных системах объем данных невелик, а объем параллелизма невелик, предпочтительнее реляционный тип.
Система высокого расхода
Например, на странице отдельного продукта электронной коммерции рассмотрите возможность выбора реляционного типа в фоновом режиме и рассмотрите возможность выбора типа памяти на стойке регистрации.
лог-система
Выбор столбца учитывается для необработанных данных, а инвертированный индекс используется для поиска в журнале.
поисковая система
Например, поиск на месте, неуниверсальный поиск, такой как поиск товаров, рассмотрите возможность выбора реляционного типа в фоновом режиме и рассмотрите возможность выбора инвертированного индекса на стойке регистрации.
транзакционная система
Такие как инвентаризация, транзакция, учет, рассмотрите возможность выбора реляционного + кэш + протокола согласованности.
Автономные вычисления
Например, при анализе больших объемов данных также можно учитывать выбор столбца или реляционный тип.
вычисления в реальном времени
Для мониторинга в режиме реального времени рассмотрите возможность выбора базы данных в памяти или столбцовой базы данных.
В практике проектирования, исходя из требований и бизнес-ориентированной архитектуры, выбран ли RDB/NoSQL/DRDB,Оно должно быть ориентировано на спрос, а окончательное решение для хранения данных должно представлять собой комплексный дизайн с различными компромиссами.
Более интересно, добро пожаловать на официальный аккаунт автора [архитектура распределенной системы]