NoSQL技术精要：剖析与实践

需积分: 41 122 浏览量更新于2024-07-24 收藏 5.91MB PDF 举报

"对NOSQL技术的深度剖析，揭示传统数据库的局限性并探讨NOSQL的核心理念。通过《NoSQL Distilled》一书，深入理解这个新兴的多元持久化世界的概览。" NOSQL（Not Only SQL）技术是为了解决传统关系型数据库在大数据、高并发、分布式环境下的局限性而提出的。传统的SQL数据库，如MySQL、Oracle等，以ACID（原子性、一致性、隔离性、持久性）特性为核心，保证了数据的强一致性和事务性，但在处理海量数据、实时查询和高可用性方面往往显得力不从心。 NOSQL技术的精华思想主要体现在以下几个方面： 1. 分布式存储：NOSQL数据库通常设计为分布式架构，能轻松扩展到多台服务器，实现水平扩展，提高系统的可伸缩性和容错性。例如，Cassandra和HBase就是基于分布式键值存储的NOSQL数据库。 2. 弱一致性：NOSQL允许在某些场景下牺牲强一致性，换取更高的系统性能和可用性。这种模式称为最终一致性，意味着数据更新可能需要一段时间才能在整个系统中可见。 3. 数据模型多样性：NOSQL数据库提供了多种数据模型，如键值对、列族、文档型和图形数据库，以适应不同的应用场景。比如，MongoDB是文档型数据库，适合处理结构灵活的数据；而Neo4j则是图形数据库，擅长处理实体间的关系。 4. 无固定模式：与SQL数据库需要预先定义表结构不同，NOSQL数据库通常不需要预定义模式，允许数据模型随着业务需求的变化而动态调整。 5. 高性能：NOSQL数据库通常采用内存优先的设计，优化读写速度，适合实时查询和大数据处理。例如，Redis作为内存数据库，提供极高的读写性能。《NoSQL Distilled》这本书由Pramod J. Sadalage和Martin Fowler合著，是一本关于NOSQL的权威指南。书中详细介绍了NOSQL技术的发展背景、核心理念以及各种类型的NOSQL数据库，包括它们的优势、适用场景和潜在挑战，帮助读者全面理解这一新兴的数据库领域。 NOSQL技术是应对现代互联网和大数据时代的一种创新解决方案，它提供了与传统SQL数据库不同的数据管理方式，为企业和个人开发者提供了更多的选择。然而，选择哪种数据库取决于具体的应用场景，理解NOSQL的优缺点并做出合适的选择至关重要。

need to process larger data volumes led to a shift, in large systems, from scaling

vertically to scaling horizontally on clusters. This explains an important feature of

the data model of many NoSQL databases—the explicit storage of a rich structure of

closely related data that is accessed as a unit. In this book we call this kind of

structure an aggregate.

Chapter 2 describes how aggregates manifest themselves in three of the main

data models in NoSQL land: key-value (“Key-Value and Document Data Models,”

p. 20), document (“Key-Value and Document Data Models,” p. 20), and column

family (“ Column-Family Stores,” p. 21) databases. Aggregates provide a natural

unit of interaction for many kinds of applications, which both improves running on

a cluster and makes it easier to program the data access. Chapter 3 shifts to the

downside of aggregates—the difficulty of handling relationships (“Relationships,”

p. 25) between entities in different aggregates. This leads us naturally to graph

databases (“ Graph Databases,” p. 26), a NoSQL data model that doesn’t fit into the

aggregate-oriented camp. We also look at the common characteristic of NoSQL

databases that operate without a schema (“Schemaless Databases,” p. 28)—a feature

that provides some greater flexibility, but not as much as you might first think.

Having covered the data-modeling aspect of NoSQL, we move on to

distribution: Chapter 4 describes how databases distribute data to run on clusters.

This breaks down into sharding (“Sharding,” p. 38) and replication, the latter

being either master-slave (“Master-Slave Replication,” p. 40) or peer-to-peer

(“ Peer-to-Peer Replication,” p. 42) replication. With the distribution models

defined, we can then move on to the issue of consistency. NoSQL databases

provide a more varied range of consistency options than relational databases—

which is a consequence of being friendly to clusters. So Chapter 5 talks about how

consistency changes for updates (“Update Consistency,” p. 47) and reads (“Read

Consistency,” p. 49), the role of quorums (“Quorums,” p. 57), and how even some

durability (“Relaxing Durability,” p. 56) can be traded off. If you’ve heard anything

about NoSQL, you’ll almost certainly have heard of the CAP theorem; the “ The

CAP Theorem” section on p. 53 explains what it is and how it fits in.

While these chapters concentrate primarily on the principles of how data gets

distributed and kept consistent, the next two chapters talk about a couple of

important tools that make this work. Chapter 6 describes version stamps, which are

for keeping track of changes and detecting inconsistencies. Chapter 7 outlines map-

reduce, which is a particular way of organizing parallel computation that fits in well

with clusters and thus with NoSQL systems.

Once we’re done with concepts, we move to implementation issues by

looking at some example databases under the four key categories: Chapter 8 uses

Riak as an example of key-value databases, Chapter 9 takes MongoDB as an

example for document databases, Chapter 10 chooses Cassandra to explore column-

family databases, and finally Chapter 11 plucks Neo4J as an example of graph

databases. We must stress that this is not a comprehensive study—there are too

many out there to write about, let alone for us to try. Nor does our choice of

examples imply any recommendations. Our aim here is to give you a feel for the

variety of stores that exist and for how different database technologies use the

concepts we outlined earlier. You’ll see what kind of code you need to write to

program against these systems and get a glimpse of the mindset you’ll need to use

them.

A common statement about NoSQL databases is that since they have no

schema, there is no difficulty in changing the structure of data during the life of an

application. We disagree—a schemaless database still has an implicit schema that

needs change discipline when you implement it, so Chapter 12 explains how to do

data migration both for strong schemas and for schemaless systems.

All of this should make it clear that NoSQL is not a single thing, nor is it

something that will replace relational databases. Chapter 13 looks at this future

world of Polyglot Persistence, where multiple data-storage worlds coexist, even

within the same application. Chapter 14 then expands our horizons beyond this

book, considering other technologies that we haven’t covered that may also be a

part of this polyglot-persistent world.

With all of this information, you are finally at a point where you can make a

choice of what data storage technologies to use, so our final chapter (Chapter 15,

“Choosing Your Database,” p. 147) offers some advice on how to think about these

choices. In our view, there are two key factors—finding a productive programming

model where the data storage model is well aligned to your application, and

ensuring that you can get the data access performance and resilience you need. Since

this is early days in the NoSQL life story, we’re afraid that we don’t have a well-

defined procedure to follow, and you’ll need to test your options in the context of

your needs.

This is a brief overview—we’ve been very deliberate in limiting the size of

this book. We’ve selected the information we think is the most important—so that

you don’t have to. If you are going to seriously investigate these technologies,

you’ll need to go further than what we cover here, but we hope this book provides

a good context to start you on your way.

We also need to stress that this is a very volatile field of the computer

industry. Important aspects of these stores are changing every year—new features,

new databases. We’ve made a strong effort to focus on concepts, which we think

will be valuable to understand even as the underlying technology changes. We’re

pretty confident that most of what we say will have this longevity, but absolutely

sure that not all of it will.

Who Should Read This Book

Our target audience for this book is people who are considering using some form of

a NoSQL database. This may be for a new project, or because they are hitting

barriers that are suggesting a shift on an existing project.

Our aim is to give you enough information to know whether NoSQL

technology makes sense for your needs, and if so which tool to explore in more

depth. Our primary imagined audience is an architect or technical lead, but we

think this book is also valuable for people involved in software management who

want to get an overview of this new technology. We also think that if you’re a

developer who wants an overview of this technology, this book will be a good

starting point.

We don’t go into the details of programming and deploying specific databases

here—we leave that for specialist books. We’ve also been very firm on a page

limit, to keep this book a brief introduction. This is the kind of book we think you

should be able to read on a plane flight: It won’t answer all your questions but

should give you a good set of questions to ask.

If you’ve already delved into the world of NoSQL, this book probably won’t

commit any new items to your store of knowledge. However, it may still be useful

by helping you explain what you’ve learned to others. Making sense of the issues

around NoSQL is important—particularly if you’re trying to persuade someone to

consider using NoSQL in a project.

What Are the Databases

剩余303页未读，继续阅读

cqtomcqtom

粉丝: 0
资源: 4

NoSQL技术精要：剖析与实践

noSQL技术 Polyglot

NoSQL技术介绍

山东大学NOSQL课程精华：TIDB体系结构与实战总结

计算机技术频道精华选

NoSQL误用与陷阱：QCon2011杭州演讲精华

JAVA MongoDB面试精华：理解NoSQL与MySQL差异与优缺点

2023年MySQL面试精华：关系型与NOSQL对比及索引优化详解

编程狂人周刊：IT技术精华分享

MapReduce与大数据管理系统：NoSQL、NewSQL的比较

Hadoop开发者第三期：技术精华与数据库访问解析

最新资源