3 ms·

Thanks for the reply. In which DB should I store this data, considering the option of either DynamoDB or ElastiCache?

by cerebrum 10y ago

brianwawok 10y ago
Why not MySQL or PostgreSQL? Any reason you can't be relational?
- cerebrum 10y ago
  Because I don't want to manage my own DB, so I would rather stick with the options that Amazon offers as a service.
  - brianwawok 10y ago
    You realized Amazon offers hosted MySQL and PostgreSQL, right? One click, and it's up. https://aws.amazon.com/rds/ https://aws.amazon.com/rds/
    - cerebrum 10y ago
      Ok, I want a 2 pronged approach: 1) A NoSQL DB for the main data providing replication and scalability(e.g. Cassandra or DynamoDB). 2) Another DB for quick access and transient Data where replication is not so important, e.g. storing the session cookie. Relational vs Non-relational would not be an issue since I'm only storing very little data here and want fast access and minimize costs(in DynamoDB you still have to pay per operation). Therefore I'm looking for some simple solution like ElastiCache.
      - brianwawok 10y ago
        How much data are you going to have, and of what format? Do you actually need NoSQL here?
        cerebrum 10y ago
        I'm doing a social networking site, so I don't know how much data I will end up with. My reasoning was as follows: 1) The data model is rather simple, basically one table with the user data(name, location, age, etc...) and some images. So it shouldn't be too difficult to do this with NoSql as opposed to SQL. Yes, simpler with SQL but not significantly so. 2) If I ever need to scale, I'd rather make the right choice from the beginning(NoSQL) so as not to need a migration later. 3) In any case NoSQL would be a learning experience for me, so another plus. If there is a mistake in my reasoning I would be grateful for any one pointing it out.
- Roodgorf 10y ago
  Just curious, what would be the major drawbacks of not using relational here? My understanding is that AWS is pushing Dynamo quite a bit and it seems cheaper, so if they're only needing to query off of session id and maybe user id, shouldn't that be sufficient?
  - brianwawok 10y ago
    Relational is super handy. Very easy to report on and do various things down the road. If all he needed was session id, sure, NoSQL is more or less the same. But what about when he adds other fields that are related? Say customer address or reports or .... His life may very well be easier with relational. You should generally start relational. Then branch out if you are hitting the brick walls of relational. People using NoSQL for a 100MB database are making their life SERIOUSLY more difficult than it needs to be. (I have done it before, not fun).
    - cerebrum 10y ago
      > You should generally start relational. I don't know if it is that easy to scale once you realize that the demand is growing, see my other reply here: https://news.ycombinator.com/item?id=12692234 https://news.ycombinator.com/item?id=12692234

Thanks for the reply. In which DB should I store this data, considering the option of either DynamoDB or ElastiCache?

brianwawok 10y ago

Why not MySQL or PostgreSQL? Any reason you can't be relational?

cerebrum 10y ago
Because I don't want to manage my own DB, so I would rather stick with the options that Amazon offers as a service.
- brianwawok 10y ago
  You realized Amazon offers hosted MySQL and PostgreSQL, right? One click, and it's up. https://aws.amazon.com/rds/ https://aws.amazon.com/rds/
  - cerebrum 10y ago
    Ok, I want a 2 pronged approach: 1) A NoSQL DB for the main data providing replication and scalability(e.g. Cassandra or DynamoDB). 2) Another DB for quick access and transient Data where replication is not so important, e.g. storing the session cookie. Relational vs Non-relational would not be an issue since I'm only storing very little data here and want fast access and minimize costs(in DynamoDB you still have to pay per operation). Therefore I'm looking for some simple solution like ElastiCache.
    - brianwawok 10y ago
      How much data are you going to have, and of what format? Do you actually need NoSQL here?
      - cerebrum 10y ago
        I'm doing a social networking site, so I don't know how much data I will end up with. My reasoning was as follows: 1) The data model is rather simple, basically one table with the user data(name, location, age, etc...) and some images. So it shouldn't be too difficult to do this with NoSql as opposed to SQL. Yes, simpler with SQL but not significantly so. 2) If I ever need to scale, I'd rather make the right choice from the beginning(NoSQL) so as not to need a migration later. 3) In any case NoSQL would be a learning experience for me, so another plus. If there is a mistake in my reasoning I would be grateful for any one pointing it out.
Roodgorf 10y ago
Just curious, what would be the major drawbacks of not using relational here? My understanding is that AWS is pushing Dynamo quite a bit and it seems cheaper, so if they're only needing to query off of session id and maybe user id, shouldn't that be sufficient?
- brianwawok 10y ago
  Relational is super handy. Very easy to report on and do various things down the road. If all he needed was session id, sure, NoSQL is more or less the same. But what about when he adds other fields that are related? Say customer address or reports or .... His life may very well be easier with relational. You should generally start relational. Then branch out if you are hitting the brick walls of relational. People using NoSQL for a 100MB database are making their life SERIOUSLY more difficult than it needs to be. (I have done it before, not fun).
  - cerebrum 10y ago
    > You should generally start relational. I don't know if it is that easy to scale once you realize that the demand is growing, see my other reply here: https://news.ycombinator.com/item?id=12692234 https://news.ycombinator.com/item?id=12692234