This whole post is based on the assumption that "Splout SQL" is something "novel" and "necessary". To me these are not clear, though.
I have prototyped some Big Data systems in the past months where we use Sqoop for exporting Hadoop to proprietary SQL databases. So far, so good. I wonder what are the real advantages of using Splout SQL in such cases.
Three things differentiate Splout SQL from using Sqoop for exporting to an existing SQL database:
1) Scalability: Relational databases rarely scales, or are too expensive for big volumes of data. They don't work well with Hadoop.
2) Update isolation: In Splout SQL, database updating never affects serving queries as it is performed in a Hadoop cluster.
3) Atomicity: Datasets are deployed atomically in Splout SQL. That avoids inconsistency problems that arises in RDMS when updating existing databases.
2 comments
[ 3.5 ms ] story [ 10.4 ms ] threadI have prototyped some Big Data systems in the past months where we use Sqoop for exporting Hadoop to proprietary SQL databases. So far, so good. I wonder what are the real advantages of using Splout SQL in such cases.