atom feed3 messages in net.launchpad.lists.openstackRe: [Openstack] [Swift] Where do we g...
FromSent OnAttachments
John DickinsonAug 14, 2012 9:48 am 
朱荣泽Aug 14, 2012 7:52 pm 
Robert van LeeuwenAug 14, 2012 11:55 pm 
Subject:Re: [Openstack] [Swift] Where do we go from here?
From:朱荣泽 (
Date:Aug 14, 2012 7:52:35 pm

It is cool!

2012/8/15 John Dickinson <>

Swift has many exciting features coming in the OpenStack Folsom Release this fall, but where do we go from here? What's next for Swift in grizzly?

I've got some ideas. I'd like to mention them and see where you the community will take them. I've written up most of them into quick one- line blueprints in Launchpad. If you'd like to contribute, grab the blueprint and jump in.

- Optimize the "many small writes" workload. Swift actually handles many small concurrent writes very well. However, "many small writes" generally also implies that the cardinality of a single container gets very large. There are two ways this use case can be improved:

- Implement transparent container sharding

- Provide better listing traversal abstractions. Listing a few billion objects ten thousand at a time is somewhat impractical.

- Solve globally distributed clusters. How can I have servers in London and servers in San Jose in the same logical swift cluster with three replicas total, but guaranteed to have at least one replica in each cluster?

- Support a single logical swift cluster with tiers of storage (eg cheap spinning disks and expensive high IOPS SSD arrays). Can, for example, a user choose to have a container and its objects be served from a particular tier of storage?

- Some deployers have implemented metadata searching by intercepting write requests and sending the metadata to another system. Can metadata searching be implemented in swift itself? One possible implementation would be to dynamically generate indexes on the container DB.

- Support PUTs with unlimited size. Implement server-side large object splitting.

- Support the full HTTP spec for range requests

- There are a few things that could be done to simplify installation

- Create or refactor existing code into a single swift binary or startup script. Would it be possible, for example, to install swift and run one command with the data drives listed and swift "just works"?

- Build a ring server that automatically discovers devices

- Provide a simple, intuitive way to test a deployment after install

- Support concurrent reads to objects to support a read-heavy workload

If you are in the San Francisco area, we will have a swift meetup on August 30 at Citizen Space SF at 6:30 pm.

We will have a swift team meeting on Monday October 1 in #openstack-meeting at 8pm UTC to discuss the plans for swift over the next six months and the sessions for the design summit. If you are interested in participating in swift development, please attend.

If you are a new contributor to swift, please read