Java Development 2.0:nosql

Introduction: In the Web 2.0 era, NoSQL data stores (such as Bigtable and CouchDB) were mainstreamed from the edge because they were able to solve scalability problems and could solve the problem on a large scale. Google and Facebook are just two well-known companies that have started using NoSQL data storage, and we are still in the early stages of using NoSQL data storage. The modeless data store is fundamentally different from a traditional relational database, but it's much simpler to use than you might think, especially if you start with a domain model rather than a relational model.

Relational databases have dominated data storage for more than 30 of years, but the growing popularity of modeless (or NoSQL) databases suggests that change is taking place. Although the RDBMS provides a solid foundation for storing data in a traditional client-server architecture, it cannot be easily (or cheaply) extended to multiple nodes. This is a very unfortunate weakness in the era of highly scalable WEB applications such as Facebook and Twitter.

Despite early alternatives to relational databases (remember object-oriented databases?) Cannot solve real-urgent problems, NoSQL databases (such as Google's Bigtable and Amazon's SimpleDB) are emerging as a direct response to the WEB's highly scalable needs. In essence, NoSQL may be a killer app for killers-as Web 2.0 evolves, Web application developers may encounter more, not less, applications.

In this issue of Java Development 2.0, I will introduce you to modeless data modeling, which is a major impediment to the use of NoSQL by many developers trained in relational thinking mode. You'll learn that starting with a domain model rather than a relational model is the key to simplifying your changes. If you use Bigtable (as shown in my example), you can extend it with the help of a lightweight framework of Gaelyk:google APP Engine.

NoSQL: A new way of thinking?

When developers talk about relationships or NoSQL databases, the first thing they often mention is that they need to change their thinking style. I think that actually depends on your initial data modeling method. If you are accustomed to designing your application by first modeling your database structure (that is, by first determining the tables and their associated relationships), then using a modeless data store (such as Bigtable) for data modeling requires you to rethink how you do things. However, if you design your application from a domain model, then the Bigtable structure will look more natural.

Build to achieve scalability

New problems with highly scalable WEB applications come with some new solutions. Instead of relying on a relational database to address its storage needs, Facebook uses a "key/value" store-primarily a high-performance HashMap. The internal solution, called Cassandra, was also used by Twitter and Digg, and recently donated to Apache Software Foundation. Google is another WEB entity, and its explosive growth requires it to seek a-bigtable data store, which is the result of the search.

The non-relational data store does not have a join table or primary key, or even the concept of a foreign key (although the two types of keys appear in a looser form). Therefore, if you try to build relational modeling as a basis for data modeling in a NoSQL database, you may end up failing. Starting with the domain model will make things easier; in fact, I've found that the flexibility of modeless structures under the domain model is coming back to life.

The relative complexity of migrating from a relational data model to a modeless data model depends on your approach: whether you start with a relationship based design or a domain-based design. When you migrate to a database such as CouchDB or Bigtable, you do lose the smooth feeling of a mature, persistent storage platform such as Hibernate (at least now). On the other hand, you have the green space effect to build it yourself. In this process, you will drill down into the modeless data store.