Gluster users - Dec 2013 - Scalability - File system or Object Store

>From any experience...which has shown to scale better...a file system or an
object store?

--Randy
San Jose CA
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131209/dcf7491e/attachment.html>

in object stores you sacrifice the consistency gauranteed by filesystems
for **higher** availability.     probably by "scale" you mean higher
availability, so...  the answer is probably object storage.

That said, gluster is an interesting file system in that it is
"object-like" --- it is really fast for lookups.... and so if you
aren't
really sure you need objects, you might be able to do just fine with
gluster out of the box.

One really cool idea that is permeating the gluster community nowadays is
this "UFO" concept, -- you can easily start with regular gluster, and
then
layer an object store on top at a later date if you want to  sacrifice
posix operations for (even) higher availability.

"Unified File and Object Storage - Unified file and object storage allows
admins to utilize the same data store for both POSIX-style mounts as well
as S3 or Swift-compatible APIs."   (from
http://gluster.org/community/documentation/index.php/3.3beta)


On Mon, Dec 9, 2013 at 10:57 AM, Randy Breunling <rbreunling at
gmail.com>wrote:
> From any experience...which has shown to scale better...a file system or
> an object store?
>
> --Randy
> San Jose CA
>
> _______________________________________________
> Gluster-users mailing list
> Gluster-users at gluster.org
> http://supercolony.gluster.org/mailman/listinfo/gluster-users
>


-- 
Jay Vyas
http://jayunit100.blogspot.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://supercolony.gluster.org/pipermail/gluster-users/attachments/20131209/e46cf569/attachment.html>

On 12/09/2013 10:57 AM, Randy Breunling wrote:
> From any experience...which has shown to scale better...a file system
>  or an object store?
In terms of numbers of files/objects, I'd have to say object stores.  S3
and Azure are both over a *trillion* objects, and I've never heard of a
filesystem that size.  In terms of performance it might go the other
way.  More importantly, I think the object stores give up too much in
terms of semantics - e.g. hierarchical directories and rename, byte
granularity, consistency/durability guarantees.  It saddens me to see so
many people working around these limitations in their apps based on
object stores - duplicating each others' work, creating
incompatibibility (e.g. with a half dozen "conventions" for simulating
hierarchical directories), and sometimes even losing data to subtle
distributed-coordination bugs.  An app that uses a subset of an
underlying filesystem's functionality is far more likely to be correct
and portable than one that tries to build extra abstractions on top of a
bare-bones object store.