NoSQL database and its business applications

Transcription

1 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

2 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 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 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.

3 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.

4 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 instancerelational 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:

5 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:

6 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.

7 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

8 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.

9 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.

10 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.

11 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

12 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 a practical guide to NoSQL, Posted by Denise Miura on March 17, 2011 at NoSQL (RDBMS) Ellis, Jonathan: NoSQL Ecosystem. November Blog post of