4 ms·

In-memory databases threaten Oracle's dominance

37 points by razorburn 18y ago

newt0311 18y ago
Yeah... Until people more to Oracle shared nothing RAC and then... problem solved. Databases can scale. Just that the ones which do currently cost on the order of several million USD/yr. When that changes, the stigma associated with them will go. PS. Well designed concurrency (ie. PostgreSQL MVCC and not MySQL MyISAM) does not create false data dependencies unless those are in the table constraints.
- wmf 18y ago
  Maybe you haven't heard: In Web 2.0, only free databases exist. Clustered relational databases can't exist, because if they could, the open source community would have already written one. Can I interest you in yet another sharding tutorial?
  - deleted 18y ago
    [deleted]
- deleted 18y ago
  [deleted]
- briansmith 18y ago
  RAC is not shared-nothing. It is exactly the opposite.
  - newt0311 18y ago
    RAC shares the disks (connected through some other technique) but the remaining system is completely shared nothing and to my knowledge, the disks can be spread out over as many servers as needed.
- JulianMorrison 18y ago
  Just looking at the design of RAC, you're still just increasing the n at which it stops scaling. Anything with a bottleneck (in this case, the shared disk image and the concurrent modification algorithms) is going to wedge for some n.
sutro 18y ago
"Thanks in part to Larry Ellison's hard work and rapacious libido, databases are to be found everywhere." This statement raises a few questions about the Oracle sales process.
zhyder 18y ago
How well does MySQL Cluster work; anyone have experience? Are there any other free (as in beer as well as freedom) in-memory databases?
newt0311 18y ago
"Google has THE ENTIRE INTERNET IN MEMORY AT ONCE" Do they? really? or is that a gross oversimplification which clouds the facts to the point of meaninglessness as I suspect it is. I am not qualified to say whether that is actually possible but it seems doubtful.
- jwilliams 18y ago
  My understanding is that the search index (at least) is all in memory - Even if you're talking about just the index hashes, that's a lot of memory. I doubt that the actual content is - given the Google model there would be no point.
  - shimon 18y ago
    I think there is perhaps a point in the text highlighting, where it shows you an excerpt from the page containing your search terms. To do that they need either a very complex index (or to optimize for the most popular queries) or full page text in-memory. Google has a lot of computers.
    - jwilliams 18y ago
      You could do that at the point you render the result... and only after the page scored highly enough. That wouldn't necessarily need to be in memory to perform.
  - quasimojo 18y ago
    all irrelevant. the google web index is not a transactional system. most uses of oracle are.
jwilliams 18y ago
Ok - well this is an interesting article in many respects - but it really brushed over the concepts around transactions. His bank transfer example is a bit oversimplified. A well designed database can have very fine grained locks that avoid that kind of thing. Big Banks will run intraday work on something like IMS Fast Path and reconcile later. So - I don't think his examples are actually all that great - I think the better examples are literally hordes of websites out there using databases. These are a better target. If you running a forum you don't necessarily need the concurrency and casuality of a transactional database. What traditional databases do give you is a metaphor that is established, well known, easy to deploy, etc, etc. You can use SQL Server and be sure it's supported on your host, and that you can find people to program for it. Until the cloud space settles more in this respect (years away) this is still going to be very compelling. Interesting to watch the trend either way.
alecco 18y ago
MonetDB and many others are already available. Their research last year on running on Cell (Playstation 3) was mind-blowing. Haven't seen anything even close to that anywhere.
quasimojo 18y ago
haha what a crock by a sad hack who continues to rely on sensationalism (go read his archives, when has he ever been right?) guess what folks, lots of people care about transactions. the "scaling" crowd balks at any notion of referential integrity v. performance because the fact is, what is in their databases isn't really important. if you run an airline booking system, stock order fulfillment system, credit card transaction system etc etc etc., you have real money riding on the integrity of the database. these people have been using oracle and its rdbms competitors for decades and will be using them decades from now, or something that provides the same integrity level. the notion that these systems will be replaced by shmem or sqlite or some other cub-scout retrieval system is absurd
jhancock 18y ago
Most web apps will never reach the level of scale that cannot be handled by a well coded app with well managed centralized atomic data stores (RDBs being the most prevalent). If you are building something with tons of content (video, images, pages that rarely change) you won't store this in an RBD, but your other data can certainly be managed well with one. I've seen lots of poorly written apps which in turn have severe RDB bottlenecks. But this doesn't mean the RDB itself needs to go away. It you need atomic commits (and most apps do for some aspects of the app), an RDB is a good choice. Besides, Oracle isn't even on the radar of most web apps; which go with MySQL or PostgreSQL. This article is mostly gibberish.

37 points by razorburn 18y ago

Yeah... Until people more to Oracle shared nothing RAC and then... problem solved. Databases can scale. Just that the ones which do currently cost on the order of several million USD/yr. When that changes, the stigma associated with them will go. PS. Well designed concurrency (ie. PostgreSQL MVCC and not MySQL MyISAM) does not create false data dependencies unless those are in the table constraints.

wmf 18y ago
Maybe you haven't heard: In Web 2.0, only free databases exist. Clustered relational databases can't exist, because if they could, the open source community would have already written one. Can I interest you in yet another sharding tutorial?
- deleted 18y ago
  [deleted]
deleted 18y ago
[deleted]
briansmith 18y ago
RAC is not shared-nothing. It is exactly the opposite.
- newt0311 18y ago
  RAC shares the disks (connected through some other technique) but the remaining system is completely shared nothing and to my knowledge, the disks can be spread out over as many servers as needed.
JulianMorrison 18y ago
Just looking at the design of RAC, you're still just increasing the n at which it stops scaling. Anything with a bottleneck (in this case, the shared disk image and the concurrent modification algorithms) is going to wedge for some n.

sutro 18y ago

"Thanks in part to Larry Ellison's hard work and rapacious libido, databases are to be found everywhere." This statement raises a few questions about the Oracle sales process.

zhyder 18y ago

How well does MySQL Cluster work; anyone have experience? Are there any other free (as in beer as well as freedom) in-memory databases?

newt0311 18y ago

"Google has THE ENTIRE INTERNET IN MEMORY AT ONCE" Do they? really? or is that a gross oversimplification which clouds the facts to the point of meaninglessness as I suspect it is. I am not qualified to say whether that is actually possible but it seems doubtful.

jwilliams 18y ago
My understanding is that the search index (at least) is all in memory - Even if you're talking about just the index hashes, that's a lot of memory. I doubt that the actual content is - given the Google model there would be no point.
- shimon 18y ago
  I think there is perhaps a point in the text highlighting, where it shows you an excerpt from the page containing your search terms. To do that they need either a very complex index (or to optimize for the most popular queries) or full page text in-memory. Google has a lot of computers.
  - jwilliams 18y ago
    You could do that at the point you render the result... and only after the page scored highly enough. That wouldn't necessarily need to be in memory to perform.
- quasimojo 18y ago
  all irrelevant. the google web index is not a transactional system. most uses of oracle are.

jwilliams 18y ago

Ok - well this is an interesting article in many respects - but it really brushed over the concepts around transactions. His bank transfer example is a bit oversimplified. A well designed database can have very fine grained locks that avoid that kind of thing. Big Banks will run intraday work on something like IMS Fast Path and reconcile later. So - I don't think his examples are actually all that great - I think the better examples are literally hordes of websites out there using databases. These are a better target. If you running a forum you don't necessarily need the concurrency and casuality of a transactional database. What traditional databases do give you is a metaphor that is established, well known, easy to deploy, etc, etc. You can use SQL Server and be sure it's supported on your host, and that you can find people to program for it. Until the cloud space settles more in this respect (years away) this is still going to be very compelling. Interesting to watch the trend either way.

alecco 18y ago

MonetDB and many others are already available. Their research last year on running on Cell (Playstation 3) was mind-blowing. Haven't seen anything even close to that anywhere.

quasimojo 18y ago

haha what a crock by a sad hack who continues to rely on sensationalism (go read his archives, when has he ever been right?) guess what folks, lots of people care about transactions. the "scaling" crowd balks at any notion of referential integrity v. performance because the fact is, what is in their databases isn't really important. if you run an airline booking system, stock order fulfillment system, credit card transaction system etc etc etc., you have real money riding on the integrity of the database. these people have been using oracle and its rdbms competitors for decades and will be using them decades from now, or something that provides the same integrity level. the notion that these systems will be replaced by shmem or sqlite or some other cub-scout retrieval system is absurd

jhancock 18y ago

Most web apps will never reach the level of scale that cannot be handled by a well coded app with well managed centralized atomic data stores (RDBs being the most prevalent). If you are building something with tons of content (video, images, pages that rarely change) you won't store this in an RBD, but your other data can certainly be managed well with one. I've seen lots of poorly written apps which in turn have severe RDB bottlenecks. But this doesn't mean the RDB itself needs to go away. It you need atomic commits (and most apps do for some aspects of the app), an RDB is a good choice. Besides, Oracle isn't even on the radar of most web apps; which go with MySQL or PostgreSQL. This article is mostly gibberish.