Merge branch 'main' into aql-timezone

Author: Simran-B

site/content/3.10/about-arangodb/features/_index.md

@@ -9,7 +9,63 @@ archetype: chapter
 aliases:
   - ../introduction/features
 ---
-## Editions
+## On-premises versus Cloud
+
+### Fully managed cloud service
+
+The fully managed multi-cloud
+[ArangoGraph Insights Platform](https://dashboard.arangodb.cloud/home?utm_source=docs&utm_medium=cluster_pages&utm_campaign=docs_traffic)
+is the easiest and fastest way to get started. It runs the Enterprise Edition
+of ArangoDB, lets you deploy clusters with just a few clicks, and is operated
+by a dedicated team of ArangoDB engineers day and night. You can choose from a
+variety of support plans to meet your needs.
+
+- Supports many cloud deployment regions across the main cloud providers
+  (AWS, Azure, GCP)
+- High availability featuring multi-region zone clusters, managed backups,
+  and zero-downtime upgrades
+- Integrated monitoring, alerting, and log management
+- Highly secure with encryption at transit and at rest
+- Includes elastic scalability for all deployment models (OneShard and Sharded clusters)
+
+To learn more, go to the [ArangoGraph documentation](../../arangograph/_index.md). 
+
+### Self-managed in the cloud
+
+ArangoDB can be self-deployed on AWS or other cloud platforms, too. However, when
+using a self-managed deployment, you take full control of managing the resources
+needed to run it in the cloud. This involves tasks such as configuring,
+provisioning, and monitoring the system. For more details, see
+[self-deploying ArangoDB in the cloud](../../deploy/in-the-cloud.md).
+
+ArangoDB supports Kubernetes through its official
+[Kubernetes Operator](../../deploy/kubernetes.md) that allows you to easily
+deploy and manage clusters within a Kubernetes environment.
+
+### On-premises
+
+Running ArangoDB on-premises means that ArangoDB is installed locally, on your
+organization's computers and servers, and involves managing all the necessary
+resources within the organization's environment, rather than using external
+services.
+
+You can install ArangoDB locally by downloading and running the
+[official packages](https://arangodb.com/download/) or run it using
+[Docker images](../../operations/installation/docker.md).
+
+You can deploy it on-premises as a
+[single server](../../deploy/single-instance/_index.md)
+or as a [cluster](../../deploy/cluster/_index.md)
+comprised of multiple nodes with synchronous replication and automatic failover
+for high availability and resilience. For the highest level of data safety,
+you can additionally set up off-site replication for your entire cluster
+([Datacenter-to-Datacenter Replication](../../deploy/arangosync/_index.md)).
+
+ArangoDB also integrates with Kubernetes, offering a
+[Kubernetes Operator](../../deploy/kubernetes.md) that lets you deploy in your
+Kubernetes cluster.
+
+## ArangoDB Editions
 
 ### Community Edition
 
@@ -70,22 +126,3 @@ See all [Enterprise Edition Features](enterprise-edition.md).
 | No on-disk encryption | **Encryption at Rest** with hardware-accelerated on-disk encryption and key rotation |
 | Only regular backups | **Datacenter-to-Datacenter Replication** for disaster recovery |
 | Only unencrypted backups and basic data masking for backups | **Hot Backups**, **encrypted backups**, and **enhanced data masking** for backups |
-
-## On-premises versus Cloud
-
-You can install ArangoDB on your local machine or run it in a Docker container
-for development purposes. You can deploy it on-premises as a
-[single server](../../deploy/single-instance/_index.md), optionally
-as a resilient pair with asynchronous replication and automatic failover
-([Active Failover](../../deploy/active-failover/_index.md)),
-or as a [cluster](../../deploy/cluster/_index.md)
-comprised of multiple nodes with synchronous replication and automatic failover
-for high availability and resilience. For the highest level of data safety,
-you can additionally set up off-site replication for your entire cluster
-([Datacenter-to-Datacenter Replication](../../deploy/arangosync/_index.md)).
-
-If you do not want to operate your own ArangoDB instances on-premises, then
-you may use our fully managed multi-cloud **ArangoGraph Insights Platform**.
-It runs the Enterprise Edition of ArangoDB, lets you deploy clusters with a
-few clicks, and is operated by a dedicated team of ArangoDB engineers day and
-night. To learn more, go to [dashboard.arangodb.cloud](https://dashboard.arangodb.cloud/home?utm_source=docs&utm_medium=cluster_pages&utm_campaign=docs_traffic).

site/content/3.10/about-arangodb/features/community-edition.md

@@ -39,7 +39,7 @@ see [arangodb.com/community-server/](https://www.arangodb.com/community-server/)
   documents, or graphs - perfect for social relations. Optional document
   validation using JSON Schema (draft-4, without remote schema support).
 
-- [**Data Storage**](../../deploy/architecture/storage-engine.md):
+- [**Data Storage**](../../components/arangodb-server/storage-engine.md):
   RocksDB storage engine to persist data and indexes on disk, with a hot set in
   memory. It uses journaling (write-ahead logging) and can take advantage of
   modern storage hardware, like SSDs and large caches.

site/content/3.10/about-arangodb/features/highlights-by-version.md

@@ -301,7 +301,7 @@ Also see [What's New in 3.5](../../release-notes/version-3.5/whats-new-in-3-5.md
   as soon as possible.
 
 - **RocksDB as Default Storage Engine**: With ArangoDB 3.4 the default
-  [storage engine](../../deploy/architecture/storage-engine.md) for fresh installations will
+  [storage engine](../../components/arangodb-server/storage-engine.md) for fresh installations will
   switch from MMFiles to RocksDB. Many optimizations have been made to RocksDB
   since the first release in 3.2. For 3.4 we optimized the binary storage
   format for improved insertion, implemented "optional caching", reduced the
@@ -342,7 +342,7 @@ Also see [What's New in 3.3](../../release-notes/version-3.3/whats-new-in-3-3.md
 
 **All Editions**
 
-- [**RocksDB Storage Engine**](../../deploy/architecture/storage-engine.md): You can now use
+- [**RocksDB Storage Engine**](../../components/arangodb-server/storage-engine.md): You can now use
   as much data in ArangoDB as you can fit on your disk. Plus, you can enjoy
   performance boosts on writes by having only document-level locks.
 

site/content/3.10/about-arangodb/use-cases.md

@@ -131,7 +131,7 @@ binary large objects (BLOBs) and works best with small to medium-sized
 JSON objects.
 
 For more information about how ArangoDB persists data, see
-[Storage Engine](../deploy/architecture/storage-engine.md).
+[Storage Engine](../components/arangodb-server/storage-engine.md).
 
 ## ArangoDB as a Search Engine
 

site/content/3.10/arangograph/data-loader/example.md

@@ -13,6 +13,7 @@ representing the nodes and a corresponding CSV file representing the edges.
 
 This example uses a sample data set of two files, `airports.csv` and `flights.csv`
 to create a graph showing flights arriving to and departing from various cities.
+You can download the files from [GitHub](https://github.com/arangodb/example-datasets/tree/master/Data%20Loader).
 
 The `airports.csv` contains rows of airport entries, which are the future nodes
 in your graph. The `flights.csv` contains rows of flight entries, which are the

site/content/3.10/deploy/architecture/storage-engine.md renamed to site/content/3.10/components/arangodb-server/storage-engine.md

@@ -1,11 +1,13 @@
 ---
 title: Storage Engine
 menuTitle: Storage Engine
-weight: 15
+weight: 20
 description: >-
   The storage engine is responsible for persisting data on disk, holding copies
   in memory, providing indexes and caches to speed up queries
 archetype: default
+aliases:
+  - ../../deploy/architecture/storage-engine
 ---
 ArangoDB's storage engine is based on Facebook's **RocksDB** and the only
 storage engine available in ArangoDB 3.7 and above. It is the bottom layer of

site/content/3.10/deploy/architecture/_index.md

@@ -3,7 +3,6 @@ title: ArangoDB Architecture
 menuTitle: Architecture
 weight: 100
 description: >-
-  Technical insights into ArangoDB's scalability, sharding, the storage engine,
-  and replication
+  Technical insights into ArangoDB's scalability, sharding, and replication
 archetype: chapter
 ---

site/content/3.10/develop/drivers/java/reference-version-7/driver-setup.md

@@ -91,7 +91,6 @@ Here are examples to integrate configuration properties from different sources:
 - `loadBalancingStrategy(LoadBalancingStrategy)`: load balancing strategy, possible values are: `NONE`, `ROUND_ROBIN`, `ONE_RANDOM`, (default: `NONE`)
 - `responseQueueTimeSamples(Integer)`:            amount of samples kept for queue time metrics, (default: `10`)
 - `serde(ArangoSerde)`:                           serde to serialize and deserialize user-data
-- `asyncExecutor(Executor)`:                      downstream `java.util.concurrent.Executor` that will be used to consume the responses of the async API
 
 ### Config File Properties
 

site/content/3.10/develop/foxx-microservices/guides/working-with-files.md

@@ -61,11 +61,11 @@ the filesystem from within a service:
   may therefore cause race conditions and **result in corrupted data**.
 
 - Writing to files outside the service folder introduces external state. In
-  a cluster this will result in Coordinators no longer being interchangeable.
+  a cluster, this results in Coordinators no longer being interchangeable.
 
 - Writing to files during setup is unreliable because the setup script may
-  be executed several times or not at all. In a cluster the setup script
-  will only be executed on a single Coordinator.
+  be executed several times or not at all. In a cluster, the setup script
+  is only executed on a single Coordinator.
 
 Therefore it is almost always a better option to store files using a
 specialized, external file storage service
@@ -77,13 +77,13 @@ ArangoDB documents by using a separate collection.
 {{< danger >}}
 Due to the way ArangoDB stores documents internally, you should not store
 file contents alongside other attributes that might be updated independently.
-Additionally, large file sizes will impact performance for operations
+Additionally, large file sizes impact performance for operations
 involving the document and may affect overall database performance.
 {{< /danger >}}
 
 {{< warning >}}
 In production, you should avoid storing any files in ArangoDB or handling file
-uploads in Foxx. The following example will work for moderate amounts of small
+uploads in Foxx. The following example works for moderate amounts of small
 files but is not recommended for large files or frequent uploads or
 modifications.
 {{< /warning >}}

site/content/3.10/develop/http-api/indexes/inverted.md

@@ -472,10 +472,10 @@ paths:
                     Wait at least this many commits between removing unused files in the
                     ArangoSearch data directory (default: 2, to disable use: 0).
                     For the case where the consolidation policies merge segments often (i.e. a lot
-                    of commit+consolidate), a lower value will cause a lot of disk space to be
+                    of commit+consolidate), a lower value causes a lot of disk space to be
                     wasted.
                     For the case where the consolidation policies rarely merge segments (i.e. few
-                    inserts/deletes), a higher value will impact performance without any added
+                    inserts/deletes), a higher value impacts performance without any added
                     benefits.
 
                     _Background:_
@@ -491,12 +491,11 @@ paths:
                     Wait at least this many milliseconds between committing inverted index data store
                     changes and making documents visible to queries (default: 1000, to disable
                     use: 0).
-                    For the case where there are a lot of inserts/updates, a lower value, until
-                    commit, will cause the index not to account for them and memory usage would
-                    continue to grow.
-                    For the case where there are a few inserts/updates, a higher value will impact
-                    performance and waste disk space for each commit call without any added
-                    benefits.
+                    For the case where there are a lot of inserts/updates, a higher value causes the
+                    index not to account for them and memory usage continues to grow until the commit.
+                    A lower value impacts performance, including the case where there are no or only a
+                    few inserts/updates because of synchronous locking, and it wastes disk space for
+                    each commit call.
 
                     _Background:_
                       For data retrieval, ArangoSearch follows the concept of
@@ -518,7 +517,7 @@ paths:
                     For the case where there are a lot of data modification operations, a higher
                     value could potentially have the data store consume more space and file handles.
                     For the case where there are a few data modification operations, a lower value
-                    will impact performance due to no segment candidates available for
+                    impacts performance due to no segment candidates being available for
                     consolidation.
 
                     _Background:_
@@ -536,8 +535,8 @@ paths:
                     _Background:_
                       With each ArangoDB transaction that inserts documents, one or more
                       ArangoSearch-internal segments get created.
-                      Similarly, for removed documents the segments that contain such documents
-                      will have these documents marked as 'deleted'.
+                      Similarly, for removed documents, the segments that contain such documents
+                      have these documents marked as 'deleted'.
                       Over time, this approach causes a lot of small and sparse segments to be
                       created.
                       A "consolidation" operation selects one or more segments and copies all of
@@ -594,7 +593,7 @@ paths:
                   description: |
                     Maximum memory byte size per writer (segment) before a writer (segment) flush
                     is triggered. `0` value turns off this limit for any writer (buffer) and data
-                    will be flushed periodically based on the value defined for the flush thread
+                    is flushed periodically based on the value defined for the flush thread
                     (ArangoDB server startup option). `0` value should be used carefully due to
                     high potential memory consumption
                     (default: 33554432, use 0 to disable)