SQL Databases Are An Overapplied Solution (And What To Use Instead)
adamblog.heroku.com
SQL Databases Are An Overapplied Solution (And What To Use Instead)
1–10 of 67 posts
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#2Although this topic is frequently discussed on HN, and the portion about document stores is well-hashed, I found the tidbit on binary assets/file uploads very interesting, as I had only used disk before.
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#3Does Heroku offer any alternate persistence engines? I thought they were PostgreSQL only.
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#4Hang on, SQL databases are poor at highly structured things like an order and that's the sort of thing suitable for a document database?
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#5Although this topic is frequently discussed on HN, and the portion about document stores is well-hashed, I found the tidbit on binary assets/file uploads very interesting, as I had only used disk before.
Yeah, I was happy to find out about Tokyo Tyrant as well, had never seen it mentioned.
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#6Yeah, Heroku should put up or shut up until they start offering alternate NoSQL databases (and no, MongoHQ is not an alternative because of network latency).
Interesting article though.
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#7I agree wholeheartedly with this article except for the part about s3/cloudfront being the only tool for storing binary assets. MongoDB's GridFS extension does a fine job of handling files in the database since they shard and replicate just like database records. As for serving them out, you can run it on a cheap unmetered server using nginx + http://github.com/mdirolf/nginx-gridfs
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#8There is no explanation of why a filesystem is a bad place to store "binary blobs".
If you're collapsing the metrics that you're storing IN SQL there is something really wrong going on.
Logs are OK to store in SQL, assuming you're scraping your logs properly and are logging the proper things. Logging every clickthrough in a relational database is somewhat insane. Logging 10 minutes worth of aggregate clickthroughs is perfectly fine. If you think logs should be a ring buffer I challenge you to tell that to any admin of a system that is subject to laws governing the length of time you must store logs (which is pretty much all e-commerce?).
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#9Gridspy monitors power usage in real time. My original plan was to effectively stream the live data through the database as it passed from collection (sensors) to display (on the website). The frequent writing to and polling of the database to keep data "live" was absolutely killing performance.
Now I have moved to a Twisted application that aggregates the data and does occasional writes into the DB. It can answer webserver queries for the latest data out of its internal datastructures and streams live data to the user's browser via Orbited
See http://blog.gridspy.co.nz/2009/09/database-meet... (the database side)
and http://blog.gridspy.co.nz/2009/10/realtime-data... (the whole application structure)
[I posted this on the original site too]
Re: SQL Databases Are An Overapplied Solution (And What To Use Instead)
#10I liked the definition of "transient data" - I've been promoting Redis for that kind of thing but I didn't have the vocabulary to explain what I meant (I've been staying "stuff like stats and counters"). Defining transient data as being frequently written, infrequently read is useful too.