Orientdb 简明教程
OrientDB - Performance Tuning
在本章中，你可以获得一些关于如何优化使用 OrientDB 的应用程序的一般性技巧。有三种方法可以提高不同类型数据库的性能。
-
Document Database Performance Tuning − 它使用一种有助于避免为每个新文档创建文档的技术。
-
Object Database Performance Tuning − 它使用通用技术来提高性能。
-
Distributed Configuration Tuning − 它使用不同的方法来提高分布式配置中的性能。
你可以通过更改内存、JVM 和远程连接设置来实现通用性能调整。
Memory Settings
在内存设置中有不同的策略可以提高性能。
Server and Embedded Settings
这些设置对服务器组件和在嵌入模式下直接使用 plocal 运行 Java 应用程序的 JVM 均有效。
调优最重要的在于确保内存设置正确。决定性因素在于正确平衡内存映射中使用的堆和虚拟内存，特别是在大数据集方面（GB、TB 及以上），在这种情况下，内存内缓存结构的重要性低于原始 IO。
例如，如果可以将最高 8GB 分配给 Java 进程，那么通常分配小堆和较大的磁盘高速缓存（堆外内存）会更好。
尝试以下命令增加堆内存。
java -Xmx800m -Dstorage.diskCache.bufferSize=7200 ...设置 storage.diskCache.bufferSize （旧“本地”存储为 file.mmap.maxMemory ）以 MB 为单位，说明磁盘高速缓存组件使用多少内存。默认值为 4GB。
NOTE − 如果最大堆和磁盘高速缓存的总和过高，可能会导致操作系统因巨大减速而交换。
JVM Settings
JVM 设置编码在 server.sh（和 server.bat）批处理文件中。您可以更改它们来根据您的使用情况和硬件/软件设置来调整 JVM。在 server.bat 文件中添加以下行。
-server -XX:+PerfDisableSharedMem此设置将禁用 JVM 的调试信息写入。如果您需要分析 JVM，只需移除此设置。
Remote Connections
使用远程连接访问数据库时有许多方法可以提高性能。
Fetching Strategy
使用远程数据库时，您必须注意所使用的获取策略。默认情况下，OrientDB 客户端仅加载结果集中包含的记录。例如，如果查询返回 100 个元素，但您如果从客户端遍历这些元素，则 OrientDB 客户端会延迟为每个丢失的记录向服务器进行一次网络调用来加载元素。
Network Connection Pool
默认情况下，每个客户端仅使用一个网络连接与服务器通信。同一客户端的多个线程共享相同的网络连接池。
当有多个线程时，可能会出现瓶颈，因为要等待释放网络连接而花费大量时间。这就是配置网络连接池很重要的原因。
配置非常简单，仅有 2 个参数 −
-
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");Distributed Configuration Tuning
通过分布式配置提高性能有很多方法。
Use Transactions
即使更新图形，您也应始终在事务中工作。OrientDB 允许您在事务之外工作。常见情况是只读查询，或者在发生故障时可以恢复的庞大且非并发操作。当您在分布式配置上运行时，使用事务有助于降低延迟。这是因为分布式操作仅在提交时发生。由于延迟，分配一个大操作比传输多个小操作更有效。
Replication vs Sharding
OrientDB 分布式配置设置为完全复制。拥有多个具有相同数据库副本的节点对于扩展读取非常重要。事实上，每台服务器都是独立执行读取和查询的。如果您有 10 个服务器节点，则读取吞吐量就是 10 倍。
对于写入操作，正好相反：如果复制是同步的，则具有完全复制的多个节点会使操作变慢。在这种情况下，将数据库分片到多个节点可以扩展写入，因为只有部分节点参与写入。此外，你的数据库可以大于一个服务器节点的 HD。
Scale up on Writes
如果你有慢速网络，并且有同步（默认）复制，则可能会付出延迟的代价。事实上，当 OrientDB 同步运行时，它至少等待 writeQuorum 。这意味着，如果 writeQuorum 为 3，并且有 5 个节点，则协调器服务器节点（分布式操作在那里启动）必须至少等待来自 3 个节点的响应，才能向客户端提供响应。
为了保持一致性，应将 writeQuorum 设置为多数。如果你有 5 个节点，则多数为 3。将 writeQuorum 设置为 3 而不是 4 或 5 可以降低延迟成本，同时仍保持一致性。