682 karma · joined July 10, 2011
Some basic questions, as I am still struggling to see the use case of this project.
* How did this project get started? What problem is it trying to solve?
* Are there any real world examples of where this project is used?
For every additional change, I look at the module as a whole again, and keep thinking "If we got a new hire, how easy would be for the person to understand this in the bigger picture?"
Understanding is all about mindset. If part of the code starts to do too much, then other developers are likely to make incorrect assumptions of the logic behind that piece of work. The small mistakes slowly compounds over time, and if not taken care of, the whole project becomes un-maintainable.
Any idea of what is going on here?
[1] https://github.com/tannerlinsley/react-table/blob/master/doc...
Meanwhile, for Angular, I keep constantly going back to the documentation, trying to remember all the small details about templating, binding, decorators, modules, dependency injection, etc...
I still find CRDB's replication interesting, since all data is replicated 3-way on every commit, and data also auto-rebalances as needed. With some exceptions, as long as you are connected to any node, you should have access to all data.
I believe immutable trees would be the correct algorithm here.
The algorithm relies on a tree structure, where the leaves are the files. Every time a new snapshot is written, every leaf node changed writes a new path to the root node, while leaving the rest of the tree intact.
When a snapshot needs to be deleted, you just remove all the old root nodes and have a garbage-collection like-process delete all the old files.
EDIT: Look at example here: https://en.wikipedia.org/wiki/Persistent_data_structure#Tree... . When xs is deleted, nodes a,c,f can also be deleted.
EDIT2: I feel like I can never make posts like these while keeping it short and sweet, and adding enough details. ZFS can be encrypted, but accessing any files is right at its fingertips, not over a slow network connection. And there are caveats about how to encrypt the metadata, but you do not need to decrypt the whole backup to figure out what to do delete.
I remember reading a long time ago that Restic was not going to natively support cold storage solutions. Has anything changed?
I love this story, as a complete unrelated kernel commit that reduced the amount of file I/O, caused the kernel to not generate enough entropy at boot, and in consequence, made the system unbootable.
It is not about the database type. It is about the underlying algorithms and data structures.
To give some examples, CockroachDB both has column-families and NoSQL characteristics. A column can be specified to be a JSON column, and it can have an inverted index.
Or MemSQL has both row-based and column-based tables, and they use an unorthodox index called "skip lists".
CockroachDB and MemSQL both have different applications and characteristis, but they are just cluttered under "NewSQL", as if it was just was some kind of "SQL but better".
I wish more time would be spent talking about the underlying algorithms that the different query languages use to accomplish the tasks. It is important for developers to understand the execution complexity of queries, and how data is distributed across a cluster.
For example, I am usually surprised when people talk about "web-scale", but they do not understand the difference between a "merge-join" and a "hash-join". Or when people do not realize that a sort requires the whole result set to be materialized and sorted.
Does anyone know how such a paradigm came to exist? What problem is this solving?
EDIT: As another note, I believe Aurora added multi-master support recently. How does that compare as well?
See:
-CockroachDB (a spinoff of Google's Spanner)
-MySQL's MyRocks (Facebook)
-YugaByte (Postgres compatible sharded SQL)
-Ceph (Opensource alternative to Amazon S3)
I am guessing this is looking into improving the performance even further.I recommend watching. The channel does really good explanations.