H-Store

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 12:59, 25 сентября 2018.
H-Store
H-Store
Разработчики: Michael Stonebraker, Sam Madden, Andy Pavlo, Daniel Abadi
Написана на: Java, C++
Операционная система: кросс-платформенная
Тип ПО: База данных
Лицензия: Berkeley Software Distribution
Веб-сайт официальный сайт

H-Store - экспериментальная СУБД, основным принципом которой является обработка транзакций в реальном времени. Выпущена в мае 2014 года группой сотрудников и студентов MIT, Yale, Brown и CMU. Основа была заложена в 2007 Michael Stonebraker, Sam Madden, Andy Pavlo и Daniel Abadi[Источник 1] . Является первой СУБД, в основе которой лежит принцип распараллеливания, представителем класса NewSQL. Уникальность таких СУБД в том, что они сохраняют основные достоинства NoSQL, такие как высокую скорость, но в то же время они следуют принципам ACID - атомарность, согласованность, изолированность, долговечность. Данная СУБД является кластерной, не требуется создание одной высокопроизводительной машины. База данных разделена на разделы, одновременно можно получить доступ только к 1 ячейке раздела. Написана на Java и C++, поддерживает ОС Windows и Linux.

Распространяется под лицензиями GPL и BSD, коммерческая версия данной БД называется VoltDB. [Источник 2]

Описание

В H-Store требуется наличие заранее специфицированного набора классов транзакций, которые могут входить в рабочую нагрузку системы. Каждый класс характеризует транзакции с одними и теми же операторами SQL и логикой приложения, различающиеся только значениями констант времени выполнения. Это требование не является неестественным, поскольку для транзакционных приложений нехарактерно наличие непредвиденных запросов, явно вводимых пользователями во время выполнения транзакции. Таким образом, задержки выполнения транзакций по вине пользователей невозможны.

H-Store выполняется в кластере компьютеров. При конфигурировании системы можно указать желаемый уровень ее надежности – число узлов, при выходе из строя которых система может восстановить работоспособность без потери выполняемых транзакций в течение заданного времени.

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

В каждом узле H-Store поддерживает ровно один поток управления, в котором полностью, без каких-либо задержек выполняется каждая поступающая операция SQL. Узлы, в процессорах которых имеется несколько ядер, разбиваются на соответствующее число логических узлов. В H-Store каждый логический узел трактуется так же, как и любой физически независимый узел, и основная память многоядерного компьютера разделяется между логическими узлами.

Выполнение транзакций в H-Store происходит по следующей схеме. На входе в систему каждой транзакции назначалась временная метка (timestamp) в формате (site_id, local_unique_timestamp). Если поддерживается порядок на множестве узлов кластера, то все метки являются уникальными и полностью упорядоченными. Предполагалось, что локальные часы в каждом узле некоторым образом синхронизуются.

Если все классы транзакций являются одноузловыми, то каждая транзакция может быть направлена в узел с требуемыми копиями данных и полностью в нем выполнена. Если не все классы транзакций являются стерильными, то узел, в котором завершилось выполнение некоторой транзакции, в течение небольшого времени (времени сетевых задержек – для локальной сети в пределах нескольких миллисекунд) ожидает поступления транзакций от других узлов-инициаторов, чтобы выполнение транзакций происходило в порядке временных меток. За счет этого все реплики будут обновляться в одном и том же порядке, и их состояние после конца любой транзакции будет идентично. Следовательно, для выполнения одноузловых транзакций не требуется журнал повторного выполнения операций, какое-либо управление параллелизмом и распределенная фиксация транзакций. Если же, в придачу ко всему остальному, транзакция является двухфазной, то для нее не требуется и журнал отката.

Если все транзакции являются стерильными, то обычно для их выполнения не требуется какое-либо управление параллелизмом. Более того, в этом случае не требуется назначение транзакциям временных меток и их выполнение в одном и том же порядке всеми репликами. Но если транзакция распространяется на несколько узлов, то отсутствует гарантия, что она будет во всех узлах успешно выполнена или аварийно завершена. Поэтому каждый исполнитель должен послать диспетчеру выполнения транзакции (в том узле, в котором она была инициирована) сообщение "аварийное завершение" или "нормальное завершение" в той точке своей части транзакции, после которой соответствующее решение изменить уже нельзя (для двухфазных транзакций – в конце первой фазы). Диспетчер, в свою очередь, должен рассылать эти сообщения в другие узлы-исполнители. Другими словами, в этом случае приходится выполнять обычную процедуру фиксации распределенной транзакции. Если транзакция является строго двухфазной, этих накладных расходов можно избежать.

Основные черты

  1. Бескомпромиссное использование подхода shared-nothing – каждому разделу базы данных (основному или резервному) соответствует в точности один поток управления, и в потоках управления не используются общие ресурсы, даже если они реализуются ядрами одного и того же процессора;
  2. Поддержка баз данных в основной памяти; долговременность хранения обеспечивается только за счет репликации данных в разных узлах кластера;
  3. Выполнение транзакций поблизости от данных без потребности в передаче по сети операций SQL и их результатов;
  4. Стремление к минимизации числа распределенных транзакций за счет статического анализа и преобразований транзакций, а также за счет разделения данных с учетом рабочей нагрузки.

Архитектура

H-Store высоко оптимизирован для трех основных функций приложений OLTP:

  1. Большинство транзакций в рабочей нагрузке OLTP имеют доступ только к небольшому подмножеству кортежей.
  2. Большинство транзакций имеют короткие сроки выполнения.
  3. Большинство транзакций неоднократно вычерчиваются из предопределенного набора хранимых процедур.

Основываясь на этих наблюдениях, H-Store был разработан как параллельная реляционная СУБД с резервированием строк, которая работает на кластере узлов общего назначения без общих ресурсов.

Мы определяем один экземпляр H-Store как кластер из двух или более вычислительных узлов, развернутых в пределах одного и того же административного домена. Узел представляет собой единую физическую компьютерную систему, на которой размещаются один или несколько сайтов-исполнителей и один координатор транзакций. Сайт является логическим операционным объектом в системе; это однопоточный механизм выполнения, который управляет некоторой частью базы данных и отвечает за выполнение транзакций от имени своего координатора транзакций. Координатор транзакций отвечает за обеспечение сериализации транзакций вместе с координаторами, расположенными в других узлах. Мы предполагаем, что типичный узел H-Store содержит один или несколько многоядерных процессоров, каждый из которых имеет несколько аппаратных потоков на ядро. Таким образом, несколько узлов назначаются узлам независимо друг от друга и не используют никаких структур данных или памяти.

Каждая таблица в H-Store горизонтально разделена на несколько фрагментов, каждая из которых состоит из непересекающегося подсектора всей таблицы. Границы фрагментов таблицы основаны на выборе атрибута разбиения (т. е. столбца) для этой таблицы; каждый кортеж присваивается фрагменту, основанному на хэш-значениях этого атрибута. H-Store также поддерживает разбиение таблиц на несколько столбцов. Связанные фрагменты из нескольких таблиц объединены вместе в раздел, который отличается от всех других разделов. Каждому разделу присваивается ровно один сайт.

Все кортежи в H-Store хранятся в основной памяти на каждом узле; системе никогда не нужно обращаться к диску для выполнения запроса. Но он должен реплицировать разделы, чтобы обеспечить как долговечность данных, так и доступность в случае сбоя узла. Репликация данных в H-Store происходит двумя способами: (1) репликация разделов на нескольких узлах и (2) репликация всей таблицы во всех разделах (т. е. количество фрагментов для таблицы равно единице, и каждый раздел содержит копию этот фрагмент). Для первого мы принимаем концепцию k-безопасности, где администратор определяет $k$ как число отказов узлов, которые может терпеть база данных до того, как она будет признана недоступной.

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

Каждый экземпляр хранимой процедуры, выполняемой в ответ на запрос клиента, называется транзакцией. Аналогично таблицам, хранимым процедурам в H-Store присваивается атрибут разбиения на один или несколько входных параметров. Когда новый запрос поступает на узел, координатор транзакции хэширует значение параметра разбиения на процедуру и направляет запрос транзакции на сайт с тем же идентификатором, что и хэш. Когда запрос поступает на соответствующий сайт, система вызывает код управления Java, который будет использовать API-интерфейс H-Store для очереди одного или нескольких запросов в пакете. Управляющий код вызывает другую команду в H-Store для блокировки транзакции, пока механизм выполнения выполняет пакетные запросы.

Системные требования

Поддерживаемые платформы

H-Store работает на следующих платформах. Обратите внимание, что он не будет компилироваться в 32-битных системах.

  1. Ubuntu Linux 9.10+ (64-bit)
  2. Red Hat Enterprise Linux 5.5 (64-bit)
  3. Mac OS X 10.6+ (64-bit)

Требования

Перед созданием H-Store на вашем локальном компьютере должны быть установлены следующие пакеты. Дополнительную информацию о настройке узлов выполнения см. в документации по настройке среды[Источник 3]:

  1. gcc/g++ +4.3
  2. JDK +1.6
  3. Python +2.7
  4. Ant +1.7
  5. Valgrind +3.5

Версии

  1. Github Release Tags
  2. Original H-Store Prototype VLDB 2007 (489K)

Дополнительные файлы

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

 ant junit-getfiles

Чтобы автоматически обновить локальную копию до последней версии, используйте команду junit-getfiles-update:

 ant junit-getfiles-update

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

Установка

Скачать

Последняя версия H-Store доступна для загрузки из публичного репозитория Github.

 git clone git://github.com/apavlo/h-store.git

Создание

Чтобы создать всю базу данных H-Store сразу, выполните следующую команду:

 ant build

Обратите внимание, что H-Store будет компилироваться только на 64-битных платформах.

Чтобы очистить и затем скомпилировать часть Java в системе, используйте clean-java и build-java.

 ant clean-java build-java

Кроме того, вы можете создать только JNI-библиотеку H-Store, используя цель build-cpp:

 ant clean-cpp build-cpp

Ant

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

Компонент Ant Описание
Google ProtocolBuffers protobuf ProtocolBuffer компилятор и поддержка библиотек.
ProtoRPC API protorpc Создание файлов Java ProtoRPC API с использованием компилятора ProtocolBuffer
Frontend Java System build-java Фронтальные обертки, транзакционные оценки, системные каталоги и другие компоненты исполнения.
Backend Execution Engine build-cpp Библиотека C ++ JNI для хост-сервера H-Store. Обратите внимание, что сначала необходимо скомпилировать интерфейс Java, чтобы генерировать файлы заголовков JNI.

Каждый подкомпонент также может быть выборочно очищен следующими командами. Используйте clean-all для удаления всего каталога $ HSTORE_HOME / obj.

Компонент Ant Description
ProtoRPC API clean-protorpc Файлы API ProtoRPC, созданные компилятором ProtocolBuffer
Frontend Java System clean-java Все Java-компоненты и тестовые примеры.
Backend Execution Engine clean-cpp Backend C++.

Настройка среды

Каждая машина в вашем кластере H-Store должна иметь доступ к учетным записям без пароля. Это позволит системе развернуть JVM H-Store на каждом хосте и выполнить тест производительности.

 ssh-keygen -t dsa # Do not enter in a password
cat ~/.ssh/id_dsa.pub >> ~/.ssh/authorized_keys

Дополнительную информацию см. на странице документации по настройке среды.

Настройка H-Store

H-Store поставляется с предварительно написанными тестовыми приложениями, которые могут использоваться для различных экспериментов. Первый шаг - создать новый каталог для эталона, который вы хотите выполнить, используя команду hstore-prepare:

 ant hstore-prepare -Dproject=$BENCHMARK

Значение $BENCHMARK должно быть одним из поддерживаемых эталонных типов (например, tpcc, tm1, auctionmark и т. д.). Создается новый JAR-файл с именем «$BENCHMARK.jar» в корневом каталоге хранилища H-Store. По умолчанию hstore-prepare создает каталог с кластером из одного узла (localhost) на двух сайтах, каждый из которых имеет два раздела. Вы можете использовать файл настраиваемых спецификаций, который определяет макет хоста / сайта / раздела целевого кластера.

Запуск тестов

Чтобы запустить экземпляр H-Store для одного узла, вы можете использовать команду hstore-benchmark. Это запустит кластер H-Store на узлах, определенных в файле проекта jar, а затем выполнит тест с использованием одного клиентского процесса.

 ant hstore-prepare -Dproject=$BENCHMARK

Например, чтобы запустить тест TPC-C, замените переменную $BENCHMARK на tpcc и выполните следующую команду:

 ant hstore-benchmark -Dproject=tpcc

Если вам нужно переопределить значение localhost по умолчанию, вы можете передать параметр global.defaulthost в hstore-prepare, когда вы создали файл .jar:

 ant hstore-prepare hstore-benchmark \
    -Dproject=$BENCHMARK \
    -Dglobal.defaulthost=hostname.mit.edu

Чтобы запустить тестовые клиентские драйверы в BenchmarkController на другом наборе хостов, вы можете использовать параметр client.host. Это может быть список, разделенный запятыми, если вы хотите использовать несколько хостов. Обратите внимание, что вам не требуется повторно создавать файл .jar.

 ant hstore-benchmark \
     -Dproject=$BENCHMARK \
     -Dclient.host=client0.mit.edu,client1.mit.edu,client2.mit.edu

По умолчанию hstore-prepare создает каталог с кластером только из одного узла (global.defaulthost) двух сайтов, каждый из которых имеет два раздела. Вы можете использовать файл настраиваемой спецификации, который определяет макет хоста / сайта / раздела целевого кластера и использовать параметр hosts для передачи этого файла при создании каталога:

 ant hstore-prepare -Dproject=tpcc -Dhosts=/path/to/cluster.txt

Кроме того, вы можете указать конфигурацию кластера непосредственно из командной строки. Опция hosts также принимает список триплетов, разделенных запятой. Каждый триплет отформатирован как HOSTNAME: SITE #: PARTITION #. PARTITION # может быть либо одним номером раздела, либо разделенным запятой номерами разделов, либо диапазоном номеров разделов. Например, следующая команда создаст кластер, где host0.csail.mit.edu будет выполняться с HStoreSite # 0, который управляет разделами # 0, # 1, # 2 и # 3, а host1.csail.mit.edu будет выполняться HStoreSite # 1, который управляет разделами # 4, # 5, # 6 и # 7:

 ant hstore-prepare -Dproject=tpcc -Dhosts="host0.csail.mit.edu:0:0-3;host1.csail.mit.edu:1:4,5,6,7"

Вы можете использовать команду catalog-info для просмотра конфигурации кластера для целевого файла jar:

 ant catalog-info -Dproject=tpcc
  Catalog File:    tpcc.jar
  # of Hosts:      2
  # of Sites:      2
  # of Partitions: 8
  ----------------------------------------------------------------------
  Cluster Information:
 
  [00] HOST host0.csail.mit.edu ┃ [01] HOST host1.csail.mit.edu
       └ SITE H00: [0, 1, 2, 3] ┃      └ SITE H01: [4, 5, 6, 7]

Выполнение тестов

 ant hstore-benchmark -Dproject=$BENCHMARK

Выполнение отдельных транзакций

Для выполнения транзакций по одному (вместо использования встроенного BenchmarkController) вы можете использовать команду hstore-invoke. В этом примере мы сначала запускаем кластер H-Store, используя hstore-benchmark, но передаем параметр noexecute, чтобы предотвратить выполнение полной рабочей нагрузки и опции noshutdown, чтобы система оставалась в сети после завершения фазы загрузки:

 ant hstore-benchmark -Dproject=$BENCHMARK -Dnoexecute=true -Dnoshutdown=true

В конце вы получите сообщение о том, что кластер базы данных H-Store останется в сети до тех пор, пока не получит сигнал об ошибке (SIGINT или выше). Теперь вы можете выполнить hstore-invoke для выполнения транзакций индивидуально. Эта команда будет подключаться к случайному HStoreSite в кластере и выполнять новую транзакцию. Параметр proc - это имя процедуры, которую вы хотите вызвать, а параметры - это список параметров, используемых для этого запроса транзакции, разделенных запятыми. Эти параметры будут отображены в соответствии с информацией о каталоговом контроле для этой процедуры.

Например, чтобы выполнить процедуру GetAccessData из теста TM1, мы можем выполнить следующую команду. Обратите внимание, что строковые параметры должны быть заключены в кавычки:

 ant hstore-invoke -Dproject=tm1 -Dproc=GetAccessData -Dparam0=100 -Dparam1=1

Исходный вывод из узла H-Store будет выведен на экран:

 GetAccessData Txn #1027476228166123520 - Status OK
 [00]:  header size: 43
        status code: -128 column count: 4
        cols (DATA1:SMALLINT), (DATA2:SMALLINT), (DATA3:STRING), (DATA4:STRING), 
        rows -
          147, 161, UHJ, JUETN,

Параметры командной строки

Название Значение по умолчанию Описание
noexecute false Не запускает клиенты и не выполняет часть рабочей нагрузки теста.
noshutdown false Не останавливает кластер базы данных H-Store. BenchmarkController будет ждать, пока он не будет прерван, прежде чем остановить все HStoreSites. Вам нужно отключить параметр конфигурации site.status_kill_if_hung, чтобы гарантировать, что база данных остается в сети, даже если нет работы для ее выполнения.
nodataload false Отключает загрузку данных тестирования. Выполняет только контрольную нагрузку
trace null Чтобы включить трассировки транзакций, укажите путь к файлу с этим параметром, чтобы указать, где H-Store будет записывать журналы трассировки.

Добавление свойств конфигурации

Конфигурационный файл H-Store управляется во время выполнения HStoreConf. Этот файл содержит все свойства конфигурации, которые используются при развертывании системы H-Store. Эти инструкции предназначены для добавления новых свойств в систему. Чтобы добавить новый параметр, сначала нужно решить, является ли это глобальным, клиентом или свойством сайта.

  1. global: Это параметры конфигурации, которые являются глобальными для сайтов или клиентов.
  2. client: Параметры конфигурации, которые влияют на поведение клиентов при выполнении теста.
  3. site: Параметры конфигурации, которые влияют на поведение выполнения каждого HStoreSite.

В этом примере мы предположим, что мы хотим добавить новый логический параметр сайта my_new_parameter. Это означает, что в HStoreConf в разделе «Конфигурация сайта» мы добавим нового члена данных:

@ConfigProperty(
    description="Describe what this parameter does.",
    defaultBoolean=true,
    experimental=false
)
public boolean my_new_parameter;

Аннотации @ConfigProperty используются для предоставления дополнительной информации о новом параметре. Поле описания используется для предоставления дополнительной информации о том, для чего используется свойство конфигурации. Экспериментальный флаг предупреждает других пользователей о том, используется ли этот параметр только для исследовательских экспериментов и не следует изменять, не понимая, что происходит в первую очередь. Поле по умолчанию определяет значение по умолчанию для параметра, если администратор не предоставляет его. Вы должны использовать правильное имя поля по умолчанию на основе того, является ли значение параметра конфигурации логическим (по умолчанию Boolean), целочисленным (defaultInt), длинным (по умолчанию), двойным (defaultDouble) или строкой (defaultString). Если значение по умолчанию для строки должно быть нулевым, вы можете использовать для поля defaultNull значение true.

После добавления нового свойства и успешного компиляции кода вы должны выполнить следующую команду для обновления build-common.xml. Этот файл содержит все свойства, которые могут быть переданы из командной строки. Команда hstore-dist автоматически выберет имя параметра и добавит его в build-common.xml.

 ant compile hstore-dist

Теперь вы можете передать свое свойство конфигурации из командной строки при развертывании H-Store:

 ant hstore-benchmark -Dproject=tpcc -Dsite.my_new_parameter=true

Настройка H-Store в Eclipse

Автоматическая настройка

Следующие инструкции предполагают, что вы установили плагин EGit, чтобы включить Eclipse в работу с репозиториями Git и правильно настроили ваши SSH-ключи в Github для обеспечения доступа без пароля.

  1. Создайте новое рабочее пространство для Eclipse (при необходимости)
  2. Выберите Файл → Импорт → Git → Проекты из Git.
  3. Когда появится следующая панель, нажмите кнопку «Клонировать ...». В следующем окне введите путь к хранилищу Github в поле URI в поле «Местоположение»:
     git@github.com:apavlo/h-store.git
    Нажмите "Далее.
  4. На следующей панели вы можете выбрать, какие ветки вы хотите клонировать из удаленного репозитория. Скорее всего, вам нужно только клонировать мастера. Нажмите "Далее.
  5. Выберите местоположение на вашем локальном компьютере, в котором вы хотите сохранить клонированный репозиторий. Вы можете оставить другие значения по умолчанию. Нажмите «Готово».
  6. Теперь он начнет вытаскивать репозиторий. После его завершения вы можете выбрать h-store и нажать «Далее».
  7. На следующей панели выберите пункт «Импорт существующих проектов» вверху и нажмите «Далее».
  8. Убедитесь, что флажок H-Store установлен на следующей странице и нажмите «Готово».

Форматирование исходного кода

Следующие шаги позволят настроить Eclipse для использования спецификаций форматирования и очистки по умолчанию для H-Store.

  1. Сначала загрузите эти два файла на локальный компьютер:
    -H-Store Eclipse Clean Up Settings
    -H-Store Eclipse Formatter Settings
  2. Откройте проект H-Store в Eclipse и выберите «Проект» → «Свойства» → «Стиль Java-кода».
  3. Нажмите «Очистить» в левом меню, а затем установите флажок «Включить специальные настройки проекта» в верхней части панели. Нажмите кнопку «Импорт», а затем выберите файл hstore-cleanup.xml с локального диска.
  4. Затем выберите параметр «Форматировать» в стиле Java Code и снова установите флажок «Включить специальные настройки проекта» в верхней части панели. Нажмите кнопку «Импорт», а затем выберите файл hstore-formatter.xml с локального диска.

Ручная настройка

  1. Выберите Файл → Новый → Проект Java. Как только панель мастера появится, снимите флажок «Использовать местоположение по умолчанию» и установите для каталога значение $ HSTORE / src. Нажмите «Далее», подождите немного, пока читает во всех исходных файлах.
  2. «Использовать местоположение по умолчанию» и установите для каталога значение $ HSTORE / src. Нажмите «Далее», подождите немного, пока читает во всех исходных файлах.
  3. На следующей панели нажмите «Ссылка на дополнительный источник» и добавьте следующее сопоставление:
Расположение папок Имя папки
$HSTORE/tests/frontend tests
$HSTORE/third_party/cpp/protobuf/java/src/main/java protobuf
$HSTORE/third_party/java/src third_party

Нажмите «Библиотеки» и нажмите кнопку «Добавить внешние jars». Перейдите в $ HSTORE / third_party / java / jars и выберите следующие:

  • ant.jar
  • ant-junit.jar
  • commons-codec-1.5.jar
  • commons-collections15-4.01.jar
  • commons-collections-3.2.1.jar
  • commons-configuration-1.6.jar
  • commons-logging-1.1.1.jar
  • commons-pool-1.5.5.jar
  • japex.jar
  • jung-algorithms-2.0.jar
  • jung-api-2.0.jar
  • jung-graph-impl-2.0.jar
  • jung-visualization-2.0.jar
  • junit-4.4.jar
  • log4j-1.2.15.jar
  • opencsv-2.3.jar
  • tools.jar
  • velocity-1.6.3.jar
  • velocity-1.6.3-dep.jar
  • weka-3.6.3.jar

Нажмите «Готово». Теперь он должен строиться без ошибок. Если сборка все еще не выполняется, вам может потребоваться изменить JRE, используемую Eclipse. Для этого выполните следующие действия: Нажмите «Проект» → «Свойства» → «Путь сборки Java» → «Библиотеки». Нажмите значок JRE внизу, а затем нажмите «Изменить». Переключите параметр «Alternate JRE» в «java-6-openjdk». Переключитесь в режим «Навигатор». Нажмите на белую стрелку в верхней части левой панели и выберите «Фильтры». Установите флажки для ". *" и "* .class" Чтобы улучшить функцию поддержки контента Eclipse (т. е. автозаполнение), нажмите «Окно» → «Настройки» → «Java» → «Редактор»> «Контент», а в разделе «Сортировка и фильтрация» нажмите ссылку «Фильтры типа». На этой панели вы можете добавить следующие фильтры:

  • org.apache.commons.collections.*
  • com.google.*
  • com.sun.*
  • com.vladium.*
  • java.rmi.*
  • net.sf.*
  • net.sourceforge.*
  • org.apache.velocity.*
  • org.doxygn.*
  • org.jcp.*
  • org.jfree.*
  • org.kohsuke.*
  • org.omg.*
  • org.w3c.*

Дополнительно

  1. Официальный сайт
  2. GitHub
  3. VoltDB
  4. Статья Сергея Кузнецова


Источники

  1. H-Store. "H-Store Release",. URL:http://hstore.cs.brown.edu (дата обращения: 24.12.2018)
  2. H-Store. "The End of an Architectural Era",. URL:http://hstore.cs.brown.edu/papers/hstore-endofera.pdf (дата обращения: 24.12.2018)
  3. H-Store GitHub. "GitHub",. URL:https://github.com/apavlo/h-store (дата обращения: 24.12.2018)