BigTable:

As a cloud architect you might be called upon to make trade-offs on the database
choices for your product. How much data can each hold, how do they scale, what are
the common use cases? An overview of each of GCPs offerings is important.

Q: Why is it easier to add alms on the fly in big table than in cloud Spanner?
A: Adding columns dynamically in BigTable is pretty easy, BigTable is a columnar
Database, if you decide to add new columns in some tables in to your dataset you need
to do insert new rows in your database you don’t need to change the schema in any
way
Adding columns in Cloud spanner is very difficult, Cloud Spanner is a relational Database,
each time you add column, that going to change schema and that would be need
whole bunch of database rights. These rights will require transaction support which will
give you terrible performance.

Q: Normalization of Data is grate in traditional database theory, but has drawbacks in

the distributed world, what are some…?

A: Normalization in traditional database design was largely driven by the needs to save
space.

Q: Big able supports equal joins but it does not constrains or indices. TRUE / FALSE..?
A: Big able does not support any operations across the tables, and it does not support Joins
of any form nor constraints and nor disease.
Big able big evil is pretty hardcore NoSQL it doesn’t support any operations across tables,
everything only at the level of row data and column families.

Q: How the RowKey effect Physical storage in BigTable or HBase..?

A: The choice of Row Key is really important, It’s completely determines physical storage
in both BigTable and HBase because all of the different values of the Row Keys
are taken and sorted in lexicographical order and data is then stored in that
order, So all values with similar Row Key values when started are going to reside
close to each other.
This clearly has a bunch of implications as far as hot spotting and the distribution
of the reads and write scope

Q: in which level the HBase operations are atomic at the level of..?
 Column family
 Colum
 Row
 Not Atomic at all
A: operations in HBase and BigTable are atomic but only at the level of Row
 HBase and BigTable don’t offer any stronger guaranty is on atomicity, they
certainly do not offer ACID support.

Q: Getting the HBase Prompt

A: Google seems to have deprecated the link to set up the HBase prompt and
put the script in a directory named "quickstart".
Once you log into the shell, setup your project id into the shell with
1. gcloud config set project [PROJECT_ID]
Navigate to the quickstart directory with
1. cd quickstart
Run the quickstart script
1. ./quickstart.sh
Now, you should see the HBase prompt.

Q: What are the two operations are very low latency in Cloud BigTable

A: HBase BigTable optimized for very fast lookup operations using that RowKey the
RowKey is what is used to index all the rows in a table and also very fast scan
operations contiguous RowKey can be looked up in a range very quickly

DATASTORE (Document Database)

Q: (Fundamentals CS). What data structure has ~ approximately constant lookup time?
A: a hash Table,
Now there are some wrinkles around look up time in hash table it is order of key,
the key is the number of buckets, but all intention purposes we can assume a
hash table is independent of the size of the dataset.
Q: Entities of a particular kind in cloud Datastore all have the same properties..? TRUE /
FALSE ?
A: FALSE: Entities are same kind in Datastore can have different properties, each
of those properties have different datatypes across entities as well

Q: What is a characteristic of Datastore?

A: Query execution time depends on size of query result, independent of size of
data set as a whole
Q: Represent similarities between Datastore and traditional RDBMS?
A: Support for Atomic transactions
Q: Map the following terms from relational databases to Datastore
Table, Row, Field
A: Table = Kind, Row = Entity, Field = Property