Открыть сервис
Главная → Блог → H-Store

H-Store

H-Store — это распределённая реляционная система управления базами данных (СУБД), ориентированная на обработку транзакций в оперативной памяти (in-memory OLTP). Разработана в 2007—2008 годах в Массачусетском технологическом институте (MIT) под руководством профессора Майкла Стоунбрейкера и аспиранта Роберта Калмана. H-Store стала прототипом для коммерческой СУБД VoltDB и легла в основу ряда исследовательских проектов, посвящённых высокопроизводительной обработке транзакций.

История

Разработка H-Store началась в 2007 году как ответ на растущие ограничения традиционных дисковых СУБД в сфере высоконагруженных OLTP-систем. Майкл Стоунбрейкер, один из пионеров реляционных баз данных, в своей статье «The End of an Architectural Era (It’s Time for a Complete Rewrite)» (2007) обосновал необходимость перехода от архитектуры «одна нить — один диск» к полностью параллельным, in-memory системам.

Прототип был реализован на языке Java и C++. Первая публичная демонстрация состоялась в 2008 году на конференции SIGMOD. В 2009 году на основе H-Store была основана компания VoltDB, выпустившая коммерческую версию СУБД. Исходный код H-Store остался открытым и использовался для академических исследований, в частности в проектах по оптимизации распределённых транзакций и устойчивости к сбоям.

Архитектура

In-memory хранение

H-Store хранит все данные исключительно в оперативной памяти. Это устраняет задержки, связанные с дисковым вводом-выводом (I/O), и позволяет достичь производительности в десятки и сотни тысяч транзакций в секунду на одном узле. Постоянство данных (durability) обеспечивается асинхронным журналированием на диск и репликацией на другие узлы кластера.

Распределённая архитектура

Система состоит из множества узлов (nodes), каждый из которых управляет собственным набором разделов (partitions). Данные горизонтально секционируются (шардируются) по первичному ключу. Каждый раздел обрабатывается одним потоком (single-threaded execution), что исключает необходимость в блокировках (locks) и снижает накладные расходы на синхронизацию.

Управление транзакциями

Транзакции в H-Store делятся на два типа:

  • Однораздельные (single-partition) — затрагивают данные только одного раздела. Выполняются без координации с другими узлами, что обеспечивает максимальную скорость.
  • Многораздельные (multi-partition) — требуют согласования между разделами. Для их выполнения используется двухфазный протокол фиксации (2PC), что увеличивает задержку.

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

Хранимые процедуры

Вся бизнес-логика транзакций реализуется в виде хранимых процедур на Java или C++. Клиент не отправляет SQL-запросы напрямую, а вызывает процедуру, которая выполняется на сервере. Это снижает сетевые издержки и позволяет системе заранее анализировать план выполнения.

Классификация

H-Store относится к классу NewSQL — систем, сочетающих реляционную модель данных с масштабируемостью NoSQL-решений. Внутри этого класса она является представителем in-memory OLTP СУБД. По способу организации параллелизма H-Store использует архитектуру shared-nothing (ничего общего), где каждый узел обладает собственной памятью и процессором.

Характеристики

  • Производительность: до 1 млн транзакций в секунду на кластере из 10 узлов (по данным тестов на синтетической нагрузке TPC-C).
  • Масштабируемость: линейное увеличение пропускной способности при добавлении узлов (до 50 узлов в исследовательских конфигурациях).
  • Задержка: среднее время выполнения однораздельной транзакции — менее 1 мс.
  • Надёжность: репликация синхронная (для критичных данных) или асинхронная (для высокой производительности). Поддерживается механизм snapshot (снимок состояния) для восстановления после сбоя.
  • Язык запросов: SQL (подмножество, без поддержки сложных JOIN и вложенных подзапросов).

Применение

H-Store и её коммерческий наследник VoltDB используются в системах, требующих сверхвысокой скорости обработки транзакций и низкой задержки:

Ограничения и критика

  • Ограниченная поддержка сложных запросов: H-Store не предназначена для аналитических нагрузок (OLAP). JOIN, агрегации по большим наборам данных, оконные функции отсутствуют или работают неэффективно.
  • Зависимость от оперативной памяти: стоимость хранения больших объёмов данных (свыше 1 ТБ) существенно выше, чем на дисковых системах.
  • Сложность проектирования схемы: для достижения высокой производительности требуется тщательное проектирование ключа секционирования и минимизация многораздельных транзакций.
  • Отсутствие полноценной поддержки ACID-транзакций в распределённом режиме: многораздельные транзакции используют 2PC, что при сбоях может приводить к блокировкам и снижению доступности.

Влияние

H-Store оказала значительное влияние на индустрию СУБД. Её идеи легли в основу не только VoltDB, но и других in-memory систем, таких как MemSQL (ныне SingleStore), SAP HANA (в части OLTP-обработки) и Google Spanner (в аспекте распределённого управления транзакциями). Архитектура single-threaded execution per partition стала стандартом де-факто для высокопроизводительных OLTP-систем.

Источники

  • Stonebraker, M., et al. «The End of an Architectural Era (It’s Time for a Complete Rewrite)». VLDB, 2007.
  • Kallman, R., et al. «H-Store: A High-Performance, Distributed Main Memory Transaction Processing System». VLDB, 2008.
  • VoltDB Technical Overview. VoltDB Inc., 2010.
  • Pavlo, A., et al. «A Comparison of Approaches to Large-Scale Data Analysis». SIGMOD, 2009.
  • TPC-C Benchmark Results for VoltDB. Transaction Processing Performance Council, 2012.

BFOmetr — база данных и аналитика по компаниям России.

На главную BFOmetr →

Похожие материалы