GridDB

Материал из Национальной библиотеки им. Н. Э. Баумана
Последнее изменение этой страницы: 16:57, 21 января 2019.
GriDB
GridDB.jpg
Разработчики: Toshiba
Выпущена: 2016; 3 years ago (2016)
Постоянный выпуск: v4.1
Написана на: C, Java
Операционная система: Linux, CentOS
Платформа: x86-64
Локализация: Английский, Японский
Тип ПО: NoSQL база данных
Веб-сайт griddb.net

GridDB представляет собой высоко масштабируемую базу данных NoSQL, наиболее подходящая для Internet of Things(IoT) и Big Data[Источник 1]. GridDB является инновационным решением, созданным компанией Toshiba для решения проблем в обработке больших данных. В основе принципов GridDB лежит предложение универсального хранилища данных, оптимизированного для Big Data, обеспечивающего высокую масштабируемость, настроенного на высокую производительность и обеспечивающего высокую надежность.

Основные достоинства GridDB

Оптимизировано для IoT

Модель данных Key Container GridDB расширяет типичное хранилище ключей-значений NoSQL. Эта модель представляет данные в виде коллекций, на которые ссылаются ключи. Ключ и контейнер являются эквивалентами именем таблицы и данных таблицы в реляционных базах данных (RDB). Моделирование данных в GridDB проще, чем с другими базами данных NoSQL, поскольку можно определить схему и спроектировать данные, аналогичные данным RDB[Источник 2].

Модель Key Container обеспечивает высокоскоростной доступ к данным используя языки Java и C. Данные в GridDB также запрашиваются через TQL, пользовательский SQL-подобный язык запросов. Базовый поиск с помощью команды WHERE и высокоскоростные операции условного поиска с помощью индексации предлагают большое преимущество для приложений, которые используют более быстрый поиск. GridDB поддерживает транзакции, в том числе с множественными записями из приложения. Транзакции в GridDB гарантируют ACID (атомарность, согласованность, изоляцию и долговечность) на уровне контейнера.

В GridDB выделяются два типа контейнеров: Collection-Container, контейнер общего назначения; и TimeSeries-Container, контейнер который предназначен для управления данными временных рядов [Источник 3] .

Рисунок 1 – Типы Контейнеров


Collection-Container

Тип контейнера для хранения и управления строками представлен на рисунке 2. У строки может быть ключ, но ключ не обязателен. Ключ может быть назначен одной строке или целому числу (только тип INTEGER или LONG) или данным типа времени. Данные, хранящиеся в этом контейнере, обычно считаются более «традиционными» (STRING, BOOLEAN, ARRAY и т.д.)[Источник 4]. Пример вызова данных и их просмотра представлен ниже:

Процесс извлечения данных

package sample;
 
import com.toshiba.mwcloud.gs.Collection;
import com.toshiba.mwcloud.gs.GSException;
import com.toshiba.mwcloud.gs.GridStore;
 
import sample.logic.GridDBLogic;
import sample.logic.WeatherStationLogic;
import sample.row.WeatherStation;
 
 
public class CollectionDeleteRow {
 
	public static void main(String[] args) throws GSException {
		GridStore store = null;
		try {
			WeatherStationLogic wsLogic = new WeatherStationLogic();
 
			// Create Connection
			store = wsLogic.createGridStore();
 
			// Get Collection
			Collection weatherStationCol =
					store.getCollection("weather_station", WeatherStation.class);

Процесс получения данных

try {
    System.out.println("ID \tName \t \t \tLongitude \tLatitude \tCamera");
    for (int i=0; i < WeatherStationLogic.JP_PREFECTURE; i ++) {
        // Retrieve row by key
        WeatherStation weatherStation=weatherStationCol.get (String.valueOf (i + 1));
        System.out.println (String.format("% - 3s \t% -20s \t% -10s \t% -10s \t% -5s",
        weatherStation.id, weatherStation.name, weatherStation.latitude,
        weatherStation.longitude, weatherStation.hasCamera));
    }
} Finally {
    // Close Connection
    weatherStationCol.close ();
}

Результат сбора данных

ID  Name                Longitude   Latitude    Camera
1   Hokkaido-Sapporo    43.06417    141.34694   true
2   Aomori-Aomori       40.82444    140.74      false
3   Iwate-Morioka       39.70361    141.1525    true
4   Miyagi-Sendai       38.26889    140.87194   false
5   Akita-Akita         39.71861    140.1025    true
(Snip)
Рисунок 2 – Collection Container

TimeSeries-Container

Тип контейнера для хранения и управления строками с ключом времени, снабженный специальной функцией для работы с данными типа TimeSeries. Ключ соответствует строке времени TimeSeries. Подходит для обработки больших объемов данных типа TimeSeries, генерируемых датчиками. Могут быть обработаны разнообразные данные, так как система поддерживает нестандартные данные, такие как данные массива, BLOB и другие данные. Уникальная функция сжатия и функция для выпуска данных с истекшим сроком действия предоставляются в контейнере TimeSeries, что делает его пригодным для управления данными, которые генерируются в больших объемах. Пример вызова контейнера TimeSeries и просмотра информации представлен ниже:

Процесс получения указанного времени

// Specify Time
InstrumentLog log=logTs.get (format.parse("2016/07/02 12:00"));
System.out.println("get by Time");
System.out.println (String.format("% s \ t% -20s \ t% -10s", log.timestamp, log.weatherStationId,
log.temperture));

Результат получения указанного времени

get by Time
Sat Jul 02 12:00:00 EDT 2016 weather_station_1 80.0

TimeSeries-Container подходит для IoT-сценариев, в которых данные связаны с отметкой времени. GridDB поддерживает множество функций временных рядов, например функция сжатия данных значительно уменьшает использование памяти по сравнению с другими СУБД.

Высокая производительность

Гибридная композиция GridDB с архитектурой In-Memory и Disk разработана для максимальной производительности. Ввод/вывод является распространенным узким местом в любой СУБД, которое может привести к критической загрузке ЦП. GridDB преодолевает это узкое место с помощью структуры «Memory first, Storage second», где первичные данные, к которым часто обращаются, находятся в памяти, а остальная часть передается на диски (SSD и HDD). Высокая производительность достигается в GridDB следующими способами:

  • Приоритизация обработки в памяти. В сценариях с большими объемами данных GridDB локализует доступ к данным, необходимый приложениям, размещая как можно больше первичных данных в одном и том же блоке. Основываясь на схеме доступа и частоте доступа приложения, GridDB эффективно использует пространство памяти, устанавливая функцию интенсивности памяти для подсказок и, таким образом, сокращает потери памяти.
  • Сокращение накладных расходов - эксплуатационные и коммуникационные накладные расходы возникают в многопоточных операциях из-за блокировки и синхронизации. GridDB устраняет это, выделяя эксклюзивную память и файл БД для каждого ядра или потока ЦП. В результате время выполнения сокращается и достигается лучшая производительность.
  • Параллельная обработка - GridDB достигает высокой производительности благодаря параллельной обработке внутри узла и между узлами. Параллельная обработка по узлам осуществляется путем распределения большого набора данных по нескольким узлам. Распараллеливание возможено благодаря управляемому событиями движку, который обрабатывает несколько запросов, используя наименьшее количество ресурсов.

Высокая масштабируемость

GridDB линейно и горизонтально масштабируется на стандартном оборудовании, поддерживая отличную производительность. Традиционные СУБД построены на архитектуре Scale-Up. Транзакции и согласованность данных превосходны в РБД. С другой стороны, базы данных NoSQL сосредоточены на архитектуре масштабирования (добавление меньших узлов для формирования большого кластера), но плохо отражаются на транзакциях и согласованности данных. GridDB масштабируется горизонтально с помощью аппаратного обеспечения, поддерживающего тот же уровень производительности. В отличие от других масштабируемых баз данных NoSQL, GridDB обеспечивает высокую согласованность данных на уровне контейнеров. Запатентованные алгоритмы GridDB позволяют добавлять узлы на лету в режиме онлайн без необходимости останавливать службу или работу.

Высокая надежность / доступность

Гибридное управление кластерами (см. рисунок 3) и высокая отказоустойчивость системы, являются исключительными аспектами для критически важных приложений. Сетевые разделы, сбои узлов и поддержание согласованности являются одними из основных проблем, возникающих при распределении данных по узлам. Как правило, распределенные системы используют архитектуру «Master-Slave» или «Peer-to-Peer». Архитектура «Master-Slave» хороша для обеспечения согласованности данных, но избыточность главного узла необходима, чтобы избежать единой точки отказа (SPOF). Архитектура «Peer-to-Peer», хотя и избегает SPOF, но также имеет огромную проблему накладных расходов связи между узлами. Архитектура автономного кластера управления GridDB объединяет преимущества и преодолевает недостатки стилей Master-Slave и Peer-to-Peer. Алгоритмы GridDB автоматически выбирают главный узел среди одноранговых узлов, и в случае сбоя главного узла операции остаются нетронутыми, так как новый мастер моментально назначается автоматически. Собственные алгоритмы GridDB позволяют избежать классической проблемы распределенных вычислений Split-Brain, которая возникает из-за разбиения кластера во время сбоев сети. GridDB также предлагает различные уровни репликации в зависимости от требований доступности приложения.

Рисунок 3 – Гибридное управление кластерами

Работа с БД

Версии

В настоящее время доступны две версии GridDB:

  • GridDB Community Edition (GridDB CE);
  • GridDB Standard Edition (GridDB SE).

GridDB CE доступен под AGPLv3 как высокопроизводительная база данных NoSQL с открытым исходным кодом, созданная с учетом масштабируемости и отказоустойчивости. Это единственная версия GridDB с открытым исходным кодом.

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

Сравнение каждого издания представлено на рисунке 4:

Рисунок 4 – Различия версий

Установка

Следующие инструкции предназначены для установки GridDB на CentOS с использованием диспетчера пакетов RedHat (RPM), утилиты пакетов Debian (dpkg) или извлечения из файла tar.

Установка с использованием RPM (RedHat Package Manager)

Запустите диспетчер пакетов RedHat (RPM) и укажите пакет GridDB.

Community Edition

Процесс установки: Необходимо перейти в папку, куда была скачена соответствующая версия GridDB,

$ cd <the mount path to the CD-ROM or DVD-ROM device>/Linux/rpm 
$ rpm –Uvh griddb-se-server-X.X.X-linux.x86_64.rpm
$ rpm –Uvh griddb-se-client-X.X.X-linux.x86_64.rpm

Замените номер X.X.X на номер соответствующей версии Также необходимо установить пакеты библиотек Java / C для разработки приложений GridDB.

$ rpm –Uvh griddb-se-c_lib-X.X.X -linux.x86_64.rpm 
$ rpm –Uvh griddb-se-java_lib- X.X.X -linux.x86_64.rpm  

Установка документации

$ rpm –Uvh griddb-se-docs-X.X.X -linux.x86_64.rpm

Источники

  1. GridDB Documentation // Официальная документация [2018-2019]. Дата обновления: 20.11.2018. URL: https://griddb.net/en/documents/what-is-griddb/ (дата обращения: 20.01.2019)
  2. GridDB // Хранилище GitHub [2006-2019]. Дата обновления: 29.09.2018. URL: https://github.com/griddb (дата обращения: 20.01.2019)
  3. GridDB // Сайт разработчика [2018-2019]. Дата обновления: 29.10.2018. URL: http://griddb.org (дата обращения: 20.01.2019)
  4. Toshiba GridDB // Сайт разработчика [2019-2019]. Дата обновления: 15.01.2019. URL: http://solutions.toshiba.com/griddb.html (дата обращения: 20.01.2019)