Amazon SimpleDB vs Amazon RDS - amazon-simpledb

I work at a small ecommerce site and we're looking to move to all Amazon hosted services and I'm unsure the exact difference in RDS and SimpleDB. RDS can use MySQL, can SimpleDB not?

Simply put, I would assume that because your business model is e-commerce that you need transactional consistency in your data solution. Because of this, you should choose one of the RDS options (these are MySQL, Oracle or SQL Server).
AWS SimpleDB is a non-relational data store (or NoSQL), so what you get is flexibility (i.e. schema-less or schema-light) and scalability, but what you don't get is immediate (transactional) consistency and also the query pattern will not use joins.

RDS is basically a relational database in the SQL vein, whereas SDB is a non-relational database. I'd recommend reading through all the info on the Amazon Web Services (AWS) site, as they answer all the questions you might have.
From the AWS FAQs:
Q: When would I use Amazon RDS vs. Amazon EC2 Relational Database AMIs vs. Amazon SimpleDB?
Amazon Web Services provides a number of database alternatives for developers. Amazon RDS enables you to run a fully featured relational database while offloading database administration; Amazon SimpleDB provides simple index and query capabilities with seamless scalability; and using one of our many relational database AMIs on Amazon EC2 and Amazon EBS allows you to operate your own relational database in the cloud. There are important differences between these alternatives that may make one more appropriate for your use case.
More information about AWS database options

Related

AWS Data Transfer charges when using Heroku Rails app with Amazon RDS backend

I have a Ruby on Rails app hosted on Heroku that has a PostgreSQL database that I have hosted outside of Heroku, in my own AWS account as an RDS instance. So Heroku manages my compute/app, and AWS directly manages my RDS. (The reason for this is because the cost is lower than buying the database on Heroku.) However, on my AWS bill, in addition to the RDS charges, I am seeing Data Transfer charges for bandwidth in the us-east-1 region. Heroku's EC2 instances and my RDS instance are both in the same us-east-1 region. I am wondering why I am seeing these Data Transfer charges, and if there is a way to mitigate them without having to stop using Heroku?
Thanks in advance.
If your instances / services are located in the same region but in different availability zones, there will be data transfer charges. This is called a regional data transfer and is charged $.01 per GB. There are variations and exceptions. Best to consult Amazon's web site to determine your exact pricing.
Pricing

How to use multiple databases for Rails server?

I have a Rails application which is using PostgreSQL database and a huge user base is expected. Is there a way to use multiple databases, may be one database for Read operations and other for Write operations.
Any suggestions/solution?
You can achieve it via database clustering. Master database and slave database. Try using amazon RDS or Heroku services.
Use database sharding. Try using Master and slave databases.
Octopus is a really useful gem for that. https://github.com/thiagopradi/octopus

Transferring from Parse-Server to dynamoDB. What foreseeable obstacles are there?

As we all know, I'm one of the thousands of devs who relied on Parse and now forced to find Parse alternative. While transferring Parse-Server to AWS+MongoDB, I've discovered DynamoDB. I'm thinking of just tranferring my whole server side logic to DynamoDB. What are some of the problems that Parse doesn't have that might exist for DynamoDB?
Since Parse includes a web server, you can interact with it via simple HTTP requests. DynamoDB is just a database, so you would need to connect directly through the AWS SDK, or build an API in front of it, possibly using API Gateway and Lambda.
In addition, since Parse is a full-featured Backend as a Service, and DynamoDB is only a database, there are some features in Parse that won't be available if you just use DynamoDB directly from your iOS application. For example user password resets require sending an email to the user. DynamoDB has no "password reset" functionality and can't send emails directly. You would have to build that feature yourself using something like Lambda and SES.
Parse also handles file upload and file hosting, which are features you would no longer have if you just used DynamoDB directly from iOS. You would have to build those features yourself, possibly using S3.
If you are only using Parse as a data store then using DynamoDB directly could certainly work for you, but then again so could MongoDB or any other NoSQL database. You should definitely explore how your database schema would look in DynamoDB before committing to it, because there are certain restrictions on index types and query types that might make it difficult to transition your current schema.
AWS + DynamoDB would be your way to go.
I worked extensively in both, DynamoDB and MongoDB systems and can give you a short summary of an advise.
MongoDB is very easy to work with and has unmatched flexibility in query structure, requires very little thinking ahead of setting up the system.
DynamoDB will provide unmatched scalability, much stricter (very strict) set of rules for creating schemas and requires a lot of planning before you do the setup. However, you don't need to worry about setting up or managing database environment, no worry about master/slave architecture and no concerns of scaling your database.
I go with DynamoDB these days and it's been great.
Just completed a migration from Parse to AWS Dynamo (a few thoughts were posted here: https://www.linkedin.com/pulse/parse-aws-migration-server-less-mobile-backend-mike-kirkwood?trk=prof-post
My experience was that DynamoDD was an acceptable replacement for much of Parse. However, it required some data model changes as DynamoDB doesn't support Pointers or Relationships like Parse did. So, in the app had to adjust some of the writes to add more data to the record in DynamoDB. This did offer some nice benefits in the queries.
DynamoDB also allows you to add indexes to match specific queries.
And, for my use, DynamoDB has proven to be much faster queries than Parse was.
DynamoDB is just a database service, so you can use it to store Parse data but you'll still need a server to process the data and host APIs, etc... On AWS, you could spin up an EC2 instance to run the server, or try to make it run on Lambda.
Parse Server does not natively support either Lambda as a hosting environment or DynamoDB as a storage backend, but fortunately members of the community have recently developed integration for both of these:
https://www.npmjs.com/package/parse-server-dynamodb-adapter
https://github.com/parse-community/parse-server/issues/483

Backend for iOS

I need a backend to store location updates and messages, I was thinking of using JSON to connect to the Amazon S3 server and to fetch and store data.
How many clients could be connected to this server? Is there a way to link a MYSQL server to Amazon S3 for login and users accounts?
S3 is not a database store; you write/delete/replace an entire object.
You want AWS RDS. Amazon manages the DB (MySQL supported). Skim the reference architectures for something applicable to your needs. Scale them down; they're designed to make use of as many AWS services as possible.
http://aws.amazon.com/rds/
http://aws.amazon.com/architecture/
Other option is Amazon Dynamo DB. This is an infinite-scale nosql db with a fully managed REST API. You dont worry about the data size growth, speed etc. AWS take care of all these.
http://aws.amazon.com/dynamodb/.
Even in this case, you need to have some code running in the backend, which receives your REST calls from the iOS and writes to the Dynamo.
Other even easier solutions are https://parse.com/ and https://www.firebase.com/
These are solutions specifically for your kind of needs - Make a mobile backend Datastore. They give client SDK, which has a very great value in terms of offline synch. You just invoke the SDK from the apps and will synch with the backend datasore when the connections are available - reduces your code complexity a lot !

What plan(s) are needed to get Rails set up on AWS?

I'm new to Amazon's cloud though I have used other cloud provides like Rackspace, Windows Azure and Heroku. I want to deploy my Ruby on Rails 4 application on Amazon but I am overwhelmed with all of the services Amazon offers. AWS, EC2, EBS, S3, SimpleDB, Elastic Beanstalk.... argh!!
My site is a relatively simple Rails app with a Postres database. There will not be much traffic at launch but we obviously hope it will grow and need to scale up.
What is a simple, no-frills plan that Amazon offers to get my app out there? I feel like I need to read 100 pages of documentation just to understand what it is that Amazon is offering.
First of all, there are no plans. You sign-up for an AWS account, and you have access to whichever services you want to use.
Secondly, I can wholeheartedly recommend a single-instance Elastic Beanstalk environment to get started. It only uses 1 EC2 virtual server behind the scenes, but you get much better deployment options.
I can't speak to other services like Heroku.

Resources