Fix some typos (#13)

docs/faq.md

@@ -48,10 +48,10 @@ Amazon Web Services (AWS) elastic file system (EFS) is very expensive ($0.30/GB-
 
 DynamoDB has a different cost structure and API than SlateDB. In general, SlateDB will be cheaper. DynamoDB charges $0.1/GiB for storage. If you use S3 standard with SlateDB, storage starts at $0.023/GiB (nearly 5 times cheaper).
 
-S3 standard charges $0.005 per-1000 writes (PUT, DELETE, etc.) and $0.0004 per-1000 reads. DynamoDB charges in read and write request units (RRU and WRU, respectively). Writes cost $1.25 per-million write units and $0.25 per0million read units. Depending on consistency and data size, a single request can cost multiple units (see [here](https://aws.amazon.com/dynamodb/pricing/on-demand/) for details). SlateDB batches writes by default, so it's usually going to have a less expensive API bill. If you batch DyanmoDB writes, you might be able to get similar fees.
+S3 standard charges $0.005 per-1000 writes (PUT, DELETE, etc.) and $0.0004 per-1000 reads. DynamoDB charges in read and write request units (RRU and WRU, respectively). Writes cost $1.25 per-million write units and $0.25 per-million read units. Depending on consistency and data size, a single request can cost multiple units (see [here](https://aws.amazon.com/dynamodb/pricing/on-demand/) for details). SlateDB batches writes by default, so it's usually going to have a less expensive API bill. If you batch DyanmoDB writes, you might be able to get similar fees.
 
 DynamoDB offers 99.999% SLA while an S3 standard bucket offers 99.99%, so DynamoDB is more available.
 
-DynamoDB also requires partitioning. SlateDB doesn't have partitioning. Instead, you must build a partitioning schemeon top of SlateDB if you need it. Though, since SlateDB fences stale writers, partitionin management should be fairly straightforward.
+DynamoDB also requires partitioning. SlateDB doesn't have partitioning. Instead, you must build a partitioning scheme on top of SlateDB if you need it. Though, since SlateDB fences stale writers, partition management should be fairly straightforward.
 
 SlateDB also offers some unique features like the ability to create snapshot clones of a database at a specific point in time.

docs/introduction.md

@@ -20,7 +20,7 @@ We believe that the future of object storage are multi-region, low latency bucke
 
 * **Zero-Disk architecture**: SlateDB is easy to operate. It runs as an in-process storage engine with no local state, no control plane, and no replication protocol.
 * **Single-writer**: SlateDB is designed for a single writer. Partitioning can easily be built on top of SlateDB since fencing is supported.
-* **Mulitple-readers**: Multiple readers on different nodes can all read the same SlateDB database.
+* **Multiple-readers**: Multiple readers on different nodes can all read the same SlateDB database.
 * **Read caching**: SlateDB supports in-memory and (optional) on-disk read caching to reduce latency and API cost.
 * **Snapshot isolation**: SlateDB supports snapshot isolation, which allows readers and writers to see a consistent view of the database.
 * **Transactions**: Transactional writes are supported.