On 07/30/2014 03:27 PM, Gergely Horv?th wrote: > Hello Everyone! > > I've been a Ceph fan since I wrote my Bsc thesis about distributed file > systems. Now I am doing DevOps at our company, and we are really excited > about cloud technology. Or well, let's say I want to use Ceph, and > everyone else is interested in how I will succeed. > > I've used Ceph as a file system, a block storage for VMs, but now I am > looking at librados and object storage. We have done performance tests, > stress tests, all went really good. > > Correct me if I am wrong, but as far as I understand, I can not create > transactions and thus, I can not really use a Ceph object storage > concurrently. > That's not completely true. The OSDs support Atomic transactions. You could look at creating your own OSD class which does local transactions on objects. > What we are dealing with is location based data, so generally speaking > we have: timestamps, user IDs, location data and extra data (like fuel > level, etc.). We want to push these into a big database and access it > regularly. > > To sum it up, I have the following questions: > * Where should I look if I want to use Ceph Object storage concurrently, > reading and writing lots of small data? Nothing specific, librados should give you what you need. Ceph is very concurrent, so if you write to different objects at the same time those I/Os will go in parallel. > * Does the object size make any difference in speed and reliability? I > mean should we aggregate small information into like one day blocks of > data and put that into the cloud as one object? > Speed? Probably because of the underlying filesystem. This could however change with the upcoming Keyvalue store instead of the filestore which uses XFS/btrfs. Reliability? Not really, but there is probably somebody who might argue that smaller or bigger objects are more reliable. But in the simple way, not really. > My best guess is that we should write a layer on top of librados that > provides us the required features that Ceph can't. The only other way I > can think of is having a really good structure and algorithm like CRUSH > for our objects, so if many nodes write data into the same object, they > can do it without transactions and locks. > Yes, that would be the best approach. Build your application logic on top of librados. A simple thing could be the object names. For example, you have a userID which is X and a timestamp which is a day. The object name would be: user_X_2014-07-30 In the object you could store any kind of data you want or even use the omap or xattrs of a object to store additional information. Wido > We have been using HyperTable, but it does not really work well in a > distributed environment (at least it can not get any close to Ceph in > terms of reliability) and we neither had any luck with mixing HyperTable > with Ceph. > > Thank you for your thoughts and help, > Gregory > > -- > ?dv?zlettel / Best regards > > Horv?th Gergely | gergely.horvath at inepex.com > > IneTrack - Nyomk?vet?s egyszer?en | Inepex Kft. > ?gyf?lszolg?lat: support at inetrack.hu | +36 30 825 7646 | support.inetrack.hu > Web: www.inetrack.hu | nyomkovetes-blog.hu | facebook.com/inetrack > > Inepex - The White Label GPS fleet-tracking platform | www.inepex.com > _______________________________________________ > ceph-users mailing list > ceph-users at lists.ceph.com > http://lists.ceph.com/listinfo.cgi/ceph-users-ceph.com > -- Wido den Hollander 42on B.V. Ceph trainer and consultant Phone: +31 (0)20 700 9902 Skype: contact42on
 |