Monica. Shiralkar wrote:Hbase tables stores data row wise instead of column wise like in Relational DB tables like sql.what is the advantage of this.
Flexibility, scalability among a couple. Any type of NoSQL database has advantages over SQL in areas that that type of NoSQL database is used for. It isn't necessarily one better than another, or that one is used over any other. It is that now we can store data in our app in a style of database that best fits that type of data. Which also means that I might have more than one database in my application. I could have a Relational DB, one like HBase, one like Neo4J, and one like MongoDB as an example.
Monica. Shiralkar wrote:Thanks Mark.Now if this data is huge say in terbytes and I have to display this in JSP, what should be the way of accessing this.One way is using Hive queries but since hive query uses map reduce it can take several minutes so JSP page has to wait all that time.What should be the correct way to displaying huge hbase data in JSP
Surely you don't really want to display terabytes of data in your JSP?
Monica also don't get confused when you use the sentences like
"Hbase tables stores data row wise instead of column wise like in Relational DB tables"
Because that isn't exactly a correct accurate statement, it can definitely confuse someone.
HBase just doesn't have a predefined set of columns that each and every row has to follow. They don't have any predefined set of columns.
So you have a concept of Keyspace which you can analogize with a database/schema
You have a ColumnFamily which you can analogize to a Table.
Then in a ColumnFamily you basically have a Key that is analogize to a Primary Key Column, and that key maps to a set of columns. Or you could think of it as the Key is mapped to a Map<Byte, Byte> of data.
Hope that helps clear things up.
There is a lot more flexibility in this form that a relational database doesn't have.
Form a query perspective, in SQL you might have a 3rd normal form database that requires many joins, which will slow down the performance.
Again, not one database is a one size fits all solution. The idea behind No SQL and New SQL is that not all data works well in a Relational Database. And vice versa.