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

How To Make An Infinitely Scalable RDBMS

highscalability.com

Post reply on HN
Print view View original

21–30 of 92 posts

Re: How To Make An Infinitely Scalable RDBMS

#21

Post by glogla »

JeffDClark wrote: post #19
glogla wrote: post #15

There was very interesting presentation by one professor. I'm not sure about what university, but he seemed to know his work. He talked about how databse world is about to change. ACID is really expensive in terms of resources, and so are the more difficult things about relational schema (foreign keys, checks, etc). And architecture of classic RDBMSes is pretty wasteful -- they use on-disk format but cache it in memo…

Is this the talk that you are referring to? http://slideshot.epfl.ch/play/suri_stonebraker

Yes, that's the one. Thank you! I'm bookmarking it right now.

Re: How To Make An Infinitely Scalable RDBMS

#22

Post by d4mi3n »

glogla wrote: post #15

There was very interesting presentation by one professor. I'm not sure about what university, but he seemed to know his work. He talked about how databse world is about to change. ACID is really expensive in terms of resources, and so are the more difficult things about relational schema (foreign keys, checks, etc). And architecture of classic RDBMSes is pretty wasteful -- they use on-disk format but cache it in memo…

You mentioned OLTP. Erlang's Mnesia store comes to mind, but as far as I'm aware it's limited to a 4GB data set. I'm not sure if that qualifies as a main-memory db, but it might be similar.

Re: How To Make An Infinitely Scalable RDBMS

#23

Post by brianpgordon »

mtravis wrote: post #8
alanctgardner2 wrote: post #6

I'm a little skeptical: - a bunch of the novel components (the UPS aware persistence layer, for example) aren't actually built yet - they're pushing for people to build businesses on it already. I would characterize it as "bleeding-edge with bits of glass glued on", so this doesn't seem entirely honest. - there's mostly a lot of breathless talk about how great and fast and scalable it is, but no mention of CAP theore…

Hi, Alan. Yes, many things are not built yet. Nowhere am I pushing anybody to build their business on it yet, but I am looking for hackers and early adopters/alpha testers. I've gone through pains on every doc that I've created that this is early, alpha, needs lots of work--including the 2nd paragraph of the linked-to article: "InfiniSQL is still in early stages of development--it already has many capabilities, but m…

When I see a new distributed database, the first thing I want to know is "Is it AP or CP?"

If you haven't answered that question yourself, it's likely you have a partition-intolerant system, and that in real-life scenarios people will lose data.

Re: How To Make An Infinitely Scalable RDBMS

#24

Post by mtravis »

yid wrote: post #13

> UPS systems will stay active for a few minutes, based on their capacity, and the manager process will gracefuly shut down each daemon and write data to disk storage. This will ensure durability--even against power failure or system crash--while still maintaining in memory performance. How does a UPS ensure durability against system or program crashes, disk corruption in large clusters, and other failures that can a…

Hi, yid. UPS protects against multiple simultaneous system crashes. Single system crash gets failed over, no problem. If both UPS systems detect their upstream PDU's as being out, then the InfiniSQL management protocol will initiate graceful shutdown, including persisting to disk. For write() issues, at least intially, I think that stuff in commodity hardware (such as ECC memory) is sufficient protection in most cases. Attaching a high end storage array, or using ZFS, also protects against low level disk problems. I don't see those problems as needing to be solved for a 1.0 relase, but am very much open to contributions that address those issues any time you want!

The fundamental insight about not needing transaction logs is pretty simple actually: if the power is guaranteed to either stay on, or to allow the system to quiesce gracefully, then the cluster will not suddenly crash. That's the motivator for transaction logs--to make sure that the data will still be there if the system suddenly crashes. Get rid of the need for transaction logs, get rid of the transaction logs.

Regarding consensus, I expect that there will be a quorum protocol in use amongst an odd number greater than 2 of manager processes, each with redundant network and power. But the specific protocol I haven't ironed out. If there's something I can grab off the shelf then it may be preferable to implementing from scratch, but I haven't gotten there yet.

This stuff hasn't been implemented yet, but the core around which it can be implemented, has been.

Do I sense a volunteer? ;-)

Re: How To Make An Infinitely Scalable RDBMS

#25

Post by glogla »

brianpgordon wrote: post #23
mtravis wrote: post #8

Earlier quoted context omitted.

Hi, Alan. Yes, many things are not built yet. Nowhere am I pushing anybody to build their business on it yet, but I am looking for hackers and early adopters/alpha testers. I've gone through pains on every doc that I've created that this is early, alpha, needs lots of work--including the 2nd paragraph of the linked-to article: "InfiniSQL is still in early stages of development--it already has many capabilities, but m…

When I see a new distributed database, the first thing I want to know is "Is it AP or CP?" If you haven't answered that question yourself, it's likely you have a partition-intolerant system, and that in real-life scenarios people will lose data.

Do you think you could write more about this?

Re: How To Make An Infinitely Scalable RDBMS

#26

Post by mtravis »

brianpgordon wrote: post #23
mtravis wrote: post #8

Earlier quoted context omitted.

Hi, Alan. Yes, many things are not built yet. Nowhere am I pushing anybody to build their business on it yet, but I am looking for hackers and early adopters/alpha testers. I've gone through pains on every doc that I've created that this is early, alpha, needs lots of work--including the 2nd paragraph of the linked-to article: "InfiniSQL is still in early stages of development--it already has many capabilities, but m…

When I see a new distributed database, the first thing I want to know is "Is it AP or CP?" If you haven't answered that question yourself, it's likely you have a partition-intolerant system, and that in real-life scenarios people will lose data.

CP in a single site. Between sites, I haven't considered it too much.

Re: How To Make An Infinitely Scalable RDBMS

#27

Post by ezequiel-garzon »

JeffDClark wrote: post #19
glogla wrote: post #15

There was very interesting presentation by one professor. I'm not sure about what university, but he seemed to know his work. He talked about how databse world is about to change. ACID is really expensive in terms of resources, and so are the more difficult things about relational schema (foreign keys, checks, etc). And architecture of classic RDBMSes is pretty wasteful -- they use on-disk format but cache it in memo…

Is this the talk that you are referring to? http://slideshot.epfl.ch/play/suri_stonebraker

If I may drool a little, you guys represent the heart of Hacker News. Insightful summary, mentioning that somewhere somebody gave such a talk. As I was reading the first comment I was silently cheering for "a librarian's follow-up", and there it was!

Re: How To Make An Infinitely Scalable RDBMS

#28

Post by mtravis »

alanctgardner2 wrote: post #12
mtravis wrote: post #8

Earlier quoted context omitted.

Hi, Alan. Yes, many things are not built yet. Nowhere am I pushing anybody to build their business on it yet, but I am looking for hackers and early adopters/alpha testers. I've gone through pains on every doc that I've created that this is early, alpha, needs lots of work--including the 2nd paragraph of the linked-to article: "InfiniSQL is still in early stages of development--it already has many capabilities, but m…

CAP theorem can apply to any clustered system, it doesn't have to be multi-site. What happens if 6 of your 12 machines die? What if they get cut off from the other 6? edit: There's a bit of discussion further down about the SQL implementation. That's something I was very curious about as well. The projects linked below spend a lot of time working on supporting full ANSI SQL, and reducing latency by pushing down as ma…

Hi, Alan. Regarding CAP, I think that given redundant cluster interconnects, redundant managed power, odd # of cluster managers for quorum, all mean that split brain is just about out of the question, configured properly.

The main reason that I have a FAQ about Hadoop is that I have been asked repeatedly by people, "what's the difference between InfiniSQL & Hadoop?" It seems to be the data project most on a lot of people's minds. It's a fair question, so I created an FAQ entry on my site.

I don't know what Impala or Shark's performance are for transaction processing. Show me the numbers, in other words. I don't believe that Hadoop is going to eat the world, but that it's best use cases are probably in the reporting realm. It seems that Impala wants to bridge that gap between reporting and operational/transactional database--but I can't read from their architectural description just how well it would actually perform for transaction processing workloads.

Regarding Shark, it looks to me like they still see it as an parallelized reporting system, and not geared towards OLTP/operational workloads.

I expect that InfiniSQL will be able to handle quite sophisticated analytics workloads, as more capabilities are added, but they will be more for real-time. I don't see it displacing special purpose analytics environments, especially the masive unstructured ones.

Regarding filtering, aggregation, windowing, I haven't documented it yet. The SQL engine is pretty simple at this point--it parses, makes an abstract syntax tree, then executes. If you need more, then the code is there. :-)

Re: How To Make An Infinitely Scalable RDBMS

#29

Post by yid »

mtravis wrote: post #24
yid wrote: post #13

> UPS systems will stay active for a few minutes, based on their capacity, and the manager process will gracefuly shut down each daemon and write data to disk storage. This will ensure durability--even against power failure or system crash--while still maintaining in memory performance. How does a UPS ensure durability against system or program crashes, disk corruption in large clusters, and other failures that can a…

Hi, yid. UPS protects against multiple simultaneous system crashes. Single system crash gets failed over, no problem. If both UPS systems detect their upstream PDU's as being out, then the InfiniSQL management protocol will initiate graceful shutdown, including persisting to disk. For write() issues, at least intially, I think that stuff in commodity hardware (such as ECC memory) is sufficient protection in most case…

I feel like you're banking a little too heavily on external measures for error protection/durability like UPSes and ECC memory, rather than embracing the inevitable fact that corruption and failures will occur. In short, I'd really need to see a white paper on why you're not reinventing the wheel before I'd use InifiSQL.

Kudos for engaging the community though; please do keep us posted as you progress.

Re: How To Make An Infinitely Scalable RDBMS

#30

Post by [deleted] »

gopalv wrote: post #7
mtravis wrote: post #5

Earlier quoted context omitted.

Hi, gopalv. What samspenc said. My understanding of the AGPL is that only the modifications made to the source code itself of the covered project would need to be opened up (or have a commercial license). Meaning that merely using InfiniSQL won't require you to open source your app. MongoDB has the same license BTW, and lots of people use it without being forced to open their code. And, yes, I want to get paid someho…

I fully understand what this means and I hope you do get calls about alternate licensing, but remember that people like me do not make these decisions. I thankfully don't have to - this means I don't need to talk to lawyers about this. Because AGPL took away the most important bit of unassailable ground I had to argue with when it came to deploying GPL - "Using this code implies no criteria we have to comply to, only…

[deleted]
Post reply on HN