March17

NoSQL links to more information

Tags: , | Categories: Database Related
Permalink | Comments (2) | Post FeedComment feed by author Jason Short

 

There has been a buzz and hype about the No SQL movement for quite some time.  There was the much publicized Netflix using No Sql, which turns out to be a lot more about reaching internet scale rather than a discussion about relational databases.  In most of the cases where I see people hyping replacement of relational databases they are usually really talking about relaxing ACID compliance, eventual consistency of writes, or caching.

NOSQL Site Link

I recently got a link to an interesting site from a colleague and wanted to share it.

NoSql Summer

Specific Points

There is a lot of good information on the site, but here are a few I wanted to point out.

Cassandra — A Decentralized Structured Storage System – Interesting on a number of levels about scale and failover.

On Designing and Deploying Internet-Scale Services  - A lot of the scalability of any solution comes around a proper design for the scenario.  Why enforce a complete relational validation on something that is temporary for a service?  There are lots of reasons when you should not use a database at all for a problem.

Eventually Consistent – This is perhaps one of the best topics (to me).  There are lots of scenarios where you know your data is cached on a mid tier, and you really only want to make sure the persisted data is eventually consistent.  Perhaps you are always going to read from some cache unless it is empty, then you go back to disk.

The Log-Structured Merge-Tree (LSM-Tree) – Ok, this is just for us computer science geeks…  But it is a really cool concept.  Anyone who has implemented a B-Tree and had to deal with merge operations in a multi threaded scenario will appreciate the thought in this paper.  Not for the neophyte.

If you are at all interested in these topics jump to the site and read through the complete list of papers.

Comments (2) -

19/03/2011 03:57 #

Rick

Good to see you.

First of all I really don’t have any experience with Object databases as a whole, but I have researched them a little bit and do see an advantage for a single user or a small database application. What I don’t immediately see is how they (Object databases) can be utilized in a large corporate setting; the local DBA making changes to the local database to accommodate new inquiries, new data for that local site and making that data available or viewable on a corporate wide level. That concept personally is a stretch for me… seems like that could be a big headache.

Seems like the LSM Tree has a trade off (inserts compared to retrieval); could you switch back and forth depending on what you are trying to do within the database or is that more trouble than it is worth (using a specific algorithm to do a specific purpose)?

Now that platter drives may be becoming an historic item of the past, do you see any optimizations that could be geared toward the new SSD’s (OCZ seems to be making improvements by leaps and bounds)?

Rick

21/03/2011 09:35 #

Jason Short

There are plenty of patterns for using object databases, but a structured corporate environment with a relational design is not one of them.  You can have object databases that have versioning, and even ones that have their central schema defined externally.  But in practice I have almost never seen object databases in use for this scenario.

LSM Trees are a design time decision.  I would think you would end up with a very complicated system if you tried to switch it off and on; but I could be wrong.

SSD's are definately going to change the way databases work in the future.  But I think most of that will be at the OS level.  The database will get faster IO and RAM usage from the VM manager in the OS.  I suppose you could build in logic to the database layer.  Perhaps for indexes and other rapidly changing files (maybe log files).  But the SSD price is still too high to get a 2 TB SSD...  But using the SSD for logs, indexes, would make good sense.  

I have honestly started thinking of SSD as a big level 3 cache.  You have the CPU cache, main memory, SSD, then rotational drive storage.  I think there are even HD's now that do that, they have small SSD's to speed up operations against the magnetic media.  

Jason Short

Comments are closed