Пост 31. Многопользовательский доступ к данным. Чтение LOB.

В ходе тестироавния так же было интересно проверить поведение системы при многопользовательском доступе. Для это было проведено следующее испытание: последовательно раз в 2 минуты запускался поток на чтение данных из базы. При этом как и в предыдущих тестах снимались все нагрузочные показатели. 

На подсистеме ввода-вывода наблюдается инкрементальный рост до некоторой величины, которая является пределом пропускной способности.

IO (Kb/sec) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).

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

IO (операций в секунду) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).

Интересен и следующий график - на нем представлена зависимость времени выполнения операции (ось Y) в зависимости от колличества одновременных пользователей (ось X).

Зависимость времени выполнения одной операции от колличества одновременных пользователей  (для увеличения кликните на картинку).

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

Обращу внимание, что в данном случае исследовалось поведение системы в случае с LOB объектами.

Пост 30. Результыты тестирования Oracle NoSQL Database. Поведение системы во время расширения.

Итак, как показало тестирование, описанное в предыдущем посте Oracle NoSQL Database - масштабируемая база данных. Как же система ведет себя во время расширения? Давайте рассмотрим следующий тест кейс.

Описание тест кейса:Кластер расширяется с 6 узлов до 9
10:37 Добавление трех узлов в кластер
10:45 Старт нагрузки на чтение
11:43 Стоп нагрузки на чтение
11:50 Старт нагрузки на запись
12:10 Стоп нагрузки на запись

IO (Kb/sec) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).

Network (MBytes/sec) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).

CPU (Idle %) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).

Выводы:
1)Вновь добавленные сервера утилизируют все имеющиеся ресурсы для достижения консистентного состояния
2)Уже имеющиеся сервера так же используют значительную часть ресурса для достижения кластером консистентного состояния
3)Данные для чтения на новых серверах доступны как только они были туда перенесены
4) Запись файлов равномерно нагружает «новые» и «старые» узлы
5) Нулевое время простоя системы

Пост 29. Результыты тестирования Oracle NoSQL Database. Масштабируемость.

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

Описание тестовой нагрузки на БД:
17:15 Запись нагрузки на чтение (20 потоков)
17:24 Выведение из строя 6 серверов
17:30 Возвращение в строй ранее выведенных серверов



IO (Kb/sec) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).



Network (Bytes/sec) как функция от времени для всех узлов кластера (для увеличения кликните на картинку)

CPU (Idle %) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).

Выводы:
Oracle NoSQL Database пытается равномерно распределить нагрузку между серверами. Чем больше серверов – тем меньше нагрузка на каждый из них.
В случае добавления новых узлов в кластер (расширение) – часть нагрузки перейдет на них.

Пост 28. Результыты тестирования Oracle NoSQL Database. Восстановление после сбоев.

Доброго времени суток!

Итак, я прождолжаю серию постов посвященную тестированию базы данных NoSQL.

В этом тесте хотелось посмотреть поведение базы данных при сбое серверов и последующемм вводе их обратно в кластер.

Описание тестовой нагрузки на БД:
15:11 – Старт записи в NoSQL DB в 5 потоков (18 узлов кластера доступно)
15:37, 15:42 – Последовательное выведение из строя 6 узлов
15:47 – Возврат нод в кластер
15:50 – Конец восстановления

IO (Kb/sec) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).Во время восстановления на каждой ноде нагрузка было около 850 Mbytes/sec

Network (Bytes/sec) как функция от времени для всех узлов кластера (для увеличения кликните на картинку)
Во время восстановления сеть утилизирована на 18 Gbit/sec.

CPU (Idle %) как функция от времени для всех узлов кластера (для увеличения кликните на картинку).
Во время восстановления используется 50% процессорного ресурса.

"Всплески" обусловлены тем, что база данных копировала данные, записанные после вывода из строя серверов на вновьпоявившиеся ноды.

Выводы:
Oracle NoSQL Database затрачивает все имеющиеся ресурсы для достижения консистентного состояния
В ходе данного теста:

-Дисковая система использовала максимальный ресурс около 850 Мбайт/сек
-Сеть была загружена на 18 Гбит/сек. Сеть Infiniband (интерконект) необходима для скорейшего восстановления системы после сбоя одного из узлов или дисков
-Процессоры загружены на 50% во время репликации недостающих данных на вновь появившиеся сервера

Пост 27. Результыты тестирования Oracle NoSQL Database. Чтение файлов.

Доброго вермени суток!
Как я писал ранее не так давно удалось поучавствовать в одном крупном тестированни базы данных NoSQL. Подробности тут. А в этом посте я хотел бы описать что происходило с базой во время чтения.

Чтение файлов из базы

Описание нагрузки на БД: 10:00 – 11:30 старт чтения из базы в 240 потоков
Конфигурация:15 узлов BDA использовались под Oracle NoSQL DB, 3 ноды использовались под сервер приложений

В коде программы использовались следующие настройки:

1)Порция чтения:
byte[] bytes = new byte[1024];

2) Consistency на чтение
Consistency.NONE_REQUIRED
Использовалось потому что запись производилась с опцией
Durability.ReplicaAckPolicy.ALL

3) Один поток – один экземпляр Java программы который вычитывает 1 Гб из базы в цикле

Зависимость ввода вывода KB/sec в зависимости от времени для каждого узла (для увеличения кликните на картинку).

IO каждого сервера 450 Mbytes/sec

Загруженность сети для каждого узла BDA (bytes/sec) в зависимости от времени (для увеличения кликните на картинку).
Сеть загружена равномерно на 3,8 Gbit/sec

Зависмость процессорной нагрузки для каждого из сервров (процент занятого ресурса) в зависимости от времени (для увеличения кликните на картинку).
CPU на всех узлах нагружено примерно на 20 %.

Выводы:

1)Во время записи файлов нагрузка ложится равномерно на все узлы кластера (IO, Network, CPU)
2)Пропускная способность на чтение 4 Gbytes/sec на одну стойку BDA
Во время максимальной нагрузки:
- IO каждого сервера примерно 450 Mbytes/sec
- Сеть на всех узлах нагружена равномерно на 3,8 Gbit/sec (репликация данных по интерконнекту).
В данном случае используются преимущества Infiniband.
- CPU равномерно загружена на всех узлах кластера на 20%

Пост 26. Результыты тестирования Oracle NoSQL Database. Запись файлов.

Доброго времени суток!
Не так давно мне посчастливилось поучавствовать в тестировании базы данных Oracle NoSQL Database на достаточно большом кластере, для достаточно интересной задачи. Пользуясь случаем хотел бы поделиться с широкой публикой результатами тестирования.

Итак, для начала постановка задачи:
1.Заказчик изготавливает авиадвигатели
2. В ходе испытаний двигателя генерится большое количество телеметрии
3. Эти данные требуются экспертам для анализа сразу после проведения испытания
4. Уже есть приложение для анализа этих данных

Теперь подробности:

- Ожидаемый объем хранилища 2.5 Pb
- Ожидаемое количество файлов 1-2милиарда
- Размер одного файла 1 Mb – 2 Gb
- Вся информация критична. Потери данных невозможны
- Требуется поддержка 20 одновременных пользователей на чтение
- Требуется поддержка 50 одновременных пользователей на запись
- Пропускная способность на запись не ниже 200 MBytes/sec
- Пропускная способность на чтение не ниже 500 MBytes/sec
- Сервер приложений работает под Windows
- Решение должно быть масштабируемым. Планируется докупать оборудование без изменений программной части
- Высокая скорость восстановления после сбоев

На данный исторический момент заказчик хранит все в СУБД Oracle. Файлы испытаний хранятся в BLOB колонках. Сама структура базы данных весьма запутана, содержит множество таблиц и связей между ними. Поисковое приложение позволяет достаточно гибко осуществлять поиск по файлам испытаний. Переделать все в структуу ключ-значение было достаточно сложно.

Поэтому предлагалась следующая архитектура:

От пользователя запрос по-прежнему уходил в СУБД, но вместо BLOB приложению возвращалась ссылка на ключ в файлом (varchar2), по которому приложение вытягивало файл и обрабатывало.

Используемое оборудование для кластера NoSQL:

Big Data Appliance x2-2:
18 узлов для вычислений и хранения данных
Для каждого узла:2 шестиядерных процессора Intel ® Xeon ® 5675 (3,06 ГГц)
48 Гб оперативной памяти
12 дисков SAS емкостью 3 Тбайт и скоростью 7200 RPM
Сеть Infiniband (40 Гбит/с)

Сервер приложений:
Sun Server X3-2L Server
CPU: Intel Xeon E5-2690 2 шт, 8 ядер, 2.9GHz
Память: 256 Гбайт
Storage: 8x 600Гбайт 10K
Сеть: 1 Гбит/сек, Infiniband 40 Гбит/сек

Запись в NoSQL производилась в LOB пары ключ - значение.

Теперь собственно тесты.

1.Запись файлов в базу

Описание нагрузки на БД:
16:05 – 16:45 запись фалов в 120 потоков (имитация 120одновременных пользователей).

15 серверов BDA использовались для NoSQL хранилища, 3 BDA узла для серверов приложений.

В коде программы использовались следующие настройки:

1) Durability
Durability.SyncPolicy.WRITE_NO_SYNC, on masterDurability.SyncPolicy.WRITE_NO_SYNC, on replicasDurability.ReplicaAckPolicy.ALL

2) Использовалось LOB API
putLOB(myKey, fis, durability, 30, TimeUnit.SECONDS)

3) Replication factor = 3

4) Один поток – один экземпляр Javaпрограммы который записывает 1 Гб данных в базу в цикле (ключи различные)

Зависимость ввода вывода KB/sec в зависимости от времени для каждого узла (для увеличения кликните на картинку).

Подсистема ввода-вывода серверов кластера базы данных NoSQL при записи фалов в базу.

Среднее значение IO для каждой ноды BDAоколо 750 Mb/sec

Загруженность сети для каждого узла BDA (bytes/sec) в зависимости от времени для каждого узла  (для увеличения кликните на картинку)

Сеть равномерно загружена на всех узлах кластера на 18,6 Gbit/sec (репликация данных по интерконнекту).

Зависмость процессорной нагрузки для каждого из сервров (процент занятого ресурса) в зависимости от времени  (для увеличения кликните на картинку).

CPU равномерно загружена на всех узлах кластера на 40 – 50%

Выводы:1) Во время записи файлов нагрузка ложится равномерно на все узлы кластера (IO, Network, CPU)
2) Пропускная способность на запись 4 Gbytes/sec на одну стойку BDA

3) Во время максимальной нагрузки:
- IO каждого сервера примерно 2700 операций/сек или 750 Mbytes/sec
- Сеть на всех узлах нагружена равномерно на18,6 Gbit/sec (репликация данных по интерконнекту).
В данном случае используются преимущества Infiniband.
-CPU равномерно загружена на всех узлах кластера на 40 – 50%
4) Узким местом системы являются диски.

Продолжение следует!

Пост 25. Добавление новых узлов в кластер. Увеличение репликационного фактора для увеличения пропускной способности на чтение.

Доброго времени суток.
Допустим вы имеете базу данных Oracle NoSQL и столкнулись с проблемой чтения данных из базы. Как решить эту проблему? Давайте добавим новых узлов в шард (увеличим репликационный фактор) - тем самым мы увеличим колличество узлов с которых можно читать одни и те же данные.
Допустим у вас есть четырехузловая конфигурация (2 шарда, репликационный фактор 2), как показано на картинке:

Создавалась такая конфигурация следующим скриптом:

[root@datanode1 ~]# cat deploy_rf2.txt

configure -name "FilDB"

plan deploy-datacenter -name "FilDC" -rf 2 -wait

plan deploy-sn -dc dc1 -host datanode1 -port 5011 -wait

plan deploy-admin -sn sn1 -port 5001 -wait

plan deploy-sn -dc dc1 -host datanode2 -port 5012 -wait

plan deploy-sn -dc dc1 -host datanode3 -port 5013 -wait

plan deploy-sn -dc dc1 -host datanode4 -port 5014 -wait

pool create -name FilPool

pool join -name FilPool -sn sn1

pool join -name FilPool -sn sn2

pool join -name FilPool -sn sn3

pool join -name FilPool -sn sn4

topology create -name topo -pool FilPool -partitions 300

plan deploy-topology -name topo -wait

[root@datanode1 ~]# kvadmin load -file deploy_rf2.txt

Теперь из этой схемы мы хотим сделать следующую:

Просто  выполним скрипт:

[root@datanode1 ~]# cat change_rf.txt

plan deploy-sn -dc dc1 -host datanode5 -port 5015 -wait

plan deploy-sn -dc dc1 -host datanode6 -port 5016 -wait
pool join -name FilPool -sn sn5
pool join -name FilPool -sn sn6
topology clone -current -name NewTopo
topology change-repfactor -name NewTopo_chrf -pool FilPool -rf 3 -dc dc1
plan deploy-topology -name NewTopo_chrf -wait

[root@datanode1 ~]# kvadmin load -file change_rf.txt

Таким образом мы добавили 2 ноды в кластер и увеличили репликационный фактор системы до 3х (тем самым увеличив пропускную способность на чтение). Колличество шардов, при этом не поменялось. Новые ноды будут отрабытывать запросы на чтение.