Hacker Newsnew | comments | show | ask | jobs | submit | ddorian43's comments login

~I got approached twice in the 'who wants to get hired'. Both were very good.

Help the archive team:


Only ones I know that follow an architecture similar to ScyllaDB are aerospike (talks directly to storage) and voltdb(partitioned on cores), while most other projects are in golang/java so I think the answer is not enough.

Also, there are many posts that show that dedicated servers have much better latency/performance compared to vps, but ~everyone still follows the ec2 bandwagon.

Things that I've used in sqlalchemy that(by a quick search) aren't in django (as far as I know):

    composite primary keys
    complex indexes (functional etc)
    arrays + json(these are in django, but I think only recently and before that in contrib)
    server side cursors
    the non-orm part(the lower layer)
    sqlalchemy-alembic (also in django, but only recently I think, still probably less features)
    server_default (define a default value for a column that will be applied to the sql-schema and not just model.field)
    more customization to the lower level db driver(psycopg2, maybe this is also supported in django)
    Use the models + library outside of your web app (ex: in several non-request-serving processes )
There are alot more features that I haven't used/don't know/didn't need.

A few minor points:

1. Django's built in migrations are essentially South 2.0 and a poster above implied that South was more featureful than Alembic. I couldn't say for sure.

2. "Use the models + library outside of your outside of your web app" - not sure why this can't be done with the Django ORM? I use the ORM for many background and batch tasks

It would be interesting to know What SQLA afficianodos think of the new goodies in Django 1.7/1.8:




Obviously the main reason to love the Django ORM is it's tight integration with Django but I think nowadays it's rather undeserving of it's "SQL Alchemy's poor cousin" reputation.

And the bandwidth is $.01/GB and you don't pay for transactions.


Have you tried doing remote freelance work ? It can get pretty lucrative. Compared to local wages, in my country(Albania) a good wage is 500$/month. What I did is that I took a small-hastle full-time job and in the meantime I tried to build a remote-freelance career. Went from 2$-20$/hour (full time) job in 1 year. (i found jobs on odesk, the beginning was very hard but after you build a profile it gets easier).


Was eating milk and cookies and put the bowl on top of the monitor (big old crt monitors) for a moment. The bowl leaked and fried the monitor.




bdr is async replication and doesn't support sharding


aws-aurora doesn't support sharding/scaling


Can you expand on this a bit with some actual technical details about how you think it doesn't scale enough?


aws-aurora is a fancy storage engine + fancy replication

You can't divide the data on multiple servers (sharding)

It will come a time, when you'll exhaust the biggest machine they have available, and then you're stuck


Wouldn't the classic sharding approach at that point simply be to use a second instance? I mean, it'd be great if they handled that for you but I'd tend to assume most apps would have hit the wall on the approach of shoving everything into a single database long before maxing out a 32-core/244GB system with 64TB on SSD.


[meme]You can't simply use a second machine/instance.

While it's true that most companies will be fine in 256GB ram, we were talking about sharding, which it doesn't have.


> [meme]You can't simply use a second machine/instance.

I'm assuming [meme] is shorthand “overly-broad assertion”? It's nice if your database has horizontal scaling built in but it's not like we don't have an entire generation of successful companies who had application-level sharding logic either by necessity or because they found the control it offered was valuable compared to the built-in generic logic.

> While it's true that most companies will be fine in 256GB ram, we were talking about sharding, which it doesn't have.

You still haven't supported the assertion that it's common for places to have massive, heavily-queried databases like this which would not be better split following natural application-level boundaries. This is particularly relevant when discussing AWS as some of the common reasons for keeping everything in one database are sweet-spots for other services (e.g. migrating data for long-term historical reporting over to RedShift).

Again, I'm not questioning that integrated sharding would have its uses – only your sweeping assertion that this is a likely problem for most people and that it's a dead-end (“you're stuck”) rather than merely one of many growing pains which you'll deal with on a successful product. In particular, it's unlikely that everyone will have the same right answer at that scale since access patterns vary widely.


Wrong, aurora supports read replicas, and of course client side sharding.


Every database supports client side sharding.



Applications are open for YC Winter 2016

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | DMCA | Apply to YC | Contact