What is the difference to Teradata or Netezza except this is open source and lack the burden of universality yet?
How To Make An Infinitely Scalable RDBMS
81–90 of 92 posts
Re: How To Make An Infinitely Scalable RDBMS
#82There 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…
Teradata is not a column store afaik. Vertica would be a good example of such.
Re: How To Make An Infinitely Scalable RDBMS
#83Earlier quoted context omitted.
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 pe…
>>Show me the numbers
Re: How To Make An Infinitely Scalable RDBMS
#84Earlier quoted context omitted.
Actually, there's precious little that an application can do if a memory chip fails, or if ECC gets too many corrupted bits. If it gets too many corrupted bits, the kernel will generally do something like halt the system. I am not familiar with any application which does a write-read-write (or similar) to memory, but would be curious to learn about them. I'm sure such an algorithm can also be used in InfiniSQL. I am…
> Actually, there's precious little that an application can do if a memory chip fails, or if ECC gets too many corrupted bits. That's where replication and (distributed) consensus comes in, usually at the application level.
Or Resilient Distributed Datasets
https://www.usenix.org/system/files/conference/nsdi12/nsdi12...
Re: How To Make An Infinitely Scalable RDBMS
#85There 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…
> My dream would be to switch Postgres to main memory or column store mode, but I guess that's not happening very soon :)
If it can be done besides the traditional architecture, be it in a fork or without touching existing code; and if you can at least start the work, it could happen soon.
Re: How To Make An Infinitely Scalable RDBMS
#86There 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…
A few years ago I was tinkering with Haskell and looked at a framework call HAppS which kept all its state in memory. Doesn't look like the project has really been active lately.
HAppS is dead, long live Happstack!
What you're talking about was the HAppS-State component of the HAppS application server, a project which is in deed not active anymore. Happstack is the active fork of HAppS and had a "happstack-state" component for a while, but this was eventually rewritten from scratch and made independent of Happstack and is now known as acid-state [1]. It's even used for the new Hackage server that powers the Haskell package ecosystem.
Re: How To Make An Infinitely Scalable RDBMS
#87This is what Clustrix (YC company) claims to do.
Hi, amalag. Yes, Clustrix is very similar to InfiniSQL (not to mention having been around longer). I believe that InfiniSQL has vastly higher performance at least for the type of workloads that InfiniSQl is currently capable of. InfiniSQL is also open source. I hope there's room for competition in this space still.
What do you base your performance claim vs Clustrix on?
Re: How To Make An Infinitely Scalable RDBMS
#88Earlier quoted context omitted.
http://www.infinisql.org/docs/overview/#idp37097184 gave me that impression.
Oh, I thought you said 2PC (two-phased commit). Yes, InfiniSQL uses two phase locking. The Achilles' Heel is deadlock management. By necessity, the deadlock management will need to be single-threaded (at least as far as I can figure). No arguments there, so deadlock-prone usage patterns may definitely be problematic. I don't think there's a perfect concurrency management protocol. MVCC is limited by transactionid gen…
TransactionID generation, as you mentioned it, is probably being limited by the incredible expense of cross-core/socket/etc. sync.
Go single-threaded and divide up a single hardware node (server) into one node per core, and your performance should go way up. You'd want to do something like this anyways, just to avoid NUMA penalties. But treating every core as a separate node is just easy and clean, conceptually. I/O might go into a shared pool - you'd need to experiment.
I've seen this improvement on general purpose software. Running n instances where n=number of cores greatly outperformed running 1 instance across all cores.
Only major design change from one node/proc is that your replicas need to be aware of node placement, so they're on separate hardware. You may even consider taking this to another level, so that I can make sure replicas are on separate racks. Some sort of "availability group" concept might be an easy way to wrap it up.
Also: your docs page clearly says 2PC was chosen (it's in the footnote). Maybe I'm misreading what "basis" means.
Re: How To Make An Infinitely Scalable RDBMS
#89Earlier quoted context omitted.
Hey Mark. The overview seem to be much of the same. There's a lot of excited talk, which is fine, but should be limited to a leading paragraph. The fundamental issue is performance in face of transactions that need to do 2PC among multiple nodes (which also need to sync with the replicas). I'm not much of an expert at all, but I like reading papers on databases. It seems to me that if you really did discover a breakt…
Your advice that I create formal academic-style paper is reasonable, and I agree that it should be something that I pursue. Will you follow me somehow (by links at http://www.infinisql.org ) so that when such is produced, you'll see it? I can't guarantee getting front page here again, and don't want to be missed in the future, especially as you (and others) have been asking for this type of information. And, yes, man…
I signed up for the newsletter.
It doesn't have to be formal and academic enough to be published. Just something that explains how performance is going to be achieved - any sort of analysis.
Re: How To Make An Infinitely Scalable RDBMS
#90Earlier quoted context omitted.
Hi, amalag. Yes, Clustrix is very similar to InfiniSQL (not to mention having been around longer). I believe that InfiniSQL has vastly higher performance at least for the type of workloads that InfiniSQl is currently capable of. InfiniSQL is also open source. I hope there's room for competition in this space still.
What do you base your performance claim vs Clustrix on?
Here is some back of napkin analysis:
Starting with this benchmark report: http://www.percona.com/files/white-papers/clustrix-tpcc-mysq...
Basically, InfiniSQL does not currently support complex indices, so it can't do a TPC-like transaction.
The maximum throughput on 9 nodes is 128,114 per node per second. I don't know if that's 4 or 8 core nodes. If roughly 10% of transactions are multi-node transactions, then 12,811/node/s for multi-node, and 115,303/node/s for single-node transactions.
I don't know if full redundancy for Clustrix was configured, or a hot spare, so I don't know how many actual usable nodes were configured, but likely fewer than 9. But I don't know the precise number.
Roughly 10% of those transactions are contain records on multiple nodes. Based on 9 nodes, that means about 12811/node/s for distributed transactions combined with 115303/node/s for single node transactions.
InfiniSQL maxsed at over 530,000 multi-node transactions on 12 x 4-core nodes. http://www.infinisql.org/blog/2013/1112/benchmarking-infinis...
That's 44,167 per node.
---------
These were not apples-apples benchmarks, but Clustrix performed about 12,000 multi-node transactions per node per second, along with a whole bunch more single-node transactions.
I don't know how it would perform on the benchmark I used. And I intend to do a tpcc benchmark once InfiniSQL is capable of complex keys (among whatever else it it currently is missing).