Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Startups should use a relational database

raycmorgan.com

Post reply on HN
Print view View original

41–50 of 79 posts

Re: Startups should use a relational database

#41

Post by raverbashing »

lmm wrote: post #40

The unhappy truth is that for many startups, relational integrity and transaction safety are simply not very valuable. Customers of an early-stage startup are by definition willing to take a risk on whatever they're getting from that startup. So simply not thinking about these problems - accepting that occasionally a partial write will happen, or two writes will collide, or a migration will not quite work correctly a…

Exactly

Relational DBs may even be the wrong choice for some specific problems.

And about this quote from the article: "At some point, you will need to ask your primary database questions. If you chose the wrong database, this is where things get tricky. "

Yes, this is correct. However, I know how to read the manual of whatever db I'm using and maybe code something simple to process the output to the format of my liking.

Re: Startups should use a relational database

#42

Post by daliusd »

HorizonXP wrote: post #19

Serious question: what are NoSQL databases really good for? I'm only really used to relational DBs, and I'm unclear about which problems a NoSQL database is useful for.

Map-reduce style scalability. SQL databases are not good for that but can be used for that as well. However then your DB will be not normalized most probably.

But again different NoSQL DBs have different purpose.

Re: Startups should use a relational database

#43

Post by coolsunglasses »

pkolaczk wrote: post #33
coolsunglasses wrote: post #10

Earlier quoted context omitted.

Rarely matters for a startup.

For the startup I once worked for, it mattered much more than we had thought at the beginning. The investors were smart enough to notice we had some considerable periods of downtime. Additionally, once we got first million of users (not really that much and nowhere near the scale of Google or FB) we ran into performance problems which couldn't be easily solved just by indexing, optimizing queries or adding more hardw…

First million users. Come on. 99% of your audience is never going to have that problem.

Especially if they spend their early days fucking with a Cassandra cluster instead of talking to customers.

And it should be noted, you made it anyway.

When you make it by the skin of your teeth, that means you probably timed it right.

Preempting a problem far-ahead of time in startups means time and effort was wasted, especially if it was done before the existence of the problem was established.

It is unreal to me that people still can't figure out how to apply Maslow's hierarchy to startups.

Re: Startups should use a relational database

#44

Post by mwhite »

est wrote: post #39
mwhite wrote: post #27

Earlier quoted context omitted.

Obligatory JSON and hstore in Postgres comment.

stable version, every value is string. No atomic incremental operations, no nesting, shitty index.

JSON has non-string values and nesting. [1]

I read somewhere that nesting in hstore is coming in the next version (Q3 2014?) and non-string types are on deck.

Compared to the nightmarish development workflows and processes I've had to deal with resulting from using CouchDB as a main datastore, having to get the entire JSON value in order to update one key seems like not that big of a deal. What NoSQL databases even let you do incremental operations in that sense?

Shitty index? It seems like you should be able to make an index on a value inside the JSON just as easily as any other index.

Then maybe some advanced features of Postgres can really shine: http://www.postgresql.org/docs/8.3/static/indexes-bitmap-sca... https://wiki.postgresql.org/wiki/Index-only_scans

I'm also exploring a solution for abstracting that as a normal, non-JSON table for semi-structured data using views.

Basically, it seems like for semi-structured data where you know what the schema is, but maybe it just changes over time or isn't 100% certain, so it's not possible to store it using a typical schema, JSON + indexes + views offers the best of both worlds.

[1] http://clarkdave.net/2013/06/what-can-you-do-with-postgresql...

Re: Startups should use a relational database

#45

Post by stiff »

lmm wrote: post #40

The unhappy truth is that for many startups, relational integrity and transaction safety are simply not very valuable. Customers of an early-stage startup are by definition willing to take a risk on whatever they're getting from that startup. So simply not thinking about these problems - accepting that occasionally a partial write will happen, or two writes will collide, or a migration will not quite work correctly a…

This is just a very bad excuse for doing ridiculously shitty systems that stay shitty way after the startup phase. If you at all bother to understand your problem domain, and are not just a monkey at the typewriter, writing down a good domain model and adding the constraints is not going to decrease development speed, quite to the contrary, it's going to increase it, web developers often spend whole workdays just tracking down in the logs the "story" of some now angry customer that happened to violate some unformalized assumption of the system and got mishandled later in the process, especially if this customer happened to pay already. Not to mention that with a good domain model, the code for the individual functionality flows out naturally, while with a shitty one, you might end up with three times as much code for the same thing.

Also, those mistakes in modelling the domain and in enforcing the constraints are often there to stay and slowly become impossible to fix, once you have 10000 records that do not fall into a few well specified states, it's hard to go through all of them, find some common denominators, and migrate the database. Not to mention that with the mess people can do in the code, and with the messy stack in use today, it's easy to introduce bugs that might be hard for anyone to notice but seriously harm your business.

The amount of fashionable nonsense in software engineering seems to be higher than ever, unfortunately.

Re: Startups should use a relational database

#46

Post by pkolaczk »

coolsunglasses wrote: post #43
pkolaczk wrote: post #33

Earlier quoted context omitted.

For the startup I once worked for, it mattered much more than we had thought at the beginning. The investors were smart enough to notice we had some considerable periods of downtime. Additionally, once we got first million of users (not really that much and nowhere near the scale of Google or FB) we ran into performance problems which couldn't be easily solved just by indexing, optimizing queries or adding more hardw…

First million users. Come on. 99% of your audience is never going to have that problem. Especially if they spend their early days fucking with a Cassandra cluster instead of talking to customers. And it should be noted, you made it anyway . When you make it by the skin of your teeth, that means you probably timed it right. Preempting a problem far-ahead of time in startups means time and effort was wasted, especially…

A million registered users is nothing for an MMORPG. You can get it pretty quickly even in a national-level game, without going global. A completely different story is keeping those users active and earning on them. The problem here is - you need to sustain a pretty massive load, yet only a few % of that load brings you revenue. And things like being out of service for even 10 minutes during peak hours (and peak load can be 100x higher than average load if you do special events in the game) can put you out of business or at least seriously worry potential investors.

The sad thing is they actually didn't make it. I don't think the revenue ever crossed the cost of f*ing with all the scalability and availability problems. AFAIK currently they use Membase.

Re: Startups should use a relational database

#47

Post by raverbashing »

stiff wrote: post #45
lmm wrote: post #40

The unhappy truth is that for many startups, relational integrity and transaction safety are simply not very valuable. Customers of an early-stage startup are by definition willing to take a risk on whatever they're getting from that startup. So simply not thinking about these problems - accepting that occasionally a partial write will happen, or two writes will collide, or a migration will not quite work correctly a…

This is just a very bad excuse for doing ridiculously shitty systems that stay shitty way after the startup phase. If you at all bother to understand your problem domain, and are not just a monkey at the typewriter, writing down a good domain model and adding the constraints is not going to decrease development speed, quite to the contrary, it's going to increase it, web developers often spend whole workdays just tra…

> If you at all bother to understand your problem domain

This is a startup. There is no problem domain. There is no spec. There's none for a startup. You may not even have code.

If you're doing a "startup" but have this ironed out, great, everything you said then applies, but it's not a startup, since you found your business model, it's a small company.

And I would love to enforce constraints on the DB but unfortunately, I already had "primary keys" that repeat, unbeknownst to the project customers.

Re: Startups should use a relational database

#48

Post by gaius »

pkolaczk wrote: post #36
gaius wrote: post #18

Earlier quoted context omitted.

None of what you wrote is true.

And you provided no arguments at all. Sure, there are things like multi-master replication in RDBMS world, but I yet have to see a scalable system that utilizes it and at the same time is fully ACID compliant (which rules out async replication). We tried multimaster HA replication once, but the write throughput was terrible.

There is no possible argument to make. There are a million - probably more - highly available RDBMS systems all over the world handling real money and real goods and services, 24/7. You can argue if you wish that tables are not a good way to store particular data structures, fine. But the claim that RDBMSs are unreliable is just ludicrous and had been for 30 years.

Re: Startups should use a relational database

#50

Post by AznHisoka »

HorizonXP wrote: post #19

Serious question: what are NoSQL databases really good for? I'm only really used to relational DBs, and I'm unclear about which problems a NoSQL database is useful for.

I have been using redis as a write though cache(not just a read cache). So I used to have 1000 concurrent writes to my Postgres db. Obviously this had a negative impact on performance even with modern specs(64gb ram, 8 cores). I realized that a lot of those writes we're updating the same column for the same row but in different threads. So I basically use redis to buffer these queries and perform 1 single write instead of multiple writes for the same row.
Post reply on HN