NoSQL Rebuttal

Loading...

Из курса от партнера University of Washington

Data Manipulation at Scale: Systems and Algorithms

676 оценки

University of Washington

Data Manipulation at Scale: Systems and Algorithms

676 оценки

Курс 1 из 4 — Specialization Data Science at Scale

Data analysis has replaced data acquisition as the bottleneck to evidence-based decision making --- we are drowning in it. Extracting knowledge from large, heterogeneous, and noisy datasets requires not only powerful computing resources, but the programming abstractions to use them effectively. The abstractions that emerged in the last decade blend ideas from parallel databases, distributed systems, and programming languages to create a new class of scalable data analytics platforms that form the foundation for data science at realistic scales. In this course, you will learn the landscape of relevant systems, the principles on which they rely, their tradeoffs, and how to evaluate their utility against your requirements. You will learn how practical systems were derived from the frontier of research in computer science and what systems are coming on the horizon. Cloud computing, SQL and NoSQL databases, MapReduce and the ecosystem it spawned, Spark and its contemporaries, and specialized systems for graphs and arrays will be covered. You will also learn the history and context of data science, the skills, challenges, and methodologies the term implies, and how to structure a data science project. At the end of this course, you will be able to: Learning Goals: 1. Describe common patterns, challenges, and approaches associated with data science projects, and what makes them different from projects in related fields. 2. Identify and use the programming models associated with scalable data manipulation, including relational algebra, mapreduce, and other data flow models. 3. Use database technology adapted for large-scale analytics, including the concepts driving parallel databases, parallel query processing, and in-database analytics 4. Evaluate key-value stores and NoSQL systems, describe their tradeoffs with comparable systems, the details of important examples in the space, and future trends. 5. “Think” in MapReduce to effectively write algorithms for systems including Hadoop and Spark. You will understand their limitations, design details, their relationship to databases, and their associated ecosystem of algorithms, extensions, and languages. write programs in Spark 6. Describe the landscape of specialized Big Data systems for graphs, arrays, and streams

Из урока

NoSQL: Systems and Concepts

NoSQL systems are purely about scale rather than analytics, and are arguably less relevant for the practicing data scientist. However, they occupy an important place in many practical big data platform architectures, and data scientists need to understand their limitations and strengths to use them effectively.

HBase, Megastore3:53

Spanner cont'd, Google Systems6:25

MapReduce-based Systems5:06

Bringing Back Joins4:32

NoSQL Rebuttal4:55

Познакомьтесь с преподавателями

Bill Howe
Director of Research
Scalable Data Analytics

[MUSIC]

So that's all I want to say about this grid.

But let me give you a little bit of a character of a response to NoSQL by

Mike Stonebraker in Communications of the ACM.

And there was a couple of different blog posts here that talked about two different

arguments in favor of NoSQL, and they responded to each one of those arguments.

And so I'm mostly gonna focus on the second one.

So those two pro NoSQL arguments are these.

Research points out that there's two value propositions offered by

the NoSQL community.

One is performance, and the story as Mike says that I more or less agree with.

Is that these people started out with a MySQL deployment of some kind and

they had a hard time scaling it out in a distributed environment,

and then they had two choices.

Either they could invest in a large scale relational database and

pay, of course, many license fees.

Or they could do something different, use one of these NoSQL systems.

All right. And then the flexibility argument is like,

well look, my data doesn't conform to a rigid schema.

So in the performance argument, I'm not gonna spend too much time on this because

we talked about the trade offs associated with different choices in

transactional guarantees in these various systems.

And the other part of the argument that Mike makes

has more to do with database internals that we didn't necessarily cover.

So let me focus on the flexibility argument.

So, an observation that he makes that I think I'd probably agree with is that,

who are the customers of these NoSQL systems?

And so it's a lot of startups, and a lot of web startups and

it's not quite the such same penetration in the enterprise.

Okay, at least not yet.

So why is this?

Well, one argument is that most of the applications in the enterprise

are traditional OLTP and if you don't know OLTP means online transaction processing.

And so these are sort of bank records,

all right things where doing the transaction right really matters.

Okay, further OLTP on structured organized data.

And so ther's a few other applications around the edges, but

they're perhaps considered less important.

It's okay to take a high risk system because

the application itself is of less interest to executives.

And so really, no asset compliance,

no transactions is equivalent to not much interest in the system.

It's not okay to screw up mission-critical data, but for that app, but for some other

application on the EDGE, maybe it's okay to experiment with a NoSQL system.

Okay, then another, second point he makes is that,

relying on these low level query interfaces is a real tough sell.

And he calls up CODASYL, which is an early data manipulation language that predated

the declarative languages that we've been talking about.

But we've sort of been down that road, and it's tough, and

it's why these higher-level languages were invented.

And again we see it with Map Reduce which is admittedly analytics as opposed to

pure NoSQL.

But we see that the value of these higher level interfaces pays off, okay.

And then the third point he makes is that you know,

NoSQL means all bets are off, right.

There's no sort of homogeneity between all these different deployments.

And so in a typical enterprise you have, you know, maybe 10,000 databases.

You already have enough of a trouble trying to integrate data

from these databases because of the heginata within their schemas.

But at least you know that you're always working with rows and columns and

at least you have kind of a standard interface to manipulating them.

And so

having the number of design decisions that you have to make to encode your data

in one of these NoSQL systems, what becomes the key, what becomes the value?

Are the blog posts nested under the comments, or

the comments nested under the blog posts?

Do users keep their own wall or do the messages on their front page,

or does the person who wrote the message keep access to it, or both?

Right, all these different design decisions of nesting layers and

so forth complicate integration and complicated standards, okay.

So it's a tough sell, the other point that I guess I like to make that's

related to this one here is that there's no real free lunch, right?

Either the complexity's gonna be in the system that you use to model the data, or

you're gonna sort of hand it over to the application.

But in some sense they're always, these schemas, right,

this application business model is gonna be encoded somewhere.

So having it centralized in the data system as opposed to hidden more than once

in various applications, it acts as the data system seems like a good idea, okay.

[MUSIC]

Ознакомьтесь с нашим каталогом

Присоединяйтесь бесплатно и получайте персонализированные рекомендации, обновления и предложения.

Coursera делает лучшее в мире образование доступным каждому, предлагая онлайн-курсы от ведущих университетов и организаций.

© Coursera Inc., 2019 Все права защищены.

Загрузить из App Store

Загрузить в Google Play