COSC 657 Db. Management Systems

Professor: RAMESH K.

Student: BUER JIANG

Research paper

NoSQL database and its business applications

The original purpose has been contemporary web-expand dbs. The movement started

since early 2009 and is increasing rapidly. Usually more features apply: schema-less, easy

replication uphold, easy API, eventually consistent / BASE (other than ACID), a large amount of

query and more. Therefore, the misleading term "NoSQL" (the community currently interpret it

mostly with "not only sql") should be treated as an alternative to something like the definition

above.

NoSQL was rising a decade ago by giant Internet companies – including Google,

Amazon, Facebook, and LinkedIn – to conquer limitations of relational dbs. such as Oracle, and

MySQL for contemporary web apps. Once those front pioneers proved the pros and efficacy of

NoSQL, app by corporations began to unveil in three different overlapping stages:

Grassroots Experimentation step: In stage I (which initiated around 2010), corporation

programmers began experimenting with NoSQL on side projects and non-duty-critical apps.

Their main requirement was flexibility to uphold agile evolution of proofs of idea and small

apps. Duty Critical Establishments: In stage II (which initiated about 2013), corporations started

to took NoSQL for duty critical apps. In this stage, the critical requirements are performance,

scalability, and availability to develop and / or migrate targeted services.

Broad Re-platforming: In stage III (which is just starting in late 2015), both programmers and

corporations require a general-purpose db. for broad corporation adoption to re-platform

all duty-critical apps and services for the internet economy. In this stage, NoSQL

db. requirements include flexibility, performance, scalability, and availability as well as a

extensive query language and useful indexing.

• Why relational dbs. Become imperfection

Companies have relied on relational dbs. like Oracle, SQL Server, DB2, MySQL and others

for years. So why does relational technology fail to meet the requirements of today’s web,

mobile?

Relational dbs. were born in the era of mainframes and business apps – long before

the Internet, the cloud, big info, mobile and currently, the Internet period. As a matter of fact, the

first business implementation was released by Oracle in 1979. These dbs. were designed to run

on a single host– the bigger, the better. The only way to increase the capacity of these dbs. was to

upgrade the servers – processors, memory, and reserve – to expand up. NoSQL dbs. appeared

because of the exponential growth of the Internet and the rise of web apps. Google released the

BigTable research in 2006, and Amazon released the Dynamo research paper in 2007. Those

dbs. were programed to meet a new generation of corporation needs: The need to develop with

agility and to run at any expand. Develop with Agility To sustain competitive in the Internet era,

business must innovate – and currently they must do it faster than ever before. As this innovation

centers on the evolution of contemporary web, mobile, programmers must deliver apps and

services faster than before. Speed is critical, so is agility, since these apps evolve far more

rapidly than legacy apps like ERP. Relational dbs. are a major blockage to agility, since they do

not uphold agile evolution very well because their monologue info model. Flexibility for faster

evolution A critical rule of agile evolution is evolving app requirements: when the requirements

change, the info prototype changes as well. This is a issue for relational dbs. because the info

prototypes fixed and defined by a static schema. So, to adjust the info model, programmers

should modify the schema, or worse, ask for a “schema change” from the DBA. That slows

down the pace of evolution, not only because it is a manual, time-consuming process, but it also

impacts other apps and services.

• Why choosing NoSQL?

By comparison, the reasons for businesses to adopt a NoSQL database environment over a

relational database have almost every aspect to do with the following market drivers and

technical requirements. When making the change, consider checking out this roadmap relational

database to NoSQL database for a walkthrough of NoSQL education, migration and success.

Simplicity for Easier Evolution Another pro of a document db. that allows faster

innovation is the ability for apps to directly read documents: There’s no need for an instance-

relational mapping layer between the app prototype and the info.

Apps and services prototype info as instances (e.g. employee), multi-valued info as

collections (e.g., roles), and related info as nested instances or collections (e.g. manager).

Therefore, relational dbs. Prototype info treated as tables of rows and columns – related info as

rows within different tables, multi-valued info as rows within the same table. The problem with

relational dbs.is that info is read and written by disassembling, and reassembling instances. This

is called the instance- relational “impedance mismatch.” The workplace is instance-relational

mapping frameworks, which are inefficient at best, problematic at worst.

For instance, thinking about an app for managing resumes. It interacts with resumes as an

instance, the user instance. It contains an array for skills and a collection for positions. Therefore,

writing a resume to a relational db. requires the app to “delete” the user instance. Storing this

resume will need the app to insert six rows into three tables:

Reading this profile would need the app to input six rows from three tables:

In contrast, a document-oriented NoSQL db. reads and writes info formatted in JSON –

which is the matter of a fact standard for consuming and producing info for web, mobile, and

apps. It not only kills the instance-relational impedance mismatch, it also deletes the extra cost of

ORM frameworks and simplifies app evolution since instances are read and written without

“deleting” them – i.e., a single instance can be read or written as a single document:

What about querying and SQL?

It’s critical to remember that “NoSQL” stands for “not only SQL.” SQL is a

comparatively mature query technology used by millions of programmers. Virtually every

programming language and framework, as well as nearly all BI and reporting tools, uphold SQL.

Therefore, it’s important that programmers should be able to influence their SQL skills and tools

when working with a NoSQL db. Host4.0 introduced N1QL, a useful query language that

extends SQL to JSON, enabling programmers to control both the power of SQL and the

flexibility of JSON. It not only upholds queries such as SELECT / FROM / WHERE statements,

it also upholds aggregation (GROUP BY), sorting (SORT BY), joins (LEFT OUTER / INNER),

and querying nested arrays and collections. Other than those, query performance can be

improved with composite, partial, covering indexes, and more.

• Run at Any Scope

Dbs. that uphold web, mobile, and apps must be able to run at any expand.

While it is possible to expand a relational db. like Oracle (using, for example, Oracle RAC),

doing so is typically complex, expensive, and not fully reliable. With Oracle, for example,

scaling out using RAC technology requires numerous components and creates a single point of

failure that jeopardizes availability. By comparison, a NoSQL distributed db. – designed with a

expand-out architecture and no single point of failure – provides compelling operational

advantages.

• Flexibility for Performance at Scope

Apps and services must uphold an ever-increasing number of users and info – hundreds

to thousands to millions of users, and gigabytes to terabytes of operational info. At the same

time, they should expand to sustain performance, and they must do it efficiently. The db. should

be able to expand reads, writes, and reserve. This is a problem for relational dbs. that are limited

to scaling up – i.e., increasing the number of processors, memory, and reserve to a single

physical server. As a result, the ability to expand efficiently, and on demand, is a challenge. It

becomes increasingly expensive, because business must purchase bigger and bigger servers to

accommodate more users and more traffic. Other than, it can cause time outfit the db. must be

taken offline to run hardware upgrades. If the host turns out to be too big, the excess capacity is

an unnecessary cost. If it proved to be too small, degraded performance results in a poor user

experience.

As distributed NoSQL db., Therefore, influences product hardware to expand out – for

instance, add more resources merely by increasing the number of servers. The ability to expand

up allows business to expand more efficiently by (a) establishing less hardware than is required

to meet the current load (b) influencing cheaper hardware and/or cloud infrastructure; and (c)

scaling in-demand and without timeout. Other than being able to expand effectively and

efficiently, distributed NoSQL dbs. are no hard to setup, configure, and expand. They were

designed to distribute reads, writes, and reserve, and they were programed to run at any level –

including the management and monitoring of nodes of all size.

Availability for global establishment as increasing client’s participants take place online

through web and cell apps, availability gradually becomes a major concern. These duty-critical

apps must be available 24/7– no exceptions. Delivering all time availability is a defiance for

relational dbs. that are established to a single physical host or that rely on aggregating with

shared reserve. If established as a single host and it fails, or as a node and the shared reserve

fails, the db. becomes unavailable.

Other than the info can be copied to one or more instances for high availability (internode

copy). While relational dbs. like Oracle need discrete software for duplication, for instance,

Oracle active info guard, NoSQL dbs.do not – it’s built in and it’s self-activate. In contrary to

relational dbs., a distributed, NoSQL db. partitions and distributes info to multiple db. instances

with no shared resources. Furthermore, self-activating failover ensures that if a node fails, the db.

can uninterrupted to perform reads and writes by sending the calls to a different node.

Ensuring global availability is difficult for relational dbs. where discrete add-ons are

required – which increases complexity – or where replication between multiple info centers can

only be used for failover, because only one info center is active at a time. Oracle, for example,

requires Oracle Golden Gate. When copying between info centers, apps built on relational dbs.

can experience performance degradation or find that the info centers are heavily out of sync.

As clients’ participants move online, the need to be available in multiple countries and

regions becomes important. While set up a db. to multiple info centers increases availability and

helps with disaster recovery, it also has the benefit of increasing performance as well since all

reads and writes can be run on the nearest info center, therefore reducing latency.

As distributed NoSQL db., contains built-in copy among info centers – no discrete

app is needed. Moreover, some contains both unidirectional and bidirectional copy

making full active establishments to several info centers – which also making the db. to be

designed in several countries and area and to provide local info to local apps and their

subscribers.

NoSQL is a good fit for current internet economy. As business move to the Internet era –

made by cloud, mobile, and big info technologies – programmers and operations teams should

create and sustain web, mobile, and Internet faster and faster, and at greater expand. NoSQL is

increasingly the db. technology to power today’s web, mobile and apps. Thousands of business,

along with tens of thousands medium-small businesses and startups, have took NoSQL. The use

of NoSQL started with a cache, proof of idea or a small app, then expanded to targeted important

apps, and is currently the base for all app evolution. Under NoSQL, business are easier for both

develop with agility and control at any scope – and to submit the performance and availability

required to satisfied the needs of internet economy businesses. Second Steps —We start with

recommendations for targeting and choosing the right app. Then, we include ideas for

conforming relational info as documents, how to access them in your app, and how to move info

from a relational db. Finally, we emphasis the basics of controlling a NoSQL db. in contrast to a

relational db., and provide instruction on how to make a successful NoSQL proof of idea. It

starts with Info, because the key requirement for Stage three apps in the modern era is the

capability to query info with an expressive language that allows programmers to query any type

of info independent of how it is constructed.

Web and book reference:

• “Couch DB the Definitive Guide”, J. Chris Anderson, Jan Lehnardt and Noah Slater.

O’Reilly Media Inc., Sebastopool, CA, USA. 2010

• “a practical guide to NoSQL”, Posted by Denise Miura on March 17, 2011 at

http://blogs.marklogic.com/2011/03/17/a-practical-guide-to-nosql/

• “NoSQL (RDBMS)”

http://en.wikipedia.org/wiki/NoSQL

• https://www.youtube.com/watch?v=pHAItWE7QMU

• https://www.sitepoint.com/sql-vs-nosql-differences/

• https://www.couchbase.com/nosql-resources/why-nosql

Ellis, Jonathan: NoSQL Ecosystem. November 2009. – Blog post of 2009-11-09.

• http://www.rackspacecloud.com/blog/2009/11/09/nosql-ecosystem/

http://www.tatvasoft.com/blog/why-nosql-is-required-when-rdbms-is-proven/