Difference between revisions of "CV"
Adelo Vieira (talk | contribs) |
Adelo Vieira (talk | contribs) |
||
| Line 1: | Line 1: | ||
| − | + | {{#tag:html| | |
| − | < | + | <style> |
| − | + | /* MediaWiki page configurations */ | |
| − | + | #content { margin-left: 300px !important; } | |
| − | + | #p-namespaces { margin-left: 124px !important; } | |
| − | + | #footer { margin: 0 0 0 308px } | |
| − | + | #mw-panel .portal { display: none; } | |
| − | + | ||
| − | + | div#toc.toc { | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
font-size: 12pt; | font-size: 12pt; | ||
margin-top: -4.5pt; | margin-top: -4.5pt; | ||
| Line 77: | Line 15: | ||
max-width: 200pt; | max-width: 200pt; | ||
margin-right: 12pt; | margin-right: 12pt; | ||
| − | + | } | |
| − | + | .toc ul { | |
overflow-y: scroll !important; | overflow-y: scroll !important; | ||
max-height: 500pt; <!-- max-height: 100vh; --> | max-height: 500pt; <!-- max-height: 100vh; --> | ||
| − | + | } | |
| − | + | .tocUl { | |
overflow-y: scroll !important; | overflow-y: scroll !important; | ||
max-height: 500pt; <!-- max-height: 100vh; --> | max-height: 500pt; <!-- max-height: 100vh; --> | ||
| − | + | } | |
| − | + | .tochidden { | |
height: 4pt !important; | height: 4pt !important; | ||
| − | + | } | |
| − | + | .title { | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
<!-- margin-top: 5px; --> | <!-- margin-top: 5px; --> | ||
margin-left: -10px !important; | margin-left: -10px !important; | ||
| Line 115: | Line 42: | ||
<!-- background: rgba(0, 0, 0, 0) linear-gradient(90deg, #007bff, rgb(0, 0, 0)) repeat scroll 0% 0% / auto padding-box border-box; margin-left:-10px; --> | <!-- background: rgba(0, 0, 0, 0) linear-gradient(90deg, #007bff, rgb(0, 0, 0)) repeat scroll 0% 0% / auto padding-box border-box; margin-left:-10px; --> | ||
<!-- linear-gradient(90deg, rgb(31, 112, 193), rgb(0, 0, 0)) --> <!-- #0074D9 --> | <!-- linear-gradient(90deg, rgb(31, 112, 193), rgb(0, 0, 0)) --> <!-- #0074D9 --> | ||
| − | + | } | |
| − | + | .titulo1-text { | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
font-size: 18px !important; | font-size: 18px !important; | ||
| − | + | } | |
| − | + | .titulo1-text-marco { | |
padding-left: 10px !important; | padding-left: 10px !important; | ||
| − | + | } | |
| − | + | .titulo1-marco-oneline { | |
padding-right: 0px !important; | padding-right: 0px !important; | ||
padding-left: 0px !important; | padding-left: 0px !important; | ||
| Line 166: | Line 56: | ||
min-height: 35pt !important; | min-height: 35pt !important; | ||
margin-top:-32pt !important; | margin-top:-32pt !important; | ||
| − | + | } | |
| − | + | .titulo1-marco-twolines { | |
padding-right: 0px !important; | padding-right: 0px !important; | ||
padding-left: 0px !important; | padding-left: 0px !important; | ||
| Line 174: | Line 64: | ||
min-height: 50pt !important; | min-height: 50pt !important; | ||
margin-top:-47pt !important; | margin-top:-47pt !important; | ||
| − | + | } | |
| − | + | .marco1-ext { | |
width: 100% !important; | width: 100% !important; | ||
padding: 0px 0px 0px 0px !important; | padding: 0px 0px 0px 0px !important; | ||
background: #e3e3e8 !important; | background: #e3e3e8 !important; | ||
| − | + | } | |
| − | + | .marco1-int { | |
background: #e3e3e8 !important; | background: #e3e3e8 !important; | ||
| − | + | } | |
| − | + | .marco1-ext .mw-editsection { | |
display: none !important; | display: none !important; | ||
| − | + | } | |
| − | + | .divline1 { | |
padding: 0; | padding: 0; | ||
border: 0; | border: 0; | ||
| Line 195: | Line 85: | ||
background-color: white; | background-color: white; | ||
height:1.2pt | height:1.2pt | ||
| − | + | } | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | /* Sidebar (Pure CSS) */ | |
| + | body { | ||
| + | |||
| + | } | ||
| + | #menuToggle { | ||
| + | display: block; | ||
| + | position: relative; | ||
| + | top: 20px; | ||
| + | padding-left: 10px; | ||
| + | margin-left: -325px; | ||
| + | z-index: 1; | ||
| + | -webkit-user-select: none; | ||
| + | user-select: none; | ||
| + | } | ||
| + | #menuToggle a { | ||
| + | text-decoration: none; | ||
| + | color: #232323; | ||
| + | transition: color 0.3s ease; | ||
| + | } | ||
| + | #menuToggle a:hover { color: tomato; } | ||
| + | #menuToggle input { | ||
| + | display: block; | ||
| + | width: 40px; | ||
| + | height: 32px; | ||
| + | position: absolute; | ||
| + | top: -7px; | ||
| + | left: -5px; | ||
| + | cursor: pointer; | ||
| + | opacity: 0; /* hide this */ | ||
| + | z-index: 2; /* and place it over the hamburger */ | ||
| + | -webkit-touch-callout: none; | ||
| + | } | ||
| + | /* Just a quick hamburger */ | ||
| + | #menuToggle span { | ||
| + | display: block; | ||
| + | width: 33px; | ||
| + | height: 5px; | ||
| + | margin-bottom: 4px; | ||
| + | position: relative; | ||
| + | background: #cdcdcd; | ||
| + | border-radius: 3px; | ||
| + | z-index: 1; | ||
| + | transform-origin: 4px 0px; | ||
| + | transition: transform 0.5s cubic-bezier(0.77,0.2,0.05,1.0), | ||
| + | background 0.5s cubic-bezier(0.77,0.2,0.05,1.0), | ||
| + | opacity 0.55s ease; | ||
| + | } | ||
| + | #menuToggle span:first-child { | ||
| + | transform-origin: 0% 0%; | ||
| + | } | ||
| + | #menuToggle span:nth-last-child(2) { | ||
| + | transform-origin: 0% 100%; | ||
| + | } | ||
| + | /* Transform all the slices of hamburger into a crossmark */ | ||
| + | #menuToggle input:checked ~ span { | ||
| + | opacity: 1; | ||
| + | transform: rotate(45deg) translate(-2px, -1px); | ||
| + | background: #232323; | ||
| + | } | ||
| + | /* But let's hide the middle one */ | ||
| + | #menuToggle input:checked ~ span:nth-last-child(3) { | ||
| + | opacity: 0; | ||
| + | transform: rotate(0deg) scale(0.2, 0.2); | ||
| + | } | ||
| + | /* Ohyeah and the last one should go the other direction */ | ||
| + | #menuToggle input:checked ~ span:nth-last-child(2) { | ||
| + | transform: rotate(-45deg) translate(0, -1px); | ||
| + | } | ||
| + | |||
| + | /* Make this absolute positioned at the top left of the screen */ | ||
| + | #menu { | ||
| + | position: absolute; | ||
| + | width: 300px; | ||
| + | margin: -50px 0 0 -10px; | ||
| + | padding: 50px 0px 30px 0px; | ||
| + | background: #ededed; | ||
| + | list-style-type: none; | ||
| + | -webkit-font-smoothing: antialiased; | ||
| + | /* to stop flickering of text in safari */ | ||
| + | transform-origin: 0% 0%; | ||
| + | transform: translate(-100%, 0); | ||
| + | transition: transform 0.5s cubic-bezier(0.77,0.2,0.05,1.0); | ||
| + | } | ||
| + | #menu li { | ||
| + | padding: 10px 0 0 0; | ||
| + | font-size: 22px; | ||
| + | } | ||
| + | /* And let's slide it in from the left */ | ||
| + | #menuToggle input:checked ~ ul { | ||
| + | transform: none; | ||
| + | } | ||
| + | |||
| + | /* Tab Menu */ | ||
| + | .button{ | ||
| + | font-size: 14px; | ||
| + | color: inherit; | ||
| + | background-color :inherit; | ||
| + | padding: 8px 0px 8px 0px; | ||
| + | border: none; | ||
| + | outline: 0; | ||
| + | cursor: pointer; | ||
| + | } | ||
| + | .bottom-selected { background-color: #f44336 !important } | ||
| + | .area { | ||
| + | color: black; | ||
| + | padding: 15px 0px; | ||
| + | border: 0px solid #ccc !important; | ||
| + | z-index: 100 !important; | ||
| + | } | ||
| + | .left {float: left; width:100px; text-align: center;} | ||
| + | .right {float: right; width:100px; text-align: center;} | ||
| + | .center {margin: 0 auto; width:100px; text-align: center;} | ||
| + | |||
| + | </style> | ||
| + | |||
| + | <script> | ||
| + | function openCity(evt, cityName) { | ||
| + | var i, x, tablinks; | ||
| + | x = document.getElementsByClassName("city"); | ||
| + | for (i = 0; i < x.length; i++) { | ||
| + | x[i].style.display = "none"; | ||
| + | } | ||
| + | tablinks = document.getElementsByClassName("tablink"); | ||
| + | for (i = 0; i < x.length; i++) { | ||
| + | tablinks[i].className = tablinks[i].className.replace(" bottom-selected", ""); | ||
| + | } | ||
| + | document.getElementById(cityName).style.display = "block"; | ||
| + | evt.currentTarget.className += " bottom-selected"; | ||
| + | } | ||
| + | </script> | ||
| + | |||
| + | <nav role="navigation" style="position: fixed;"> | ||
| + | <div id="menuToggle"> | ||
| + | <!-- | ||
| + | A fake / hidden checkbox is used as click reciever, | ||
| + | so you can use the :checked selector on it. | ||
| + | --> | ||
| + | <input type="checkbox" /> | ||
| + | |||
| + | <!-- | ||
| + | Some spans to act as a hamburger. | ||
| + | --> | ||
| + | <span></span> | ||
| + | <span></span> | ||
| + | <span></span> | ||
| + | |||
| + | <!-- | ||
| + | Too bad the menu has to be inside of the button | ||
| + | but hey, it's pure CSS magic. | ||
| + | --> | ||
| + | <ul id="menu"> | ||
| − | + | <!--Tap Menu --> | |
| + | <div style="padding: 10px 0px 0px 0px;"> | ||
| + | <div style="color:#fff !important; background-color: #000 !important"> | ||
| + | <button class="button left tablink bottom-selected" onclick="openCity(event,'PE')">PE</button> | ||
| + | <button class="button center tablink" onclick="openCity(event,'Tools')"> Tools </button> | ||
| + | <button class="button right tablink" onclick="openCity(event,'Others')"> Others </button> | ||
| + | </div> | ||
| + | |||
| + | <div id="PE" class="area city"> | ||
| + | <div style="overflow-y: scroll; height: 100vh !important; background: #e3e3e8; margin-top:0px; padding:0px 5px 0px 0px;"> | ||
| + | <!-- {{#lst:Mis páginas|Carrera1}} --> | ||
| + | <div style="margin-bottom: 42px; margin-top:2px"> {{#lst:Mis páginas|formal_natural_and_applied_sciences0}}</div> | ||
| + | <div style="margin-bottom: 50px"> {{#lst:Mis páginas|social_sciences0}}</div> | ||
| + | <div style="margin-bottom: 30px"> {{#lst:Mis páginas|musica0}}</div> | ||
| + | <div style="margin-bottom: 150px">{{#lst:Mis páginas|Carrera0}}</div> | ||
| + | </div> | ||
| + | </div> | ||
| − | + | <div id="Tools" class="area city" style="display:none"> | |
| − | </div> | + | <div>Tools</div> |
| − | < | + | <p> Tools is the capital of France.</p> |
| − | + | </div> | |
| − | < | ||
| − | <!-- < | + | <div id="Others" class="area city" style="display:none"> |
| − | + | <div>Others</div> | |
| − | + | <p> Others is the capital of Japan.</p> | |
| − | + | </div> | |
| − | + | </div> | |
| − | + | ||
| − | + | <!-- <a href="#"><li>Home</li></a> | |
| − | + | <a href="#"><li>About</li></a> | |
| − | + | <a href="#"><li>Info</li></a> | |
| − | + | <a href="#"><li>Contact</li></a> | |
| + | <a href="https://erikterwan.com/" target="_blank"><li>Show me more</li></a> --> | ||
| + | |||
| + | </ul> | ||
| + | </div> | ||
| + | </nav> | ||
}} | }} | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | ==Relational databases vs Non-relational databases== | ||
| + | https://www.jamesserra.com/archive/2015/08/relational-databases-vs-non-relational-databases/ | ||
| + | |||
| + | *'''Relational databases''', which can also be called '''relational database management systems (RDBMS)''' or '''SQL databases'''. The most popular of these are Microsoft SQL Server, Oracle Database and MySQL. | ||
| − | + | *'''Non-relational databases''', also called '''NoSQL databases''', the most popular being MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis, and Neo4j. These databases are usually grouped into four categories: Key-value stores, Graph stores, Column stores, and Document stores (see Types of NoSQL databases). | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | All relational databases can be used to manage transaction-oriented applications (Online transaction processing (OLTP)), and most non-relational databases that are in the categories Document stores and Column stores can also be used for OLTP. OLTP databases can be thought of as "Operational" databases, characterized by frequent, short transactions that include updates and that touch a small amount of data and where concurrency of thousands of transactions is very important (examples including banking applications and online reservations). Integrity of data is very important so they support ACID transactions (Atomicity, Consistency, Isolation, Durability). This is opposed to '''data warehouses''', which are considered "Analytical" databases characterized by long, complex queries that touch a large amount of data and require a lot of resources. Updates are infrequent. An example is analysis of sales over the past year. | |
| + | Relational databases usually work with structured data, while non-relational databases usually work with semi-structured data (i.e. XML, JSON). | ||
| − | + | ===Relational Databases=== | |
| − | + | A relational database is organized based on the relational model of data, as proposed by E.F. Codd in 1970. This model organizes data into one or more tables (or "relations") of rows and columns, with a unique key for each row. Generally, each entity type that is described in a database has its own table with the rows representing instances of that type of entity and the columns representing values attributed to that instance. Since each row in a table has its own unique key, rows in a table can be linked to rows in other tables by storing the unique key of the row to which it should be linked (where such unique key is known as a "foreign key"). Codd showed that data relationships of arbitrary complexity can be represented using this simple set of concepts. | |
| − | |||
| − | == | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | Virtually all relational database systems use SQL (Structured Query Language) as the language for querying and maintaining the database. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | The reasons for the dominance of relational databases are: simplicity, robustness, flexibility, performance, scalability and compatibility in managing generic data. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| + | But to offer all of this, relational databases have to be incredibly complex internally. For example, a relatively simple SELECT statement could have dozens of potential query execution paths, which a query optimizer would evaluate at run time. All of this is hidden to users, but under the hood, the RDBMS determines the best “execution plan” to answer requests by using things like cost-based algorithms. | ||
| − | + | For large databases, especially ones used for web applications, the main concern is scalability. As more and more applications are created in environments that have massive workloads (i.e. Amazon), their scalability requirements can change very quickly and grow very large. Relational databases scale well, but usually only when that scaling happens on a single server (“scale-up”). When the capacity of that single server is reached, you need to “scale-out” and distribute that load across multiple servers, moving into so-called distributed computing. This is when the complexity of relational databases starts to cause problems with their potential to scale. If you try to scale to hundreds or thousands of servers the complexities become overwhelming. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | ===Non-relational databases=== | |
| + | A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases. | ||
| + | Motivations for this approach include: | ||
| + | *Simplicity of design. Not having to deal with the "impedance mismatch" between the object-oriented approach to write applications and the schema-based tables and rows of a relational database. For example, storing all the customer order info in one document as opposed to having to join many tables together, resulting in less code to write, debug, and maintain. | ||
| − | + | *Better "horizontal" scaling to clusters of machines, which solves the problem when the number of concurrent users skyrockets for applications that are accessible via the web and mobile devices. Using documents makes it much easier to scale-out as all the info for that customer order is contained in one place as opposed to being spread out on multiple tables. NoSQL databases automatically spread data across servers without requiring application changes (auto-sharding), meaning that they natively and automatically spread data across an arbitrary number of servers, without requiring the application to even be aware of the composition of the server pool. Data and query load are automatically balanced across servers, and when a server goes down, it can be quickly and transparently replaced with no application disruption. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | *Finer control over availability. Servers can be added or removed without application downtime. Most NoSQL databases support data replication, storing multiple copies of data across the cluster or even across data centers, to ensure high availability and disaster recovery. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | *To easily capture all kinds of data "Big Data" which include unstructured and semi-structured data. Allowing for a flexible database that can easily and quickly accommodate any new type of data and is not disrupted by content structure changes. This is because document database are schemaless, allowing you to freely add fields to JSON documents without having to first define changes (schema-on-read instead of schema-on-write). You can have documents with a different number of fields than other documents. For example, a patient record that may or may not contain fields that list allergies. | |
| + | *Speed. The data structures used by NoSQL databases (i.e. JSON documents) differ from those used by default in relational databases, making many operations faster in NoSQL than relational databases due to not having to join tables (at the cost of increased storage space due to duplication of data – but storage space is so cheap nowadays so this is usually not an issue). In fact, most NoSQL databases do not even support joins. | ||
| + | *Cost. NoSQL databases usually use clusters of cheap commodity servers, while RDBMS tend to rely on expensive proprietary servers and storage systems. Also, the licenses for RDBMS systems can be quite expensive while many NoSQL databases are open source and therefore free. | ||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | The particular suitability of a given NoSQL database depends on the problem it must solve. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | *NoSQL databases are increasingly used in big data and real-time web applications. They became popular with the introduction of the web, when databases went from a max of a few hundred users on an internal company application to thousands or millions of users on a web application. NoSQL systems are also called “Not only SQL” to emphasize that they may also support SQL-like query languages. | |
| + | *Many NoSQL stores compromise consistency (in the sense of the CAP theorem) in favor of availability and partition tolerance. Some reasons that block adoption of NoSQL stores include the use of low-level query languages, the lack of standardized interfaces, and huge investments in existing SQL. Also, most NoSQL stores lack true ACID transactions or only support transactions in certain circumstances and at certain levels (e.g., document level). | ||
| − | + | ===Comparing the two=== | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | *One of the most severe limitations of relational databases is that each item can only contain one attribute. If we use a bank example, each aspect of a customer’s relationship with a bank is stored as separate row items in separate tables. So the customer’s master details are in one table, the account details are in another table, the loan details in yet another, investments in a different table, and so on. All these tables are linked to each other through the use of relations such as primary keys and foreign keys. | |
| − | |||
| − | |||
| − | |||
| − | |||
| − | |||
| − | + | *Non-relational databases, specifically a database’s key-value stores or key-value pairs, are radically different from this model. Key-value pairs allow you to store several related items in one “row” of data in the same table. We place the word “row” in quotes because a row here is not really the same thing as the row of a relational table. For instance, in a non-relational table for the same bank, each row would contain the customer’s details as well as their account, loan and investment details. All data relating to one customer would be conveniently stored together as one record. | |
<br /> | <br /> | ||
Revision as of 18:29, 6 March 2021
Contents
Relational databases vs Non-relational databases
https://www.jamesserra.com/archive/2015/08/relational-databases-vs-non-relational-databases/
- Relational databases, which can also be called relational database management systems (RDBMS) or SQL databases. The most popular of these are Microsoft SQL Server, Oracle Database and MySQL.
- Non-relational databases, also called NoSQL databases, the most popular being MongoDB, DocumentDB, Cassandra, Coachbase, HBase, Redis, and Neo4j. These databases are usually grouped into four categories: Key-value stores, Graph stores, Column stores, and Document stores (see Types of NoSQL databases).
All relational databases can be used to manage transaction-oriented applications (Online transaction processing (OLTP)), and most non-relational databases that are in the categories Document stores and Column stores can also be used for OLTP. OLTP databases can be thought of as "Operational" databases, characterized by frequent, short transactions that include updates and that touch a small amount of data and where concurrency of thousands of transactions is very important (examples including banking applications and online reservations). Integrity of data is very important so they support ACID transactions (Atomicity, Consistency, Isolation, Durability). This is opposed to data warehouses, which are considered "Analytical" databases characterized by long, complex queries that touch a large amount of data and require a lot of resources. Updates are infrequent. An example is analysis of sales over the past year.
Relational databases usually work with structured data, while non-relational databases usually work with semi-structured data (i.e. XML, JSON).
Relational Databases
A relational database is organized based on the relational model of data, as proposed by E.F. Codd in 1970. This model organizes data into one or more tables (or "relations") of rows and columns, with a unique key for each row. Generally, each entity type that is described in a database has its own table with the rows representing instances of that type of entity and the columns representing values attributed to that instance. Since each row in a table has its own unique key, rows in a table can be linked to rows in other tables by storing the unique key of the row to which it should be linked (where such unique key is known as a "foreign key"). Codd showed that data relationships of arbitrary complexity can be represented using this simple set of concepts.
Virtually all relational database systems use SQL (Structured Query Language) as the language for querying and maintaining the database.
The reasons for the dominance of relational databases are: simplicity, robustness, flexibility, performance, scalability and compatibility in managing generic data.
But to offer all of this, relational databases have to be incredibly complex internally. For example, a relatively simple SELECT statement could have dozens of potential query execution paths, which a query optimizer would evaluate at run time. All of this is hidden to users, but under the hood, the RDBMS determines the best “execution plan” to answer requests by using things like cost-based algorithms.
For large databases, especially ones used for web applications, the main concern is scalability. As more and more applications are created in environments that have massive workloads (i.e. Amazon), their scalability requirements can change very quickly and grow very large. Relational databases scale well, but usually only when that scaling happens on a single server (“scale-up”). When the capacity of that single server is reached, you need to “scale-out” and distribute that load across multiple servers, moving into so-called distributed computing. This is when the complexity of relational databases starts to cause problems with their potential to scale. If you try to scale to hundreds or thousands of servers the complexities become overwhelming.
Non-relational databases
A NoSQL database provides a mechanism for storage and retrieval of data that is modeled in means other than the tabular relations used in relational databases.
Motivations for this approach include:
- Simplicity of design. Not having to deal with the "impedance mismatch" between the object-oriented approach to write applications and the schema-based tables and rows of a relational database. For example, storing all the customer order info in one document as opposed to having to join many tables together, resulting in less code to write, debug, and maintain.
- Better "horizontal" scaling to clusters of machines, which solves the problem when the number of concurrent users skyrockets for applications that are accessible via the web and mobile devices. Using documents makes it much easier to scale-out as all the info for that customer order is contained in one place as opposed to being spread out on multiple tables. NoSQL databases automatically spread data across servers without requiring application changes (auto-sharding), meaning that they natively and automatically spread data across an arbitrary number of servers, without requiring the application to even be aware of the composition of the server pool. Data and query load are automatically balanced across servers, and when a server goes down, it can be quickly and transparently replaced with no application disruption.
- Finer control over availability. Servers can be added or removed without application downtime. Most NoSQL databases support data replication, storing multiple copies of data across the cluster or even across data centers, to ensure high availability and disaster recovery.
- To easily capture all kinds of data "Big Data" which include unstructured and semi-structured data. Allowing for a flexible database that can easily and quickly accommodate any new type of data and is not disrupted by content structure changes. This is because document database are schemaless, allowing you to freely add fields to JSON documents without having to first define changes (schema-on-read instead of schema-on-write). You can have documents with a different number of fields than other documents. For example, a patient record that may or may not contain fields that list allergies.
- Speed. The data structures used by NoSQL databases (i.e. JSON documents) differ from those used by default in relational databases, making many operations faster in NoSQL than relational databases due to not having to join tables (at the cost of increased storage space due to duplication of data – but storage space is so cheap nowadays so this is usually not an issue). In fact, most NoSQL databases do not even support joins.
- Cost. NoSQL databases usually use clusters of cheap commodity servers, while RDBMS tend to rely on expensive proprietary servers and storage systems. Also, the licenses for RDBMS systems can be quite expensive while many NoSQL databases are open source and therefore free.
The particular suitability of a given NoSQL database depends on the problem it must solve.
- NoSQL databases are increasingly used in big data and real-time web applications. They became popular with the introduction of the web, when databases went from a max of a few hundred users on an internal company application to thousands or millions of users on a web application. NoSQL systems are also called “Not only SQL” to emphasize that they may also support SQL-like query languages.
- Many NoSQL stores compromise consistency (in the sense of the CAP theorem) in favor of availability and partition tolerance. Some reasons that block adoption of NoSQL stores include the use of low-level query languages, the lack of standardized interfaces, and huge investments in existing SQL. Also, most NoSQL stores lack true ACID transactions or only support transactions in certain circumstances and at certain levels (e.g., document level).
Comparing the two
- One of the most severe limitations of relational databases is that each item can only contain one attribute. If we use a bank example, each aspect of a customer’s relationship with a bank is stored as separate row items in separate tables. So the customer’s master details are in one table, the account details are in another table, the loan details in yet another, investments in a different table, and so on. All these tables are linked to each other through the use of relations such as primary keys and foreign keys.
- Non-relational databases, specifically a database’s key-value stores or key-value pairs, are radically different from this model. Key-value pairs allow you to store several related items in one “row” of data in the same table. We place the word “row” in quotes because a row here is not really the same thing as the row of a relational table. For instance, in a non-relational table for the same bank, each row would contain the customer’s details as well as their account, loan and investment details. All data relating to one customer would be conveniently stored together as one record.
