Ingo, Maximum size involves more components of Riak than my specialty area of leveldb. So I did some asking around the engineering room. The word back is:
- 1M is a typical, recommended maximum, - if you care about worst case latencies (tail latencies), should stay below 100K - if you really, really care about latencies, stay below 10K Matthew On Mar 24, 2014, at 12:44 PM, Ingo Rockel <[email protected]> wrote: > Hi Matthew, > > thanks for the Infos. What is the maximum size of objects which I can store > into riak without the need of splitting them and without suffering from > performance issues? > > Best, > > Ingo > > Am 24.03.2014 13:55, schrieb Matthew Von-Maszewski: >> Ingo, >> >> We regularly test Riak and its leveldb backend with 130k objects as part of >> our performance and qualification tests. Works just fine. >> >> The one thing to remember is that with N=3 redundancy, the bandwidth between >> the nodes will approach 3 times the incoming user bandwidth. Make sure your >> network infrastructure is ready between your nodes (servers). >> >> The 130K testing is based upon the loads created by one of our enterprise >> customers. You can read details of that use case here: >> >> http://media.basho.com/pdf/Voxer-Case-Study.pdf >> >> Matthew >> >> >> On Mar 24, 2014, at 7:22 AM, Ingo Rockel <[email protected]> >> wrote: >> >>> Hi List, >>> >>> I'm currently evaluating the possibilities to migrate our mysql-based image >>> storage to something which actually scales and is easier to maintain. >>> >>> Among different distributed file systems (like ceph, openstack swift) I was >>> looking at riak as we already have a riak cluster for storing our users >>> messages. >>> >>> As we are only storing quite stripped down versions of our users photos, >>> the average size of the photos is only about 30-40kb, there might be some >>> above 100KB though. But all are less than 1MB. >>> >>> As our objects are quite small and I don't need anything besides getting >>> the binary for a key I want to use riak without riak CS. Is this a good or >>> bad idea? >>> >>> The current storage (which needs to be migrated) in MySQL has about 35 >>> million entries which consume 1.1TB of space. >>> >>> Any ideas or suggestions? >>> >>> Ingo >>> >>> -- >>> Software Architect >>> >>> Blue Lion mobile GmbH >>> Tel. +49 (0) 221 788 797 14 >>> Fax. +49 (0) 221 788 797 19 >>> Mob. +49 (0) 176 24 87 30 89 >>> >>> [email protected] >>>>>> qeep: Hefferwolf >>> >>> www.bluelionmobile.com >>> www.qeep.net >>> >>> _______________________________________________ >>> riak-users mailing list >>> [email protected] >>> http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com >> > > > -- > Software Architect > > Blue Lion mobile GmbH > Tel. +49 (0) 221 788 797 14 > Fax. +49 (0) 221 788 797 19 > Mob. +49 (0) 176 24 87 30 89 > > [email protected] > >>> qeep: Hefferwolf > > www.bluelionmobile.com > www.qeep.net _______________________________________________ riak-users mailing list [email protected] http://lists.basho.com/mailman/listinfo/riak-users_lists.basho.com
