В последнее время возникла необходимость модифицировать существующую структуру хранения, что предполагает рассмотрение условий запросов и эффективности запросов.После прочтения нескольких статей, связанных с индексами и HBase, я вспомнил соответствующие знания в сочетании с требованиями проекта и рассказал о своем собственное понимание и обобщение.
Предыдущие статьи были сосредоточены на знаниях, связанных с индексами MySQL, от преимуществ индекса, эволюции структуры индекса до процесса SQL-запроса, плана выполнения и, наконец, окончательной оптимизации индекса.Друзья, которые пропустили это, могут просмотреть предыдущие статьи:
- Структура индекса и процесс размещения данных
- Процесс запроса и расширенный запрос
- Детали плана выполнения
- Оптимизация индекса
Позже я начну знакомить с индексами HBase и сравнивать их с MySQL, чтобы углубить понимание индексов. введение, вы поймете:
- Почему появляется HBase?
- Особенности HBase
- Общая архитектура HBase
Часть контента взята из статей нескольких блоггеров, и, наконец, будет дана ссылка на статью, чтобы поблагодарить их за прекрасный анализ.
Почему появляется HBase?
Для появления любой технологии есть причина, и понимание того, почему она появилась и какие проблемы решает, полезнее для понимания ее характеристик и дизайнерских идей.
узкое место MySQL
MySQL является реляционной базой данных с высокой согласованностью данных и гарантиями надежности.Когда объем доступа особенно велик, особенно операция записи, будет большое узкое место в производительности O.
Хотя эту проблему можно решить, разделив чтение-запись master-slave, подбазу данных и подтаблицу, по мере того, как количество данных продолжает увеличиваться, а параллелизм продолжает увеличиваться, разработка приложений MySQL становится все более и более сложной и технически сложной.
Кроме того, установка правил для подтаблицы и подбазы данных требует опыта.Хотя существуют уровни промежуточного программного обеспечения Cobar, MyCat, Sharding-JDBC, TDDL и DBProxy для защиты от сложности разработчиков, сложность всей архитектуры не может избегать.
Подбиблиотеки подбаз и подтаблиц сталкиваются с проблемами расширения на определенном этапе, и изменения требований могут потребовать нового сегментирования.
Плохая масштабируемость MySQL, высокая нагрузка на операции ввода-вывода при работе с большими данными и сложность изменения структуры таблиц — вот проблемы, с которыми сталкиваются разработчики MySQL, и узкие места MySQL.
Несмотря на наличие этих узких мест, его по-прежнему необходимо использовать для предприятий, которым требуется очень высокая согласованность данных.Однако для некоторых сценариев приложений слишком высокая согласованность не требуется.В компаниях с большими объемами данных и высокой степенью параллелизма можно выбрать другие решения для хранения данных. .
Появление NOSQL
Существует много типов баз данных NoSQL, но общей особенностью является удаление реляционных функций реляционных баз данных, и нет никакой связи между данными, что упрощает расширение.
NOSQL имеет следующие характеристики:
- Свобода режима: в отличие от традиционных реляционных баз данных, которым для доступа к данным необходимо определять такие структуры, как базы данных и таблицы данных, каждая запись в таблице данных может иметь разные атрибуты и форматы;
- Обратная парадигма: устранение ограничений, снижение требований к транзакциям и облегчение распределенного хранения данных, в отличие от парадигмы MySQL;
- Многораздельное хранилище: Хранится на нескольких узлах, горизонтальное расширение выполняется хорошо, а скорость чтения и записи данных повышается;
- Асинхронная репликация с несколькими копиями: для обеспечения безопасности данных сохраняется несколько копий данных;
- Эластичность и масштабируемость: узлы можно динамически добавлять или удалять во время работы системы, а данные можно автоматически балансировать и перемещать без ручного вмешательства;
- Мягкие транзакции: транзакции являются особенностью реляционных баз данных.Базы данных NoSQL не могут полностью соответствовать характеристикам ACID транзакций, но могут обеспечить конечную согласованность транзакций;
NOSQL имеет некоторую теоретическую поддержку:
- Теория CAP: она должна сбалансировать согласованность, доступность и отказоустойчивость разделов, поскольку одновременно могут быть реализованы не более двух, и необходимо обеспечить баланс;
- БАЗОВАЯ модель: базовая доступность в основном доступна, мягкое состояние может быть не синхронизировано в течение определенного периода времени, окончательная согласованность — это окончательная согласованность, она не гарантирует, что одни и те же данные на любом узле в любое время будут одинаковыми, но с миграцией времени, разные узлы Одни и те же данные всегда меняются в сторону сближения;
Выложив картинку в интернет, можно увидеть, что разные тестпоинты БД отличаются:
На приведенном выше рисунке также различаются разные модели данных по цвету, который кратко описан здесь.
Реляционная база данных: MySQL, которая была введена, упоминаться не будет;
Ключ-значение: кэш содержимого, в основном используемый для обработки высокой нагрузки доступа к большим объемам данных, высокой скорости поиска, но неструктурированных данных, которые обычно обрабатываются только как строковые или двоичные данные, такие как Redis, MemcacheDB;
База данных хранения столбцов: распределенная файловая система, хранящаяся по столбцам, запрос для определенного столбца или нескольких столбцов имеет очень большое преимущество ввода-вывода, с хранилищем кластера столбцов один и тот же столбец данных существует вместе, высокая скорость поиска, масштабируемость Сильный, это проще осуществлять распределенное расширение, но функции относительно ограничены, такие как BigTable, HBase, Cassandra;
База данных документов: хранит содержимое в формате, подобном JSON, и может индексировать некоторые поля. Это наиболее реляционная база данных. Ключ-значение соответствует паре ключ-значение. Значение представляет собой структурированные данные. Требования к структуре данных не являются строгими. переменная, но производительность запросов не высока, и отсутствует унифицированный синтаксис запросов, такой как MongoDB и CouchDB;
HBase генерирует фон
Как упоминалось выше, по мере того, как масштаб данных становится все больше и больше, большое количество бизнес-сценариев начинают рассматривать горизонтальное расширение хранилища данных.Массовое хранение данных стало узким местом для повышения производительности приложений.Одна машина не может справиться с массовой обработкой данных Существует множество решений для распределенного хранения, и HBase — одно из них.
HBase — база данных на базе Hadoop, основанная на базе данных, созданной в распределенной файловой системе. HBase представляет собой столбцовую базу данных с открытым исходным кодом.
Команда с открытым исходным кодом реализовала базу данных столбцов на основе распределенной файловой системы в соответствии с документом об основной идее поисковой системы Google BigTable, опубликованным Google в 2008 году.
Позже он присоединился к Apache Foundation и стал проектом верхнего уровня в экосистеме Hadoop.
Особенности HBase
высокая производительность
Набор индексов HDFS хранится в HBase, а местоположение данных определяется с помощью набора индексов, таких как имя таблицы-> ключ строки-> семейство столбцов-> квалификатор столбца-> версия времени.HBase поддерживает набор индексов для каждый столбец правил данных, для конкретного запроса определенного фрагмента данных место хранения данных можно быстро найти и получить через дерево B+.
Кроме того, HBase обычно развертывается в кластере, а данные распределяются по нескольким узлам для хранения.Когда клиент инициирует запрос запроса, несколько узлов в кластере выполняют операцию запроса параллельно, и, наконец, результаты запроса разных узлов объединяются и возвращаются клиенту.Улучшение производительности ввода-вывода.
Высокая доступность
Сбой любого узла в кластере HBase не приведет к краху кластера. Это зависит от двух причин:
Во-первых, ZooKeeper решает проблему централизации HBase;
С другой стороны, HBase хранит данные на HDFS, а данные HDFS избыточно хранятся в разных узлах, при параличе одного узла данные могут быть получены с других узлов, что обеспечивает высокую доступность HBase.
Легко расширить
Масштабируемость Hbase в основном отражается в двух аспектах: один основан на расширении возможностей обработки верхнего уровня RegionServer, а другой основан на расширенной HDFS хранилища.
немодальный
Использование HBase не требует предварительного определения количества столбцов в таблице, а также не требует определения типа данных, хранящихся в каждом столбце.HBase может динамически добавлять столбцы и указывать типы данных хранилища, когда это необходимо.
Общая архитектура HBase
Статус Hbase во всей экосистеме Hadoop следующий:
понять несколько понятий
rowkey: Концепция Rowkey похожа на первичный ключ в mysql.Hbase использует Rowkey для уникального различения данных строки;
регион: аналогично разделу или сегментированию MySQL, Hbase будет распределять данные большой таблицы по разным регионам на основе разных диапазонов Rowkey, и каждый регион отвечает за определенный диапазон доступа к данным и их хранения;
Временная метка: временная метка очень важна для Hbase, потому что это ключ к реализации многоверсионности Hbase.При записи данных, если пользователь не укажет соответствующую временную метку, Hbase автоматически добавит временную метку, которая соответствует времени сервера. Данные одного и того же ключа строки располагаются в порядке, обратном временной метке. По умолчанию запрашивается последняя версия. Вы можете указать значение временной метки, чтобы считать данные старой версии.
Внутренний базовый состав
Вся Hbase в основном состоит из файловой системы zookeeper, Hmaster, HRegionServer и Hdfs.Эти четыре части работают вместе для чтения и записи данных.
Различные диапазоны данных делятся на разные места, называемые HR-регионами. Разные HR-регионы размещаются на разных хостах. При запросе данных, если данные находятся в HR-регионе в этом диапазоне в соответствии с ключом строки, вы можете перейти непосредственно к этому HR-региону. , Чтобы найти данные в базе данных, эффективность запроса намного выше, чем в традиционной базе данных.
весь кадр
1.HMater
- После разделения региона он отвечает за выделение нового региона;
- При добавлении новой машины управляйте балансировкой нагрузки сервера HRegion и корректируйте распределение по регионам;
- После выхода из строя сервера HRegion он отвечает за миграцию регионов на вышедшем из строя сервере HRegion;
2.Region Server
- Региональный сервер поддерживает регионы, назначенные ему Мастером, и обрабатывает запросы ввода-вывода к этим регионам;
- HRegion Server управляет многими разделами таблицы, то есть регионами;
3.Zookeeper
- ZooKeeper предоставляет услуги координации для кластера HBase, управляет состоянием HMaster и HRegionServer (доступен/работает и т. д.) и уведомляет HMaster, когда они не работают;
- Метаданные hbase управляются в zookeeper, например, местоположение -root-;
4.HDFS
- Место хранения файлов данных, благодаря собственному распределенному механизму хранения, файлы данных очень безопасны;
- Датанода хаупа предпочтительно находится на том же хосте, что и регион, что удобно для чтения данных и максимально исключает передачу данных по сети;
Эта статья в основном является введением, а следующая статья посвящена индексу в HBase, а также некоторым принципам и методам проектирования строковых ключей.
Справочная статья:
- Узкое место MYSQL и введение NOSQL в большой параллелизм и большие числа
- Как много вы знаете о NoSQL?
- HBase понимает большие данные Hadoop
- Подробные примечания к изучению технологии Hbase
- Простой анализ архитектуры Hbase
Добро пожаловать, чтобы отсканировать QR-код ниже, обратите внимание на мою личную общедоступную учетную запись WeChat и просмотрите другие статьи ~