leif
Joined 17 years ago
Joined 17 years ago
https://www.cs.berkeley.edu/~brewer/cs262/Aries.pdf
> Remember that merge operations are O(N). Then remember that there are N of them to do. O(N^2) is a horrible algorithmic complexity.
No. Mountains of actual math refute this. LSM-tree merges are O(N log N). This is an Actual Fact.
Read more, kids.
An interesting new development is http://getkudu.io/ which applies some ideas common with Fractal Trees and other write-optimized data structures (like LSM-trees) to column stores.
At Tokutek, we had some designs for how to implement column store-like data models on Fractal Trees (we called them "matrix stores" because they had some of the benefits of both row stores and column stores), but we didn't get around to implementing them.
Where TokuDB gets its speed boost is by delaying the random reads associated with updating the indexing structure (the Fractal Tree). The buffers are written to disk on checkpoint, but because they're buffers, the potentially random writes are localized to a smaller number of nodes high in the tree, which minimizes the number of disk seeks required. Since sequential I/O is cheaper than random, the sequential writes to the write-ahead log are very fast, so even in very strict durability configurations, TokuDB can easily outperform databases which use random writes to update the indexing structures, such as the B-trees used by InnoDB and most other RDBMSes.
More details here: https://www.percona.com/blog/2011/09/22/write-optimization-m...
It may depend on your upbringing. In the modern US, particularly the more puritan regions, any alcohol at all is usually considered a luxury reserved for celebration, but in some parts of the world, wine or beer is just the drink you drink with a meal, and there's less of a stigma about it. If it's not your thing, it's not your thing, but applying the label "excess" is a pretty specifically cultural decision.
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 never said I had any of the answers. All I said was listen to the people that are affected, try to learn about their problems, and be empathetic, and maybe you'll find the answers.
I'm not trying to be revolutionary here, I just think one of the nice features of these types of issues is that the people being affected are actual people that you can listen to and have conversations with, and I think that's a good place to start.
Most likely they'll tell you they have a lot of worse things to deal with than how much eye contact you're giving them, but it'll be a learning experience and at least you'll open up a dialogue.
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 is good, you're about to become a more valuable member of society.
4. Accept that you need to put in some effort. Not much, don't worry. Most of it is shutting up.
5. Read what women write about this problem. They're all experts because they've been studying it literally their entire lives.
6. Learn (from step 5 and some self-reflection) how to recognize in real time when you're being a jerk. Then stop.
Now it gets a little harder. But remember, not nearly as hard as being a woman in tech, so buck up, kid!
7. Learn (from step 5) how to recognize in real time when other people are being jerks, and good techniques for how to advocate on behalf of women. This takes practice and courage, keep at it.
8. You'll be tempted to brag about how helpful you are to women (hi @wadhwa). Resist this temptation. Whenever you feel yourself about to tell someone how great and helpful you are, instead, show them something an actual woman has said about their problems, and try to point them in the right direction.
Note that you can replace "woman/women" in the above with any minority/disenfranchised/disadvantaged group you want to help, and the same formula pretty much works verbatim.
We build and sell high-performance databases TokuDB and TokuMX.
We are hiring:
- Inside Sales Exec
- QA Engineer
- Tech Support Engineer
- Product Manager
- Technical Writers (contract)
We are currently growing our customer base almost too fast with TokuMX, so we are expanding on sales, support, and documentation. For the engineering positions, MongoDB experience is preferred but any database experience is good.
For engineering, email myself ([email protected]) or Tim Callaghan ([email protected]) with a resume and say hi. For sales and marketing, email sales@ or marketing@. Referral bonuses available!
We have run Jepsen and have not been able to get it to show data loss in TokuMX. The problems it found in MongoDB were already fixed in other ways in earlier versions of TokuMX, but we're trying to get Jepsen to demonstrate the other problems we've found.
Model checking may be another way we can prove correctness, but since Ark is so similar to Raft, I think the Raft model in TLA+[1] is probably sufficient. Anyway, we'd also need a proof that the model is equivalent to the implementation, and I don't know of a way to do that, so I think functional tests are more important.
In any case, we'll look in to using a model checker, and any help would be greatly appreciated. If you're interested, feel free to email me.
http://leifwalsh.com