leif

5 ms·

1.
by leif 11y ago
> In that case all you've got is an in-memory queue that evaporates on a system crash. https://www.cs.berkeley.edu/~brewer/cs262/Aries.pdf > Remember that merge operations are O(N). Then remember that t
2.
by leif 11y ago
The TokuDB implementation of Fractal Trees uses a single-process, multi-threaded model, which is incompatible with PostgreSQL's multi-process model. In theory, one could patch TokuDB to be suitable, but this is a ton of work.
3.
by leif 11y ago
That's not really online, it still rebuilds the entire table, it just does it in the background and shows the results once it's done. This is pretty similar to how TokuDB hot indexing works, but TokuDB's hot column add/
4.
by leif 11y ago
Cracking is kind of similar in that it delays the "sorting work" done in the indexing structure. However, cracking is fairly heuristic and therefore hard to analyze without an intimate understanding of the workload. Fractal Tree
5.
by leif 11y ago
This is the critical insight. TokuDB uses a write-ahead log which is synced according to the configuration, and can be made as immediate as full fsync on commit. This provides the strongest durability available on a single machine. Where
6.
by leif 11y ago
TokuDB is built for a single-process model with threads for connections. This is incompatible with PostgreSQL's multi-process model, and patching TokuDB to support such a model would be a large effort. Not impossible, but a lot of wo
7.
by leif 11y ago
A bottle is usually about 4 glasses (which is consistent with my experience, not sure how you made your calculation), so when shared, that's one to drink with the meal and one to share over conversation after. I'm far from a teet
8.
by leif 12y ago
you seem fun at parties
9.
by leif 12y ago
>You even seem certain that a stranger on the Internet is part of the problem The stranger on the internet said they felt like part of the problem, so I don't really know what to tell you. If you read between the lines a bit, I neve
10.
by leif 12y ago
You could try talking to them about this. Try "hey, I understand being in this industry can be difficult as a woman, I am not very familiar with the problem but I don't want to be part of it, and I'm concerned about how much
11.
by leif 12y ago
You've successfully completed steps 1 and 2: 1. Acknowledge there is a real problem. 2. Acknowledge you are part of the problem. Now, on to steps 3-n! 3. Don't be discouraged, accept that there are things you can do to help! This
12.
by leif 12y ago
I agree, the mask/not/and is standard within systems contexts. It need not be cognitive overhead, not to be elitist but if you don't have a copy of hacker's delight or the ability to understand constructs like this, you
13.
by leif 12y ago
Tokutek, Boston, MA and New York, NY http://www.tokutek.com/careers We build and sell high-performance databases TokuDB and TokuMX. We are hiring: - Inside Sales Exec - QA Engineer - Tech Support Engineer - Product Manager
14.
by leif 12y ago
It won't be patented. We hope others find it helpful and consider implementing it in similar systems.
15.
by leif 12y ago
We are working on several ways to prove to ourselves and the community that what we have is correct. The most important is obviously testing. We have tests that demonstrate the problems we found, and Ark passes those tests. Publishing th
16.
by leif 12y ago
No, none of us know how to use those. :( If you're interested in building one and you have experience with them, get in touch and we can work through it together. I think the biggest challenge would be modeling the semantics of write
17.
by leif 12y ago
Multi-document and multi-collection transactions are already a part of TokuMX[1]. Since commit of the oplog insert is atomic together with the actual operation's changes to documents, atomicity is also guaranteed in replication. Atom
18.
by leif 12y ago
My other reply didn't address some of your specific questions about 2.8: > We're seeing document-level locking We've had it from the beginning. Their implementation so far doesn't handle index updates or replication.
19.
by leif 12y ago
I can't add much to what Chris and Zardosht already said, but let me reiterate a few things regarding our fork: 1. You're a bit out of date. We merged changes to catch up to 2.4 in about a month (once we decided 2.4.x was stable)
20.
by leif 12y ago
Yes, there are still problems with the election protocol, e.g. [1]. The right kind of network partitions can cause multiple primaries to stay up indefinitely, accepting writes on both sides of the partition, which will eventually be rolled
21.
by leif 12y ago
whining about gifs seems like overkill
22.
by leif 12y ago
OK but the point in the article is to reduce reliance on shared state. This doesn't work in a database.
23.
by leif 12y ago
FTA: "Assuming servers are kept synchronized enough (the enough depending on your application), you may just solve the problem by acquiring time precisely enough." How on earth are "sub-microsecond timers" supposed to be
24.
by leif 12y ago
http://lynx.isc.org/
25.
by leif 12y ago
(c) a load balancer can often understand a server that's down, a server that might end up doing I/O while holding locks probably wouldn't be detected.
26.
by leif 12y ago
You're wrong. http://dev.mysql.com/doc/refman/5.6/en/innodb-create-index-o... InnoDB tables have online, non-copying (for most operations) DDL in 5.6. Also, TokuDB has had online, non-copying DDL (c
27.
by leif 12y ago
Last time you checked was a while ago, it's 2.4 compatible now (except geo and full-text) and has been since TokuMX 1.3. We generally don't criticize indiscriminately. MongoDB has a lot of good sides and we embrace and extend tho
28.
by leif 12y ago
I believe they are on a ~yearly schedule now.
29.
by leif 12y ago
It means the foundation has been laid. 2.6 included a lot of refactoring and rewriting of some core subsystems, with the apparent goal of eliminating technical debt so they can make more impactful changes in 2.8. Don't asphyxiate, tok
30.
by leif 12y ago
It means we have some auditing and backporting work ahead of us in the next few months.

More ›