Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cluster insert update performance exception #8944

Closed
arendtmeng opened this issue May 9, 2019 · 3 comments
Closed

Cluster insert update performance exception #8944

arendtmeng opened this issue May 9, 2019 · 3 comments

Comments

@arendtmeng
Copy link

ArangoDB Version: 3.3.16
Storage Engine: RocksDB
Deployment Mode: Cluster Mode
Deployment Strategy: Manual Start in stater
Cluster Nodes: 52core, 256GB, 3TB
Data volume: 1--5 billion
Cluster Deployment command:
arangodb --auth.jwt-secret "/data/arangodb/auth" --starter.data-dir=/data/arangodb/adb01 --server.storage-engine=rocksdb --starter.host=192.168.1.244 &
arangodb --auth.jwt-secret "/data/arangodb/auth" --starter.data-dir=/data/arangodb/adb02 --server.storage-engine=rocksdb --starter.join 192.168.1.244:8528 &
arangodb --auth.jwt-secret "/data/arangodb/auth" --starter.data-dir=/data/arangodb/adb03 --server.storage-engine=rocksdb --starter.join 192.168.1.244:8528 &

Single Deployment Command:
yum localinstall -y arangodb3-3.3.16-1.x86_64.rpm
systemctl start arangodb3

  1. Why is the speed of insertion and update of data in single-point mode nearly 20%-30% faster than that in cluster mode?

  2. The cluster deployed in this way has three Coordinator access links. If a read-write request is sent to the Coordinator of the node 1 node, will the request be processed only at the node 1 node, or will it be processed with all the nodes?

  3. Cluster mode, the collection uses three shared and one replication. When a large number of data updates are carried out, the lower part of Follow shows yellow, and all the other unupdated collection fragments are green. What state does this yellow mean? What impact will it have?

@graetzer
Copy link
Contributor

to a degree it is expected that the latency of a single write is higher in the cluster, because there is an additional network hop from coordintor -> DBserver.
The upside is that the entire system should be more scalable in total

@HansonZhu-bd
Copy link

1.Does this yellow state affect the high available of ArangoDB cluster? When importing in batches, the import time took about 2-3 hours, but it takes 3-4 days for the yellow state to become green,Is this normal?
2.When the import completed, we restart the Arango cluster,and make a query, there will be a problem that the collection cannot be found.Does it coused by the yellow alarm status?
3.What does this yellow state mean? Whether the underlying copy synchronization is completed?The yellow state is just a delayed performance of the web page about the underlying synchronization.

@dothebart
Copy link
Contributor

ArangoDB 3.3 is EOLed. Meanwhile ArangoDB 3.7 is available. Closing as solved.

@dothebart dothebart added the 2 Solved Resolution label Sep 2, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants