3 ms·

Exactly. And its not just hardware you can forget about. No longer having to worry about indexing, scheduled backups and database shrinks, temp table sizes, con

Exactly. And its not just hardware you can forget about. No longer having to worry about indexing, scheduled backups and database shrinks, temp table sizes, connection pooling, and all the other nasty stuff that goes along with maintaining a DBMS is equally as nice. I've switched my project from a local MySQL instance to SimpleDB and I'm never looking back. It took some work to simplify my existing schema to be purely atomic (no joins), but after that you can forget just about everything else.

jrockway 18y ago
I would be interested in hearing more about your migration from MySQL to SimpleDB. Basically, I am a big fan of normalization (since none of the other ways seem elegant to me). For example, if I were going to write the schema for a Blog, I would have an articles table, a tags table, and an article<->tag mapping table. This means that "show me articles with tag foo" is indexed (and "faster" than an O(n) search over the articles table). The only approach I can see with SimpleDB is to tolerate scanning all articles to search tags (and authors, etc.) or to maintain a separate "document" for each tag (that links to the articles with the tag). Then I worry about concurrent updates to a tag ( {foo:[1,2]} gets updated to {foo:[1,2,3]} while someone else immediately changes it to {foo:[1,2,4]}; the correct result would be {foo:[1,2,3,4]} but adding 4 overwrites adding 3.) Anyway, like I said, I would be interested in hearing people's experiences. Perhaps I am missing something obvious.
- jsjenkins168 18y ago
  With SimpleDB, you can still accomplish many-to-one and even one-to-many. So in your example schema you described, you could have an attribute (aka column) in your tags domain (aka table) which holds the ids of the article items (aka rows) in your article domain that the tag is associated with. Since your data is denormalized though, you will have many duplicate items if a tag applies to many different articles. Thats ok though, SimpleDB was designed for this dont worry about large domains. So this is how you could get your many-to-one mapping. To determine what articles have tag foo, you would just do the equivalent of select from tags where your attribute value matches the item id for the desired article. It seems unintuitive, but you can actually do one-to-many mappings too with SimpleDB. So you could say "show me all the tags for article A" without a join table or duplicate items. The reason this is possible is because SimpleDB can attach up to 256 values to a single attribute. This obviously isnt possible in SQL. You just assign references to each tag id for that article to one attribute. Kinda like putting a list of Strings in a single cell in SQL. Be very careful with this though, as you cannot exceed 256 values bound to 1 attribute. So no more than 256 tags per article in your example. But the problem with all this is keeping track of changes. updates and deletes do not cascade so you have to handle that yourself. And of course you have to consider eventual consistency if making frequent changes on top of each other. My suggestion to help reduce the complexity of managing your domain references is to use this library (if you are using Java that is). It makes SimpleDB so much more usable: http://code.google.com/p/simplejpa/ http://code.google.com/p/simplejpa/
  - jrockway 18y ago
    Thanks. I hacked together a SimpleDB-alike tonight and played with various index-on-write schemes. I feel a bit better about the situation now. Of course, now I just need to make it as scalable as SimpleDB :) ( Example usage: http://git.jrock.us/?p=MooseX-Storage-Directory.git;a=blob;f=t/example-blog.t;hb=HEAD http://git.jrock.us/?p=MooseX-Storage-Directory.git;a=blob;f... ) You can tell from the test data that I am in a weird mood, though, so time for bed :)

jrockway 18y ago

I would be interested in hearing more about your migration from MySQL to SimpleDB. Basically, I am a big fan of normalization (since none of the other ways seem elegant to me). For example, if I were going to write the schema for a Blog, I would have an articles table, a tags table, and an article<->tag mapping table. This means that "show me articles with tag foo" is indexed (and "faster" than an O(n) search over the articles table). The only approach I can see with SimpleDB is to tolerate scanning all articles to search tags (and authors, etc.) or to maintain a separate "document" for each tag (that links to the articles with the tag). Then I worry about concurrent updates to a tag ( {foo:[1,2]} gets updated to {foo:[1,2,3]} while someone else immediately changes it to {foo:[1,2,4]}; the correct result would be {foo:[1,2,3,4]} but adding 4 overwrites adding 3.) Anyway, like I said, I would be interested in hearing people's experiences. Perhaps I am missing something obvious.

jsjenkins168 18y ago
With SimpleDB, you can still accomplish many-to-one and even one-to-many. So in your example schema you described, you could have an attribute (aka column) in your tags domain (aka table) which holds the ids of the article items (aka rows) in your article domain that the tag is associated with. Since your data is denormalized though, you will have many duplicate items if a tag applies to many different articles. Thats ok though, SimpleDB was designed for this dont worry about large domains. So this is how you could get your many-to-one mapping. To determine what articles have tag foo, you would just do the equivalent of select from tags where your attribute value matches the item id for the desired article. It seems unintuitive, but you can actually do one-to-many mappings too with SimpleDB. So you could say "show me all the tags for article A" without a join table or duplicate items. The reason this is possible is because SimpleDB can attach up to 256 values to a single attribute. This obviously isnt possible in SQL. You just assign references to each tag id for that article to one attribute. Kinda like putting a list of Strings in a single cell in SQL. Be very careful with this though, as you cannot exceed 256 values bound to 1 attribute. So no more than 256 tags per article in your example. But the problem with all this is keeping track of changes. updates and deletes do not cascade so you have to handle that yourself. And of course you have to consider eventual consistency if making frequent changes on top of each other. My suggestion to help reduce the complexity of managing your domain references is to use this library (if you are using Java that is). It makes SimpleDB so much more usable: http://code.google.com/p/simplejpa/ http://code.google.com/p/simplejpa/
- jrockway 18y ago
  Thanks. I hacked together a SimpleDB-alike tonight and played with various index-on-write schemes. I feel a bit better about the situation now. Of course, now I just need to make it as scalable as SimpleDB :) ( Example usage: http://git.jrock.us/?p=MooseX-Storage-Directory.git;a=blob;f=t/example-blog.t;hb=HEAD http://git.jrock.us/?p=MooseX-Storage-Directory.git;a=blob;f... ) You can tell from the test data that I am in a weird mood, though, so time for bed :)