Show HN: Haystack – Simple graph abstraction over Hbase
1–7 of 7 posts
Re: Show HN: Haystack – Simple graph abstraction over Hbase
#2Confusing as there is already a successful software named Haystack.
Re: Show HN: Haystack – Simple graph abstraction over Hbase
#3Man I love graph abstractions and database, but the inevitable questions comes - why HBase? Why not use a database that isn't nearly impossible to set up?
Re: Show HN: Haystack – Simple graph abstraction over Hbase
#4Man I love graph abstractions and database, but the inevitable questions comes - why HBase? Why not use a database that isn't nearly impossible to set up?
The primary motive for writing this was the fact that Hbase gives a fairly cheap(hdfs) backend storage and near linear scalability. Also most of the schema is encoded in row keys in such a way that hbase prefix scans can be leveraged to serve traversals across billions of nodes/edges.
Re: Show HN: Haystack – Simple graph abstraction over Hbase
#5Confusing as there is already a successful software named Haystack.
I agree although,I was not aware of django-haystack at the time :)
Re: Show HN: Haystack – Simple graph abstraction over Hbase
#6Man I love graph abstractions and database, but the inevitable questions comes - why HBase? Why not use a database that isn't nearly impossible to set up?
The primary motive for writing this was the fact that Hbase gives a fairly cheap(hdfs) backend storage and near linear scalability. Also most of the schema is encoded in row keys in such a way that hbase prefix scans can be leveraged to serve traversals across billions of nodes/edges.
Cheap in only the most puerile sense - the complexity and availability foists a particular cost on HBase that is just too high for most people.
Re: Show HN: Haystack – Simple graph abstraction over Hbase
#7Earlier quoted context omitted.
The primary motive for writing this was the fact that Hbase gives a fairly cheap(hdfs) backend storage and near linear scalability. Also most of the schema is encoded in row keys in such a way that hbase prefix scans can be leveraged to serve traversals across billions of nodes/edges.
Cheap in only the most puerile sense - the complexity and availability foists a particular cost on HBase that is just too high for most people.
Maybe you are correct, Hbase is not easy to configure for sure but in terms of scalability (sheer number of row keys you can dump) there are not a lot of other components which can compete.
Although theoretically this abstraction can live on top of any backend which has facilities for fast prefix scans.