OrientDB - Настройка производительности

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

Настройка производительности базы данных документов — в ней используется метод, помогающий избежать создания документа для каждого нового документа.
Настройка производительности базы данных объектов — использует общие методы для повышения производительности.
Настройка распределенной конфигурации — она использует различные методологии для повышения производительности в распределенной конфигурации.

Настройка производительности базы данных документов — в ней используется метод, помогающий избежать создания документа для каждого нового документа.

Настройка производительности базы данных объектов — использует общие методы для повышения производительности.

Настройка распределенной конфигурации — она использует различные методологии для повышения производительности в распределенной конфигурации.

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

Настройки памяти

Существуют разные стратегии в настройке памяти для улучшения производительности.

Сервер и встроенные настройки

Эти параметры действительны как для серверного компонента, так и для JVM, где приложение Java запускается с использованием OrientDB в встроенном режиме, напрямую используя plocal .

Самое главное при настройке — убедиться в правильности настроек памяти. Что может реально измениться, так это правильный баланс между кучей и виртуальной памятью, используемой отображением памяти, особенно в больших наборах данных (ГБ, ТБ и т. Д.), Где структуры кэша памяти имеют меньший объем, чем необработанный ввод-вывод.

Например, если вы можете назначить максимум 8 ГБ процессу Java, обычно лучше назначить малую кучу и большой буфер кеша диска (память вне кучи).

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

java -Xmx800m -Dstorage.diskCache.bufferSize=7200 ...

Параметр storage.diskCache.bufferSize (со старым «локальным» хранилищем это был file.mmap.maxMemory ) находится в МБ и сообщает, сколько памяти нужно использовать для компонента Disk Cache. По умолчанию это 4 ГБ.

ПРИМЕЧАНИЕ. — Если сумма максимальной кучи и буфера дискового кэша слишком велика, это может привести к перестановке ОС с огромным замедлением.

Настройки JVM

Настройки JVM кодируются в пакетных файлах server.sh (и server.bat). Вы можете изменить их, чтобы настроить JVM в соответствии с вашим использованием и настройками hw / sw. Добавьте следующую строку в файл server.bat.

-server -XX:+PerfDisableSharedMem

Этот параметр отключит запись отладочной информации о JVM. Если вам нужно профилировать JVM, просто удалите этот параметр.

Удаленные подключения

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

Выбор стратегии

При работе с удаленной базой данных вы должны обращать внимание на используемую стратегию выборки. По умолчанию клиент OrientDB загружает только запись, содержащуюся в наборе результатов. Например, если запрос возвращает 100 элементов, но если вы скрещиваете эти элементы с клиента, клиент OrientDB лениво загружает элементы еще одним сетевым вызовом на сервер для каждой пропущенной записи.

Пул сетевых подключений

Каждый клиент по умолчанию использует только одно сетевое соединение для связи с сервером. Несколько потоков на одном клиенте совместно используют один и тот же пул сетевых подключений.

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

Конфигурация очень простая, всего 2 параметра —

minPool — это начальный размер пула соединений. Значение по умолчанию настраивается как глобальные параметры «client.channel.minPool».
maxPool — это максимальный размер, который может достичь пул соединений. Значение по умолчанию настраивается как глобальные параметры «client.channel.maxPool».

minPool — это начальный размер пула соединений. Значение по умолчанию настраивается как глобальные параметры «client.channel.minPool».

maxPool — это максимальный размер, который может достичь пул соединений. Значение по умолчанию настраивается как глобальные параметры «client.channel.maxPool».

Если все соединения пула заняты, то клиентский поток будет ожидать первого свободного соединения.

Пример команды настройки с использованием свойств базы данных.

database = new ODatabaseDocumentTx("remote:localhost/demo"); 
database.setProperty("minPool", 2); 
database.setProperty("maxPool", 5);  

database.open("admin", "admin");

Настройка распределенной конфигурации

Есть много способов улучшить производительность распределенной конфигурации.

Использовать транзакции

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

Репликация против Шардинга

Распределенная конфигурация OrientDB настроена на полную репликацию. Наличие нескольких узлов с одной и той же копией базы данных важно для масштабного чтения. Фактически, каждый сервер независим от выполнения операций чтения и запросов. Если у вас есть 10 серверных узлов, пропускная способность чтения будет 10x.

С записью все наоборот: наличие нескольких узлов с полной репликацией замедляет операции, если репликация синхронная. В этом случае разделение базы данных между несколькими узлами позволяет увеличить масштаб записи, поскольку при записи участвует только подмножество узлов. Кроме того, вы можете иметь базу данных больше, чем один серверный узел HD.

Увеличьте на Пишет

Если у вас медленная сеть и у вас синхронная (по умолчанию) репликация, вы можете оплатить стоимость задержки. Фактически, когда OrientDB работает синхронно, он ожидает, по крайней мере, writeQuorum . Это означает, что если writeQuorum равен 3, а у вас 5 узлов, узел сервера-координатора (с которого начинается распределенная операция) должен ждать ответа как минимум от 3 узлов, чтобы предоставить ответ клиенту.

Чтобы поддерживать согласованность, для writeQuorum должно быть установлено большинство. Если у вас 5 узлов, то большинство — 3. При 4 узлах это все равно 3. Установка для writeQuorum значения 3 вместо 4 или 5 позволяет снизить стоимость задержки и при этом сохранить согласованность.

Асинхронная репликация

Чтобы ускорить процесс, вы можете настроить асинхронную репликацию, чтобы устранить узкое место задержки. В этом случае узел сервера-координатора выполняет операцию локально и дает ответ клиенту. Вся репликация будет в фоновом режиме. Если кворум не достигнут, изменения будут отменены прозрачно.

Расширять чтение

Если вы уже установили writeQuorum для большинства узлов, вы можете оставить readQuorum равным 1 (по умолчанию). Это ускоряет все чтения.

OrientDB — Настройка производительности