editorial updates

Author: renetapopova

modules/ROOT/pages/scalability/sharded-property-databases/planning-and-sizing.adoc

@@ -23,14 +23,22 @@ image::scalability/property-shard-architecture.svg[title="Sample architecture wi
 
 == Planning the sizing of a sharded property database
 
-Property sharding relies on the capabilities offered by autonomous clustering for use and sizing of the infrastructure.
+Property sharding relies on the capabilities provided by autonomous clustering for managing and sizing the infrastructure.
 More specifically:
 
 * Some servers can be associated to the graph shard databases, they can also be separated between primary and secondary members of the cluster.
-* Other servers can be associated to the property shard databases. It is important to consider the number of servers available in conjunction with the number of shards and the number of replicas (i.e. copies of the same shard for availability and read scalability).
-* Data in sharded property databases will be evenly distributed. It is recommended to consider that each database does not exceed a size the is suitable for the available hardware and that allows a relatively smooth set of admin operations. For example, in commodity virtual or physical hardware, the size of the database should not exceed 1 to 3 TBytes in size.
+
+* Other servers can be associated to the property shard databases.
+It is important to consider the number of servers available in conjunction with the number of shards and the number of replicas (i.e. copies of the same shard for availability and read scalability).
+
+* Data in sharded property databases will be evenly distributed.
+It is recommended to consider that each database does not exceed a size the is suitable for the available hardware and that allows a relatively smooth set of admin operations. For example, in commodity virtual or physical hardware, the size of the database should not exceed 1 to 3 TBytes in size.
+
 * Should property sharding start relatively small and increase in size overtime, it is recommended to create more property shards that initially may be co-located on the same server.
-* When the size of the database grows, more servers may be added to allow hardware resharding of the database. This administrative change happens during normal online operations.
+
+* When the size of the database grows, more servers may be added to allow hardware resharding of the database.
+This administrative change happens during normal online operations.
+
 * Database resharding, i.e. the change of the number of property shards, can be executed offline using the `neo4j-admin database copy` command.
 See xref:scalability/sharded-property-databases/data-ingestion.adoc#splitting-existing-db-into-shards[Splitting an existing database into shards].