4 ms·

I work on an oracle-based system with roughly a thousand tables and 200.000 lines of PL/SQL code. What keeps us on oracle is: 1. We know it well. It is easy to

by Joeri 13y ago

I work on an oracle-based system with roughly a thousand tables and 200.000 lines of PL/SQL code. What keeps us on oracle is: 1. We know it well. It is easy to develop for because it's just SQL on a single server. 2. In traditional ACID transactional processing, our core business, it performs quite well. Even mediocre queries often perform well. We've never had a customer or use case outgrow a single oracle db yet. Part of the reason oracle is so expensive is that you need very few servers if you properly design your db architecture. 3. Our customers already know how to deploy it, which makes rolling out our product much easier. It is proven and well-understood technology. Often they already have an oracle server for us to share. 4. Our product is designed around oracle and ACID. Migrating to an alternative would be painful (if moving to an ACID alternative like postgres) or horribly painful (if moving to a BASE database). I think people often make the mistake of looking at the single license cost of sql server or oracle and assuming they're more expensive than the <insert favorite alternative> nosql db of the hour when you add up all the costs. I used to mock microsoft for bringing up TCO, but i have to admit it's a fair point. Stackoverflow runs off of a mirrored pair of sql server instances. You have to wonder how much servers they would need and how much extra development it would have cost to handle the same load on an eventually consistent alternative. My personal opinion is that you have to choose up-front whether to scale up or scale out. Scaling up means paying for oracle or sql server and having a simpler development model because you have a single db instance. Scaling out means going for nosql and taking some of the reliability and synchronization work into your codebase. I don't think companies like oracle are selling the development advantages of scaling up very well, probably because they're not developer-oriented. The strategic mistake oracle continues to make is to alienate devs. They could build a strong case for oracle over nosql, if they cared about developer relations.

gbog 13y ago
Interesting. Where do you put postgres in this landscape?
- Joeri 13y ago
  My opinion is that if you're going the rdbms route, you should keep everything on a single instance (mirrored to a hot backup ofcourse). As soon as you start managing a menagerie of servers with intricate programming logic to shuffle data back and forth, the nosql solutions will be a better fit. So, for any rdbms i would advise using it where it can handle the load on one instance, or possibly a few with a very simplistic sharding model (e.g. we never shard the schema, but we do host different customers on different oracle instances, without any data shared across customers). I haven't worked enough with postgres to know what loads it can handle, but i'm sure there are plenty of cases where a single instance is just fine.
  - voltagex_ 13y ago
    How do you work out what load Postgres can handle on what hardware? (Same question for anyone here who knows MSSQL)
dmpk2k 13y ago
Scaling up means paying for oracle or sql server and having a simpler development model because you have a single db instance. Scaling out means going for nosql and taking some of the reliability and synchronization work into your codebase. Ignoring some of the specific details and focusing on the underlying point here: Having had to work with both ACID and BASE systems extensively, the above point strikes a chord with me. Those of you who haven't dealt with both in anger, take heed of it. BASE is a lot of code and reasoning to work with properly, and you're sacrificing the many knobs, tools, and easy ad-hoc queries (read: simpler debugging) that the common ACID systems have to get it. Common ACID systems are well understood, so there are many fewer surprises in wait. Furthermore, those systems are mature and have walked the inescapable trail of tears to get there; data is the lifeblood of most businesses, so it's not a place to take risks. I'd rather work with ACID. BASE is for when you really need it (and when you really need it, you'll know).
- jacques_chester 13y ago
  Distributed systems are hard, including for database vendors. So when the database "doesn't scale", the database gets blamed. It's a bit like blaming Boeing for gravity, then swearing only to use fleets of microlights to relocate your shipping containers.
tootie 13y ago
I've been slowly coming to thus realization every time I read about another gotcha with MongoDB or any of other upstarts who are running into problems Oracle solved 15 years ago. I'm surprised Oracle isn't leveraging BerkeleyDB more to combat the NoSQL upstarts. It's languished since the acquisition even though it had a big headstart.
- Joeri 13y ago
  They've wrapped berkeleydb as 'oracle nosql', but haven't gotten any traction, probably because they don't know how to approach that market. http://www.oracle.com/technetwork/products/nosqldb/overview/index.html http://www.oracle.com/technetwork/products/nosqldb/overview/...
rbanffy 13y ago
> Stackoverflow runs off of a mirrored pair of sql server instances. You have to wonder how much servers they would need and how much extra development it would have cost to handle the same load on an eventually consistent alternative Considering they really don't need ACID and the amount of complexity their cache layers add, it would probably be much simpler to develop, maintain and operate. Seriously, their model is the textbook example for non-relational datastores.

by Joeri 13y ago

gbog 13y ago

Interesting. Where do you put postgres in this landscape?

Joeri 13y ago
My opinion is that if you're going the rdbms route, you should keep everything on a single instance (mirrored to a hot backup ofcourse). As soon as you start managing a menagerie of servers with intricate programming logic to shuffle data back and forth, the nosql solutions will be a better fit. So, for any rdbms i would advise using it where it can handle the load on one instance, or possibly a few with a very simplistic sharding model (e.g. we never shard the schema, but we do host different customers on different oracle instances, without any data shared across customers). I haven't worked enough with postgres to know what loads it can handle, but i'm sure there are plenty of cases where a single instance is just fine.
- voltagex_ 13y ago
  How do you work out what load Postgres can handle on what hardware? (Same question for anyone here who knows MSSQL)

dmpk2k 13y ago

Scaling up means paying for oracle or sql server and having a simpler development model because you have a single db instance. Scaling out means going for nosql and taking some of the reliability and synchronization work into your codebase. Ignoring some of the specific details and focusing on the underlying point here: Having had to work with both ACID and BASE systems extensively, the above point strikes a chord with me. Those of you who haven't dealt with both in anger, take heed of it. BASE is a lot of code and reasoning to work with properly, and you're sacrificing the many knobs, tools, and easy ad-hoc queries (read: simpler debugging) that the common ACID systems have to get it. Common ACID systems are well understood, so there are many fewer surprises in wait. Furthermore, those systems are mature and have walked the inescapable trail of tears to get there; data is the lifeblood of most businesses, so it's not a place to take risks. I'd rather work with ACID. BASE is for when you really need it (and when you really need it, you'll know).

jacques_chester 13y ago
Distributed systems are hard, including for database vendors. So when the database "doesn't scale", the database gets blamed. It's a bit like blaming Boeing for gravity, then swearing only to use fleets of microlights to relocate your shipping containers.

tootie 13y ago

I've been slowly coming to thus realization every time I read about another gotcha with MongoDB or any of other upstarts who are running into problems Oracle solved 15 years ago. I'm surprised Oracle isn't leveraging BerkeleyDB more to combat the NoSQL upstarts. It's languished since the acquisition even though it had a big headstart.

Joeri 13y ago
They've wrapped berkeleydb as 'oracle nosql', but haven't gotten any traction, probably because they don't know how to approach that market. http://www.oracle.com/technetwork/products/nosqldb/overview/index.html http://www.oracle.com/technetwork/products/nosqldb/overview/...

rbanffy 13y ago

> Stackoverflow runs off of a mirrored pair of sql server instances. You have to wonder how much servers they would need and how much extra development it would have cost to handle the same load on an eventually consistent alternative Considering they really don't need ACID and the amount of complexity their cache layers add, it would probably be much simpler to develop, maintain and operate. Seriously, their model is the textbook example for non-relational datastores.