The Cache: Technology Expert's Forum
 
*
Welcome, Guest. Please login or register.
Did you miss your activation email?
May 23, 2012, 07:42:02 AM

Login with username, password and session length


Pages: 1 2 3 [4]
  Print  
Author Topic: noSQL FTW!  (Read 4281 times)
vsloathe
vim ftw!
Global Moderator
Lifer
*****
Offline Offline

Posts: 1669



View Profile
« Reply #45 on: September 10, 2010, 10:04:58 AM »

vsloathe, what's your opinion about Riak? It looks very interesting but I'm little bit worried about performance side. There's also Hypertable which is backed up by Baidu. If it can handle China's search traffic, it probably can handle our sites Wink
Can't speak to Riak yet as I have virtually 0 experience with it aside from reading a couple tech articles. We narrowed our choices down pretty quickly so that we were only choosing between Cassandra, MongoDB, and HBase. Hypertable seems cool, but it also seems like it's "just another noSQL solution". There's nothing about it really that stands out. I like that it's modeled after BigTable, which probably means it has a straight 1:1 implementation of MapReduce, but again why not just use BigTable?

Quote
Right now I'm in love with Redis. The whole key/value pair paradigm is so fascinating to me for some reason. With key/value you don't get any of those nice features like "where age > 18" but in return you get 80000 operations per second with your average Linux machine. I might be horribly wrong here and I challenge you to proof me wrong but in reality there's very little stuff you can't do with key/value datastore. It's just matter of organizing data and coding proper logic to get it.
Redis is awesome. I think you're exactly right. If there is some storage problem that can't be solved with a simple key/value datastore, I can't yet think of it. Granted, there are some problems where it's not the *best* solution, but it would still work.
Logged

hai
kurdt
Lifer
*****
Offline Offline

Posts: 1153


paha arkkitehti


View Profile
« Reply #46 on: September 10, 2010, 02:09:22 PM »

Hypertable seems cool, but it also seems like it's "just another noSQL solution". There's nothing about it really that stands out. I like that it's modeled after BigTable, which probably means it has a straight 1:1 implementation of MapReduce, but again why not just use BigTable?
Check this out: http://nosql.mypopescu.com/post/1037255626/hypertable-the-ultimate-scaling-machine .. I learned few things from that presentation, great presentation overall.

Quote
Redis is awesome. I think you're exactly right. If there is some storage problem that can't be solved with a simple key/value datastore, I can't yet think of it. Granted, there are some problems where it's not the *best* solution, but it would still work.
Yeah.. if you just want to do a quick and "dirty" scalable Ruby on Rails app, just put MongoDB with MongoId and you'll get it done in record time. And it will take a quite lot of pounding before you'll hit the ceiling with that setup.
Logged

I met god and he had nothing to say to me.
lamontagne
Journeyman
***
Offline Offline

Posts: 89


View Profile
« Reply #47 on: September 17, 2010, 02:46:01 PM »

Hey I just wanted to follow up with a cool article I found that goes a bit more in depth about nosql and how there are different kinds of nosql (i think this is where the confusion gets cleared up, or at least it did for me). It also may help you to know which nosql database you should use depending on your problem... I'm finding that most of my problems require a graph nosql database as opposed to just a basic key/store.. though a key/store could be used to implement. I picked this because for most of my apps the relationships between data in a overall view is what's important along with speed and being dynamic. size is generally not an issue and therefore speed is not generally an issue but even small data sets with advanced relationships in a typical relational database require many joins which are expensive. so being dynamic but having the ability to normalize at the end of the day is important to me. Yes I am aware i could use mapreduce and do the same things in mongodb but it's so much easier to deal with the database as a whole as opposed to "here is my collection... here is my map reduce stuff" (basically you see and deal with it all as one big vastly changing spiderweb)... Anyways heres the link

http://www.infoq.com/articles/graph-nosql-neo4j
Logged

"Long time no see. I only pray the caliber of your questions has improved." - Kevin Smith
kurdt
Lifer
*****
Offline Offline

Posts: 1153


paha arkkitehti


View Profile
« Reply #48 on: September 18, 2010, 12:37:25 AM »

Hey I just wanted to follow up with a cool article I found that goes a bit more in depth about nosql and how there are different kinds of nosql (i think this is where the confusion gets cleared up, or at least it did for me). It also may help you to know which nosql database you should use depending on your problem... I'm finding that most of my problems require a graph nosql database as opposed to just a basic key/store.. though a key/store could be used to implement. I picked this because for most of my apps the relationships between data in a overall view is what's important along with speed and being dynamic. size is generally not an issue and therefore speed is not generally an issue but even small data sets with advanced relationships in a typical relational database require many joins which are expensive. so being dynamic but having the ability to normalize at the end of the day is important to me. Yes I am aware i could use mapreduce and do the same things in mongodb but it's so much easier to deal with the database as a whole as opposed to "here is my collection... here is my map reduce stuff" (basically you see and deal with it all as one big vastly changing spiderweb)... Anyways heres the link

http://www.infoq.com/articles/graph-nosql-neo4j
MapReduce is so last year Wink But you are right, it's all about choosing correct tool for the problem. Like if you are going to map out social networks around let's say stamp collectors, you'll end up doing a lot of extra work if you go with MongoDB instead of specialized graph database like Neo4j. We are currently in unprecedented era where everybody has access to tools that make it possible to scale to Google size and beyond. Of course after certain point you'll have to have army of engineers like Google does but that's a different problem that will solve itself when you grow. The main point is that tools that you can grab for free are capable of handling 100k request per second with average commodity hardware and they scale horizontally. One thing where I do respect Google a lot is how they inspired people to create these great tools. Google hasn't provided any tools themselves (because with them it's all about strategy and self-servering corporate agenda), all they did was to release some white papers but that was enough for smart people to create open-source solutions.

I can recommend at least www.highscalability.com and nosql.mypopescu.com which are both covering this whole new-wave database movement quite nicely.
Logged

I met god and he had nothing to say to me.
Pages: 1 2 3 [4]
  Print  
 
Jump to:  

Perkiset's Place Home   Best of The Cache   phpMyIDE: MySQL Stored Procedures, Functions & Triggers
Politics @ Perkiset's   Pinkhat's Perspective   
cache
mart
coder
programmers
ajax
php
javascript
Powered by MySQL Powered by PHP Powered by SMF 1.1.2 | SMF © 2006-2007, Simple Machines LLC
Seo4Smf v0.2 © Webmaster's Talks


Valid XHTML 1.0! Valid CSS!