31–40 of 61 posts
I'm supposed to use the perl api for user and schema management? Perl holds a special place in my heart, but I'm not too excited about managing my database with it. How about an interactive console? I'm currently using MySQL, how similar is the SQL syntax?
On backlog to fix. But InfiniSQL is for hackers and early adopters at this stage. The SQL support is documented ( http://www.infinisql.org/docs/index/ )
Earlier quoted context omitted.
From their documentation: > InfiniSQL currently is an in memory database. This means that all records are stored in system memory, and not written to disk. This provides very high performance--but it also means that InfiniSQL currently lacks the property of Durability. If the power goes out, all data is gone. This limitation is temporary. They do mention that they'll implement persistence, but that's likely to lower…
1) persistence: battery-backed UPS and synchronous replication. No WAL anywhere. I'm thinking about ways to do disk-based storage without synchronous IO, to provide decent performance with higher storage capacity 2) no joins supported yet. However, the benchmark that I performed (on the blog) involves 3 updates across random nodes. I designed InfiniSQL specifically to perform multi-node transactions very well, becaus…
Should be quite easy to do equijoins especially if you're joining a couple thousand rows at most at a time; it only gets hairier when you're joining all records of very large tables that don't necessarily fit in memory, which is not very OLTP-y.
With regards to persistence, I'm really curious to hear how you're planning to have durability without writing something to disk on every transaction. It could work if you're relaxing the definition of durable to mean written to memory on at least $n$ nodes, though that's likely to be surprising to someone with a stricter definition of durable.
Edit: By the way, it's really cool that you have a C++ implementation of actors, I'll have to look into it. Have you thought about turning that into a library?
It uses 2pc so it won't really scale.
I think you mean 2PL. It does really scale, check out the benchmark report on the blog. http://www.infinisql.org/blog/2013/1112/benchmarking-infinis... For deadlock-prone workloads, it will likely not be as good, admittedly. I'm considering a variation on MVCC that gets around the single transactionid bottleneck, but the currently implementation is based on 2PL. http://www.infinisql.org/docs/overview/#ftn.idp37098256…
Earlier quoted context omitted.
1) persistence: battery-backed UPS and synchronous replication. No WAL anywhere. I'm thinking about ways to do disk-based storage without synchronous IO, to provide decent performance with higher storage capacity 2) no joins supported yet. However, the benchmark that I performed (on the blog) involves 3 updates across random nodes. I designed InfiniSQL specifically to perform multi-node transactions very well, becaus…
Gotcha, it's for OLTP, don't know how I missed that. Should be quite easy to do equijoins especially if you're joining a couple thousand rows at most at a time; it only gets hairier when you're joining all records of very large tables that don't necessarily fit in memory, which is not very OLTP-y. With regards to persistence, I'm really curious to hear how you're planning to have durability without writing something…
I've thought about having an actor library, or minimally, to have the actor basis of InfiniSQL independent of specific workload, but haven't thought it through entirely. I'd be supportive of any efforts to that effect if you want to work on it!
Earlier quoted context omitted.
I think you mean 2PL. It does really scale, check out the benchmark report on the blog. http://www.infinisql.org/blog/2013/1112/benchmarking-infinis... For deadlock-prone workloads, it will likely not be as good, admittedly. I'm considering a variation on MVCC that gets around the single transactionid bottleneck, but the currently implementation is based on 2PL. http://www.infinisql.org/docs/overview/#ftn.idp37098256…
Have you given any more thought to ... not multithreading it? Since you're scaling across servers, apply the same concept across cores. Presto, no more bottleneck on atomically incrementing an ID.
Instead, a friend and I have been thinking about how to perhaps modify MVCC to work with distinct transactionid's per partition. Namely, I'm already generating what I call "subtransactionid"'s for each partition involved in a transaction. And those must be ordered for synchronous replication, so I think the way to implement a variation on MVCC may already be mostly there.
I know I still owe you an architectural doc...fixin' ta, ya know.
Earlier quoted context omitted.
Please consider the Apache License or some other license instead of the GPL. There are many organizations that cannot use any flavor of GPL, including LGPL, for legal reasons. You can debate the wisdom of that amongst yourselves, but alas, that's how it is in some places. (And I really want to try this...)
I assume these shops have Linux in their environments, including the GNU toolchain. There must be some contradiction somewhere that I'm not aware of. Based on FSF feedback, I'm going to modify the license to include a Classpath-like exception. The intention is to allow people to write stored procedures that link against infinisql without triggering the copyleft. Only if the source to infinisql itself is modified (and…
A few things (I'm the author of InfiniSQL) 1) I include keystore-like stored procedures in the source. They do get/set with integer key and string val. I haven't done thorough benchmarking, but I expect them to outperform the other benchmark I've published, which is quite a bit more complex workload 2) (camus2) agreed, nothing ever dies in IT. But roll back the clock a few years. How much noSQL would come into exisen…
Please consider the Apache License or some other license instead of the GPL. There are many organizations that cannot use any flavor of GPL, including LGPL, for legal reasons. You can debate the wisdom of that amongst yourselves, but alas, that's how it is in some places. (And I really want to try this...)
To be clear, there are no legal reasons I can think of that would ever prevent internal use of LGPL/GPL software.
You mean these companies (Apple, for example) have policies.
Policies like this often change because someone decides the cost vs risk tradeoff is worth it.
Changing a license because of bad policies of certain companies is not a great reason to change a license (in fact, it's, IMHO, an actively bad one).
You really should only change licenses if you find the license you chose does not suit the needs of your users (and policies are not really needs).
Earlier quoted context omitted.
I assume these shops have Linux in their environments, including the GNU toolchain. There must be some contradiction somewhere that I'm not aware of. Based on FSF feedback, I'm going to modify the license to include a Classpath-like exception. The intention is to allow people to write stored procedures that link against infinisql without triggering the copyleft. Only if the source to infinisql itself is modified (and…
Generally, Linux and the GNU toolchain are carefully managed exceptions and there is massive commercial pressure against continuing to use anything GPL-licensed. Linux itself is strong enough to hold out against this pressure, but other things like GCC are not, which is why there is so much work being invested into LLVM/Clang.
I actually generally see just the opposite - even automakers, who are traditionally stalwarts about anything, are now starting to use GPL software in cars.
"which is why there is so much work being invested into LLVM/Clang"
This is a weird opinion, that i've seen a few times.
This is not why LLVM was/is chosen, AFAIK. LLVM was/is chosen for greater control over destiny, a better platform, and a better community.
If LLVM was GPL there is exactly one company that would theoretically stop contributing (admittedly, it's been about 2 months since i calculated the list of companies that contributed in the past year). I doubt that would actually happen, too (mainly because I asked once if they would)
I was just at an LLVM social this evening, and not a single person there worked for a company that chose LLVM because of "massive commercial pressure against the GPL".
Earlier quoted context omitted.
I assume these shops have Linux in their environments, including the GNU toolchain. There must be some contradiction somewhere that I'm not aware of. Based on FSF feedback, I'm going to modify the license to include a Classpath-like exception. The intention is to allow people to write stored procedures that link against infinisql without triggering the copyleft. Only if the source to infinisql itself is modified (and…
Generally, Linux and the GNU toolchain are carefully managed exceptions and there is massive commercial pressure against continuing to use anything GPL-licensed. Linux itself is strong enough to hold out against this pressure, but other things like GCC are not, which is why there is so much work being invested into LLVM/Clang.
But I'm conflicted about GPL vs Apache (or BSDish) in the sense that I'm getting the message that I have to bend over backwards just a little bit further before somebody, somewhere might be willing to use my software, maybe. Free isn't enough. I also have to let them fork it, keep it proprietary, wrap their own brand around it, before maybe they might consider using it.
That said, I really want people to use it, and of course help me hack on it. But I'm conflicted.
Earlier quoted context omitted.
Generally, Linux and the GNU toolchain are carefully managed exceptions and there is massive commercial pressure against continuing to use anything GPL-licensed. Linux itself is strong enough to hold out against this pressure, but other things like GCC are not, which is why there is so much work being invested into LLVM/Clang.
"massive commercial pressure against continuing to use anything GPL-licensed" I actually generally see just the opposite - even automakers, who are traditionally stalwarts about anything, are now starting to use GPL software in cars. "which is why there is so much work being invested into LLVM/Clang" This is a weird opinion, that i've seen a few times. This is not why LLVM was/is chosen, AFAIK. LLVM was/is chosen for…