+1 thanks for adding that Todd.
Mike
On Mon, Mar 27, 2017 at 9:55 AM, Todd Lipcon wrote:
> On Sat, Mar 25, 2017 at 2:54 PM, Mike Percy wrote:
>
>> Kudu currently relies on local storage on a POSIX file system. Right now
>> there is no support for S3, which would be interesting but is non-triv
On Sat, Mar 25, 2017 at 2:54 PM, Mike Percy wrote:
> Kudu currently relies on local storage on a POSIX file system. Right now
> there is no support for S3, which would be interesting but is non-trivial
> in certain ways (particularly if we wanted to rely on S3's replication and
> disable Kudu's a
Yeah. I think the reason HBase can pretty easily use something like Alluxio or
S3 and Kudu can't as easily do it is because HBase already relied on external
storage (HDFS) for replication so substituting another storage system with
similar properties doesn't really amount to an architectural cha
Mike,
Thanks for the informative answer. I asked this question because I saw that
Alluxio can be used to handle storage for HBase. Plus, we could keep our
cluster size to a minimum and not need to add more nodes based on storage
capacity. We would only need to size our clusters based on load (c
Kudu currently relies on local storage on a POSIX file system. Right now there
is no support for S3, which would be interesting but is non-trivial in certain
ways (particularly if we wanted to rely on S3's replication and disable Kudu's
app-level replication).
I would suggest using only either