108 SQL vs NoSQL PDF

108 SQL vs. NoSQL ~ In the world of databases, there are two main types of solutions: SQL and NoSQL (or relational ***...

108 SQL vs. NoSQL ~ In the world of databases, there are two main types of solutions: SQL and NoSQL (or relational *** ***~** ** ** ** ** ** * * databases and non-relational databases). Both of them differ in the way they were built, the kind of * * information they store, and the storage method they use. *** Relational databases are structured and have predefined schemas like phone books that store *** *** *** *** *** * * phone numbers and addresses. *** Non-relational databases are unstructured, distributed, and have a dynamic schema like file *** *** *** *** *** *** *** * folders that hold everything from a person’s address and phone number to their Facebook 'likes' and * online shopping preferences. SQL * Relational databases store data in rows and columns. * ** ** ** ** *** Each row contains all the information about one entity *** * ** *** and each column contains all the separate data points. *** *** * ** ** * Some of the most popular relational databases are MySQL, Oracle, MS SQL Server, SQLite, ** ** ** ** ** ** ** ** ** Postgres, and MariaDB. ** ** ** NoSQL *** Following are the most common types of NoSQL: *** ~ Key-Value Stores: ~ * Data is stored in an array of key-value pairs. * *** *** The 'key' is an attribute name which is linked to a 'value'. ** ** * * * * ** ** Well-known key-value stores include Redis, Voldemort, and (Amazon DynamoDB) Dynamo. ** ** ** ** ** ** **~~ ~~** ~ Document Databases: ~ In these databases, data is stored in documents (instead of rows and columns in a table) and ** ** * * these documents are grouped together in collections. * ** *** * Each document can have an entirely different structure. *  Document databases include the CouchDB and MongoDB. ** ** ** ** ~ Wide-Column Databases: ~ * Instead of ‘tables,' in columnar databases we have column families, which are containers for* ** ** ** ** *** rows. *** * Unlike relational databases, we don’t need to know all the columns up front and each row * *** *** * * * ** doesn’t have to have the same number of columns. ** * Columnar databases are best suited for analyzing large datasets - * * big names include Cassandra and HBase. ** ** ** ** ~ Graph Databases: ~ These databases are used to store data whose relations are best represented in a graph. * * Data is saved in graph structures with ** nodes (entities), ** ** properties (information about the entities), ** and lines (connections between the entities). ** ** Examples of graph database include Neo4J and InfiniteGraph. ** ** ** ** High level differences between SQL and NoSQL ~ Storage: ~ ** SQL stores data in tables where ** *** each row represents an entity ** * ** ** and each column represents a data point about that entity; ** ** * * ** ** * *...for example, if we are storing a car entity in a table, different columns could be ‘Color’, * * * * * * * * * ‘Make’, ‘Model’, and so on.* * * ** NoSQL databases have different data storage models. The main ones are ** * * ** key-value, ** ** document, ** ** graph, ** and columnar. ** ** We will discuss differences between these databases below. ~ Schema: ~ In SQL, each record conforms to a fixed schema, meaning the columns must be decided and chosen ** ** * * *** *** * before data entry and each row must have data for each column. * == The schema can be altered later, but it involves modifying the whole database and going * * *** *** * offline. *== In NoSQL, schemas are dynamic. ** ** *** *** * Columns can be added on the fly * and each ‘row’ (or equivalent) doesn’t have to contain data for each ‘column.' * * ~ Querying: ~ ** SQL databases use SQL (structured query language) for defining and manipulating the data, which is ** ** ** very powerful. In a NoSQL database, ** ** * queries are focused on a collection of documents. * Sometimes it is also called UnQL (Unstructured Query Language). ** ** Different databases have different syntax for using UnQL. ~ Scalability: ~ * In most common situations, SQL databases are vertically scalable, * ** ** *** *** i.e., by increasing the horsepower (higher Memory, CPU, etc.) of the hardware, which can get very expensive. *** *** It is possible to scale a relational database across multiple servers, but this is a challenging and * time-consuming process. * On the other hand, NoSQL databases are horizontally scalable, meaning we can add more servers ** ** *** *** * easily in our NoSQL database infrastructure to handle a lot of traffic. * * Any cheap commodity hardware or cloud instances can host NoSQL databases, thus making it a * lot more cost-effective than vertical scaling. ** ** A lot of NoSQL technologies also distribute data across servers automatically. * * ~ Reliability or ACID Compliancy (Atomicity, Consistency, Isolation, Durability): ~ The vast majority of relational databases are ACID compliant. So, when it comes to data reliability ** ** ** ** == *** *** and safe guarantee of performing transactions, SQL databases are still the better bet. *** *** ** ** == Most of the NoSQL solutions sacrifice ACID compliance for performance and scalability. ** ** ~~ ~~ *** *** *** *** SQL VS. NoSQL - Which one to use? When it comes to database technology, there’s no one-size-fits-all solution. *** *** ~~ ~~ That’s why many businesses rely on both relational and non-relational databases for different needs. * ** *** * * * * * * Even as NoSQL databases are gaining popularity for their speed and scalability, there are still ** ** ** ** ** ** * situations where a highly structured SQL database may perform better; choosing the right * ** ** *** technology hinges on the use case. *** Reasons to use SQL database Here are a few reasons to choose a SQL database: 1. We need to ensure ACID compliance. ACID compliance ** ** *** reduces anomalies and ~~ ~~*** protects the integrity of your database by prescribing exactly how transactions interact *** *** *** *** * * with the database. * Generally, NoSQL databases sacrifice ACID compliance for scalability and processing * ** ** * * * * speed, but for many e-commerce and financial applications, an ACID-compliant database *** *** ** ** ** ** *** *** * remains the preferred option. * 2. Your data is structured and unchanging. If your business is not experiencing massive growth * * ** ** ** ** *** *** ~~ ~~ * that would require more servers and if you're only working with data that is consistent, then * *** *** * ** *** * there may be no reason to use a system designed to support a variety of data types and high * * * * traffic volume. * Reasons to use NoSQL database When all the other components of our application are fast and seamless, NoSQL databases prevent * * * * * * *** data from being the bottleneck. Big data is contributing to a large success for NoSQL databases, *** mainly because it handles data differently than the traditional relational databases. A few popular * * examples of NoSQL databases are MongoDB, CouchDB, Cassandra, and HBase. ** ** ** ** ** ** ** ** 1. Storing large volumes of data that often have little to no structure. * ** ** ** ** * A NoSQL database sets no limits on the types of data we can store together *** *** and allows us to add new types as the need changes. * * *** ***  With document-based databases, you can store data in one place without having to define ** ** * what “types” of data those are in advance. * 2. Making the most of cloud computing and storage. * ** ** ** ** * * Cloud-based storage is an excellent cost-saving solution but requires data to be easily * * * *** *** * spread across multiple servers to scale up. Using commodity (affordable, smaller) hardware * ** ** on-site or in the cloud saves you the hassle of additional software * * and NoSQL databases like Cassandra are designed to be scaled across multiple data ** ** * centers out of the box, without a lot of headaches. * 3. Rapid development. *** *** NoSQL is extremely useful for rapid development as it doesn’t need to be prepped ahead * * *** ** ~~ of time. ~~ * == *** If you’re working on quick iterations of your system which require making frequent *** * * * updates to the data structure without a lot of downtime between versions, a relational * * * * ~~ ~~ * * database will slow you down. * ==