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

31–40 of 79 posts

Re: Startups should use a relational database

#31

Post by microtonal »

taspeotis wrote: post #24
microtonal wrote: post #23

Earlier quoted context omitted.

For example, XML databases are handy when you have large XML datasets that you like to query. The database indexes the XML, allowing you to execute most XPath queries and XQuery programs quickly.

I had a quick Google and MSSQL [1], DB2 [2] and Oracle [3] all support indexing XML. [1] http://technet.microsoft.com/en-us/library/ms191497.aspx [2] http://publib.boulder.ibm.com/infocenter/db2luw/v9r5/index.j... [3] http://docs.oracle.com/cd/B28359_01/appdev.111/b28369/xdb_in...

It's not about indexing paths you indicate, XML databases are about indexing the whole structure (remember, XML is not relational, but are graphs). Besides that they provide XPath/XQuery processing and optimization. You can query large XML documents or sets of documents, like you'd query them with e.g. XQilla.

Of course, it is possible to implement all of this on top of existing database technology. E.g. Oracle's Berkeley DB XML is implemented on top of Berkeley DB. But, a relational database with some indexing of XML does not provide the same functionality as an XML database.

Re: Startups should use a relational database

#32

Post by nl »

charliesome wrote: post #5
RyanZAG wrote: post #4

Depends what your startup is doing. If you are only using your database to store some basic transactions, then a relational database is a very good fit. This is really the case for most startups tackling common problems. However, if your startup is tackling a problem with unique technical challenges, then you can't just ignore the issue. For example, a geo-location startup tracking the location in real time of users…

> For example, a geo-location startup tracking the location in real time of users with a free app is simply not going to be able to use a relational database. Why not?

Rapidly growing, infrequently queried data is not the ideal scenario for most relational databases.

1) Relational databases typically aren't optimised for write-throughput. It's quite possible to do it, but you'll need fast and large disks (eg, FusionIO in a SAN or something).

2) Location-tracking applications typically don't require interactive queries - generally it is more a batch-based system that can be run offline.

Saying you are not going to be able to use a relational database is overstating it a bit in my view.

Clearly you can make it work, but something like Cassandra will give you better write thoughput, won't force you to rely on a SAN/NAS for data storage and will let you use Map/Reduce to batch process the data.

Re: Startups should use a relational database

#33

Post by pkolaczk »

coolsunglasses wrote: post #10
pkolaczk wrote: post #8

He forgot one of the very important reasons to use (some) NoSQL databases: high availability. Relational database systems are very poor at providing that. Most often the availability options are limited to resistance to node failures. RDBMSes have several SPOFs and must use failover which is not dependable, hard to test, and in many times needs manual intervention. Forget resistance to network partitions.

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 hardware, and "buying" a beefy Oracle superserver was not an option as we didn't have enough revenue yet. So we had to dump joins, relax transactions, denormalize a lot and ended with a half-baked, bug-ridden NoSQL store on top of PostgreSQL, that couldn't even do horizontal partitioning well. I wished we had a proper solution like Cassandra right from the start. It would save us lots of pain.

Re: Startups should use a relational database

#34

Post by karterk »

nostromo wrote: post #12
robconery wrote: post #9

One thing that could likely get you fired rather quickly is running analytics on your live transactional system. Yes, your business needs to make decisions based on data, this is not terribly new. To think that you only have one data store is a bit short-sighted. Many businesses (including startups) have moved to using document stores for high read environments and scraping nightly drops to their backend analytics sy…

The disconnect between your comment and the article is the term "startup" now means giant companies like Airbnb and tiny two person companies that haven't yet created an MVP. I think this article is targeted at the latter: pre-MVP and just post-MVP. For those startups, having two databases with one dedicated to a backend analytics system reeks of premature optimization.

Having taken this path from a 2-person running a "nobody cares about this" app to an app with some decent traction, there are always other things more worthwhile to do in the early stages than trying to get insights from the invariably small amounts of data in the DB. A 2-person company should be talking to users rather than trying to analyze patterns from database tables. Sample size is just too small, and you will be evolving so fast that the trends will almost be meaningless.

If you grow to be more than 2-people, then taking a mirror dump of the prod db to run queries against is pretty trivial effort.

Re: Startups should use a relational database

#35

Post by pkolaczk »

jahewson wrote: post #14
pkolaczk wrote: post #8

He forgot one of the very important reasons to use (some) NoSQL databases: high availability. Relational database systems are very poor at providing that. Most often the availability options are limited to resistance to node failures. RDBMSes have several SPOFs and must use failover which is not dependable, hard to test, and in many times needs manual intervention. Forget resistance to network partitions.

CAP theorem tells us that you can't have availability without sacrificing consistency or partition tolerance, which means that there isn't a NoSQL database which can do that either. It is not true that relational databases must have a single point of failure (SPoF) or must use failover: MySQL Cluster is a sharded multi-master distributed database without a SPoF. On the other hand Redis, for example, is a master-slave…

CAP theorem says it cannot be done at the same time. But it is perfectly fine to sacrifice consistency for availability at the time partition happens and restore consistency once the partition is fixed. Still better than nothing if revenue counts. Financial institutions do like that all the time.

Re: Startups should use a relational database

#36

Post by pkolaczk »

gaius wrote: post #18
pkolaczk wrote: post #8

He forgot one of the very important reasons to use (some) NoSQL databases: high availability. Relational database systems are very poor at providing that. Most often the availability options are limited to resistance to node failures. RDBMSes have several SPOFs and must use failover which is not dependable, hard to test, and in many times needs manual intervention. Forget resistance to network partitions.

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.

Re: Startups should use a relational database

#37

Post by lampe3 »

I often read that argument that NoSQL Databases are Schemaless and yes the Database is but your Data is or it isn't. YOU must know your Data.

"All the while moving work onto the developers to standardize how they handle different migration cases."

I know a startup is fast and bla bla... BUT your team should know the tools that you are using... For me SQL DB's force me to add a new field and some kind of value and i don't like to be forced to a solution.

"In document stores, you have two choices: store related data as sub-documents, or store related data as separate documents with references. It is up to the developers to understand the trade-offs of both approaches. Selecting one over the other can lead to performance gains or issues, scalability issues and above all, make asking certain questions of the data a lot harder."

Again know the tools you are using. And for example MongoDB has good ORM's too.

"But that takes much more forethought and is dependent on a particular problem."

If your startup is doing something new and shiny you don't have the knowledge and forethought and you often dont know what particular problem will come at you.

Most of the point's look like: You learned at your University SQL now you know it(but in really life you don't) and now use it because you know how to normalize a Database. This argumentation is often used to say why java is so great or why javascript is bad.

I personally started with php then moved to rails and now to meteor(uses MongoDB) and we never before meteor could make so fast a good prototype which for a startup is very important.

So yeah if you are comfy with SQL use it if your comfy with NoSQL use it.

Re: Startups should use a relational database

#38

Post by SiVal »

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.

Somewhat similar to the difference between C/C++ or enterprise Java and various dynamic or "scripting" languages in terms of structure, the "S" in SQL or NoSQL. The former tends to require more up-front structural design to do anything, which is a nuisance at first when you're not sure what you will end up needing. The latter tends to be quicker to throw together and repeatedly rearrange in the early days of its evolution, which is a huge advantage to a small startup trying to figure out what business it's in, but often runs into trouble later, once the needs have stabilized and the structure becomes more of a benefit than a cost.

For areas other than structure, the difference can be more like the difference between a general purpose programming language and a domain-specific language. SQL databases are general purpose, so they offer a large, nicely integrated package of features, while NoSQL databases often sacrifice some of those features to optimize for some niche. From this perspective, the SQL database can be the best choice for a startup trying to find its niche with the NoSQL chosen as an optimization once that niche has been identified.

The fact that a new business can't be sure what its business will end up being is an argument both for and against using a SQL database.

Re: Startups should use a relational database

#39

Post by est »

mwhite wrote: post #27
est wrote: post #25

Earlier quoted context omitted.

Another reason to choose MongoDB is built-in array and nested dict support, with good enough indexing. So you don't have to create bullshit m2m tables with tedious joins for a fucking tagging system

Obligatory JSON and hstore in Postgres comment.

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

Re: Startups should use a relational database

#40

Post by lmm »

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 and your pages will crash until it's fixed - is a worthwhile sacrifice to increase development speed.
Post reply on HN