Everand Logo

Welcome to Everand!

  • Discover millions of ebooks, audiobooks, and so much more with a free trial

    Only $11.99/month after trial. Cancel anytime.

    Joe Celko’s Complete Guide to NoSQL: What Every SQL Professional Needs to Know about Non-Relational Databases
    Joe Celko’s Complete Guide to NoSQL: What Every SQL Professional Needs to Know about Non-Relational Databases
    Joe Celko’s Complete Guide to NoSQL: What Every SQL Professional Needs to Know about Non-Relational Databases
    Ebook423 pages3 hours

    Joe Celko’s Complete Guide to NoSQL: What Every SQL Professional Needs to Know about Non-Relational Databases

    By Joe Celko

    4/5

    ()

    Read preview

    About this ebook

    Joe Celko's Complete Guide to NoSQL provides a complete overview of non-relational technologies so that you can become more nimble to meet the needs of your organization. As data continues to explode and grow more complex, SQL is becoming less useful for querying data and extracting meaning. In this new world of bigger and faster data, you will need to leverage non-relational technologies to get the most out of the information you have. Learn where, when, and why the benefits of NoSQL outweigh those of SQL with Joe Celko's Complete Guide to NoSQL.

    This book covers three areas that make today's new data different from the data of the past: velocity, volume and variety. When information is changing faster than you can collect and query it, it simply cannot be treated the same as static data. Celko will help you understand velocity, to equip you with the tools to drink from a fire hose. Old storage and access models do not work for big data. Celko will help you understand volume, as well as different ways to store and access data such as petabytes and exabytes. Not all data can fit into a relational model, including genetic data, semantic data, and data generated by social networks. Celko will help you understand variety, as well as the alternative storage, query, and management frameworks needed by certain kinds of data.

    • Gain a complete understanding of the situations in which SQL has more drawbacks than benefits so that you can better determine when to utilize NoSQL technologies for maximum benefit
    • Recognize the pros and cons of columnar, streaming, and graph databases
    • Make the transition to NoSQL with the expert guidance of best-selling SQL expert Joe Celko
    LanguageEnglish
    PublisherElsevier Science
    Release dateOct 7, 2013
    ISBN9780124072206
    Joe Celko’s Complete Guide to NoSQL: What Every SQL Professional Needs to Know about Non-Relational Databases
    Author

    Joe Celko

    Joe Celko served 10 years on ANSI/ISO SQL Standards Committee and contributed to the SQL-89 and SQL-92 Standards. Mr. Celko is author a series of books on SQL and RDBMS for Elsevier/MKP. He is an independent consultant based in Austin, Texas. He has written over 1200 columns in the computer trade and academic press, mostly dealing with data and databases.

    Read more from Joe Celko

    Related to Joe Celko’s Complete Guide to NoSQL

    Related ebooks

    Databases For You

    View More
    View More

    Related podcast episodes

    Related articles

    • Article

      The Future Of The Database

      Aug 27, 2019

      The Future Of The Database
      7 min read

    • Article

      Types Of Databases

      Aug 27, 2019

      NoSQL databases provide the performance, scalability and stability that’s required by the modern data-driven apps we interact with these days. But that is where the similarity between NoSQL systems end. In fact, it wouldn’t be wrong to say that the o

      1 min read

    • Article

      What is ELT?

      Apr 1, 2021

      It stands for extract, load, and transform- the processes a data pipeline uses for replicating the data from a source system into a target system such as a cloud data warehouse. 1. Extraction is the first step in which data is copied from the source

      6 min read

    • Article

      Rokoko Studio 2.0

      Feb 23, 2021

      Rokoko Studio 2.0
      1 min read

    • Article

      Mailserver

      May 3, 2022

      Mailserver
      2 min read

    • Article

      Mailserver

      May 3, 2022

      Mailserver
      2 min read

    • Article

      Browser Wars 2020

      May 26, 2020

      Browser Wars 2020
      8 min read

    • Article

      Browser wars 2020

      Nov 2, 2020

      Browser wars 2020
      8 min read

    • Article

      Observability Of The Kernel And Containers

      Apr 4, 2023

      Mihalis Tsoukalos is currently working on Time Series. You can reach him at: @mactsouk. For our final delve into eBPF, we’re tackling applications, the kernel and Docker containers. At the end of the day, all Linux machines execute code for applicat

      10 min read

    • Article

      Crystal Db Balls

      Dec 15, 2020

      “It’s that time of year where luminaries across the tech world try to predict what will happen in the next 12 months. First, a safe bet… database as a service (DBaaS) will continue to grow. DBaaS is the leading way to consume databases as it’s more c

      1 min read

    • Article

      Browser Wars 2020

      Aug 24, 2020

      Browser Wars 2020
      8 min read

    • Article

      Browser Wars 2020

      Jun 30, 2020

      Browser Wars 2020
      8 min read

    • Article

      Kernel Watch

      Jul 25, 2023

      Linus Torvalds announced both the release of Linux 6.4, and the first release candidate for what will become Linux 6.5 in another couple of months. Linux 6.4 had few “big ticket” user visible features (although it did include initial Apple Silicon M2

      2 min read

    • Article

      Jonathan Ellis INTERVIEW

      Oct 22, 2019

      Jonathan Ellis INTERVIEW
      6 min read

    • Article

      Mailserver

      May 4, 2021

      Mailserver
      4 min read

    • Article

      Mailserver

      Oct 19, 2021

      Mailserver
      3 min read

    • Article

      REDUCING IT COSTS FOR SMEs

      Jan 5, 2023

      Where is your company’s data stored? It’s all the rage to push data up into the cloud and to make it someone else’s problem. However, this is rarely the real outcome. While I would accept that a well-run data centre is likely to be more robust than a

      4 min read

    • Article

      Declutter Your Network

      Apr 4, 2024

      Declutter Your Network
      9 min read

    • Article

      “When Something Goes Wrong, You Realise You’re Like That Cartoon Character That Has Run Off The Edge Of The Cliff”

      Feb 9, 2023

      We need to talk about data. Specifically, your data and my data. The stuff we use on a day-to-day basis, from where we store it to what our expectations are for its safe handling. Now let me get one thing clear from the beginning: I am going to sugge

      9 min read

    • Article

      Kernel Watch

      Apr 2, 2024

      Linus Torvalds announced Linux 6.8, noting that the development cycle had been calm over the trailing couple of weeks, “just as it should be”. The new kernel includes many performance enhancements under the bonnet. Among these are support for variabl

      2 min read

    • Article

      Nextcloud

      Jan 5, 2021

      Nextcloud
      4 min read

    Related categories

    Reviews for Joe Celko’s Complete Guide to NoSQL

    4/5

    1 rating0 reviews

    What did you think?

    Tap to rate

    Review must be at least 10 words

      Book preview

      Joe Celko’s Complete Guide to NoSQL - Joe Celko

      1

      NoSQL and Transaction Processing

      Abstract

      This chapter discusses traditional batch and transaction processing. A queue of jobs being read into a mainframe computer is how the bulk of commercial data processing is still done. Even transaction processing models finish with a batch job to load the databases with their new ETL tools. We need to understand both of these models and how they can be used with new technologies, and this chapter discusses these details.

      Keywords

      NoSQL; transaction processing

      Introduction

      This chapter discusses traditional batch and transaction processing. A queue of jobs being read into a mainframe computer is still how the bulk of commercial data processing is done. Even transaction processing models finish with a batch job to load the databases with their new ETL (extract, transform, load) tools. We need to understand both of these models and how they can be used with new technologies.

      In the beginning, computer systems did monoprocessing, by which I mean they did one job from start to finish in a sequence. Later, more than one job could share the machine and we had multiprocessing. Each job was still independent of the others and waited in a queue for its turn at the hardware.

      This evolved into a transaction model and became the client–server architecture we use in SQL databases. The goal of a transactional system is to assure particular kinds of data integrity are in place at the end of a transaction. NoSQL does not work that way.

      1.1 Databases Transaction Processing in the Batch Processing World

      Let’s start with a historical look at data and how it changed. Before there was Big Data there was Big Iron—that is, the mainframe computers, which used batch processing. Each program ran with its own unshared data and unshared processor; there was no conflict with other users or resources. A magnetic tape or deck of punch cards could be read by only one job at a time.

      Scheduling batch jobs was an external activity. You submitted a job, it went into a queue, and a scheduler decided when it would be run. The system told an operator (yes, this is a separate job!) which tapes to hang on, what paper forms to load into a printer, and all the physical details. When a job was finished, the scheduler had to release the resources so following jobs could use them.

      The scheduler had to assure that every job in the queue could finish. A job might not finish if other jobs were constantly assigned higher priority in the queue. This is called a live-lock problem. Think of the runt of a litter of pigs always being pushed away from its mother by the other piglets. One solution is to decrease the priority number of a job when it has been waiting for n seconds in the queue until it eventually gets to the first position.

      For example, if two jobs, J1 and J2, both want to use resources A and B, we can get a dead-lock situation. Job J1 grabs resource A and waits for resource B; job J2 grabs resource B and waits for resource A. They sit and wait forever, unless one or both of the jobs releases its resource or we can find another copy of one of the resources.

      This is still how most commercial data processing is done, but the tape drives have been swapped for disk drives.

      1.2 Transaction Processing in the Disk Processing World

      The world changed when disk drives were invented. At first, they were treated like fast tape drives and were mounted and dismounted and assigned to a single job. But the point of a database is that it is a common resource with multiple jobs (sessions) running at the same time.

      There is no queue in this model. A user logs on in a session, which is connected to the entire database. Tables are not files, and the user does not connect to a particular table. The Data Control Language (DCL) inside the SQL engine decides what tables are accessible to which users.

      If the batch systems were like a doorman at a fancy nightclub, deciding who gets inside, then a database system is like a waiter handling a room full of tables (sorry, had to do that pun) that are concurrently doing their own things.

      In this world, the amount of data available to a user session is huge compared to a magnetic tape being read record by record. There can be many sessions running at the same time. Handling that traffic is a major conceptual and physical change.

      1.3 ACID

      The late Jim Gray really invented modern transaction processing in the 1970s and put it in the classic paper The Transaction Concept: Virtues and Limitations in June 1981. This is where the ACID (atomicity, consistency, isolation, and durability) acronym started. Gray’s paper discussed atomicity, consistency, and durability; isolation was added later. Bruce Lindsay and colleagues wrote the paper Notes on Distributed Databases in 1979 that built upon Gray’s work, and laid down the fundamentals for achieving consistency and the primary standards for database replication. In 1983, Andreas Reuter and Theo Härder published the paper Principles of Transaction-Oriented Database Recovery and coined the term ACID.

      The terms in ACID mean:

      ◆ Atomicity. Either the task (or all tasks) within a transaction are performed or none of them are. This is the all-or-none principle. If one element of a transaction fails, the entire transaction fails. SQL carries this principle internally. An INSERT statement inserts an entire set of rows into a table; a DELETE statement deletes an entire set of rows from a table; an UPDATE statement deletes and inserts entire sets.

      ◆ Consistency. The transaction must meet all protocols or rules defined by the system at all times. The transaction does not violate those protocols and the database must remain in a consistent state at the beginning and end of a transaction. In SQL this means that all constraints are TRUE at the end of a transaction. This can be because the new state of the system is valid, or because the system was rolled back to its initial consistent state.

      ◆ Isolation. No transaction has access to any other transaction that is in an intermediate or unfinished state. Thus, each transaction is independent unto itself. This is required for both performance and consistency of transactions within a database. This is not true in SQL; we have a concept of levels of isolation. A session can see uncommitted data at certain levels of isolation. This uncommitted data can be rolled back by its session, so in one sense, it never existed.

      ◆ Durability. Once the transaction is complete, it will persist as complete and cannot be undone; it will survive system failure, power loss, and other types of system breakdowns. This is a hardware problem and we have done a good job of this. We just do not let data sit in volatile storage before we persist it.

      This has been done with various locking schemes in most SQL databases. A lock says how other sessions can use a resource, such as reading only committed rows, or allowing them to read uncommitted rows, etc. This is called a pessimistic concurrency model. The underlying assumption is that you have to protect yourself from other people and that conflict is the normal situation.

      The other popular concurrency model is called optimistic concurrency. If you have worked with microfilm, you know this model. Everyone gets a copy of the data to do with it as they wish in their session. In microfilm systems, the records manager would make copies of a document from the film and hand them out. Each employee would mark up his or her copy and turn it into central records.

      The assumptions in this model are:

      ◆ Queries are much more common than database changes. Design for them.

      ◆ Conflicts are rare when there are database changes. Treat them as

      Enjoying the preview?
      Page 1 of 1